我让 Codex 修一个视频号下载器，结果把小问题修成了大事故

微信视频号有个老问题：看完想保存，没有下载按钮。

不是藏得深，是真没有。

微信视频号没法保存？这个开源工具能在PC微信加下载按钮

所以我看到亦仁收藏夹里有人推荐一个开源工具时，确实心动了。

它的功能听起来很简单：给 PC 微信的视频号播放器加一个下载按钮。打开微信，看视频，点下载。

我一开始也确实跑通过，开始是电脑的媒体播放器播放不了，我还发给自己微信，能打开，只是需要在电脑换成VLC。

后来短视频能下载，VLC 也能播放。那一刻我以为：稳了，终于可以把视频号素材保存下来，后面交给 AI 做对标拆解了。

但后来，我测试一个更长的视频时，问题开始出现。

文件下载不完整，有时候能下但打不开，有时候 VLC 能播，系统播放器不能播，有时候下载失败，有时候工具又突然断掉。

于是我让 Codex 继续修。

结果真正的坑来了。

第一个坑：一开始成功，反而让我放松了警惕

这篇不是说这个开源工具完全不能用。

相反，它一开始确实成功过。

短视频下载成功，VLC 播放成功，说明它在某些环境、某些视频、某些情况下是能跑通的。

真正让我崩溃的，不是“它完全不能用”。

而是：它一开始成功了，所以我放松了警惕。

我以为既然短视频能下，那长视频应该只是小问题。

我以为既然 VLC 能播，那文件应该没什么大毛病。

我以为既然按钮出来了，那工具就算安装成功了。

后来才发现，这种工具不是“能用一次”就等于彻底跑通。

短视频能下载，只能证明短视频那一层暂时没问题。

不能证明长视频没问题。

不能证明合并没问题。

不能证明播放器兼容没问题。

更不能证明后续让 AI 修复时不会引爆其它问题。

第二个坑：长视频一出错，Codex 开始越修越偏

真正的灾难，是从长视频出错开始的。

本来长视频失败，应该只排查几件事：

视频链接是不是过期；

分片有没有下载完整；

合并有没有成功；

文件编码是不是兼容播放器；

播放器能不能识别时长。

这本来是“下载层”的问题。

但我当时只是让 Codex 继续修。

它就开始自由发挥。

一会儿改代理。

一会儿改启动脚本。

一会儿改配置。

一会儿改日志识别。

一会儿重启后台服务。

一会儿检查系统代理。

一会儿又折腾证书和 TUN。

结果原本只是“长视频下载失败”，最后变成了：AI 工具断线、Codex Reconnecting、本地代理混乱、下载器残留进程、证书清理、系统网络排障。

我后来复盘才发现，最危险的不是报错。

最危险的是：你没有把 AI 限制在正确的问题层级里。

第三个坑：我以为是下载器，其实是本地代理系统

普通用户很容易误会这类工具。

你以为它是：打开工具，点击下载，保存视频。

但它实际上更接近：让微信视频号流量经过本地代理，工具识别视频请求，注入下载按钮，抓取真实地址，再下载保存。

也就是说，它不是一个单纯的“下载按钮”。

它会涉及本地代理、系统代理、证书、端口监听、WebView 注入、流量抓取、视频解密、文件合并。

如果你的电脑网络环境很干净，可能体验会很好。

但如果你的电脑本来就有代理工具、VPN、加速器、开发环境、AI 编程工具，那它就可能和原来的网络链路打架。

这也是我后来才明白的地方：

我不是在装一个普通下载器。

我是在主力电脑上装了一个会接管网络流量的本地代理系统。

第四个坑：原来的联网工具和下载器开始抢控制权

我电脑上原本就有一个负责联网的工具。

而这个视频号下载器，为了抓微信视频号流量，也想让流量先经过自己。

问题来了：

原来的联网工具要管网络。

下载器也要管网络。

两个工具都想当“网络总开关”。

结果就是，系统代理被来回改。

表现出来就是：

ChatGPT 断线；Codex 一直 Reconnecting；浏览器网络忽好忽坏；下载器有时能打开，有时打不开；页面能开，但视频抓不到；改来改去，越来越乱。

最崩溃的是，一开始我根本不知道问题出在哪。

我以为是 Codex 卡了。

我以为是下载器坏了。

我以为是微信版本不兼容。

我以为是网络抽风。

最后才发现，真正冲突的是：两个工具在抢同一个网络入口。

第五个坑：页面亮着，不代表顾客进门了

后来我们把下载器启动起来了。

本地页面能打开。

端口也在监听。

系统代理也没有再被污染。

看起来好像一切正常。

但我播放一个新的短视频后，日志没有任何新增。

这说明什么？

说明微信视频号的流量根本没有进入下载器。

也就是说，工具只是“活着”，但它没有真的抓到视频。

这就像你开了一家店，灯亮着，门也开着，但顾客根本没进门。

所以页面能打开，不代表能下载。

端口在监听，不代表抓取成功。

服务启动成功，不代表微信流量真的经过它。

这类工具最关键的不是“页面能不能打开”，而是“视频播放后有没有新增抓取记录”。

第六个坑：日志里有链接，但那可能是“过去的成功”

日志也很容易骗人。

我们一开始看日志，里面确实有视频链接、视频 ID、下载记录。

如果不仔细看，很容易以为：工具不是能抓到吗？

但后来我们严格对比：

播放前日志大小是多少；

播放后日志大小有没有增加；

新增部分有没有视频链接；

新增部分有没有视频 ID。

结果发现，当前播放的视频并没有新增任何记录。

也就是说，之前看到的是历史记录，不是本次测试结果。

这个坑非常关键。

不要用历史日志证明当前功能正常。

尤其是让 AI 排障时，一定要提醒它：

只看本次新增日志。

不要把历史记录当成当前测试结果。

不要因为以前成功过，就判断现在也成功。

第七个坑：VLC 能播，不等于文件真的健康

一开始短视频下载成功后，我用 VLC 能播放。

这让我误以为文件没问题。

但后来长视频就开始出各种情况：

有文件但打不开；

VLC 能播但系统播放器不能播；

文件像是下完了，但可能不完整；

有时候只是片段或合并失败。

后来才明白，VLC 的容错能力很强。

有些半坏的文件，它也能勉强播放。

所以“VLC 能播”不能作为唯一成功标准。

更稳的判断应该是：

文件大小是否合理；

扩展名是否正确；

能不能识别视频时长；

VLC 能不能播；

系统自带播放器能不能播。

这几个都过了，才算比较可靠。

第八个坑：AI 最吓人的不是不会干活，而是太能干

这次我对 Codex 最大的感受是：

它不是不能干活。

相反，它太能干了。

你让它修，它真的会修。

它会查日志、改配置、改脚本、改源码、重启进程、分析端口、清理证书。

问题是，如果你没有给它非常明确的边界，它会把所有层混在一起修。

本来是下载失败，它可能去动系统代理。

本来是文件不完整，它可能去改启动脚本。

本来是日志误判，它可能去重启服务。

本来是播放器兼容问题，它可能去改抓取逻辑。

最后你会发现，不是问题被解决了，而是问题被放大了。

AI 编程工具最危险的时候，不是它不会修。

而是它什么都敢修。

第九个坑：你一句“继续修”，它可能把整台电脑都纳入修复范围

我现在最想提醒普通用户的一句话是：

不要对 Codex 说“继续修一下”，这句话太危险了。

因为“继续修”没有边界。

它不知道你只想修下载。

它可能去修代理。

它不知道你只想查日志。

它可能去改脚本。

它不知道你不想动系统设置。

它可能去改系统代理。

更安全的说法应该是：

只读检查，不许修改。

只查日志，不许启动。

只改一个文件，不许动其它。

只验证代理，不许下载。

只测试页面，不许修代码。

断线后先查状态，不许继续处理。

AI 编程工具需要被管住。

尤其是涉及系统代理、证书、TUN、后台进程、管理员权限的项目。

第十个坑：系统代理被动了，AI 工具也会跟着断线

这次最关键的问题，是系统代理被改。

系统代理不是一个小设置。

它可能影响浏览器、微信、开发工具、AI 工具，甚至整台电脑的联网。

我一开始只是想下载一个视频。

结果下载器为了抓视频号流量，去接管系统代理。

而我的 AI 工具又依赖原来的网络链路。

系统代理一被改，Codex 和 ChatGPT 就开始不稳定。

这就是为什么后来会出现 Reconnecting、一直思考、断线、页面卡住。

所以以后只要一个工具会修改系统代理，就必须提高警惕。

它动的不是某个软件的小按钮。

它动的是整台电脑的网络入口。

第十一个坑：TUN 看起来高级，但不是普通用户的安全开关

后来我还试过 TUN。

它听起来好像更安全，因为它不直接改系统代理。

但 TUN 会涉及虚拟网卡和路由表。

这其实比普通代理更底层。

如果电脑上本来就有代理工具、VPN、加速器，多个工具一起碰路由，就很容易冲突。

我这次临时开 TUN 测试，系统代理没有被污染，这是好事。

但播放视频后日志仍然没有新增，说明它也没有成功把微信视频号流量导入下载器。

所以 TUN 不是“打开就解决”的按钮。

它也是一个高风险网络实验。

对普通用户来说，不建议随便开，更不建议在主力电脑上长期用。

第十二个坑：删了文件夹，不代表卸载干净

最后我决定放弃这个下载器。

但卸载过程也给我上了一课。

这类工具可能会留下：

项目目录；

日志文件；

数据库；

缓存；

下载残留；

后台进程；

监听端口；

根证书。

所以卸载不能只是把文件夹删掉。

根证书残留，比日志和缓存更值得警惕。

日志和缓存删不干净，最多占点空间。

但根证书不一样。

抓包类工具可能会安装本地根证书，用来解析 HTTPS 流量。

项目目录删掉后，证书可能还留在系统里。

这就是为什么我最后还单独检查并删除了它留下的证书。

正确的清理顺序应该是：

先确认进程不在；

再确认端口不监听；

再删除项目目录；

再检查系统代理有没有被改；

再单独检查根证书；

最后只删除确认属于这个工具的证书。

真正卸载干净，不是“文件夹没了”。

而是进程、端口、证书、代理状态都恢复正常。

证书不能乱删。

看不懂的证书不要动。

不确定来源的证书不要动。

只能删除确认属于这个工具的那一个。

否则你可能把其它软件、浏览器或系统 HTTPS 信任链搞坏。

最后两句话

1.最大的反思是：内容创作者别把自己拖成网络排障员

我的目标本来不是研究下载器。

我的目标是做内容、拆对标、保存素材、提高产能。

结果一个视频号下载器，把我拖进了代理、证书、端口、TUN、日志、源码、进程、卸载清理里。

这已经偏离了我的主线。

如果你也是内容创作者，我真建议你先想清楚：

你要的是素材效率，还是要自己变成网络排障员？

如果只是为了保存素材，未必一定要在主力电脑上折腾这种抓包类工具。

可以用更轻量的方式。

可以用备用电脑。

可以用虚拟机。

也可以先手动保存、录屏、拆脚本。

不要为了一个工具，把自己的主力工作环境搞崩。

2.最大的教训是：别让AI无边界修复

AI 能帮你写代码，能帮你排障，但它不一定知道你的电脑网络环境有多脆弱。

工具是为人服务的。

一旦工具开始反过来折腾你，就该及时停手。

凡是会接管网络的工具，都不能让 AI 随便安装、随便修、随便改。

遇事不决，问ChatGPT，截图给他，让他给你排查给你提示词。