使用 Codex 修改代码时，真正让人担心的通常不是“它会不会写代码”，而是“它会不会顺手改掉不该动的东西”。一个看似简单的需求，可能牵涉多个目录、配置文件和依赖关系。如果任务边界没有说清楚，Codex 可能基于自己的理解扩大修改范围；如果仓库本来就有未提交的改动，还可能把用户正在进行的工作混在一起。

好消息是，文件被乱改并不是一个只能靠运气避免的问题。只要把任务约束、检查步骤和验收方式设计好，就能显著降低误改风险。下面介绍五个实用方法，既适合个人项目，也适合多人协作的正式代码仓库。

一、先划定修改范围，不要只描述最终效果

很多人给 Codex 下指令时，只会说最终想得到什么，例如：

把登录页面优化一下，并修复相关问题。

这句话对人来说似乎已经足够，但对代码代理而言，“相关问题”的范围非常模糊。它可能修改登录组件，也可能继续调整路由、接口、全局样式，甚至更换依赖。需求越抽象，代理自行解释的空间就越大。

更稳妥的写法，是同时说明“可以改什么”和“不能改什么”：

只修改 src/pages/Login.tsx 和对应测试文件。
修复登录按钮重复提交的问题，不调整页面视觉样式，
不修改接口协议，不升级依赖，也不要改动其他目录。
如果发现必须修改范围外的文件，先说明原因，不要直接操作。

这样的指令包含四类关键信息：

1. 目标文件：明确允许编辑的位置。
2. 行为目标：说明需要解决的具体问题。
3. 禁止事项：排除样式、依赖、接口等非目标变更。
4. 越界规则：遇到范围外需求时先报告，而不是自行扩张任务。

如果暂时不知道具体文件名，也可以先让 Codex 只做调查：

先定位这个问题涉及的文件并说明原因，此阶段不要修改任何文件。
等我确认方案后再开始实现。

这相当于把“分析”和“执行”拆成两个阶段。对于陌生仓库、核心业务和高风险配置，这种方式尤其有效。

二、开始前检查工作区，区分旧改动与本次改动

Codex 进入一个项目时，工作区不一定是干净的。里面可能有尚未提交的代码、临时调试内容，或者其他人刚生成的文件。如果不先确认状态，本次修改就容易与原有改动混在一起。

开始任务前，可以要求它执行并说明以下检查：

git status --short
git diff --stat
git diff
git diff --cached

这些命令分别帮助确认：

• 哪些文件已经被修改、新增或删除；
• 当前改动的整体规模；
• 尚未暂存的具体改动；
• 已经暂存、准备提交的具体改动。

检查的重点不是机械地要求“工作区必须干净”，而是建立清晰的归属：哪些变更在任务开始前就存在，哪些变更由本次任务产生。

可以直接使用下面的提示词：

开始前先检查 Git 工作区。已有改动都视为用户的工作，
不得覆盖、删除或回退。请说明本次任务预计修改哪些文件，
确认后再实施。

如果仓库没有使用 Git，也应先列出目标目录，并读取相关文件内容。虽然缺少版本差异工具，但仍然可以通过“修改前记录文件列表”和“修改后重新核对”的方式控制范围。

特别需要警惕的是回退命令。诸如 git reset --hard、git checkout -- 文件名 等操作可能直接抹掉未提交内容。除非用户明确要求，否则不应让 Codex 用这类命令“清理现场”。遇到已有改动时，正确做法通常是保留它们，并围绕现状继续工作。

三、坚持最小修改原则，让每一处变更都有理由

修复一个问题时，最安全的改动通常不是最“漂亮”的改动，而是能准确解决问题、同时影响范围最小的改动。

例如，用户只是要求修复一个空值判断，Codex 却顺便完成了以下事情：

• 重命名多个变量；
• 调整整个文件的格式；
• 抽取新的公共函数；
• 更新无关注释；
• 改写附近的旧逻辑。

这些修改单独看未必错误，但会增加审查成本，也会扩大回归风险。更麻烦的是，真正的修复可能被淹没在大量无关差异中。

因此，可以明确要求：

采用最小修改方案。不要做顺手重构，不要批量格式化，
不要重命名无关变量。每个被修改的文件都必须直接服务于本次需求。

最小修改原则并不等于拒绝所有重构。如果现有结构确实使修复无法可靠完成，可以重构，但要满足两个条件：

1. 重构与问题之间存在直接、可解释的关系；
2. 在动手前说明必要性、影响范围和替代方案。

还要注意自动格式化工具。有些项目的格式化命令会扫描整个仓库，一次产生上百处变化。更稳妥的方式是只格式化本次编辑的文件，或者使用项目已有的针对性命令。例如，与其运行全仓库格式化，不如只对目标文件执行格式检查。

判断一次修改是否足够克制，可以问三个问题：

• 删除这处变更后，需求还能正常完成吗？
• 这处变更是否影响了任务范围外的行为？
• 审查者能否快速看出它与需求的关系？

如果第一题答案是“能”，那么这处修改很可能没有必要。

四、修改后审查差异，不要只听结果描述

Codex 完成任务后，常会给出一段总结，例如“已修复登录问题并补充测试”。总结可以帮助理解，但不能替代实际差异审查。判断它有没有乱改文件，最可靠的证据仍然是文件清单和代码差异。

建议在任务结束前要求它完成以下核对：

git status --short
git diff --stat
git diff --check
git diff

其中，git diff --check 可以发现部分空白字符错误；git diff --stat 能快速暴露异常规模，例如一个小修复却改动了几十个文件。

审查时应重点关注四件事：

1. 文件数量是否合理

一个局部按钮问题通常不应触及数据库迁移、构建配置或依赖锁文件。出现意外文件时，要让 Codex 逐一解释。

2. 是否有大面积格式变化

如果业务改动只有几行，但整个文件都显示变化，可能是换行符、编码或格式化规则发生了改变。这类差异不仅难审查，还可能引发跨平台问题。

3. 是否删除了原有逻辑

特别检查条件分支、错误处理、权限判断和兼容代码。代理有时会为了让新逻辑更简洁而移除它认为“多余”的部分，但那些代码可能承载尚未写进测试的业务规则。

4. 是否生成了不该提交的文件

测试缓存、构建产物、日志、截图和临时文件都可能出现在工作区。它们未必属于正式变更，应根据项目规则处理，而不是默认全部保留。

一个实用的结束指令是：

完成后列出所有改动文件，并分别说明修改原因。
再检查实际差异，确认没有范围外变更、批量格式化、
临时文件或对用户原有改动的覆盖。

这会迫使最终说明与真实文件状态对应起来，减少“总结很正确，差异却失控”的情况。

五、用测试和可回滚节点约束修改过程

防止乱改文件不仅要控制“改了哪里”，还要验证“改完是否真的正确”。如果没有验证，Codex 可能为了让表面现象消失而改变其他行为，最终形成隐蔽的回归。

测试应与改动风险匹配：

• 修改纯文本或独立配置时，可进行语法检查和目标文件核对；
• 修改单个函数时，应运行对应单元测试；
• 修改共享组件或公共接口时，应扩大到相关模块测试；
• 修改核心流程时，应增加集成测试或端到端验证。

不要只说“运行测试”，而要让 Codex 先找出项目现有的测试入口，例如查看 package.json、构建脚本或项目文档。这样能避免它凭习惯编造命令，或运行与项目无关的检查。

对于较大的任务，还可以将工作拆成可审查的小节点：

1. 定位问题并提交分析，不改文件；
2. 修改核心逻辑，展示差异；
3. 补充测试，展示新增用例；
4. 运行验证，汇报结果；
5. 最后检查全部文件状态。

每完成一个节点，就能确认修改方向是否正确。即使后续方案需要调整，也只需回看有限范围，而不是面对一次性产生的大量改动。

这里的“可回滚”不代表可以随意执行破坏性 Git 命令，而是要保留清晰的变更边界。最理想的状态是：每一步都有明确目的，每一批差异都能独立审查，出现问题时也能准确识别需要撤销的部分。

一套可以直接使用的安全提示词

如果不想每次重新组织语言，可以在给出具体任务后附上这段约束：

请按以下规则完成任务：

1. 开始前检查工作区，保留所有已有改动，不得覆盖或回退。
2. 先说明预计修改的文件及原因，再开始编辑。
3. 只修改与需求直接相关的内容，不做顺手重构、批量格式化或依赖升级。
4. 如果必须超出约定范围，先说明原因并等待确认。
5. 完成后列出全部改动文件，检查 Git 差异，并运行与改动相关的测试。
6. 明确报告未能执行的验证以及仍然存在的风险。

对于高风险任务，还可以增加一句：

本轮只做分析和修改方案，不要编辑文件；得到确认后再实施。

这段话会把任务切换为只读调查模式，让用户先掌握影响范围，再决定是否授权修改。

常见误区：看起来谨慎，其实仍然不够

误区一：只要求“不要乱改”

“不要乱改”缺少可执行标准。什么算乱改，用户和 Codex 的理解可能不同。应把它转换成文件范围、禁止事项、越界处理和验收步骤。

误区二：只在最后查看修改结果

如果任务很大，最后才检查会积累过多差异。把工作拆成小阶段，可以更早发现方向错误。

误区三：工作区不干净就让 Codex 全部还原

未提交内容可能正是用户的重要工作。正确做法是识别并保留，而不是为了方便操作而清除。

误区四：测试通过就代表修改合理

测试只能覆盖它实际检查到的行为。即使测试全绿，无关文件仍可能被修改，原有内容也可能被覆盖。因此，测试与差异审查缺一不可。

误区五：把更多改动等同于更高质量

一次任务修改得多，不代表完成得更彻底。对于维护工作，清晰、局部、可验证的改动往往比全面翻新更有价值。

总结

Codex 是否会乱改文件，很大程度上取决于任务有没有清晰的工程边界。仅仅提出功能目标，等于把大量判断留给代理；补充修改范围、现有状态、最小变更原则、差异审查和测试要求，才能把一次开放式操作变成可控流程。

五个方法可以浓缩为一句话：动手前明确边界，修改中保持克制，完成后用差异和测试说话。

当这些步骤成为固定习惯后，Codex 就不再只是一个能够快速写代码的工具，而会成为一个行为更透明、结果更容易审查的协作伙伴。速度依然重要，但在真实项目中，可控性通常比单纯的速度更有价值。