作者: Ryan Lopopolo, OpenAI 技术团队成员 发表时间: 2026年2月11日 核心实验: 5个月内，用 Codex Agent 生成了100%的代码（约100万行），0行手写代码，构建并发布了一个有真实用户的内部产品。
总论：文章的元观点
核心命题: 当 AI Agent 成为主要代码编写者时，软件工程师的角色、工作方式和整个开发流程需要根本性重新定义。
通俗解释: 就像工业革命时，工人从”亲手织布”变成了”设计和维护织布机”——软件工程师正在从”写代码的人”变成”设计让AI写好代码的环境的人”。
提出背景: OpenAI 团队用了几周时间要交付100万行代码的产品，靠手写不可能完成，必须让 Agent 做执行层的工作。
观点一：工程师角色的重新定义
大观点
“人类掌舵，Agent 执行”（Humans steer. Agents execute.）
痛点: 传统软件工程中，工程师80%的时间花在写代码上。但当 Agent 能写代码后，工程师该做什么？如果只是”把需求告诉AI”，效率并不高——早期他们发现进展比预期慢得多。
背景: 团队刚开始时，Codex 并非”不能”写代码，而是环境没有准备好。Agent 缺少工具、抽象和内部结构来完成高层目标。
依据: 3名工程师驱动 Codex，5个月内合并了约1500个 PR，平均每人每天3.5个 PR。团队扩展到7人后，吞吐量反而增加了。
解决方向: 工程师的新职责是赋能 Agent——设计环境、指定意图、构建反馈循环。
子观点 1.1：深度优先拆解任务
通俗解释: 不是给 Agent 一个大目标说”去做吧”，而是像教实习生一样，先把大目标拆成小积木块，让 Agent 先搭小块，再用小块组合出大功能。
痛点: Agent 面对模糊的大目标时会”乱猜”，产出质量不稳定。
解决路径:
- 把大目标拆分为小构建块（设计、代码、评审、测试等）
- 先让 Agent 构建基础块
- 用基础块解锁更复杂的任务
- 失败时不是”再试一次”，而是问”缺少什么能力？怎么让 Agent 能理解和执行？”
子观点 1.2：Agent-to-Agent 评审取代人类评审
通俗解释: 以前是人看人的代码，现在是 AI 看 AI 的代码。人类从”逐行审代码”升级为”设计审查标准”。
痛点: 人类评审代码速度远远跟不上 Agent 的产出速度。
解决路径:
- Codex 先自我评审
- 再请其他 Agent 评审（本地和云端）
- 根据反馈自动迭代
- 形成”Ralph Wiggum 循环”（Agent 之间反复互审直到满意）
- 人类可以评审但不是必须
子观点 1.3：提示词（Prompt）成为新的编程语言
通俗解释: 工程师与系统的交互方式从”写代码”变成了”写任务描述”。描述一个任务，运行 Agent，Agent 自动开 PR。
解决路径: Agent 使用标准开发工具（gh 命令、本地脚本、仓库内嵌的 skills）自行收集上下文，不需要人类复制粘贴。
观点二：提升应用的”可读性”（Application Legibility）
大观点
让 Agent 能”看懂”和”操作”整个应用，而不仅仅是代码。
痛点: 随着代码产出量增大，人类 QA 能力成为瓶颈。Agent 写得快，但人测不过来。
背景: 人类时间和注意力是固定资源，不可能线性增长。
解决方向: 让 Agent 自己能看 UI、看日志、看监控指标，自己验证自己的工作。
子观点 2.1：让 Agent 能驱动和观察 UI
通俗解释: 就像给 Agent 装了一双”眼睛”——它可以打开浏览器，看到页面长什么样，点按钮，检查结果。
痛点: Agent 写了前端代码，但不知道页面实际渲染效果是否正确。
解决路径:
- 让应用可以按 git worktree 独立启动（每个修改有自己的运行实例）
- 接入 Chrome DevTools Protocol
- 创建操作 DOM 快照、截图、导航的 skills
- Agent 可以：复现 bug → 验证修复 → 推理 UI 行为
子观点 2.2：让 Agent 拥有完整的可观测性工具栈
通俗解释: 给 Agent 装了”体检仪器”——它可以查看日志、监控指标、调用链，就像医生看体检报告一样诊断问题。
痛点: Agent 无法判断代码的运行时性能是否达标。
解决路径:
- 每个 worktree 配备独立的本地可观测性栈（日志/指标/链路追踪）
- 通过 Vector 将应用数据分发到 Victoria Logs/Metrics/Traces
- Agent 用 LogQL、PromQL、TraceQL 查询数据
- 任务完成后环境自动销毁
- 使类似”确保服务启动在800ms内”的提示词变得可执行
子观点 2.3：长时间自主运行
通俗解释: Agent 可以像一个通宵加班的员工，连续工作6小时以上（往往是人类睡觉的时候），自主完成复杂任务。
依据: 他们经常看到单次 Codex 运行持续工作6小时以上。
观点三：仓库知识成为唯一的”事实来源”（System of Record）
大观点
给 Codex 一张地图，而不是一本1000页的说明书。
痛点: 怎么告诉 Agent”该怎么做事”？最初他们尝试了”一个大 AGENTS.md 文件”的方式，失败了。
背景: 这是上下文管理（Context Management）问题——Agent 一次能”看到”的信息是有限的。
子观点 3.1：大文件方式失败的四个原因
痛点拆解:
- 上下文是稀缺资源 — 巨大的指令文件会挤占任务、代码和相关文档的空间。就像考试时桌面太小，铺满了参考书反而找不到答案。
- 过多的指导等于没有指导 — 当一切都”重要”时，什么都不重要。Agent 会就近模式匹配而不是有目的地导航。就像路标太多的十字路口，司机反而不知道该往哪走。
- 即时腐烂 — 单体手册变成”过时规则的坟场”。Agent 分不清哪些还有效，人类也懒得维护。
- 难以验证 — 单个大文件无法做覆盖率、新鲜度、所有权等机械化检查，偏移不可避免。
子观点 3.2：分层知识库 + 目录式 AGENTS.md
解决路径:
- AGENTS.md 只有约100行，作为目录表，指向深层信息源
- 真正的知识库在结构化的 docs/ 目录中：
- design-docs/ — 设计文档（含核心信念、验证状态）
- exec-plans/ — 执行计划（活跃的/已完成的/技术债务）
- product-specs/ — 产品规格
- references/ — 参考资料（如 llms.txt 文件）
- generated/ — 自动生成的文档（如数据库 schema）
- 还有架构文档（ARCHITECTURE.md）、质量评分（QUALITY_SCORE.md）、安全（SECURITY.md）等
子观点 3.3：渐进式信息披露（Progressive Disclosure）
通俗解释: 不一次性灌输所有信息，而是告诉 Agent “先看这个小入口，需要更多信息时去这里找”。就像新员工入职——先给入职手册，遇到具体问题再查内部 wiki。
解决路径:
- Agent 从小而稳定的入口开始
- 被教导”下一步去哪里找信息”
- 而非被海量信息淹没
子观点 3.4：机械化强制执行
通俗解释: 不靠人”记得更新文档”，而是用自动化工具检查文档是否过时。
解决路径:
- 专用 linter 和 CI 任务验证知识库的时效性、交叉链接和结构正确性
- 定期运行的”文档园丁”Agent 扫描过时文档，自动开 PR 修复
观点四：Agent 可读性是终极目标
大观点
Agent 看不到的东西，对它来说就不存在。
痛点: 很多关键信息存在于 Google Docs、Slack 聊天、人脑中——这些对 Agent 完全不可见。就像一个远程员工无法访问公司内网一样。
背景: Agent 只能看到仓库内的、版本化的工件（代码、Markdown、Schema、执行计划）。
子观点 4.1：将隐性知识显性化到仓库
通俗解释: 那次 Slack 上讨论确定的架构决策？如果没写进仓库，Agent 就不知道，就像三个月后入职的新人也不会知道一样。
解决路径:
- 所有对齐讨论、架构决策必须编码进仓库
- 像给新队友做入职培训一样（产品原则、工程规范、团队文化）
- 给 Agent 越多结构化的上下文，产出越对齐预期
子观点 4.2：偏好”无聊”的技术栈
通俗解释: 选技术时不追求新潮，而选那些”老掉牙但稳定”的——因为 Agent 对它们更熟悉，更容易推理。
痛点: 复杂的、不透明的外部库让 Agent 难以理解和正确使用。
依据: “无聊”技术通常具备可组合性、API 稳定性、在训练集中有大量表示。
解决路径:
- 优先选择能在仓库内被完全内化和推理的依赖
- 某些情况下，自己重写一个子集功能比对抗外部库的不透明行为更便宜
- 例子：没有用通用的 p-limit 包，而是自己实现了并发控制 helper——与 OpenTelemetry 深度集成、100%测试覆盖、行为完全可预测
子观点 4.3：可检查性带来杠杆效应
通俗解释: 系统中越多东西能被 Agent 检查、验证和修改，效率杠杆越大。不只是一个 Agent 受益，所有在这个代码库上工作的 Agent 都受益。
观点五：强制执行架构和”品味”
大观点
通过强制不变量（invariants），而非微管理实现，让 Agent 既能快速交付又不破坏根基。
痛点: 光有文档不能保持全 Agent 生成的代码库的一致性。Agent 会”随意发挥”，导致架构腐化。
通俗解释: 就像管理一个大型工程组织——中央强制”边界和规则”，但在规则范围内允许自由发挥。就像交通法规规定”靠右行驶、限速60”，但不规定你具体怎么转方向盘。
子观点 5.1：刚性分层架构
解决路径:
- 每个业务领域划分为固定层级：Types → Config → Repo → Service → Runtime → UI
- 代码只能沿固定方向”向前依赖”
- 跨切面关注点（认证、连接器、遥测、特性开关）通过唯一的显式接口 Providers 进入
- 所有其他依赖方向被机械化禁止
通俗解释: 就像城市规划——住宅区、商业区、工业区有明确边界，你不能在住宅区盖工厂。每种区域有固定的”供给方向”（水电从哪来，污水往哪排）。
为什么重要: 这种架构通常是在有几百名工程师时才会做的事。但用 Agent 开发时，它是早期前提——约束才是速度不衰减的保障。
子观点 5.2：自定义 Linter + “品味不变量”
痛点: Agent 不天然具备团队的”品味”——什么样的代码算”好”、什么命名规范是对的。
解决路径:
- 用自定义 linter 和结构测试强制执行规则
- 静态强制：结构化日志、Schema/类型命名规范、文件大小限制、平台可靠性要求
- 关键技巧：自定义 lint 的错误信息本身就是修复指南——因为错误信息会被注入到 Agent 的上下文中
- 例子：要求在边界处”解析数据形状”（parse, don’t validate），但不指定用哪个库（Agent 自己选了 Zod）
子观点 5.3：允许风格差异
通俗解释: Agent 写的代码不一定符合人类的审美偏好，这没关系。只要正确、可维护、对未来 Agent 运行可读就行。就像每个人的笔迹不同，只要能辨认就行。
子观点 5.4：持续反馈品味
解决路径:
- 评审意见、重构 PR、用户发现的 bug 被捕获为文档更新或直接编码到工具中
- 当文档不够时，将规则提升为代码（即从”建议”变成”强制”）
观点六：高吞吐量改变了合并哲学
大观点
当 Agent 吞吐量远超人类注意力时，“纠正”比”等待”更便宜。
痛点: 传统工程规范（严格的合并门控、长生命周期的 PR、对测试 flake 零容忍）在高吞吐量环境下变成了反生产力。
通俗解释: 在传统开发中，一个 PR 要经过严格审批才能合并，就像机场安检一样。但当每天有几十个 PR 时，每个都严格审批会让整条流水线停滞。不如快速放行，出了问题快速修复——因为修复的成本很低（Agent 分分钟就能修）。
解决路径:
- 最小化阻塞性合并门控
- PR 保持短生命周期
- 测试 flake 用后续运行修复，而非无限阻塞
- 前提条件: 这在低吞吐量环境下是不负责任的；在高吞吐量+快速修复能力的环境下，是正确的权衡
观点七：“Agent 生成”意味着一切
大观点
不只是产品代码，连工具链、CI、文档、评审意见、管理仓库本身的脚本都是 Agent 生成的。
痛点: 人们往往以为”AI 写代码”只是写业务逻辑，但其实整个软件工程生态都可以由 Agent 产出。
Agent 产出清单:
- 产品代码和测试
- CI 配置和发布工具
- 内部开发者工具
- 文档和设计历史
- 评估工具链（Evaluation harnesses）
- 评审意见和回复
- 管理仓库自身的脚本
- 生产环境仪表盘定义文件
人类的新角色:
- 优先级排序
- 将用户反馈转化为验收标准
- 验证结果
- 当 Agent 挣扎时，识别缺失的工具/护栏/文档，让 Codex 自己写修复
观点八：不断提升的自主水平
大观点
当足够多的开发循环被编码到系统中后，Agent 可以端到端驱动一个新功能。
痛点: 早期 Agent 只能做”写一段代码”这样的小任务，无法独立完成从 bug 发现到修复上线的完整流程。
背景: 随着测试、验证、评审、反馈处理、故障恢复被逐步编码进系统，仓库跨越了一个有意义的门槛。
Agent 现在的完整能力链:
- 验证代码库当前状态
- 复现已报告的 bug
- 录制视频展示故障
- 实现修复
- 通过驱动应用验证修复
- 录制第二个视频展示修复效果
- 开 PR
- 响应 Agent 和人类的反馈
- 检测并修复构建失败
- 仅在需要人类判断时升级
- 合并变更
重要限制: 这严重依赖于这个特定仓库的结构和工具，不应假设可以直接推广——至少目前还不行。
观点九：熵增与”垃圾回收”
大观点
Agent 会复制仓库中已有的模式——包括不好的模式。不主动清理，代码库会不可避免地腐化。
痛点: Agent 没有”品味”——它看到一个不好的写法被用了3次，就会认为这是”正确模式”并继续复制。久而久之，坏模式像病毒一样扩散。
通俗解释: 就像复印机——如果原件有污点，每次复印都会带上这个污点，而且可能越来越糊。
子观点 9.1：人工清理不可扩展
痛点: 早期团队每周五（20%的工作时间）手动清理”AI 废代码”。
为什么失败: 不可扩展——代码量指数增长，人力线性增长。
子观点 9.2：“黄金原则”+ 自动化清理循环
解决路径:
- 将”黄金原则”直接编码到仓库中——机械性的、有明确意见的规则
- 例子： a. 优先使用共享工具包而非手写 helper（集中管理不变量） b. 不允许”YOLO 式”探测数据——必须验证边界或使用类型化 SDK
- 定期后台 Codex 任务： a. 扫描偏离规范的代码 b. 更新质量评分 c. 开针对性的重构 PR d. 大多数可以在1分钟内评审并自动合并
子观点 9.3：技术债 = 高利贷
通俗解释: 技术债就像信用卡债——不及时还就会利滚利。小额持续还款远好于攒到还不起时的痛苦大扫除。
解决路径:
- 人类品味捕获一次，持续执行于每一行代码
- 每天发现和修复坏模式，而非让它们扩散数天或数周
观点十：我们仍在学习的事情
大观点
这套方法目前有效，但长期可持续性仍是未知数。
开放性问题:
- 全 Agent 生成的系统中，架构一致性如何在数年尺度上演化？
- 人类判断在哪些环节提供最大杠杆？
- 如何编码人类判断使其能复利式增长？
- 随着模型能力持续提升，这套系统会如何演化？
核心结论
构建软件仍然需要纪律，但纪律体现在”脚手架”而非”代码”上。
通俗解释: 以前的纪律是”写干净的代码”，现在的纪律是”搭建好的环境”——工具、抽象、反馈循环。
最困难的挑战现在集中在：设计环境、反馈循环和控制系统，帮助 Agent 构建和维护复杂、可靠的大规模软件。
全文逻辑链总结
传统工程师写代码 ↓ Agent 能写代码了 痛点：工程师角色失焦，怎么让 Agent 高效工作？ ↓ 观点1：重新定义工程师角色 → 人掌舵，Agent 执行 ↓ Agent 写得快但人验不过来 观点2：提升应用可读性 → 让 Agent 自己验证（UI/日志/监控） ↓ Agent 需要知道”该怎么做” 观点3：仓库知识系统 → 地图式而非百科全书式的知识管理 ↓ Agent 看不到仓库外的信息 观点4：Agent 可读性 → 所有隐性知识显性化到仓库 ↓ 代码量爆炸，质量如何保持？ 观点5：强制架构和品味 → 刚性分层 + 自定义 Linter ↓ 传统流程成为瓶颈 观点6：合并哲学变革 → 纠正比等待便宜 ↓ Agent 能力逐步完整 观点7+8：全栈 Agent 生成 + 自主水平提升 → 端到端能力 ↓ 坏模式会扩散 观点9：熵增管理 → 自动化”垃圾回收” ↓ 长期可持续？ 观点10：开放问题 → 纪律从代码转移到脚手架