Codex 自动化开发流程常见错误

Codex 能把很多开发动作串起来，但新手常常把“能执行”误解成“能交付”。一次看似顺利的自动化开发，如果没有需求边界、工作区检查、验证命令和交付记录，后面很容易出现返工、误删、误改或客户无法验收。

这篇草稿整理常见错误和修正方式。建议配合 流程检查清单、项目范围判断 和 /tools/error-explainer 使用。

适合谁

适合已经开始用 Codex 改代码，但经常遇到“不知道它改了哪里”“build 过不了”“客户说不是这个需求”的新手。

也适合准备把 Codex 纳入项目流程的人。提前知道错误模式，比出问题后补救更省时间。

不适合谁

不适合处理高风险生产任务的新手。数据库迁移、付款流程、账号权限、客户隐私和安全修复，都不应该靠一份新手文章直接上手。

也不适合希望完全不读代码的人。Codex 可以协助，但你至少要理解修改目标、变更文件和验证结果。

具体步骤

1. 先复述需求，不清楚就追问。
2. 修改前看工作区状态和相关文件。
3. 每次只处理一个小范围目标。
4. 让 Codex 解释将要修改的地方。
5. 修改后看 diff，不理解就暂停。
6. 跑验证命令，失败就记录原因。
7. 交付前写清已做、未做和客户待确认。

常见错误

错误一：客户需求只有一句话就开始改。比如“帮我做个自动化”，你还不知道输入、输出、触发条件和失败处理，就让 Codex 写代码，结果很可能偏题。

错误二：没有看 git status。仓库里可能已有客户改动、生成文件或上一次未提交内容。你如果直接修改，很容易把无关变更混进交付。

错误三：盲目执行命令。安装、删除、迁移、清理缓存、修改配置都可能带来影响。新手应该先理解命令目的，再执行。

错误四：只看工具说完成，不跑项目检查。工具输出不能替代 lint、build、测试、页面截图和人工验收。

错误五：没有交付说明。客户不知道你做了什么，也不知道怎么验收，后面就会继续追加问题。

解决流程

遇到错误时，先缩小范围。不要让 Codex 连续做五个方向的修改。先回到最近一次可解释的 diff，确认问题来自需求不清、命令失败、代码逻辑，还是验证方式不对。

如果你已经改乱了，先不要继续扩散。记录当前状态、失败命令和错误输出，再决定是修复、回退自己的改动，还是向客户说明需要补材料。

停止条件

如果任务涉及生产数据、真实账号、客户密钥、付款配置、权限提升或不可逆操作，应立即暂停。把它写进风险记录，等待人工确认。

如果你无法解释某个 diff，也不要提交。能说清为什么改，比看起来改得快更重要。

修正习惯

新手可以给自己定一个固定节奏：每完成一个小改动，就先看 diff；每跑一个命令，就记录结果；每遇到失败，就先保存错误原文，不要急着让工具继续猜。这个节奏会让你慢一点，但能减少“越修越乱”的情况。

如果客户项目比较急，也不要跳过这些动作。你可以缩小交付范围，比如先做诊断报告、先修一个明确报错、先处理一页样例，而不是把所有不确定问题一次性承诺下来。

复盘记录

每次出错后都应该留下很短的复盘记录：错误发生在需求确认、文件选择、命令执行、验证方式，还是交付沟通。不要只写“已修复”，要写清楚为什么会错、下次用什么检查动作提前发现。几次记录积累下来，你会看到自己的高频失误，比如总是忘记看 diff、总是低估验收时间，或者总是把客户一句模糊描述当成完整需求。

复盘记录也可以反过来帮助报价。一个任务如果需要多轮确认、样例数据清洗、失败重试和人工审核，就不应该按“改一行代码”的价格处理。把风险写清楚，既能保护自己，也能让客户知道哪些步骤是在减少返工，而不是在拖延时间。

风险提醒

不要把 Codex 生成的内容当成最终责任转移。客户项目是你接的，工具只是辅助。每一次交付都要有人工判断。

不要承诺工具能稳定解决所有问题。不同项目依赖、框架、环境和客户验收标准差异很大，必须按当前项目验证。

免责声明

本文仅供学习和排查参考，不构成安全、法律或平台合规建议。真实项目应根据授权、环境和验证结果处理，发布前请人工复核案例。

CTA：接任务前先用 /templates 写检查记录；遇到报错用 /tools/error-explainer 拆原因；客户沟通用 /tools/proposal-generator 起草后人工复核。