当代码不再由你来写：工程师角色的一次硬着陆

读 OpenAI《Harness engineering》后的一些想法，以及几句不太客气的话。

一个让人不太舒服的事实

OpenAI 公布了一个实验：三名工程师，五个月，从一个空仓库开始，构建并发布了一款约一百万行代码的生产 beta 产品。期间没有一行代码是人手写的——应用逻辑、测试、CI 配置、文档、可观测性工具，全部由 Codex 智能体生成。三个人合计提交了约 1500 个被合并的 PR，平均每人每天 3.5 个。后来团队扩到七人，吞吐量不降反升。

我知道你看到这种数字的第一反应。我也是：又一篇大厂的营销稿，million lines of code 这种说法本身就经不起推敲，行数从来不是好指标。这些都对。

但如果你因此把它当成纯粹的 PR 稿划走，我觉得是看走眼了。这篇报告真正有价值的地方不是输出数字，而是它无意中给"软件工程师"这个职业做了一次相当残酷的定义重写。它在说一件很多人不愿意明说的事：写代码这件事，正在从工程师的核心技能里被剥离出去。

"人类掌舵，智能体执行"

报告里反复出现的一句话是 "Humans steer. Agents execute."——人类掌舵，智能体执行。

听起来像句正确的废话。但他们把它执行到了一个极端：团队定下规矩，任何工程师都不许直接动手写代码。当某件事失败时，标准反应永远不是"我来手动修一下"，而是一个固定的追问——

"缺了什么能力？怎么让这个能力对智能体既可见、又可强制执行？"

这个约束是故意的。报告坦承早期进展比预期慢，但慢的原因不是 Codex 不行，而是环境定义得不够充分——智能体缺少实现目标所需的工具、抽象和内部结构。换句话说，瓶颈从来不在模型，而在工程师有没有把环境搭好。

我喜欢这个约束，因为它逼出了一个诚实的结论：只要你还能"我来手写修一下"，你就永远不会去认真建设那个让智能体可靠工作的环境。 退路本身就是建设的敌人。这跟戒掉任何坏习惯是一个道理——留着后门，你就总会走后门。

工程师到底在干什么

那么不写代码，这三个人五个月都在干嘛？报告和几篇拆解给出的答案，大致可以归到四件事上，而这四件事恰好就是"工程师角色转变"的全部内容。

第一，把意图变成可执行的规格。 工程师的产出从"代码"上移到了"验收标准"。你不再实现一个功能，你定义这个功能"做对了"长什么样，然后让智能体去逼近它。他们把这个流程做成了 research → spec → 任务清单 → 实现 的流水线，每一步都产出版本化的 markdown 工件。

第二，机械地强制架构，而不是写在文档里劝说。 这是整篇报告里我最认同的一点。他们给应用定了一套严格的分层依赖（Types → Config → Repo → Service → Runtime → UI，只能向前依赖），但关键词是 enforced，不是 documented。约束通过三样东西落地：Codex 自己生成的自定义 linter、验证依赖方向的结构化测试、会拦住违规 PR 的 CI。

为什么必须机械强制？因为智能体会忠实复制仓库里已有的模式——包括烂模式。文档对智能体几乎没有约束力，它不会"读了规范就自觉遵守"，它只会模仿它看到的代码。没有机械强制，一个坏模式会指数级地复制下去。这件事人类团队通常拖到几百号工程师规模才会做，但在智能体面前它是 day-one 的前提。

第三，把仓库变成唯一的真相来源。 他们提出一条听起来废话、但含义很深的原则：

从智能体的视角看，任何它在运行时无法访问到的东西，等于不存在。

那条你们在 Slack 里对齐架构的讨论串？不在仓库里，智能体就不知道。那份在 Google Doc 里的产品规格？不可见。于是设计决策、执行计划、产品规格、技术债，全部被塞进仓库变成版本化的文件。你脑子里的、聊天记录里的、口头共识里的知识，对智能体一文不值。

第四，建反馈回路，替代人工 QA。 当写代码不再是瓶颈，验证就成了新瓶颈。他们把 Chrome DevTools Protocol 接进智能体运行时，让 Codex 能自己截 DOM、抓截图、查日志和指标，然后 fix → restart → revalidate 循环到干净为止（也就是所谓 Ralph Wiggum Loop）。报告说他们经常看到单次 Codex 运行在一个任务上连续干六个小时，常常是趁工程师睡觉的时候。

这个回路能成立，是因为它把主观的"这看起来对吗"换成了机械的"这通过了吗"。智能体不需要品味，它需要的是测试信号。

这意味着什么——以及它没说出口的代价

如果把上面四点抽象一下，工程师的角色转变可以一句话概括：

纪律的载体，从代码本身，转移到了代码周围的脚手架。

过去，你的工程素养体现在代码里——干净的抽象、好的测试、一致的风格。现在，你的工程素养体现在脚手架里——工具链、文档结构、反馈回路、架构约束。代码长什么样不再那么重要，只要它正确、可维护、对未来的智能体可读，就达标了。报告里有句话挺到位：人的品味只被捕捉一次，然后在每一行代码上被持续强制执行。

我认同这个方向，但我想说几句报告没怎么说的话。

第一，这是一种角色的窄化，别假装它只是升级。 "你不再写代码，你设计让代码被写出来的系统"——这话说得很体面，但它同时意味着，一大批以"能把活干漂亮"为立身之本的工程师，护城河被填了。把意图翻译成规格、把品味编码成 lint 规则，这是另一套技能，不是写代码的自然延伸。会写一手好代码，不等于会设计约束系统。这中间的转换成本，报告轻描淡写地略过了。

第二，这套打法的前提条件，比报告承认的要苛刻。 三个（后来七个）OpenAI 的工程师、近乎无限的算力预算、一个全新的绿地项目、没有历史包袱。请把这几个条件里任何一个换成你的真实处境——一个十年的遗留单体、一个对 token 成本敏感的团队、一群水平参差的人——再看看"零手写代码"还成不成立。报告给的是一个理想气体模型，不是你车库里那台漏油的发动机。

第三，"机械强制一切"有它的暗面。 当架构、品味、技术债清理全都变成自动跑的后台任务和 CI 拦截，系统会变得极其一致，也会变得极其难以质疑。一条编码进 linter 的"黄金原则"，没人会再去 review 它对不对，它只是默默地在每个 PR 上执行。一致性的代价，往往是某种集体性的不再思考。这不是说不该做，而是说，谁来定这些规则、多久重新审视一次，本身就该是个一等公民的问题。

那么，今晚就能做的一件事

如果你被说动了，但又不想被宏大叙事忽悠着推倒重来，最小可行的起点其实很小：

下次智能体把某件事做错了，你修好它之后，多问自己一句——"我能不能把这个修复变成一条 lint 规则，或者一条写进 AGENTS.md / CLAUDE.md 的原则，让它永远不再发生？"

如果能，你就完成了一次微型的角色转变：你没有修一个 bug，你修了"会产生这个 bug 的环境"。这件事重复一千次，就是这篇报告的全部。

至于要不要一路走到"零手写代码"那个极端——我倾向于认为，那更多是 OpenAI 的处境决定的，而不是软件工程的终点。但"工程师的价值正在从写代码上移到造环境"这个趋势，我不觉得有回头路。

值得高兴的是，这些模式是可学的、可增量的、今天就能用的。值得警惕的是，越早把它当回事的人，护城河挖得越深——这次站在沟另一边的，可能就是我们自己。

---

参考：OpenAI《Harness engineering: leveraging Codex in an agent-first world》，以及社区的若干篇拆解。文中数据与机制描述来自这些公开报告，观点与吐槽是我自己的。