Appearance
用 AI 重塑软件开发全流程
本文整理自 OpenAI 官方指南：Build an AI-native engineering team，分享 AI 编码代理如何在软件开发生命周期的每个阶段发挥作用，以及工程师可以采取的实际行动。
背景：AI 能干的活越来越多了
截至 2025 年 8 月，顶级 AI 模型已经能以约 50% 的置信度完成长达 2 小时 17 分钟的连续工作，而且这个时长大约每七个月翻一番。
几年前模型只能处理 30 秒的推理，够做代码补全。现在，整个软件开发周期——规划、设计、开发、测试、代码审查、部署——AI 都能真正参与进来了。
在 OpenAI 内部，过去需要几周才能完成的工作现在几天就能交付。很多例行工作（写文档、写测试、维护依赖、清理 feature flag）已经完全交给 Codex 处理。
1. 规划阶段
过去的痛点：评估功能可行性、拆解工作范围，需要工程师深入翻代码库，还要跟各方开多轮对齐会议。
Codex 能做什么
- 读取功能规格，跟代码库交叉比对，自动标出模糊点和依赖关系
- 把工作拆成子任务，估算难度
- 追踪某个功能涉及哪些服务——以前这个工作可能要花几小时手动挖代码，现在几秒出结果
工程师做什么
代理负责初步的可行性分析；团队负责审核结果的准确性、评估风险、做最终的优先级和方向决策。
起步清单：
- 找出哪些流程需要把功能描述和代码库对齐（比如功能范围确认、工单拆解）
- 先从简单的工作流开始，比如自动标记重复需求
- 进阶：让代理在工单进入某个阶段时自动补充更多细节
2. 设计阶段
过去的痛点：原型搭建慢，设计稿和实现之间总有落差，需要多轮返工。
Codex 能做什么
- 接受自然语言描述，直接生成符合团队规范的组件骨架或原型代码
- 把设计稿转成代码，提出可访问性改进建议
- 分析代码库中的用户流程和边缘情况
原来几天才能出的原型，现在几小时就能迭代多版。设计师可以把更多时间放在评估用户体验上，而不是等实现落地。
工程师做什么
代理负责初始实现和模板搭建；团队负责审核组件质量、无障碍标准、系统集成；架构决策和整体用户体验方向仍由人来掌舵。
起步清单：
- 使用支持图片输入的多模态编码代理（可以直接丢设计稿进去）
- 通过 MCP 把设计工具和编码代理打通
- 用 TypeScript 等有类型的语言来约束代理生成的组件属性
3. 构建阶段
过去的痛点：这是工程师最累的阶段——把规格变成代码、跨文件复制模式、填写模板代码，哪怕一个小功能也可能要好几个小时的体力活。
Codex 能做什么
- 根据书面规格，一次性生成从数据模型、API、UI 组件到测试和文档的完整功能
- 在几十个文件里搜索和修改代码，保持一致性
- 遇到构建错误时自动修复，不需要暂停等人
- 生成符合内部规范的 PR，附带 commit message
Cloudwalk 案例：工程师、PM、设计师每天都在用 Codex 把规格变成可运行的代码——一个脚本、一条新的风控规则、或者一整个微服务，几分钟搞定。
工程师做什么
代理负责第一遍实现；工程师转变为审查者、编辑者和方向把控者——专注于架构合理性、业务逻辑正确性、性能关键路径，以及那些真正需要深度判断的部分。
起步清单：
- 从描述清晰的任务开始
- 让代理通过 MCP 或 PLAN.md 先做规划，再动手
- 检查代理执行的命令是否都在正常跑通
- 持续迭代 AGENTS.md，把"跑测试"、"跑 Lint"这类反馈循环配置好
4. 测试阶段
过去的痛点：写测试耗时、上下文切换频繁，赶 deadline 时测试覆盖率往往是第一个被牺牲的。
Codex 能做什么
- 读需求文档和功能代码，自动建议测试用例——包括开发者容易忽略的边缘情况
- 随着代码演进自动更新测试，减少脆弱测试的积累
工程师做什么
测试不是能被代理完全替代的——恰恰相反，随着代理能跑测试并根据结果迭代，写好测试变得比以前更重要。定义高质量测试，往往是让代理成功构建功能的第一步。
工程师更多关注测试覆盖的整体模式，审查代理是否走了捷径（比如写了空实现或假断言）。
起步清单：
- 让代理在单独的会话里生成测试，先确认新测试会失败，再做功能实现（TDD 流程）
- 在 AGENTS.md 里写明测试覆盖要求
- 给代理提供代码覆盖率工具，让它知道覆盖率现状
5. 代码审查阶段
过去的痛点：平均每周花 2-5 小时做代码审查。时间压力下，很多 PR 只是走个过场，导致 bug 溜进生产。
Codex 能做什么
- 给每个 PR 提供一致的基础审查，不会因为时间紧就偷懒
- 不只是静态规则匹配——可以执行代码、追踪跨文件的逻辑，发现真正的问题
Sansan 案例：用 Codex 审查竞态条件和数据库关联关系（这类问题人工很容易漏掉），还能发现不当的硬编码，甚至预见到未来的扩展性问题。
在 OpenAI 内部，Codex 审查了 100% 的 PR，让工程师在提交给同事前就能发现并修掉问题。
工程师做什么
工程师委托代理做第一遍审查；自己的审查重心转向架构对齐、可组合性、功能是否符合需求——最终 merge 的责任还是在人。
起步清单：
- 整理一批高质量 PR（包含代码和 review 评论）作为评估基准
- 选专门针对代码审查训练过的模型，通用模型信噪比太低
- 定义审查质量的衡量指标，推荐用"评论是否被采纳"来低摩擦地打标
6. 文档阶段
过去的痛点：文档欠债严重，追平成本高；关键知识存在个人脑子里；文档写完就开始过时。
Codex 能做什么
- 读代码库，自动生成功能说明、模块概述、系统架构图（支持 Mermaid 语法）
- 在构建功能时顺手更新文档，而不是事后专门补
- 接入发布流程，自动总结这次发版包含哪些关键变更
在 AGENTS.md 里加上"需要时更新文档"的指令，文档维护就变成了每次代理运行的标配。
工程师做什么
工程师从"亲手写每一篇文档"变成"设计文档体系、审查关键文档、把控质量标准"。低风险的内容（模块概述、输入输出说明、PR 摘要）可以全部交给代理；核心服务、公开 API、Runbook 等文档由工程师审核后再发布。
起步清单：
- 先直接提示代理生成文档，看看质量如何
- 把文档规范加进 AGENTS.md
- 识别哪些工作流（比如发版周期）可以自动触发文档生成
7. 部署与运维阶段
过去的痛点：发生故障时，工程师需要在日志工具、代码、部署记录之间来回切换，手动关联信息，既耗时又容易出错。
Codex 能做什么
通过 MCP 把日志工具和代码库都接入代理，工程师只需一个提示词："帮我看看这个接口最近的报错"——代理会：
- 查看日志
- 在代码库里追踪相关代码
- 翻 git 历史，找出可能引入问题的变更
Virgin Atlantic 案例：通过 VS Code 插件 + Azure DevOps MCP + Databricks MCP，工程师在 IDE 里就能完成日志分析、跨代码追踪、变更审查，大幅缩短了故障定位时间。
工程师做什么
代理负责日志解析、异常指标上报、可疑变更识别，甚至生成初步修复方案；工程师负责验证诊断结果、确认修复方案符合可靠性和安全要求；高风险的生产变更，最终决策仍由人来做。
起步清单：
- 通过 MCP 把日志和部署系统接入 Codex
- 设置访问权限范围，确保代理能读日志和代码历史，但保持安全边界
- 建几个常用的提示词模板，比如"分析 X 接口的报错"、"排查部署后的日志异常"
- 用模拟故障场景测试工作流，再推到真实场景
总结：哪些交给代理，哪些留给自己
| 阶段 | 代理做 | 工程师做 |
|---|---|---|
| 规划 | 可行性分析、工作拆解、依赖追踪 | 优先级决策、方向判断 |
| 设计 | 组件搭建、原型生成、设计转代码 | 架构决策、用户体验方向 |
| 构建 | 第一遍实现、跨文件修改、错误修复 | 架构审查、业务逻辑把控 |
| 测试 | 生成测试用例、更新测试 | 测试策略、审查覆盖质量 |
| 审查 | 初步代码审查 | 最终审查、merge 决策 |
| 文档 | 生成初稿、更新文档 | 审核关键文档、制定规范 |
| 运维 | 日志分析、故障定位 | 验证诊断、高风险决策 |
不需要一次性改造全部流程——从一个环节开始，跑通之后再扩展。团队越早建立起"代理是第一遍实现者、工程师是审查者"的协作模式，积累的收益就越大。