DeepDojo.AI发布 2026-11-10更新 2026-11-10English
Claude Code 改完代码后怎么检查
计划里写得清清楚楚：首页空状态的文案在 EmptyState.tsx，只改这一个文件。Claude Code 动手后报告“已修改文案”。可它打开文件才发现，文案其实放在 i18n/en.json。如果它悄悄改了那个文件，或者顺手又调了点别的，光看那句“已修改”，你什么都发现不了。
改完代码最容易出的问题，是把总结当成结果。总结说的是它打算做了什么，diff 才显示文件实际变了什么；构建通过，也只说明满足了构建的约束，文案有没有在页面上正确显示是另一回事。验证一失败，又顺口说一句“再修一下”，一串顺手优化下来，最初的问题解没解决反倒说不清了。
收尾时，按一条固定的顺序走：
- 执行边界跟着计划走，实际情况和计划对不上就先暂停；
- 拿完整的 diff 对照计划和总结，查清有没有越界改动；
- 按改动选验证方式，既看目标达成，也看原有行为还在；
- 失败时先分清来源，再定最小的下一步。
最后依据原计划、实际 diff 和验证结果三样东西，决定接受、继续修正还是回退。
01 一次小改动的完整收尾
计划通过后，进入获准范围内的小改动。执行完成，还要检查实际 diff、取得验证证据、分析失败，才能决定接受、继续修正或回退：
确认计划
↓
授权小范围修改
↓
查看 diff
↓
运行验证
↓
处理失败
↓
记录结果
第一次修改可以是一处文案、一小段 README、一个简单测试、一个可稳定复现的小 bug、低风险样式或已有函数的边界处理。整模块重构、数据库、认证、权限、支付、部署、批量删除和跨系统联动，留到具备更完整的审批与验证能力之后。
第一次练习，先选一个自己能看懂整个过程的任务。范围小一些，更容易看清每一步改了什么、带来什么变化。
02 执行边界跟着计划走
执行边界应与计划一致。空状态文案任务只包含文案，组件重构要另外判断；补测试也只是补测试，调整函数结构不在其中。本次 diff 与验证围绕同一个目标检查。计划本身怎么审，可以先看审查改动计划的七个问题。
执行前可以这样说：
我们现在进入执行阶段。
请严格按照刚才确认的计划执行。
要求：
1. 只修改计划中列出的文件
2. 不做额外重构
3. 不引入新依赖
4. 不修改数据库、认证、部署、环境变量等高风险区域
5. 每次修改后说明改了什么
6. 修改完成后给我总结 diff 和验证方式这段提示说清了可以改哪些文件、哪些区域不能碰，以及最后要报告什么。执行阶段只批准计划内的动作，新的文件或命令要重新解释和确认。
03 实际和计划对不上，先暂停
授权时再说清一个条件：实际代码与计划对不上，就先暂停。让 Claude Code 说明发现了什么、为什么要调整；新增文件或命令得到确认后，再继续。
开头那种情况，它可能会发现：
计划中说文案在 `EmptyState.tsx`，
但实际文案位置是 `i18n/en.json`。这时让它先报告事实和新的文件范围：
我发现原计划需要调整。实际文案位置是 `i18n/en.json`。
是否允许我修改这个文件？调查有了新发现，调整计划很正常。先报告差异、得到确认，再改新文件，你才知道这次任务为什么变了、变到哪里。
04 拿 diff 对照总结
Claude Code 准备编辑时，先看清它打算改什么，再决定是否批准。
用 IDE 扩展时，通常可以先看它准备做的修改；在终端里，也先看待批准的编辑内容。等文件实际修改后，再用 Git diff 或编辑器检查差异。Git diff 显示的是已写入的变化，还没执行的计划不会出现在里面。
总结说明改动意图，实际 diff 显示文件变化。两者要对照着看，“已修改文案”这句报告只是一条线索。
下面是一段假设的文案改动：
--- a/src/pages/Home.tsx
+++ b/src/pages/Home.tsx
@@ -24 +24 @@
- <p>No data</p>
+ <p>No items yet. Add your first item to get started.</p>- 行是删掉的旧内容，+ 行是新增内容，上方路径告诉你改了哪个文件。看完这段，还要继续查：
| 要确认什么 | 去哪里看 |
|---|---|
| 改的是目标页面的空状态吗？ | 对照计划，读周围代码的显示条件 |
| 是否夹带了别的修改？ | 检查完整 diff |
| 页面实际显示正确吗？ | 运行页面，进入对应状态 |
这段 diff 证明的是这里的文字变了，其他结论要分别找依据。
检查完整 diff 时，至少看四件事：
1. 它改的是不是计划中的文件？
2. 它有没有顺手改无关内容？
3. 它有没有引入新依赖或复杂逻辑？
4. 它有没有触碰高风险区域？如果文案任务的 diff 里出现认证逻辑、数据库或构建配置，就先停在这里。它已经超出原计划，要拒绝或追问原因。可以这样说：
这个 diff 超出了计划范围。
请先指出哪些无关改动是你本次造成的，再提出撤回方案。
保留原有和其他人的改动，不要整文件重置。或者：
请解释为什么需要修改这个文件。如果不是必须修改，请不要改它。对照计划和总结检查变化时，记得查全文件状态：
`git status` → 先看哪些文件有变化
`git diff` → 看已跟踪文件里尚未暂存的变化
`git diff --cached` → 看已暂存的变化
新增的未跟踪文件 → 单独打开检查按 Git 官方文档，不带参数的 git diff 比较的是工作区和暂存区，--cached 才显示已暂存的内容。单独运行 git diff 会漏掉已暂存内容和未跟踪的新文件，所以要结合状态与对应差异一起看。
05 验证：目标达成，原有行为还在
代码改完，接着验证。既要看目标是否达成，也要看原有行为是否保留。根据改动组合三类验证：
| 类型 | 主要检查 |
|---|---|
| 自动检查 | 相关测试、lint、构建或类型检查是否通过 |
| 人工场景 | 页面、按钮或错误提示是否符合目标；bug 是否复现；README 步骤能否执行 |
| 代码审查 | diff 范围、依赖、删除、命名和风格是否符合计划与项目习惯 |
可以让 Claude Code 按计划验证：
请按照计划中的验证方式进行检查。
如果需要运行命令，请先说明命令作用。
验证完成后，请告诉我：
1. 运行了哪些命令
2. 结果是否通过
3. 如果失败，失败原因是什么
4. 是否需要进一步修改看不懂验证命令时，先让它解释作用、参数和副作用，再决定是否执行。
空状态文案要在页面进入无数据状态时检查实际显示。构建或类型检查说明代码满足了相应约束；文案、布局和显示条件是否符合目标，要靠页面检查来证明。
Claude Code 官方最佳实践建议提供能返回通过或失败的检查，让它依据实际结果继续修正。
06 验证失败，先找原因
验证失败时，先保留错误信息和发生步骤，再决定要不要修改。只说“再修一下”，没有给出失败依据，调查可能偏离当前问题。可以先要求分析：
验证失败了。请先不要继续修改。
失败信息如下：
[粘贴错误信息]
请你先分析：
1. 失败发生在哪一步
2. 失败可能和刚才的改动有关吗
3. 是否需要修改原计划
4. 最小修复方案是什么
5. 修复后如何再次验证先查失败来自哪里：本次代码、环境、原有问题，还是验证命令本身？
“找不到测试脚本”，就先核对配置；“无法连接测试数据库”，就先查测试环境。找到原因后，再决定是否需要改业务代码。怀疑问题原本就有，也要找改动前的记录或其他可比证据。
处理失败时，你也要说清范围：
只允许修复和本次改动直接相关的问题。
不要顺手重构。
不要修改未确认文件。先守住这个范围。一个报错引出一串“顺手优化”，往往会让你更难判断最初的问题有没有解决。
07 接受、修正还是回退
收尾时核对改动文件、实际运行的检查和剩余风险。通过、失败、未运行与阻塞分别报告，再据此决定是否接受结果。可以这样问：
请总结本次改动：
1. 修改了哪些文件
2. 每个文件改了什么
3. 为什么这样改
4. 运行了哪些验证
5. 验证结果是什么
6. 是否还有遗留风险Claude Code 可以帮你总结改动、准备 commit message 或 PR 描述。新手阶段由你确认后再提交，至少确认三件事：
diff 没问题
验证通过
改动范围符合原计划最终判断同时依据原计划、实际 diff 与验证结果。符合目标就接受；仍有问题，就选择最小修正，必要时撤回本次改动。撤回前先区分本次与原有内容，保留自己和他人的已有修改；哪些改动能撤回、靠什么撤回，可以看 checkpoint 和 Git 各能兜住什么。接受结果之后，提交仍是另一个需要你点头的动作。