Codex 中转介绍
📚 AI 原生开发流程
用 Codex 重塑软件开发全流程 — 规划、设计、构建、测试、审查、文档、部署 7 阶段全覆盖。
AI 不再只是写函数的小工具。本页梳理软件开发 7 个核心阶段，每个阶段说清楚 Codex 能做什么、工程师该做什么，帮你把 AI 真正融进工作流，而不是只用它来"写代码"。
背景：AI 能干的活越来越多了
过去一年，AI 编码助手从"补全单行"演进到"接管整个工作流"：
- 能 plan 多步任务、跨文件改造
- 能调用 Shell / MCP 操作外部世界
- 能跑测试、读 diff、写文档
- 能审 PR、起草 release notes
意义：开发者的核心价值正在从"亲手敲代码"转向"决定方向 + 把关结果"。下面是 7 个阶段的分工建议。
1. 规划阶段
Codex 能做什么
- 把模糊需求拆解成可执行任务清单
- 分析现有代码库结构，定位影响范围
- 估算工作量，识别潜在风险点
- 起草 PRD / 技术方案初稿
> 我们要给现有 KV 缓存层加 LRU 淘汰，
> 先告诉我影响哪些文件、需要分几步、有什么风险，
> 不要写代码。
工程师做什么
- 提供业务上下文和约束条件（哪些不能改、哪些是优先项）
- 审 Codex 的拆解清单，挑出遗漏的边界场景
- 做取舍决策（性能 vs 简洁、兼容 vs 重构）
- 最终拍板"按这个方向干"
2. 设计阶段
Codex 能做什么
- 起草 API 接口设计（OpenAPI / GraphQL schema）
- 画 ER 图 / 时序图 / 架构图（Mermaid 输出）
- 对比多种方案的 tradeoff
- 检查设计与现有代码的一致性
> 给登录加 2FA。出 3 个方案，分别用：
> A. TOTP（如 Google Authenticator）
> B. SMS 验证码
> C. WebAuthn
> 每个方案给：实现复杂度、用户体验、安全等级、上线周期
工程师做什么
- 选定方案、明确接口契约
- 把方案对齐到团队架构原则（哪些事不能做）
- Review 边界条件（错误处理、并发、回滚）
3. 构建阶段
Codex 能做什么
- 按方案写代码、自动维护多文件改动
- 复用现有工具函数、保持代码风格一致
- 跑 build / lint / typecheck 自检
- 提交前自动整理 commit message
> 按上面 TOTP 方案实现，遵循 @AGENTS.md 的规范，
> 写完跑 npm test 和 npm run lint，全过了再停。
工程师做什么
- 监督关键决策（命名、抽象层级）
- 复审复杂模块（鉴权、并发、状态机）
- 处理 Codex 卡壳的地方（生僻库、复杂业务规则）
- 把控安全敏感代码（密钥处理、权限校验）
4. 测试阶段
Codex 能做什么
- 按代码自动生成单测、集成测试
- 补充边界条件、错误路径覆盖
- 生成测试数据 / fixture
- 跑测试套件、修复失败的测试
> @src/auth/totp.ts 这个文件还没有测试。
> 写 vitest 测试覆盖：
> 1. 正常流程
> 2. 时间窗口边界（±30s）
> 3. 重放攻击防护
> 4. secret 泄露场景
工程师做什么
- 决定测什么 / 不测什么（覆盖率优先级）
- Review 测试用例的合理性（是不是测的真问题）
- 维护测试数据（脱敏 / 合规）
- 决定 flake test 的去留
5. 代码审查阶段
Codex 能做什么
- 跑预 review（找明显 bug、安全问题、性能瓶颈）
- 检查与
AGENTS.md规范的一致性 - 起草 review 评论
- CI 里自动 review PR（见 auto-review）
> /review main..HEAD
> 重点检查：
> - 鉴权逻辑有没有绕过
> - SQL 注入风险
> - N+1 查询
> - 错误处理是否完整
工程师做什么
- Review 业务正确性（Codex 不一定懂业务）
- 评估架构层面的合理性
- 把控团队风格 / 价值观（哪些 patterns 不要进 codebase）
- 与作者沟通、教导新人
6. 文档阶段
Codex 能做什么
- 根据代码生成 API 文档 / SDK 用法
- 写 changelog / release notes
- 更新 README / 架构文档
- 翻译文档（中英互译）
> 看 @src/api/user.ts 的接口变更，
> 更新 docs/api/user.md，
> 并在 CHANGELOG.md 顶部加一条 [BREAKING] 说明。
工程师做什么
- 决定写什么文档（不是所有事都需要文档）
- 把控叙事节奏和读者视角
- 校对技术细节
- 维护核心文档的长期一致性
7. 部署与运维阶段
Codex 能做什么
- 起草 CI/CD pipeline 配置
- 写 Dockerfile / k8s manifest
- 生成监控告警规则
- 分析故障日志、起草 RCA（Root Cause Analysis）
- 起草 incident response runbook
> 服务今早 10:23 - 10:47 间 500 率飙到 30%。
> 看 @logs/error-2026-05-18.log，
> 分析根因 + 写一份初版 RCA。
工程师做什么
- 审 deployment 配置（资源、权限、网络）
- 决定故障响应优先级（影响面、紧急程度）
- 沟通对外（用户、合作方、监管）
- 总结复盘、推动改进
总结：哪些交给代理，哪些留给自己
| 维度 | 交给 Codex | 留给自己 |
|---|---|---|
| 机械重复工作 | ✅ | — |
| 模板化产出（测试、文档、CI） | ✅ | — |
| 跨文件改动 / 重构 | ✅ | — |
| 代码补全 / 写新功能 | ✅ | 复杂业务规则 |
| 业务理解 / 优先级判断 | — | ✅ |
| 架构决策 / 取舍权衡 | — | ✅ |
| 安全敏感代码 | 起草 | ✅ 审核 |
| 对外沟通 / 跨团队协作 | — | ✅ |
| 故障响应判断 | 数据分析 | ✅ 决策 |
三个判断原则
重复性高 → 给 Codex
做过 2-3 次的事，封装 Skill / Hook 让 Codex 接手
风险高 → 自己把关
影响线上、涉及钱、涉及隐私的，必须人审最后一道
方向 / 价值 → 自己定
做什么、为什么做、做到什么程度，永远是人的判断
核心心态调整：不是「我会被 AI 取代吗」，而是「我能驾驭 AI 把团队产能放大 5 倍吗」。把 AI 当队友配置、维护、训练。时间越长，它对你项目和团队风格的理解越深，结果会越来越好。