StreamSparkAI

核心概览

2026年2月11日，Ryan Lopopolo 介绍了团队过去五个月的一项工程实验：从一个空的 Git 仓库出发，在“0 行人工手写代码”的约束下，使用 Codex 构建并持续交付一个真实可用的软件产品。这个产品并非演示样品，而是已经有内部日常用户、外部 alpha 测试者、会发布部署、会出现故障、也会被修复的运行中系统。团队估计，如果改为传统手写代码方式，完成同等规模工作所需时间大约会是现在的十倍。

文章的中心命题不是“AI 替人写了多少代码”，而是软件工程的主工作对象正在发生转移：人类从直接实现功能，转向设计环境、表达意图、组织知识、设置约束、建立反馈闭环，并让智能体在这个系统里可靠执行。在这种模式下，“Humans steer. Agents execute.” 不是口号，而是整个工程体系的分工原则。

五个月后，这个完全由 Codex 产出的仓库已经扩展到约百万行代码，覆盖应用逻辑、基础设施、内部工具、测试、CI、文档、可观测性与开发辅助工具。期间，三名工程师驱动 Codex 发起并合并了约 1500 个 PR，平均每名工程师每天约 3.5 个 PR；随着团队扩展到七人，总吞吐量并未下降，反而还在提升。文中据此提出，在智能体优先的开发范式下，真正稀缺的资源不再是代码产出能力，而是人类的时间与注意力。

一、从空仓库开始：把“零人工代码”变成一条硬约束

实验始于 2025 年 8 月底的第一次提交。最初的仓库脚手架——包括目录结构、CI 配置、格式规则、包管理器设置、应用框架——由 Codex CLI 配合 GPT‑5，并参考少量现有模板生成。甚至连指导智能体如何在仓库内工作的 AGENTS.md，也是由 Codex 编写。

这一点非常关键：团队并不是在一套人类既有代码基础上让智能体做增量修改，而是让智能体从第一天开始塑造仓库本身。因此，代码库的组织方式、文档结构、架构边界、工作流工具、质量门槛，都是围绕“如何让智能体稳定工作”逐步形成的。

在整个开发过程中，人类从未直接向仓库提交代码，这被团队明确为核心哲学：no manually-written code。如果出现问题，解决方式也不是“人类先补一段关键逻辑”，而是继续让 Codex 来完成修复，包括补代码、补文档、补 lint 规则、补自动化检查和补内部工具。由此，仓库不仅是智能体的产出物，也是智能体持续工作的运行环境。

二、工程师角色被重新定义：不再以写代码为中心

文中指出，早期进展比预期更慢，但原因并不是 Codex 本身“不会写”，而是系统环境定义不足：工具不够、抽象不够、内部结构不够、目标与约束不够可执行。换言之，瓶颈不在生成能力，而在可操作的工程系统没有搭起来。

于是，工程师的职责发生了重构：

• 不再把主要精力放在亲自实现功能；
• 而是拆解目标、设计脚手架、补齐工具、沉淀文档、编码规则；
• 让智能体可以沿着明确边界持续推进任务。

团队的实际工作方式是“深度优先”推进：先把大目标分解为更小的构件，例如设计、实现、审查、测试、验证、发布，然后让 Codex 分别完成这些构件，并用这些构件去解锁更复杂的任务。当某项工作失败时，团队不会简单要求智能体“再试一次”，而是反过来追问：到底缺少了哪一种能力？这种能力如何被表达清楚？又如何被系统机械地强制执行？

这使工程师的工作层级整体上移。人类主要负责：

• 排定优先级；
• 把用户反馈转写为明确的验收标准；
• 判断什么时候需要升级人工裁决；
• 把经验和偏好持续沉淀进仓库；
• 维护让智能体可以长期稳定工作的控制系统。

三、PR 不再只是代码提交，而是一条 agent-to-agent 的闭环流水线

在这套体系里，人类与系统的主要交互手段几乎全部变成了提示词。工程师描述任务后运行智能体，由 Codex 直接打开 PR。随后，一个典型 PR 会沿着以下闭环推进：

1. Codex 先在本地审查自己的改动；
2. 再请求额外的、更加具体的智能体审查，既可以在本地，也可以在云端进行；
3. 然后读取人类或其他智能体提出的反馈；
4. 回应评论并迭代修改；
5. 重复上述过程，直到所有智能体审查者都满意。

文中把这个过程称为一种 Ralph Wiggum Loop。它的关键不在某个单点动作，而在于：智能体不仅负责“产出第一版代码”，还负责围绕这份代码进行自检、复审、吸收反馈、再次修正，直到进入可合并状态。这意味着审查本身也被纳入智能体工作流，而不再完全依赖人类精读每一次改动。

Codex 在这个过程中并不依赖工程师手工复制粘贴上下文。它直接使用团队的标准开发工具，例如 gh、本地脚本，以及嵌入仓库的技能模块，自主拉取上下文、读取反馈、做出修改、推送更新，甚至常常自己 squash 并 merge PR。人类仍可介入审查，但并非每次都必须介入；随着系统成熟，团队已经把绝大多数审查工作尽量转移到智能体之间完成。

四、吞吐量上升后，瓶颈变成了人类 QA，而不是编码速度

随着代码产出速度持续提高，团队很快发现新的瓶颈不是“写得够不够快”，而是人类是否有足够时间做质量验证。既然真正稀缺的是人类注意力，最直接的办法不是压低产出，而是让应用本身更容易被 Codex 读取、驱动、观察和验证。

1. 让应用对智能体可操作：git worktree + 独立实例

团队先把应用改造成可以按 git worktree 启动。这意味着每个改动都能拥有一个独立运行的应用实例，Codex 可以针对当前任务单独启动、验证、回收，不会和其他任务互相污染。这样，智能体不只是静态读代码，而是能在属于当前任务的隔离环境中真正运行系统。

2. 让 UI 对智能体可读：接入 Chrome DevTools Protocol

团队把 Chrome DevTools Protocol 接入智能体运行时，并为 DOM 快照、截图、页面导航等能力编写专门技能。这样一来，Codex 可以：

• 自主打开页面并沿着指定路径操作；
• 在操作前后抓取 DOM 状态；
• 观察页面截图和运行时事件；
• 对照变化判断问题是否被复现；
• 修改代码后重启应用，再次执行相同路径验证修复是否成立。

由此，UI 行为本身不再只靠人类肉眼确认，而成为智能体可直接检验的反馈源。文中的图示进一步说明了这种循环：Codex 选择目标路径，记录修复前状态，触发界面行为，读取运行时事件，应用补丁后重新启动，再重复运行验证，直到界面行为恢复正常。

3. 让日志、指标、追踪都进入智能体的可见范围

团队对可观测性也做了同样处理。每个 worktree 对应一个本地、临时性的可观测性栈，日志、指标和追踪都暴露给 Codex 使用；任务结束后，这套环境随之销毁。智能体可以直接查询：

• 日志；
• 指标；
• 追踪信息。

文中明确提到，Codex 可以使用 LogQL 查询日志，使用 PromQL 查询指标，并围绕这些信号推断问题位置与性能表现。在配图中，还展示了通过 TraceQL API 查询追踪信息的方式。这样，像下面这类目标就从模糊指令变成了可执行约束：

• “确保服务启动在 800ms 内完成”；
• “这四条关键用户路径中，没有任何 span 超过 2 秒”。

换言之，当 UI、日志、指标、追踪都能被智能体直接访问时，修复 bug、调优性能、验证可靠性就不再依赖工程师亲自跑环境、翻日志、点界面。文中还提到，单次 Codex 运行经常会围绕同一任务持续工作 6 小时以上，很多时候发生在人类已经下线休息的时间段。

五、把仓库变成唯一真相源：给智能体一张地图，而不是一整本说明书

在大任务场景下，上下文管理是智能体效率的核心问题之一。团队最早的经验之一是：不要试图用一个巨大的 AGENTS.md 把一切都写进去。要给 Codex 一张地图，而不是一份一千页的说明书。

团队尝试过“单一大文档”方案，结果很差，原因包括：

• 上下文资源本来就稀缺，大量说明会挤占任务本身、代码本身和真正相关文档的空间；
• 当所有规则都被写成“重要”，真正关键的约束反而失去辨识度；
• 大而全的文档极易过时；
• 单块文档很难做覆盖率、时效性、归属和交叉引用等机械检查，最终一定漂移。

因此，团队改造了知识结构：短小的 AGENTS.md 只承担目录作用，真正的知识库存放在结构化的 docs/ 目录中，并作为系统记录源存在。

仓库中的知识被组织为多个明确区域，例如：

• 设计文档与索引；
• 核心信念；
• 产品规格；
• 执行计划；
• 已完成计划与技术债跟踪；
• 参考资料；
• 面向设计、前端、产品理解、质量、可靠性、安全等主题的专项文档；
• 自动生成内容，例如数据库 schema 文档。

其中，执行计划被视为一等工件。小改动可以用轻量、短期的计划处理；复杂任务则用正式的 execution plan，记录进度与决策日志，并直接提交进仓库。活跃计划、已完成计划和已知技术债都与代码共同版本化，避免依赖外部聊天记录或临时说明。

这种方式对应文中强调的渐进披露：先给智能体稳定、简短、不会频繁变化的入口，再清楚告诉它下一步应该去哪一类文档查找更深层信息，而不是一开始就把所有说明硬塞进上下文。

为了防止知识库再次失真，团队还把维护动作自动化：

• 用专门的 lint 和 CI 检查文档是否更新、是否交叉链接、结构是否正确；
• 用一个定期运行的“文档园艺”智能体扫描过时或已不符合真实代码行为的文档；
• 由该智能体直接发起修复 PR。

这意味着文档不再只是给人看的附属物，而是智能体工作能力的一部分。

六、仓库首先要对智能体可读，而不是优先满足人的阅读习惯

文中提出了一个重要判断：对智能体来说，任何无法在运行时上下文中访问到的知识，实际上就等于不存在。 代码、Markdown、schema、执行计划这类仓库内本地可见、可版本控制的工件，是它真正能够依赖的世界；而 Google Docs、聊天记录、口头共识、人脑中的默会知识，如果没有被编码进仓库，就无法参与推理。

这让团队逐渐把更多上下文“推回仓库”：

• 一次 Slack 上达成的架构共识；
• 一套产品原则；
• 某个设计取舍的决策历史；
• 团队默认接受的工程规范；
• 甚至团队文化层面的偏好。

只要这些信息会影响后续实现质量，就需要以仓库内工件的形式沉淀。这种做法既服务于 Codex，也服务于未来加入的工程师，因为两者面对的问题本质相同：看不见的信息就无法被可靠使用。

这一原则还直接影响技术选型。团队更偏向那些常被称为“boring”的技术：可组合、API 稳定、在训练数据中更常见、更容易被模型内化。某些情况下，与其围绕行为不透明的上游库做复杂适配，不如让智能体直接在仓库内重写一个更小、但完全可理解、可测试、可修改的功能子集。文中的例子是，他们没有直接引入类似 p-limit 的通用包，而是实现了自己的并发映射辅助工具，让它与 OpenTelemetry 深度集成、保持 100% 测试覆盖，并完全符合当前运行时需求。

七、靠不变量而不是人工盯梢来维持架构与“口味”

文章明确指出，文档本身不足以维持一个完全由智能体生成的代码库的整体一致性。仅靠“告诉它应该怎么做”不够，必须把关键约束变成能自动检查、自动阻止、自动纠偏的机制。

团队采用的原则是：强制执行不变量，而不是微观管理每个实现细节。

一个例子是，团队要求在边界处解析数据形状，而不是只做验证；但并不强制指定必须选哪一个库，虽然模型似乎倾向使用 Zod。更重要的是整体架构约束。团队把每个业务域都做成固定分层，并严格控制依赖方向：

Types → Config → Repo → Service → Runtime → UI

横切关注点，如认证、连接器、遥测、功能开关，只能通过一个明确接口进入：Providers。除此之外的依赖路径一律视为非法，并通过自定义 lint 与结构测试机械执行。图示中还展示了位于边界外的 Utils 模块，以及业务域和应用装配层的关系。

文章特别强调，在传统团队里，这种架构纪律往往会被认为要等到数百名工程师时才值得建立；但在智能体优先的开发模式下，它恰恰是非常早期的前提。因为没有强边界，速度带来的不是规模化收益，而是规模化漂移。

除了分层结构，团队还编码了一组“口味不变量”，例如：

• 强制结构化日志；
• 对 schema 和类型命名设定规则；
• 限制文件大小；
• 固化平台相关的可靠性要求。

由于这些 lint 是自定义的，报错信息也被刻意写成“带修复提示的错误说明”，这样错误本身就能把 remediation 指令重新注入到智能体上下文中。对人类开发者而言，这类规则可能显得琐碎甚至刻板；但对智能体来说，一旦编码成规则，就会在整个仓库同时生效，形成成倍放大的约束收益。

八、吞吐量改变了合并哲学：等待更贵，修正更便宜

当 Codex 的吞吐量大幅提高后，许多传统工程规范开始显得不再合适。团队采用的是低阻塞合并策略：

• 尽量减少阻塞式 merge gate；
• 让 PR 保持短生命周期；
• 遇到测试抖动时，经常通过后续运行补修，而不是长时间阻塞主线。

文中的判断非常直接：在一个智能体吞吐远超人类注意力的系统里，修正通常很便宜，等待反而很昂贵。 当然，这并不是一条脱离场景的普适规则。文中也明确指出，若在低吞吐、低修复能力环境里照搬这种做法，将是不负责任的。它成立的前提，是已经拥有持续自动修复、快速重跑、短周期回路和较强环境控制能力。

九、“agent-generated”不是局部辅助，而是几乎整个仓库都由智能体生成

文中对“智能体生成代码库”的定义非常彻底。它不是指“主要业务代码用 AI 写”，而是指仓库中的几乎一切都由 Codex 生成，包括：

• 产品代码和测试；
• CI 配置和发布工具；
• 内部开发工具；
• 文档与设计历史；
• 评估 harness；
• 审查评论与回复；
• 管理仓库自身的脚本；
• 生产环境仪表盘定义文件。

人类始终在环，但处于比过去更高的抽象层。团队把智能体遇到困难视为系统信号：说明缺了工具、护栏或文档，于是再把这些缺失补回仓库，而且仍然要求由 Codex 自己完成这些补丁。由此，系统能力会随着每次失败不断内生增强，而不是通过人工“越俎代庖”来短路问题。

十、自主性已经提升到端到端完成新功能的程度

随着测试、验证、审查、反馈处理与故障恢复逐步编码进系统，团队认为仓库最近跨过了一个重要门槛：给定单个提示，Codex 已经能够端到端推动一个新功能或缺陷修复闭环完成。

它可以依次完成：

• 校验当前代码库状态；
• 复现已报告的问题；
• 录制展示失败现象的视频；
• 实现修复；
• 驱动应用验证修复结果；
• 录制修复后视频；
• 打开 PR；
• 响应人类与智能体反馈；
• 检测并处理构建失败；
• 仅在需要判断力时升级给人类；
• 最终合并改动。

这可以视为文中给出的一个完整“从问题到合并”的端到端流程实例。与此同时，文章也强调，这种高度自治依赖于当前仓库的结构、文档、工具链和反馈系统，不应被当作未经投入即可复制的通用状态。

十一、完全自治会带来新的熵增：因此必须做持续“垃圾回收”

文章没有把高度自治描绘成无代价状态。相反，作者明确指出：Codex 会复制仓库里已经存在的模式，包括不均匀甚至不理想的模式。 当这种复制在高吞吐环境中持续发生时，漂移几乎不可避免。

团队最初靠人工治理：每周五拿出整整 20% 的工作时间清理所谓 “AI slop”。这显然无法扩展。于是，他们把人类偏好与经验压缩成一组黄金原则，直接编码进仓库，并配套后台清理流程。

文中给出的黄金原则示例包括：

1. 优先使用共享工具包，而不是到处手写小工具，让关键不变量集中维护；
2. 不要用“YOLO 式”方式试探数据结构，要么在边界严格验证，要么依赖带类型的 SDK，避免让智能体建立在猜测形状之上继续扩展。

在此基础上，团队安排了一组定期运行的后台 Codex 任务，负责：

• 扫描偏离黄金原则的代码模式；
• 更新各领域和架构层的质量评分；
• 发起有针对性的重构 PR。

这些 PR 多数可以在一分钟内完成审查，并自动合并。文章把这一过程比作垃圾回收：技术债像高利贷，越早、越连续地小额偿还，越能防止其复利式累积。这里的关键不是偶尔做一次大清扫，而是让偏好被编码一次后，持续作用于每一天新增的每一行代码。

十二、仍未解决的问题：长期一致性、判断力分配、模型演进

尽管这套方法已经支持了 OpenAI 内部发布与采用，但文末保持了明确的开放性。团队仍在持续学习的问题包括：

• 完全由智能体生成的系统，在多年尺度上会如何演化其架构一致性；
• 哪些地方最值得投入人类判断力，以及如何把这种判断转写成可复用、可积累的系统能力；
• 随着模型能力继续增强，今天的仓库结构、工具和控制回路会如何变化。

文章最终给出的结论不是“软件工程从此变简单”，而是：纪律仍然是软件工程的核心，只是它越来越少体现在逐行代码书写上，而越来越多体现在脚手架、抽象边界、知识组织、反馈闭环和控制系统的设计上。

结论

这项实验展示的不是单一工具效率提升，而是一种工程范式转移：

• 人类的主要职责从写代码，转向设计让智能体稳定工作的环境。
• 仓库内的代码、文档、计划、规则和质量信号被统一为智能体可见、可验证、可执行的工作空间。
• 高速度必须依赖强约束、强反馈和持续清理，否则吞吐量只会放大熵增。
• “零人工手写代码”并不意味着人类退出开发流程，而意味着人类上移到更高层的目标设定、系统设计和规则编码位置。

文中最清晰的方向是：未来复杂软件的竞争力，越来越不只是“谁能写出代码”，而是“谁能设计出一个让智能体可靠地产生、验证、修复和维护代码的工程系统”。