OpenAI 用 5 个月、3 名工程师、零行手写代码交付了一个百万行级产品的内部 beta 版。本文精读其官方工程博客，提炼这套「人类掌舵、智能体执行」的方法论：环境怎么搭、知识怎么存、架构怎么约束、熵怎么清理。
他们给自己加了一条硬约束，目的是逼出「工程速度提升数个数量级」所必需的条件
2025 年 8 月下旬，团队向一个空的 Git 仓库做了第一次提交。初始架构——仓库结构、CI 配置、格式化规则、包管理器设置、应用框架——全部由 Codex CLI 使用 GPT‑5 生成。连指导智能体如何在仓库中工作的 AGENTS.md 本身，也是 Codex 写的。
五个月后，这个仓库拥有约 100 万行代码，涵盖应用逻辑、基础设施、工具、文档到内部开发者工具。期间约 1500 个 PR 被创建与合并，而推动 Codex 的只有 3 名工程师——相当于人均每天 3.5 个 PR。更反直觉的是：当团队扩大到 7 人时，吞吐量不降反升。
整个开发过程中，人类从未直接贡献过任何代码行。人类始终参与，但工作层次变了：优先处理工作、把用户反馈转化为验收标准、验证结果。当智能体卡住时，团队把它当作一个信号——去识别缺失的工具、约束或文档，然后依然由 Codex 自己编写修复。
通常「团队变大、人均产出下降」是软件工程的铁律（沟通成本随人数平方增长）。这里之所以相反，是因为人类的工作不再是写代码，而是搭建让智能体能可靠工作的环境——环境投入是可复用、可累积的，第 7 个人能直接享受前 6 个人建好的 harness。这是「规模收益递增」而非递减。
「再努力一点」不再是解法；新的解法是「还缺什么能力，怎么让它对智能体清晰可读且可强制执行」
由于没有人工编码，工程师的工作重点转向了系统、架构和杠杆作用。早期进展比预期慢，但原因不是 Codex 能力不足，而是环境规范不够明确——智能体缺乏实现高级目标所需的工具、抽象层和内部结构。
工程师描述任务 → 运行智能体 → 允许其开一个 PR。为了推动 PR 完成，会指示 Codex：
Codex 直接使用标准开发工具（gh、本地脚本、嵌入仓库的技能）收集情境，无需人工把内容复制粘贴到 CLI 里。
人类可以审核 PR，但并非必须。随着时间推移，团队把几乎所有评审工作都调整为智能体对智能体的方式。这是整个方法论里最反直觉、也最能释放吞吐量的一个转变。
Codex 还会直接使用标准开发工具完成闭环：拉取审查反馈、行内回复、推送更新，并且经常自己压缩并合并自己的 PR。
代码吞吐量上去之后，瓶颈变成了人工 QA——而人类的时间和注意力是固定的硬约束
唯一的出路是：让应用的 UI、日志、指标对 Codex 直接可读，把人类的验证能力「外包」给智能体。
git worktree 启动 → Codex 能为每次更改起一个独立实例有了这些能力后，团队经常见到单次 Codex 运行在单个任务上持续工作超过 6 小时——通常发生在人类睡觉的时候。这是「人类时间不再与产出线性绑定」的直接体现。
情境管理是让智能体在大型复杂任务中有效的最大挑战之一
他们先试了「一个巨大的 AGENTS.md」方案，结果是一次失败的尝试。四个失败原因值得逐条记住：
巨大的指令文件会挤掉任务、代码和相关文档——智能体要么错过关键约束，要么针对错误的约束进行优化。
当一切都「重要」时，一切都不重要。智能体最终会退化成本地模式匹配，而不是有意识地导航。
庞杂手册会变成陈旧规则的坟场。智能体无法判断哪些还有效；一旦人类停止维护，它就成了「颇具吸引力的麻烦源头」。
单个大文件不适合机械检查（覆盖率、新鲜度、所有权、交叉链接），因此漂移不可避免。
一份简短的 AGENTS.md（约 100 行）被注入情境，主要用作地图，指向其他地方更深层的真实信息源。真正的知识库位于结构化的 docs/ 目录。
AGENTS.md ← 约 100 行，只做地图 ARCHITECTURE.md ← 域与包分层的顶层地图 docs/ ├── design-docs/ ← 已编目索引，含验证状态 + 核心理念 │ ├── index.md │ ├── core-beliefs.md │ └── ... ├── exec-plans/ ← 执行计划：一等工件 │ ├── active/ │ ├── completed/ │ └── tech-debt-tracker.md ├── generated/ ← 自动生成，如 db-schema.md │ └── db-schema.md ├── product-specs/ │ ├── index.md │ ├── new-user-onboarding.md │ └── ... ├── references/ ← 外部文档的 llms.txt 快照 │ ├── design-system-reference-llms.txt │ ├── nixpacks-llms.txt │ └── uv-llms.txt ├── DESIGN.md ├── FRONTEND.md ├── PLANS.md ├── PRODUCT_SENSE.md ├── QUALITY_SCORE.md ← 对每个产品域/架构层评分，追踪差距 ├── RELIABILITY.md └── SECURITY.md
智能体从一个小而稳定的切入点开始，并被指引下一步去哪看，而不是一开始就被淹没。同时他们严格执行：专职 linter 和 CI 作业会验证知识库的更新状况、是否已交叉链接且结构正确；还有一个定期运行的 「doc-gardening」智能体，扫描不再反映真实代码行为的过时文档，并发起修复 PR。
计划被视为一等工件：小幅变更用轻量临时计划，复杂工作记录在执行计划中，附带进度与决策日志，一并提交进仓库。活跃计划、已完成计划、已知技术债务都版本化集中存放——让智能体不依赖外部情境即可运行。
代码库完全由智能体生成，所以第一优化目标不是人类可读性，而是 Codex 的可读性
他们倾向于选择可以完全内化于仓库中进行推理的依赖项和抽象。对智能体来说，通常被称为「枯燥」的技术，由于其可组合性、API 稳定性、以及在训练集里的充分表现，往往更容易建立模型。
他们没有引入通用的 p-limit 风格并发包，而是自己实现了带并发的 map 辅助函数。理由：它与他们的 OpenTelemetry 仪表紧密集成、具备 100% 测试覆盖率、行为完全符合运行时预期。有时重新实现一个功能子集，比绕过公共库中不透明的上游行为更便宜。
给 Codex 更多情境，重点是组织和展示正确的信息，让智能体能基于它推理，而不是用临时指令把它压垮。就像给新队友做入职引导（产品原则、工程规范、团队文化）一样，把这些提供给智能体会带来更一致的输出。
仅靠文档无法保持完全由智能体生成的代码库的连贯性——要靠强制执行不变量
例如：他们要求 Codex 在边界处解析数据形状（parse, don't validate），但不规定具体实现方式——模型似乎偏好 Zod，但他们没有指定库。
因为这些规则一旦编码，就能立即应用于所有地方。生成的代码不总是符合人类的风格偏好，这没关系——只要输出正确、可维护、对未来的智能体运行清晰易读，就算达标。人类的品味通过评审评论、重构 PR、面向用户的 Bug 持续反馈回系统；当文档不够完善时，就把规则转化为代码。
当智能体的吞吐量远超人类的注意力，传统的工程规范开始失效
仓库在运行过程中刻意减少阻塞合并门，Pull Request 的生命周期很短。
测试偶发失败通常通过后续重跑解决，而不是无限期阻碍进展。
在智能体吞吐量远超人类注意力的系统里，纠错成本低，等待成本高。
原文明确说：「在低吞吐量环境中，这样做是不负责任的。而在这里，这通常是正确的选择。」 这条经验不可直接照搬——它成立的前提是你已经有了可靠的可观测性、自动回滚能力和极高的修复速度。如果你的团队还在人工验证为主、回滚要半小时，那么「减少合并门」就是灾难。
不只是业务代码——整个仓库的每一个角落
先确认起点，不假设。
用真实运行环境复现，而非推测。
用可视化证据锚定问题。
在分层架构约束内改动。
靠 CDP + 可观测性栈自证。
前后对比，形成可审查证据。
走标准 gh 流程。
Ralph Wiggum 循环迭代。
自己收拾自己的烂摊子。
人只做真正的判断。
自行压缩并合并 PR，完成闭环。
「此行为在很大程度上取决于此代码仓库的具体结构和工具，不应在没有类似投入的情况下假定它可以泛化——至少目前还不行。」换句话说：这不是开箱即用的能力，而是先投入建好 harness 之后的回报。
完全自主的智能体也引入了新问题：它会复现仓库里已有的模式——包括那些不够理想的模式
这不可避免导致漂移。最初人类手动处理：团队每周五（占一周的 20%）都要花时间清理「AI 残渣」。原文的评价很坦率：「不出所料，那并不具备可扩展性。」
黄金原则是带主观意见的机械规则，目的是保持代码库对未来智能体运行的可读性与一致性。两个例子：
倾向于使用共享的实用程序包，而不是手工编写的辅助工具，以便将不变式集中管理。
不使用猜测式的探测数据——验证边界，或依赖类型化的 SDK，这样智能体就不会意外地基于猜测的结构进行构建。
这套机制让他们能够每天发现并解决不良模式，而不是让它们在代码库中传播数天或数周。原文把它类比为垃圾回收（GC）——持续、自动、小额，而不是周期性的人工大扫除。
原文诚实地列出了三个「还不知道」
在一个完全由智能体生成的系统中，架构连贯性会随着时间的推移如何演变，尚不清楚。
人类的判断力在哪些方面能发挥最大作用，以及如何把这种判断力编码使其发挥更大作用。
随着模型能力不断增强，这套系统在长期会如何演变。
「我们当前最棘手的挑战集中在设计环境、反馈回路和控制系统方面，帮助智能体实现我们的目标：大规模构建和维护复杂、可靠的软件。」
按投入产出比排序，可直接照做与必须谨慎照做的分开列
| 实践 | 具体做法 | 可照搬度 |
|---|---|---|
| AGENTS.md 当目录不当手册 | 控制在 ~100 行，只做地图与索引；真正的知识放结构化 docs/，按 design-docs / exec-plans / references 分类 | 高 |
| 知识进仓库，不进人脑 | 把架构决策、约定、Slack 里达成的共识，全部以 Markdown 提交进仓库；建立「文档园艺」任务定期清理过期文档 | 高 |
| 渐进式披露 | 入口小而稳定，指引下一步去哪看，而不是一次性灌入全部约束 | 高 |
| 用 lint 强制架构不变量 | 分层依赖方向、命名约定、文件大小上限等机械化；错误信息里写修复指引 | 高 |
| 让应用对智能体可读 | 每 worktree 起一个实例；接入 DevTools 协议；临时可观测性栈 + LogQL/PromQL 供查询 | 中 |
| 黄金原则 + 后台清理循环 | 把品味写成机械规则，用后台任务扫描偏差、发小重构 PR、快速自动合并 | 中 |
| 执行计划作为一等工件 | 复杂工作的计划、进度、决策日志一并提交进仓库，让智能体不依赖外部情境 | 高 |
| 减少阻塞式合并门 | 缩短 PR 生命周期；偶发失败靠重跑而非阻塞 | 低 需先有回滚能力 |
| 几乎取消人工代码评审 | 转向智能体对智能体评审 | 低 需先建好验证体系 |
当写代码不再是瓶颈，工程的重心就从「代码本身」转移到了承托代码的那一层——环境、约束、知识结构与反馈回路。人类掌舵，智能体执行：人类负责设计环境、明确意图、构建反馈回路；智能体负责在其间可靠地工作。而衡量这套体系的指标，也从「写了多少代码」变成「智能体能自主、正确、一致地走完多少步」。