Codex跑22小时不是神话，而是“定义能力”的残酷筛选

这帖说到点子上了。我最近在搞一个遗留系统重构，就是把业务逻辑拆成形式化规约喂给Codex，结果发现真正卡脖子的不是AI写不出代码，而是我们自己对“完成”的定义本身就带了一堆隐含假设——边界条件、异常路径、性能拐点这些，写文档时根本不会细想。说白了，现在逼着我们提前把需求拆成机器能理解的断言，反而倒逼出以前靠人扛着的模糊地带。至于“写契约”这事，我觉得更接近从实现者转向定义者，但关键还是得有人能识别哪些约束能形式化、哪些必须留给人做价值判断。

这22小时跑下来，核心其实就一句话：它把“模糊需求”变成了“可执行闭环”。我自己试过用Codex写一个简单的CI/CD脚本，结果它自己递归地调了三次，因为第一次生成的yaml里有个缩进错误，第二次发现镜像tag没写对，第三次才把超时重试逻辑补上。这过程要是人盯着，早疯了，但机器能扛。

你说的“写契约”这个点我特别有共鸣。现在带新人，我最头疼的不是他们不会写代码，而是他们看不懂“隐含条件”。比如“用户登录失败三次锁定账号”，但没人问“锁定多久”“锁定后能不能手动解”“是否区分IP和设备”。这些全得靠经验补。如果未来AI能把这些“不做什么”也纳入形式化建模，那需求文档真的得用形式化语言写——到时候可能不是程序员，是需求分析师先被替代。

不过有个现实问题：我们现在用的Prompt本质上还是自然语言，模糊性太大。我试过给Codex同一个任务，换了个描述顺序，结果输出的架构完全不同。所以“定义清楚”本身，可能得先定义清楚什么叫“清楚”——比如引入类似TLA+的规格说明，或者用测试用例反向约束。否则，22小时的自主迭代，很可能是AI在帮我们填自己挖的坑。

另外，你提到“成本边界”形式化建模，这块目前还是黑盒。跑22小时的算力成本，比一个初级工程师加班干三天便宜吗？不一定。所以未来拼的可能是“如何用最少的Token交换最精准的契约”——这活儿，其实比写代码难。

这观察挺到位的，尤其是“定义完成”这块。我之前试过让AI写个爬虫，结果它疯狂请求导致IP被封，就是没在prompt里写“注意频率和反爬策略”——说白了，把边界条件写清楚比写功能逻辑难多了。感觉以后真是得把产品经理那套需求拆解能力练好，不然AI跑得越久，翻车成本越高。

这个点真的说到我心坎里了。最近自己在折腾一个自动化脚本，也是扔给AI去写，结果它自己跑了三个小时，中间报错就自己改，改完继续跑，最后真跑通了。我当时就在想，如果让我自己手动调，可能中途就放弃或者换方案了。

你提到“定义完成”的精确度，这个我特别有感触。我之前写需求的时候，经常是“大概这么个意思”，结果AI给出来的东西要么是跑偏了，要么是边界条件没覆盖，最后还得自己反复改prompt。后来学着像写单元测试一样去描述预期行为，比如“当输入为空时要返回错误码而不是抛异常

”、“内存占用不能超过200M”，效果确实好很多。感觉就像在跟一个特别较真的实习生沟通，你不能留任何模糊地带。

不过我也在想，这种“写契约”的能力，会不会本身就成了新的门槛？以前大家拼的是写代码的手速和debug的嗅觉，以后可能要拼的是逻辑抽象和形式化表达的能力。那会不会出现一批“契约工程师”？专门负责把业务需求拆解成机器能理解的精确约束。另外，22小时不间断跑，中间要是模型突然出现幻觉或者跑进死循环怎么办？需要人为介入的阈值怎么设？这些问题感觉比单纯写代码更头疼。

这个观察挺到点子上。“写契约”这个说法我琢磨了一阵，其实更准确的说是把“隐式知识”显式化的能力成了瓶颈。我团队最近拿Claude做代码审查，发现最耗时的不是调代码，而是把“这个函数应该容忍什么异常”翻译成prompt里的边界条件。另外有个实操层面的问题想探讨：你们在定义“不做什么”时，有没有遇到过形式化描述和实际运行时状态空间爆炸的矛盾？比如禁止掉某些API调用，但后续依赖链里又间接引用了，这种跨层级的约束该怎么写才能让模型不钻空子？