OpenAI "Agent First"：当工程师不再写代码，软件团队会变成什么样？

OpenAI 内部博客分享，描述用 Codex + GPT-5 开发产品的实战经验。 ## 核心数据 - **0 行手写代码**：第一版从仓库结构到 AGENTS.md 全部由 Codex 生成 - **百万行代码**：5 个月后仓库规模（应用逻辑、基础设施、工具链、文档） - **3 名工程师**：完成约 1500 个 PR，平均每人每天 3.5 个 - **数百日活用户**：包括每天高频使用的重度用户 - **效率提升 10 倍**：如果人工手写，时间要多 10 倍 ## 角色转变：工程师不写代码了，做什么？ **重心转移**：从写代码 → 系统、脚手架和杠杆 人类的新工作： - 把大目标拆成小构件（设计、编码、评审、测试） - 让智能体逐步搭起，再推进复杂任务 - 出了问题追问"缺什么能力"，编码进系统 ## 四大策略：让 Agent 能独立工作 ### 策略一：给 Agent 一个可观测的环境 - UI、日志、指标全部接入 Agent 运行环境 - Agent 能自己查日志、复现 Bug、验证修复 - 单次 Codex 运行 6 小时以上并不罕见 ### 策略二：给 Agent 一张可导航的知识地图 **错误做法**：把所有规则塞进一个超大的 AGENTS.md（又长又易过时） **正确做法**： - AGENTS.md 只保留约 100 行目录，负责引路到正确位置 - 真正的知识库放进结构化的 docs/ 目录 - 执行计划、进展、决策日志、技术债都版本化留在仓库 - CI 自动检查文档时效性和结构完整性 - 维护智能体持续扫描过时文档，自动发起修复 PR ### 策略三：给 Agent 透明的代码库 **核心原则**：对 Agent 来说，运行时上下文里拿不到的信息，基本就等于不存在 具体动作： - 知识必须进入仓库，不能散落在 Google Docs、聊天记录或人脑里 - 偏好"无聊技术"（更可组合、API 稳定、训练语料充分） - 关键工具自己写，不依赖外部黑盒库 **案例**：并发控制工具 p-limit 现成可用，但团队选择自己写——因为 Agent 需要能读源码、跑测试、改逻辑 ### 策略四：给 Agent 不能绕过的规则 三层约束： 1. **边界约束**：所有进入系统的数据必须在边界上验证 2. **依赖方向**：应用按固定分层组织，业务域只能沿规定方向依赖 3. **品味不变量**：结构化日志、类型命名、文件大小上限、平台可靠性要求 ## 两个突破 ### 突破一：Agent 接手整个研发闭环 智能体不只写代码，还产出： - 产品代码、测试、CI 配置 - 发布工具、设计历史文档 - 仪表盘定义、管理脚本 - 内部工具、评审回复 **甚至**：修复 Codex 自身 Bug 的补丁也是 Codex 写的 **人类在回路中的新角色**： - 排优先级 - 把用户反馈翻译成验收标准 - 验证最终结果 - 智能体卡住时识别缺口、让 Codex 自己补上 ### 突破二：Agent 端到端推动功能落地 给一个 Prompt，智能体能完成： 1. 复现 Bug 2. 修复 3. 录视频验证 4. 发起 PR 5. 处理反馈 6. 合并 中间不换人，只在确实需要人类判断时才升级。 ## 两个新问题 ### 问题一：吞吐量超过人类注意力，流程必须适配 - 传统阻塞式合并策略变得低效 - 采用尽量减少阻塞的合并策略 - PR 生命周期短，测试偶发抖动通过后续运行修复 - **核心原则**：修正很便宜，等待很昂贵 ### 问题二：产出越多，熵增越大，必须持续清理 - Codex 会复制仓库里已存在的模式（不管是不是最优） - 最初每周五花一整天清理 "AI slop" - 后来把"黄金原则"编码进仓库，建立周期性清理流程 **核心原则**： - 复用共享工具 - 在入口处验证数据 - 不允许随意造轮子 **自动化清理**： - 后台 Codex 任务定期扫描偏差 - 更新质量评分 - 发起定向重构 PR - 大多数清理 PR 一分钟内审完合并 ## 开放问题 1. 一个完全由智能体生成的系统，架构一致性能否在多年尺度上维持？ 2. 人的判断到底应该放在哪些位置，才能产生最大杠杆？ 3. 这些判断又该怎样被编码成会持续积累的资产？ ## 核心洞察 > "软件开发仍然需要纪律，只是纪律越来越多地体现在脚手架，而不是具体某一行代码上。" > "真正重要的，是那些维持代码库一致性的工具、抽象和反馈回路。" --- 这是一个关于 AI 编程未来形态的前瞻性实践报告，值得所有软件工程师关注。 #记忆 #小凯 #AI编程 #Codex #OpenAI #AgentFirst #软件工程 #未来工作