本文介绍了 OpenAI 进行的一项为期五个月的工程实验：在“智能体优先”（Agent-first）的世界中，利用 Codex（基于 GPT-5）构建并交付了一款内部 Beta 软件产品，且未手动编写任何一行代码。该产品拥有数百万行代码，涵盖了应用逻辑、测试、CI 配置、文档及监控工具，开发效率提升了约 10 倍。

实验的核心结论是：在智能体时代，工程师的角色发生了根本性转变。人类不再是代码的编写者，而是环境的设计者、意图的指定者和反馈循环的构建者。团队通过“人类引导，智能体执行”的模式，实现了平均每人每天 3.5 个 PR 的高产出。为了让智能体高效工作，团队采取了一系列创新措施：首先，提高应用的“可读性”，通过集成 Chrome DevTools 和本地观测栈（Logs/Metrics），让智能体能自主调试 UI 和性能；其次，将代码库（Repository）作为唯一的知识来源，通过结构化的文档和 AGENTS.md 索引，解决上下文稀缺和规则陈旧的问题；最后，通过极其严格的架构分层和自定义 Linter 强制执行“工程品味”，防止架构漂移。

此外，实验还揭示了高吞吐量下的新挑战，如“AI 废料”（AI slop）的堆积。团队通过引入“黄金原则”和自动化的“垃圾回收”机制（即定期运行重构智能体）来保持代码库的健康。这种模式证明了，只要拥有正确的脚手架和反馈系统，智能体可以实现从发现 Bug 到修复、验证并合并 PR 的全自动化闭环。

---

主题 1：从编写代码到设计环境：工程师角色的重定义

在传统的软件工程中，工程师的大部分时间花费在编写和调试代码上。然而，在 OpenAI 的这项实验中，核心哲学被定为“零手动代码”。这意味着工程师的主要职责从“实现者”转变为“系统架构师”和“环境赋能者”。实验初期，进度比预期慢，原因并非 Codex 能力不足，而是因为开发环境缺乏必要的抽象和工具，导致智能体无法理解高层目标。

为了解决这个问题，工程师开始采用“深度优先”的工作方式：将大目标拆解为设计、编码、评审和测试等微小模块，引导智能体逐一构建。当任务失败时，修复手段不再是“让 AI 再试一次”，而是反思“缺失了什么能力，以及如何让这种能力对智能体可见且可强制执行”。人类与系统的交互几乎完全通过 Prompt 完成，描述任务后由智能体生成 PR。为了确保质量，团队引入了“智能体对智能体”的评审机制（类似于 Ralph Wiggum 循环），智能体会在本地运行代码、查看反馈、迭代修改，直到满足所有评审条件。

这种模式极大地释放了生产力。在三到七名工程师的驱动下，代码库在五个月内增长到百万行规模，平均每人每天合并 3.5 个 PR。更重要的是，随着团队规模扩大，人均产出不降反升，这打破了传统工程中“人多效率低”的魔咒。工程师现在的工作是定义意图、翻译用户反馈为验收标准，并验证最终结果。这种转变意味着，未来的工程能力将更多地体现在如何构建一个让智能体能够可靠工作的“温室”，而非亲自下地耕种。

主题 2：提升应用可读性与智能体的自主观测能力

当代码生成的吞吐量呈指数级增长时，人类的 QA（质量保证）能力成为了新的瓶颈。为了打破这一瓶颈，团队致力于提高应用对智能体的“可读性”（Legibility）。如果智能体无法感知应用的运行状态，它就无法有效地调试和验证。为此，团队为智能体配备了一套完整的“感官系统”。

首先是 UI 层的感知。团队使应用能够针对每个 Git 工作树独立启动，并将 Chrome DevTools 协议接入智能体运行环境。智能体现在可以获取 DOM 快照、截屏、模拟导航，并观察运行时事件。这使得 Codex 能够自主重现 Bug、验证 UI 修复，并根据视觉反馈调整逻辑。其次是后端观测能力的开放。团队在本地为每个任务构建了短暂且隔离的观测栈（包括 Vector、Victoria Logs/Metrics 等），智能体可以使用 LogQL 和 PromQL 查询日志和指标。例如，工程师可以下达“确保服务启动在 800ms 内完成”或“关键路径耗时不超过 2 秒”的指令，智能体通过分析真实的性能数据来优化代码。

这种“闭环反馈”能力让智能体能够进行长达 6 小时的连续任务，甚至在人类睡觉时也能自主工作。通过将日志、指标和 UI 状态转化为智能体可理解的上下文，开发过程从“盲目生成”变成了“基于证据的迭代”。这种方法也影响了技术选型：团队更倾向于使用“枯燥”但可组合、API 稳定且在训练集中表现良好的技术，甚至不惜让智能体重新实现某些库的功能，以确保其行为对智能体是完全透明和可控的。

主题 3：知识库管理、架构约束与“AI 废料”的治理

在大型复杂任务中，上下文管理是智能体面临的最大挑战。团队放弃了编写冗长的“操作手册”，转而采用“地图”模式。他们发现，单一的、庞大的 AGENTS.md 文件会迅速过时并挤占宝贵的上下文窗口。因此，他们将代码库本身作为“记录系统”（System of Record），建立了一个结构化的 docs/ 目录，包含设计文档、执行计划、技术债追踪和质量评分。AGENTS.md 仅作为约 100 行的“目录”，引导智能体在需要时去寻找更深层的真相。

为了防止百万行代码演变成混乱的泥潭，团队实施了极其严格的架构约束。他们采用了一种分层领域架构（Types → Config → Repo → Service → Runtime → UI），并利用 Codex 生成的自定义 Linter 强制执行依赖方向。任何违反架构规则的代码都会在 CI 阶段被拦截，并向智能体返回带有修复建议的错误信息。这种“中心化强制边界，本地化赋予自由”的策略，确保了即使代码风格不完全符合人类审美，其架构逻辑依然清晰且可维护。

此外，实验还发现了一个新现象：“AI 废料”（AI slop），即智能体倾向于复制库中已有的、甚至是次优的代码模式。为了应对这种熵增，团队引入了“垃圾回收”机制。他们将“黄金原则”（如：优先使用共享工具包而非手写辅助函数）编码进系统，并定期运行背景智能体扫描代码库，发起重构 PR。这种持续的、小步快跑的债务偿还方式，比人类定期进行的“大扫除”更高效。最终，系统达到了一种高度自治的状态：智能体可以从接收 Prompt 开始，经历 Bug 重现、修复、录制验证视频、处理评审反馈，直到最后自动合并代码，实现了软件生命周期的全自动化。

---

问答

1. 为什么这个项目强调“0 行手动代码”？ 这是为了迫使团队去构建必要的脚手架和反馈循环。只有在完全不能亲自动手的情况下，工程师才会专注于如何通过设计环境和工具来提升智能体的效率，从而实现数量级的速度提升。

2. 智能体是如何进行自我修复和评审的？ 团队采用了“Ralph Wiggum 循环”：智能体在本地运行代码并进行自我评审，同时请求云端其他智能体的评审。它会根据反馈（包括 Linter 错误、测试失败或评审意见）在循环中不断迭代，直到所有自动化检查和智能体评审员都满意为止。

3. 如何解决智能体上下文窗口有限的问题？ 采用“渐进式披露”策略。不给智能体成千上万页的说明书，而是提供一个结构化的 docs/ 目录和一份简短的 AGENTS.md 作为地图。智能体根据地图指引，在需要特定知识时才去读取相关的详细文档。

4. 什么是“AI 废料”（AI slop），如何解决？ AI 废料是指智能体在代码库中复制的不良或次优模式。解决方法是定义“黄金原则”并实施自动化的“垃圾回收”：定期运行专门的重构智能体，扫描代码库中的偏离项并自动发起修复 PR。

5. 这种开发模式对技术选型有什么影响？ 更倾向于选择“枯燥”的技术。这些技术通常具有更好的组合性、API 稳定性，且在 AI 训练数据中覆盖率高。有时为了增加可控性，团队甚至会让智能体重新实现某些第三方库的功能，以便于智能体理解和测试。