SRC-DEV-001：我用了 8 个月 Codex CLI，总结出这套 AI 编程工作流
来源基础信息
这份来源在讲什么
程序员HaiJun 在少数派发布的个人复盘文章，记录他在约 8 个月时间内把 Codex（AI 编程与自动化辅助工具） 放进真实软件开发流程的完整做法。文章的核心不是"用 Codex 一次生成一段代码"，而是怎样准备项目上下文、拆解需求、执行实现、测试、审查和复盘，使 Codex 能承担一段连续的工程工作。
来源的关键判断是：Codex 可以承担连续工程工作，但前提是用户提供明确规则、计划、测试和人工审查，而不是把仓库完全交给模型自由修改。
准备阶段（作者的做法）
- 检查 Codex 的模型、推理等级、沙箱和常用工具配置。
- 建立或更新项目说明文件（如
AGENTS.md），记录命令、目录结构、代码规范、测试要求和禁止事项，使新会话不必重新猜测项目规则。
- 接入 通过 MCP 接入外部工具（Model Context Protocol）（MCP），并准备 Skills 与快捷命令。
- 让 Agent 阅读仓库并主动提出澄清问题。
- 形成需求文档 + 技术方案 + 任务拆解。
实现阶段（作者的做法）
- 按计划逐步编码，把大需求拆成可单独验证的小任务。
- 每完成一段改动就运行单元测试、构建检查或页面验证（前端任务可用浏览器或 Playwright）。
- 查看 Git diff，检查遗漏、越界修改与业务约束。
- 由 Agent 或人工进行第二轮 review。
- 把稳定做法沉淀为 Skills、快捷命令或新的项目规则。
- 输出 Git diff 与变更总结。
输入、输出与适用对象
- 输入：现有代码仓库、项目规则文件、经过澄清的功能需求、可运行的测试或验证环境。
- 输出：需求文档 + 技术方案、分步实施计划、代码改动、测试结果、页面验证结果、Git diff 与变更总结。
- 适用对象：已经在维护真实项目、希望把 Codex CLI 接入日常开发流程的个人开发者和小团队。
作者写明的使用边界
- Codex 可能因为上下文过长而偏离目标。
- Codex 可能生成"能运行但不符合业务"的代码。
- 高风险权限与沙箱设置需要按项目调整，不能因为追求速度直接取消保护。
- 缓解手段：小步任务、频繁测试、重新开会话、保留计划文件、人工审查。
来源边界（重要）
"使用 8 个月"和公司项目实践均为作者自述；本文没有独立核验其公司项目的代码、提交记录或业务结果。这里记录的是作者公开描述的工作流，不把它扩写为 Codex 的普遍性能保证。模型名称、权限模式、客户端能力和命令可能在 2026-07-13 之后变化，使用时应再查看对应版本文档。
可串联的页面