第一次让 Codex 改代码：从只读分析到安全小改

第一次让 Codex 参与项目，最重要的不是改得多，而是建立一个你能看懂、能检查、也能撤回的完整过程。一个小而清楚的任务，往往比一句“帮我优化整个项目”更容易得到可靠结果。

先选一个适合练习的小任务

理想的第一次任务应当同时满足几个条件：只涉及少量文件；结果可以直接观察；不会修改生产数据；即使失败也容易恢复；你自己能够判断做得对不对。

• 修改一段提示文字或按钮名称；
• 给已有表单增加一条明确的校验提示；
• 修复一个可以稳定复现的小问题；
• 为现有函数补一个简单测试。

不要把数据库重构、支付流程、权限体系或大面积升级作为第一次尝试。这些任务并非不能做，而是需要更多上下文和更严格的验证。

第一步只让它阅读

先请 Codex 找出相关入口、数据流和可能涉及的文件，并明确要求暂时不要修改。阅读阶段的目标，是确认它理解的范围和你的判断一致。

请先定位这个页面对应的控制器、模板和样式，说明当前流程以及你预计需要修改的文件。现在只分析，不要改动。

如果分析结果提到了不相关模块，应该立刻缩小范围；如果遗漏关键文件，就补充背景后再继续。

把目标写成可检查的结果

一个好任务至少应包含目标、范围、约束和验收四部分。例如：在登录页修改验证码失败提示；只允许改登录相关前后端文件；沿用站内现有消息样式；输入错误验证码时必须显示中文错误且页面不刷新。

修改完成后检查三件事

1. 文件范围：实际修改的文件是否都与任务有关。
2. 代码差异：有没有删除原有逻辑、写死配置或引入临时代码。
3. 验证结果：语法检查、自动化测试和人工操作是否覆盖了目标场景。

当这三项都有明确证据，第一次任务才算真正完成。以后再逐步增加任务规模，你会更容易判断 Codex 在哪里可靠、哪里需要补充约束。

完成前快速清单

• 我能用一句话说明完成后的结果；
• 我知道允许修改哪些区域；
• 我看过完整差异，而不只是最终页面；
• 我执行了与风险相匹配的验证；
• 出现问题时有可用的回退方式。