想象一下这个场景：你的团队交付了一个产品，代码仓库里有大约一百万行代码，一千五百个 Pull Request，有日常用户在使用，有 alpha 测试者在反馈。一切看起来很正常，对吧？

但有一个细节：这百万行代码里，没有哪怕一行是人类工程师亲手写的。

这不是科幻设定。这是 OpenAI 一个内部团队过去五个月的真实经历。他们用 Codex 从零搭建了一个完整的产品，所有代码，包括应用逻辑、测试、CI 配置、文档、可观测性工具、内部脚本，全部由 AI Agent 生成。人类工程师从未直接提交过任何一行代码。

Ryan Lopopolo 在 OpenAI 官方博客上详细记录了这次实验。这篇文章不是 PR 通稿，而是一份诚实的工程复盘：什么碎了、什么加倍了、人的时间应该花在哪里。我觉得这是近期关于 AI 编程最值得一读的实战报告。

起点：一个空的 Git 仓库#

故事开始于 2025 年 8 月底。团队往一个空仓库里做了第一次提交，内容是 Codex CLI 用 GPT-5 生成的初始脚手架：仓库结构、CI 配置、格式化规则、包管理器设置、应用框架。连第一篇 AGENTS.md 文件都是 Agent 自己写的。

没有人类写的「锚定代码」。这意味着整个仓库从一开始就是 Agent 的领地，不存在一个「先由人搭好骨架再由 AI 填充」的阶段。

五个月后，仓库膨胀到百万行级别，贡献了约 1500 个 PR。团队从最初几个人扩展到七名工程师。产品有数百内部用户在使用。

这里有一个反直觉的发现：早期进展比预期慢。不是因为 Codex 不行，而是因为环境不够「具象」。Agent 缺少工具、抽象层和内部结构来支撑它朝高层目标前进。

换句话说，Codex 不是缺算力，而是缺 context。

第一条教训：给 Agent 一张地图，别给一千页说明书#

团队最初试过一个朴素的策略：把所有规则写进一个巨大的 AGENTS.md。结果呢？惨败。

问题有三个层面。第一，巨大的指令文件会挤占任务的上下文空间，Agent 要么漏掉关键约束，要么开始优化错误的优先级。第二，当所有东西都被标记为「重要」时，就没什么是重要的了，Agent 变成了局部模式匹配而非全局导航。第三，单体文档变成过时规则的坟场，Agent 分不清哪些还适用，人类也懒得维护。

他们的解决方案是把知识库结构化为一个分层的目录系统。核心的 AGENTS.md 只有大约 100 行，起的是 「地图」 的作用，而非「百科全书」。它告诉 Agent 去哪里找设计文档、架构决策记录、质量评分、领域边界说明。

然后他们用机械化的手段来保证这些文档不过时：专门的 linter、CI 校验、以及一个定期运行的「文档园艺」Agent，专门扫描和清理过时内容。

这个思路很深刻。传统的软件开发知识管理（Confluence、Google Docs、Slack 聊天记录）对 Agent 来说等于不存在，因为 Agent 无法在运行时访问这些信息。所以任何想让 Agent 遵守的知识，必须存在于仓库中。这迫使团队把越来越多的上下文「下沉」到版本控制里：架构决策、设计讨论、甚至是 Slack 上的一次重要对齐，都要写成仓库里的文档。

第二条教训：边界比实现细节更重要#

当代码完全由 Agent 生成时，架构约束变成了生存问题。

团队构建了一个严格的层状架构模型。每个业务域被划分为固定的层级（Types → Config → Repo → Service → Runtime → UI），依赖方向被严格控制，不允许跨层调用。这些约束不是靠「代码审查时发现再改」，而是通过自定义 linter 和结构测试在 CI 中机械化执行。

在传统开发中，这种程度的架构约束往往被认为「过于死板」。但在 Agent 驱动的代码库中，它从枷锁变成了放大器：规则一旦编码进系统，就会同时作用于所有地方。

他们还引入了一组「品味不变量」：结构化日志、命名规范、文件大小上限、平台特性的安全使用。这些规则在人类团队中可能显得学究气，但对 Agent 来说，它们是防止代码在高速迭代中迅速腐化的最后防线。

团队也清醒地划定了「管什么」和「不管什么」的边界。架构边界、接口正确性、API 契约必须严格管；但模块内部的实现风格可以灵活。结果就是，代码不总是符合人类审美偏好，但只要正确、可维护、能被未来的 Agent 运行理解，就算合格。

第三条教训：当吞吐量暴涨时，工程规范必须重写#

传统工程实践中，合并前需要严格的 CI 通过、代码审查、测试覆盖率检查。这些在低吞吐量环境下是负责任的。但在 Agent 吞吐量远超人类注意力带宽的环境下，它们变成了瓶颈。

团队的应对策略是务实的：最小化阻塞合并门禁。PR 生命周期极短。测试用例偶尔 flake？用后续重跑解决，而不是阻塞进度。这个策略在低吞吐环境是不负责任的，但在这里是正确的权衡。

他们还推动了一个关键转变：把代码审查从「人类必须做」变为「Agent 之间互相审查」。人类审查变成了可选步骤。Codex 会自己拉取审查意见、回复评论、推送更新，甚至自己 squash 和 merge PR。

最近，这个仓库跨过了一个有意义的门槛：给定一个 prompt，Agent 可以端到端驱动一个完整功能。 具体来说：

  • 验证代码库当前状态
  • 录一段视频展示失败场景
  • 实施修复
  • 驱动应用验证修复
  • 录第二段视频展示问题已解决
  • 响应 Agent 和人类的反馈
  • 检测并修复构建失败
  • 只有在需要判断力时才升级给人类

这条链路能否泛化到其他仓库？作者很诚实地表示：不能。这套能力严重依赖这个仓库特定的结构和工具投资，至少在目前阶段不能假设其他项目也能直接复制。

第四条教训：代码腐化不会消失，需要设计「垃圾回收」#

Agent 会复现仓库中已有的模式，包括不均衡的、次优的模式。随着时间推移，代码漂移不可避免。

团队最初的应对是：每周五花 20% 的时间手动清理「AI 垃圾代码」。不出所料，这根本不具备可扩展性。所以他们改用了另一套做法。

他们把「金科玉律」编码进仓库本身，并建立了一个定期运行的清理流程。这些原则是带有强烈观点的机械化规则，用来保证代码库对未来 Agent 运行保持可读和一致。这就像垃圾回收：技术债是高息贷款，持续小额偿还几乎总是优于放任不管等它堆积成灾难。

人的角色去哪了？#

这是我最喜欢本文的地方：它没有贩卖「AI 取代程序员」的焦虑，而是冷静地描述了角色转变。

在这个团队中，人类工程师仍然始终在循环中，但工作层面变了。他们不是在关心这个函数怎么写、那个变量怎么命名，而是在做更有杠杆效应的事情：

  • 定义「好软件」是什么样子的，并把它编码进系统
  • 把用户反馈翻译成验收标准
  • 在 Agent 出错时诊断根因，改进工具或文档
  • 设计环境和反馈循环，让 Agent 更不容易犯错

用作者的话说：「构建软件依然需要纪律，但纪律更多地体现在脚手架而非代码上。」

反思：这到底意味着什么？#

读完这篇文章，我有几个感触。

第一，context engineering 正在成为新的 prompt engineering。 提示词的技巧很快会达到天花板，真正的区别在于谁能给 Agent 构建更好的工作环境：更好的文档结构、更好的架构约束、更好的反馈循环。

第二，「工具即约束」的思想在 Agent 时代获得了新生。 以前我们说 lint、CI、自动化测试是为了保证代码质量，现在它们还承担了一个新角色：定义 Agent 可以操作的安全边界。

第三，人类工程师的核心能力正在转移。 从「写出正确的代码」变为「设计让代码不容易出错的环境」。这有点像从手工艺人转型为工厂设计师，值得每个开发者深思。

当然，文章也诚实地承认了很多未知：全 Agent 生成的代码库在几年后架构一致性会怎样？人类判断力在哪些环节最有杠杆效应？怎么把这种判断力编码进系统让它持续积累？这些问题目前没有答案。

但有一件事是清楚的：如果你还在把 AI 编程助手当成「更方便的 Stack Overflow」，你其实错过了它真正的可能性。Codex 不是来帮你写代码的，它是来重新定义「写代码」这件事本身的。

参考来源：Harness engineering: leveraging Codex in an agent-first world — Ryan Lopopolo, OpenAI Blog, June 5, 2026