用 Codex 改项目代码，我最怕的不是它不会写——说实话它的生成能力挺强的。真正让人头疼的是它改得太多了。

明明只让它修一个小 bug，结果它顺手帮你重构了变量命名、调整了目录结构、甚至改了配置文件。等你发现的时候，git diff 里一堆文件飘红，也不知道哪些是必须的、哪些是它自作主张。

我之前遇到过好几次这种情况。一开始以为是 Codex 本身不稳定，后来慢慢摸索出来——问题不全是工具，很多时候是我们给的任务边界太模糊了。它不像人一样能自动判断“这个能碰、那个不能动”，你不说清楚，它就按自己的理解来。

下面这 4 个提示词方法，是我自己用下来比较管用的。不一定每次都完美，但至少能把改动范围锁住。

方法1：先让 Codex 只读项目，不要马上修改

很多人一上来就扔给 Codex 一句话：“帮我改一下登录页面的样式”。然后 Codex 直接开始改，结果改完发现它把路由也动了，甚至帮你装了个新依赖。

这不是 Codex 故意的——它只是没有“先了解再动手”的习惯。我们需要主动让它先读代码。

我的做法是，第一轮对话只让它分析，不给修改权限：

“请先阅读相关文件，告诉我这个功能涉及哪些文件、当前逻辑是什么、你准备怎么改。暂时不要修改任何代码。”

这一步做完，你能看到它的理解对不对。如果它搞错了文件职责，你还有机会纠正，而不是等改完才发现方向偏了。

方法2：明确只允许修改哪些文件

这是最直接的一招——把允许修改的文件列表写进提示词。

Codex 在修改时会倾向于“保持一致性”，比如你改了组件，它可能觉得样式文件也得跟着调、工具函数也得优化一下。这个出发点是好的，但在实际项目里，很多代码我们暂时不想动。

我的提示词通常长这样：

“这次只允许修改 src/components/xxx 和 src/styles/xxx，不要修改路由、配置文件、package.json，也不要重构无关代码。”

加了这句话之后，Codex 越界的概率明显下降。它有时候还会在回答里确认一遍“我只修改了指定文件”，这本身就是个好的信号。

方法3：要求它先列修改计划，再等确认

这个方法适合稍微复杂一点的任务——比如页面性能优化、接口字段调整、登录状态逻辑修复。

如果直接让它改，你很难预判它会动哪些地方。不如让它先把方案摆出来，你过一遍再放行。

我常用的说法：

“先给我一个修改计划，列出每一步要改哪里、为什么改、可能影响什么。等我确认后再执行。”

这个做法的额外好处是：你能在计划阶段就发现它准备“顺手优化”的东西。比如它可能会在计划里写“顺便调整一下 hooks 的依赖项”——你完全可以选择性拒绝。

方法4：改完后让它输出变更说明和自查清单

改完了不等于结束了。Codex 自己觉得改完了，但它可能没意识到某些改动会影响到别的页面。

我会在最后让它做一件事：

“修改完成后，请列出本次改动的文件、每个文件改了什么、有没有影响其他功能、我应该重点测试哪些地方。”

这份清单可以直接对照着做回归测试。万一改出问题了，你也知道从哪开始排查，不用满项目找 diff。

---

补充一句：Plus 和 Pro 怎么选？

这个顺便聊一下，因为确实经常有人问。

如果你只是偶尔让 ChatGPT 写文案、改小段代码、做一些零散的问答，Plus 完全够用。

但如果你像我一样，经常让 Codex 连续处理项目级任务——多文件修改、反复调试、长上下文对话——那 Pro 的价值主要体现在额度和连续工作流上，不用频繁切号或等额度重置。

不过这个真的看个人使用习惯。不用盲目上 Pro，先看看自己每周的对话量和任务类型再决定更稳妥。

---

总结一下

Codex 改偏这件事，我现在的看法是：大部分情况不是工具差，而是任务边界没说清楚。

“先读、限文件、列计划、做自查”这四步，本质上不是在限制 Codex，而是在帮它理解你到底要什么。养成这个习惯之后，返工的次数确实少了很多。

我主页会继续整理 ChatGPT Plus / Pro / Codex 的实际使用记录、订阅区别和避坑内容。如果你也在纠结 Plus、Pro 或 Codex 怎么用，可以先看这些记录再决定，不建议盲目升级。