AI牛马驱使手记

一、AI牛马让我体会到了当老板的感觉

作为一名上班族牛马，我每天开车上班的20分钟，中午食堂吃饭的20分钟，以及下班的20分钟，是一天之中可以不用面对电脑的闲暇时光。我要么在车上听听音乐或播客，要么在吃饭的时候刷刷手机阅览天下大事，并不觉得是在浪费时间。

但现在我不这么淡泊了——除非 codex 正在工作。20分钟已经足够让 codex 完成一次中等难度以下的代码任务，当我再次回到电脑前面时，我需要及时 review 它的成果，并提出下一轮的迭代要求。

如果在步入地库的时候竟然忘记了给 codex 布置任务，我会在开车的路上情不自禁地加速。

粗略地估算一下， codex 的工作效率大概是一名全职程序员的 20-30 倍。那么，浪费 20 分钟，差不多相当于耽误了他一天的工作，这怎么可以？

二、我最近在干啥？

这一个多月，我用 codex 干了两件“大事”。

一是 Teamrun 传统网站重构，将使用了十几年的 ASP+Access 网站，完全重写成了 PHP+SQLite 。这项工作原本在数年前就想推进，结果发现大大低估了重构网站的工作量。当时雇佣了两个南大的学生，花了几千大洋，用了几周时间，结果根本捣鼓不出来，只好悻悻放弃。谁让当时还没有 AI 呢？

但即便有了 AI ，我也迟迟没有动手，因为我始终没有想清楚新网站的前端布局究竟应该长什么样儿。这主要是我的原因，毕竟只是一个门外汉，对于诡谲曲折的前端技术知之甚少，别说了解哪些技术栈了，连前端想要的效果都未必能准确地想象出来，更别说用语言描述出来。当然，另一个重要原因是对 AI 的能力边界始终心存怀疑，直到 codex 出现，直到用 codex 小试牛刀做了几个新网站之后，我有信心它可以了。

最终，80 多个 ASP 文件重构成 PHP，代码量一共 3 万多行，前前后后用了两周时间就顺利上线了。ChatGPT 告诉我，这样的工作量，让一个专业程序员全职来干，最少需要 5 个月，这还不包括需求沟通的时间。

第二件事，是基于 Karpathy 的 LLM wiki 框架下搭建的知识库。准确来说，知识库并不是重点，只用了 2 天时间，我就完成了从框架搭建到 3 层检索的升级。但任何知识库都面临一个文档清洗的难题。在我的设想中，Markdown 是对 LLM 最为友好的格式，那么提供给 LLM 的，应该是清一色 MD 后缀文件。但很明显我们日常使用的文件里，docx 和 pdf 是最多的。其中最难解决的，当然是扫描版 PDF。

从第 3 天开始，就和扫描版 PDF 卯上了。 ollama 是有一个配套的 ollama-ocr 库的，如果是纯文本 PDF 的扫描件，实际上只需要几十行代码就足够了。但我们的规范、项目说明，全部是图表混排，必须解决复杂排版下的图表识别，才能称得上有起码的实用性。

这项工作的挑战远远超过了我的想象。Python 已经写了超过 5 万行了，仍然没有达到我要求的理想效果。但它又确实在不断接近目标，让我感觉成功是有希望的。

想想难才是正常的，否则腾讯云、百度云上的同类服务，就不会收 30元/200 页的天价了。

就在我写这篇文章的时候， codex 还在没日没夜地工作着，昨天晚上我要求它“干不完就别睡觉了”，这句 Prompt 威力很强，它一夜没睡，连续干了 6 个半小时。今天我检查作业，发现还有一堆问题，批评它“为什么搞成这样就交作业，有没有仔细检查”？结果它一定是入心入脑入魂了，又埋头苦干了 9 个多小时。现在它会自己组织 ExecPlan 文件，我不太担心它浅尝辄止。但 codex 的快要见底的额度开始让我忧虑起来，一周的额度还剩下 6%，而重置期还有 2 天，这可如何是好，这可如何是好。

codex 服务坏一下就好了——这是 codex 重度用户的奇特期待，因为 Tibo 每次修好它之后都会重置额度。

好，概况交待完毕，算是给部分关心我的近况的朋友一个交代。下面谈谈感悟。

三、“回答机”与“问题机”的拉扯

前面我提到，在重构 Teamrun 的时候，其实我自己起初的想法是模糊的。在第一个 Prompt 中，我只是要求 codex 重写成 PHP，同时按“响应式布局”来设计页面。但对于响应式布局在我的传统页面上具体应该“长”什么样子，我是不清晰的，甚至对于什么是“响应式布局”，我也并没有深入的理解，只简单认为是“能自适应屏幕宽度”。

事实上，codex 交出的第一稿作业是非常糟糕的，但它至少让这些 PHP 文件能够被顺利执行了。看着它残缺不全的作业，我开始思如泉涌，Typeless 一开，Prompt 如潮水般向 codex 涌去。在这个拉扯的过程中，我对于网站究竟应该长什么样的想法逐渐成型，对于什么是响应式布局的分组，什么是宽度上限、宽度下限有了进一步的认识。在与 codex 交流过程中，它那些“虽黑但准”的互联网行话也在不断调教着我的 Prompt 表达。

除了前端之外，网站的功能逻辑也在这个过程中从久远的过去逐渐加载到我的大脑内存，一些以前曾经考虑过，但因为怕麻烦没有去实现的想法，重新占满了我的脑海。于是，网站的重构不再仅限于 UI，进一步延伸到 UX，乃至基础功能和业务逻辑。

我突然想到，如果 AI 是一名普通员工，想必会背地里猛烈吐槽：这位老板（也就是我）为什么不把需求一次性说清楚、说明白、说完整？反反复复，每天，oh 不，每小时都有新的想法，太折腾人，oh 不，折腾 AI 了！

我悟到了：不仅仅是问题的解答者——员工、乙方或 AI ——需要需求或 Prompt 的输入，问题的提出者——老板、甲方或“我”——也同样需要答案的输入以产生新的问题。

是否能预见到老板或甲方的下一步问题并提前做好准备，是一位优秀员工或乙方的评判标准之一。类似地，这也是衡量 AI 智能水平的评判标准之一。这并不能消灭迭代，但可能会减少迭代的次数。

四、“小本本”是长任务的基石

在之前的 blog 中我曾经介绍过 ExecPlan。通常对于有一点点复杂但又不那么复杂的任务，ExecPlan 的推荐模板已经足够好用了。但我这次扫描版的 PDF，最长的任务会在一次对话中用尽 5 次上下文窗口（我使用的是 GPT-5.5 xhigh），这时候，一个强烈可遵循的 ExecPlan 是必须的，且它的内容需要进一步明确。

以我这一次的项目为例，我会要求它将 OCR 的结果与一个标准成果的备份库作比对，比对包含每一张表和图，并将差异逐条记录到 ExecPlan ；在修改任何函数时，都要根据上一轮 OCR 的 Trace 结果调查该函数的覆盖面，并对这些潜在的受影响覆盖面做额外验证，并再次与备份库做比对。同时，我也给出了每页的 OCR 时间上限，给出明确的性能优化目标。

这样一来，在每一轮“大梦初醒”（压缩上下文）后，codex 通常可以从 ExecPlan 中找到清晰的工作方式、足够的线索、明确的验收标准继续工作。

五、AI 被逼出来的投机取巧

为了避免 codex 松松垮垮地交作业，我的要求是很严格的，并不容易达成。有时候， codex 会在绝境下想出意料之外的好点子，比如把串行子进程改为并行，一下子把 OCR 的效率提升了 4 倍。但也有时候，它在无奈之下会作出猥琐的选择。

OCR 对图像中的表格识别是一大挑战。如果完全只用通用逻辑，那么程序必须从图像的线与线之间的关系、vision 模型提供的未必正确的表格结构着手，处理海量的判断逻辑和边界条件，还需要不断调整一些裁切阈值。本质上看，准确性和性能就像鱼与熊掌，不可能一下子都做到满分。程序的目标是找出质量判断的方法，并将需要重建的表格送到适当的分支链路中去，但又要尽量不让原本已经正确的表格被错误地送进这些分支链路，因为那反而会导致用错误的结果覆盖了正确的。

这个过程有点像是一个巨大的迷宫，需要反复地修改代码、测试跑 OCR、对照结果、再次修改代码。

在这个迭代过程中，我担心出现“特判”。所谓特判就是，直接在程序中放行一些文案，比如表头是“凸曲线”时直接判定为正确；或者直接在程序中硬编码某张表“表3.5.1你直接这样写”。这种程序完全不具备通用性，它只会在当前测试对象上表现良好。

我很早就交待 codex ，不要“特判”。我这个程序将来要处理几千个 PDF，你必须给我上通用逻辑。但当迭代次数增加，它在既定的框架内始终不能同时满足性能要求和质量要求时，它的某个决策权重就开始悄悄偏移了——它开始搞特判。

我一开始都没有发现，它为了我的两个测试 PDF ，一共写了大几千行的特判代码，害得我一度看着完美的测试结果得意洋洋“我完成了一个里程碑”。直到在第三个测试文档调试时，codex 又故技重施，这次恰好被我看见，我才发现它竟然干了这么多投机取巧的事情！

所以，“监工”还是要监的。

六、人类的不可或缺性来自于人类本身的局限性

网上经常有人晒出牛逼经验：用一个代理程序或 Openclaw 来控制 codex 或 claude code，只要运行一中止，就发指令“请继续”，实现完全的“无监管 vibe coding”。反正 AI 编的那些代码你也不会看，AI 反馈的这些过程你也不关心，你只关心结果对吗？

非也。除了前面我说的防止 AI 投机取巧外，还有一个很重要的原因，让现在的 vibe coding 还是离不开人类。这并非是由于 AI 的能力缺陷，相反，这种不可或缺恰恰来自人类自身的思维局限。

我们回到上文第一条。你的需求绝非固定不变的，而是在与 AI 迭代的过程中不断演变的。很多金点子，是在“结对编程”中灵光一现冒出来的。很多死胡同，是在“监工”的枯燥过程中恍然大悟到的。

举例说明，起初每次 codex 交作业后，我都会手动 review OCR 的成果与原始文档，并逐个列出错误的表格与插图，然后发给 codex 迭代。这样干了 10 天之后，实在是疲惫不堪。我突然想到，通用逻辑对于这些各种各样的表格与图片来说，常常是“按下葫芦浮起瓢”，所以，我需要一个可以跟踪函数影响面的 Trace 机制。

但注意，因为你起初没有要求 codex 去设计这样一个机制，它不会主动去做的，因为这是架构层面、或者说是原始约定层面的事情。这就好比，老板要求保洁打扫楼道，保洁并不会主动去采购一台戴森来干活——这台戴森得老板买过来交到保洁的手上：“你以后用这个，效率高。”

更别提在前端领域，如果你不亲自上手测试，你压根提不出像样的需求，也根本发现不了那些隐藏的 bug。

所以，之所以目前还不应要求 AI 全自动完成工作，恰恰来自于人类不可避免的无知。你在没有真正“参与”一个项目的时候，是不可能一次性提出最终的需求（因为你自己并不知道你的最终需求）和完美的 Prompt （因为你很可能要求 AI 使用错误的方法来完成目标）。

这恰恰印证了“知行合一”的真谛。