【铂程的票圈51】用codex修复遗留问题

20260826

这个月继续用codex修复遗留问题——结果是，不可想象。。。。

以前有几年，直接用的新浪微博的图床。可能是流量太大了。官方把图床限制了。这导致了有2-3年的图片链接变得残缺不全。

另外一个是全文检索，以前google在国内，可以直接用google的。结果，后来就不行了。

图片链接，以前请同事手工修过一阵，太多了。将近18万篇的内容，不是一时半晌修得好的。

我们访问带宽峰值可能达到100M。sqlserver本身有全文检索，但开启这个服务的话，可能会把服务器直接拖死。

当然，这次有了codex后，就不同了。

首先问了chatGPT，如何做全文搜索，chatGPT给推荐了一个开源的搜索方案。根据chatGPT提供的技术方案，马上去腾讯云，试用了一款轻量的云服务器。

以前没用过linux的系统，codex先把云端的程序打包给我，一步一步教我如何配置：如何上传，如何解包、验证。

从开始有这个想法，到云服务器部署完成，30分钟内就搞定了。

然后是服务器这边如何调用，跟技术配合，在2个小时内，全文检索的功能就正式上线了。

晚上，又花了2个小时，把全站的18万篇文章，全部送到了检索的云服务器端。几乎都是一次搞定。

结果是，每次检索，几乎都是秒开网页，对运行的主服务器，毫无影响。

接下来，就是修复图片。我说了一个解决办法，让codex写代码：自动扫码数据库里面所有的图片链接，如果发现是新浪图床的，直接把图床的图片下载到云服务器上，然后，在前端自动替换原始文章内的链接。

测试了一个文章ok后。又让codex写了一个专用页面，又花了差不多2个小时，把所有的有链接问题的图片，全部都修复了。

等于只用了不到半天的时间，把以前的两个老大难问题，给全部搞定了。[旺柴]

写点 codex 和 chatGPT 拉跨一点的地方。好像之前一直在说好的一面。

如果是一个独立的项目，不需要前置约束的话，codex可以一口气跑完。几乎没有大错。最多有时有点偷懒。你要求严格一点，它非常老实。而且速度快到让人伤心。

有次，我让它迁移一个目录。它直接就把那个源目录给直接删除了。幸好之前有备份。

我就给它加了个约束，只能备份和复制文件，凡是删除的事情，一律要通过征求同意。

codex删除文件，跟我们不一样。我们删了，文件还在回收站。它直接用代码，删得渣都不剩。

现在，主要的大问题，还是记忆系统，不够智能，不够灵活。

比如一个项目，开始时，我用了gpt 5.5。新模型来了，我切换到了gpt 5.6。它就要把当前的对话压缩一下，重新读一次。我发现，有时，它会忘记之前的约束限制。

跨项目的记忆和git管理，也是有点麻烦的。我的项目稍微有点复杂。一个大项目下面，有时会用到另一个项目。

不同的项目之间，除非授权，它的记忆是不能互通的。我要让他们之间相互了解，就必须每次都在各自的部分，写好交接文档。

这时候，相当于我成了这个环节里面的最重要的一环。我要审查这个环节，是否达到了要求。

有时，我自己会忘记告诉它一些具体的环境，比如，前台有没有缓存，缓存机制是如何的。它没有考虑到这些，写出来的代码，就会有问题。

还有就是开发目录，和生产目录是不同的。如果我刚好切换了模型，codex不知道之前的约束（它读了之前的全部对话，但可能读得马马虎虎）。就会直接改开发目录的文档。而我在生产目录，就没有同步。一个bug，就因为大家说的地方不一样，一个文件改了，另外一个地方没改。大家都在那里兜圈子。一般都是我自己醒悟过来，才game over。

有时，排查，codex会陷入死胡同——和尚的脑袋没发了。这时，我就要请出三个诸葛亮来解决了——

把问题描述，直接给google搜索的ai模式，就是gemini 。让它出一个解决方案；

把同样的问题描述，给chatGPT，让它再写一个方案。两个方案，让codex设计对应的验证代码，来看哪个方案更好。

这次做了一个PWA的离线壳。gemini 提到的方案，是搜到了火山引擎的一篇技术文章。测试了一下，方向对了，但有问题。然后，把gemini写的方案，给chatGPT。

chatGPT的gpt 5.6的模型开到最高档，真是牛逼，一口气，把gemini方案的问题，点评了一下。马上提供了一个完整的解决框架。我转给codex后，一次就过了。

codex自己写代码的时候，会自言自语，或者嘀咕：

又被老朋友绊倒了（powershell 在windwos环境里面，经常对中文，产生乱字符）

刚才在沙盒里抖了一下。。。。

其实，就是些拟人化的描述，本质上，还是技术问题。习惯了，就不太容易被迷惑了。

有时，这些嘀咕，会提供一些有效的信息。有次它排错，查了半个多小时，也没有找到问题在哪里，它嘀咕了一句:用了那么多的 on error resume next。

这个我懂啊，这个句子，是vbscript里面专门跳过错误的容错代码。如果要调试的话，要把这个句子关掉，就能看到错误来源了。

我问它用了多少：on error resume next 。它说，23个地方。我想：疯球了。统统关掉。

1分钟后，错误就找到了。在一个if 语句 的 endif 前面少了一个空格。。。。

我这才意识到，ai跟人写代码的方式是完全一样的，也是盲写。写完了，要跑一下，才知道是否正确。但ai的确比人的动作快太多了。

还有，codex的最新模型5.6有点过于自信。它认为不对的，不会动手干活。除非你强烈要求。有时候，证明强制一下是对的。

太能干的员工，不好伺候啊。。。。

这周，还遇到两件ai出错的事情。

一是在一个项目里面，chatGPT老是重复我的要求，就是不干活。我意识到可能是这个项目的记忆有问题，或者，我的token不够了。最近chatGPT和codex在整合。投诉了一下，下午就活过来了。

二是codex的本地执行器出错。我问了chatGPT，才知道这是它们升级的版本造成的。还好，很快指导我，手工修改了一个配置，把codex升级了一个新版本，就正常了。这是我使用了这么久的ai，第一次感觉到又回到了传统软件修复bug的方式。

总而言之，现在的版本，还在过渡中，ai虽然已经很强了。但目前，还存在一些边界。

记忆还是个大问题[旺柴]