审查 Claude Code 改动计划的七个问题

你让 Claude Code 先出计划再动手，它很快给了一句：“我会更新前端代码，并确保功能正常。”看起来没毛病，目标也对得上。可要改哪个文件？哪些地方不碰？改完怎么查？这些一个都没说。批准它，等于把范围交给它自己去猜。

“先计划，再改代码”这个顺序，很多人都听过。真正难的是拿到计划之后，不知道该看什么。笼统的计划被批准，改动就容易越做越多：顺手重构一个组件，引入一个新依赖，甚至提出改数据库结构。等你在 diff 里发现时，文件已经变了。

审计划，可以落到七个问题上：

1. 要解决的具体问题是什么？
2. 需要查看或修改哪些文件？
3. 当前逻辑大概是怎样的？
4. 准备怎么改？
5. 哪些区域明确不改？
6. 可能有什么风险？
7. 改完后怎么验证？

七个问题都有明确答案，才有批准的依据。缺项就要求补充，范围过大或碰到高风险区域就暂缓、换个更小的任务。拿一个“把首页空状态提示改清楚”的小任务走一遍，就能看出笼统计划和可执行计划差在哪里。

01 修改前先看计划

代码修改前先看计划，可以在文件改变之前发现目标误解、范围扩大或验证缺项。方向不对，就先修订方案，在编辑前确认范围。

涉及代码修改时，用这个顺序：

先让它看懂问题
  ↓
再让它提出计划
  ↓
你审查计划
  ↓
确认后再允许它改代码

“加搜索”“修登录”“优化页面”，都还没说清具体要做什么。搜索可能涉及页面、接口和数据库；优化页面可能是提速，也可能是改布局。先说明当前现象，再用计划确认范围和完成标准。否则，Claude Code 就得自己猜，改动也容易越做越多。

02 一份计划要回答七个问题

看计划时，重点是能不能据此决定下一步。目标、文件范围和验证方式写清了，修改前就能逐项核对。开头那七个问题，就是一份合格的改动计划要回答的内容。

比如要修改错误提示，不合格的计划可能只说：

我会修改相关逻辑，让错误提示更友好。

“更友好”听起来符合目标，却还没说到具体做法。要改哪个文件？显示什么文字？改完怎么查？这些没确定，就还没有批准的依据。

即使只改登录文案，也可能让别人猜出账号是否存在。遇到新增错误分类或改变认证行为的方案，先暂停；账号或密码错误仍保留统一提示。第一次练习，优先选空状态这类文案，更容易看清范围和验证方式。

03 先用计划模式分析，再挑小任务

计划模式让你先看到它的思路：准备查哪些文件，现有逻辑是什么，怎样修改，又怎样验证。分析和探索都发生在源码修改之前，发现方向不对，可以先调整方案。官方常用工作流里也专门有一节“编辑前先计划”，推荐的就是这种做法。

这一步停在调查与计划阶段：核对相关文件、当前逻辑、最小方案和验证方式，不执行修改。还要确认界面中的实际模式是 plan；提示词里写“先计划”，代替不了模式设置，探索命令的副作用也要检查。

任务最好从项目理解笔记中选，同时满足四个条件：

范围小
风险低
结果明确
可以验证

页面文案、README、小样式或已有函数的边界测试都合适，下面就用首页空状态提示作为例子。还没有项目笔记的话，可以先让 Claude Code 画一张项目地图，再从里面挑任务。认证、数据库、支付和部署，留到以后再练。

04 写出计划请求

先在界面确认处于 plan 模式，再把下面的占位文字换成自己的小任务。调查时只读，不安装依赖，也不运行会改变状态的项目脚本：

请进入计划模式。先不要修改任何文件。

我的任务是：[写清楚你要完成的小任务]

请你先完成以下分析：
1. 找出和这个任务最相关的文件
2. 解释当前相关逻辑是如何工作的
3. 给出最小改动方案
4. 明确哪些文件会被修改，哪些文件不会被修改
5. 说明这个方案可能有什么风险
6. 说明修改后如何验证
7. 如果你认为这个任务不适合新手，请说明原因，并推荐更小的替代任务

请等我确认后，再进入代码修改。

这个请求把调查和执行分开，要求用相关文件说明方案，也给你留下审查的机会。计划清楚、实际模式和范围都确认了，再进入修改。

05 三种常见回复，怎么追问

收到计划，先核对目标：它要解决的是你选的那个问题吗？目标一致，再检查文件依据、现有逻辑和最小方案，最后看不改的区域、风险与验证办法。哪里缺信息、哪里超出了目标，就逐项指出来。

修改前审查计划，执行后再审查 diff。“更新相关模块”还缺文件范围，“顺手重构”则可能带进无关改动；先要求补齐依据或收紧方案。与当前目标无关的依赖也要拿掉，它们会增加安装、维护和验证范围。

开头那种回复：

我会更新前端代码，并确保功能正常。

你应该追问：

这个计划太笼统。请补充：
1. 具体会修改哪些文件？
2. 为什么这些文件和任务相关？
3. 哪些文件明确不会修改？
4. 修改后用什么方式验证？

如果它说：

我会重构相关组件，让代码更清晰。

重构不属于当前目标，就要求移除。它会增加文件范围、行为变化与验证成本，“更清晰”这个理由撑不起这些代价：

请不要做重构。请给出一个最小改动方案，只解决当前任务，不顺手优化无关代码。

如果它说：

我需要修改数据库 schema。

数据库 schema 指表、字段及其约束等结构。修改它可能需要迁移或改变已有数据，先暂缓，再问：

有没有不修改数据库结构的替代方案？
如果必须修改数据库，请说明为什么这个任务不适合作为新手练习。

审查结果有三种：批准、补充或暂缓。关键文件、影响范围或验证还不清楚时，先补信息；涉及不适合入门的风险，就缩小或更换任务。批准之后，执行阶段怎样对照计划检查 diff、跑验证，可以看改完代码后的验收方法。

06 一份可执行的计划长什么样

假设你的任务是：

把首页的空状态提示文案改得更清楚。

不够清楚的计划可能是：

我会查看首页代码，修改提示文案，并测试页面。

这份计划提到了修改和测试，却没有说明文件、当前显示逻辑和具体检查。可执行的计划要把这些依据和最小改动连起来，而不只是列出动作名称。

下面继续用这个假设项目说明。计划中写“可能”的地方，都还需要调查；批准前，让 Claude Code 读取实际文件，确认文案位置和组件的使用范围：

目标：
把首页无数据时的提示文案改得更清楚。

相关文件：
- `src/pages/Home.tsx`：可能负责首页结构
- `src/components/EmptyState.tsx`：可能负责空状态展示
- `src/components/__tests__/EmptyState.test.tsx`：如果存在，可以补充测试

当前逻辑：
首页在数据列表为空时渲染 `EmptyState` 组件。当前提示文案比较泛。

最小改动方案：
1. 优先只修改 `EmptyState` 组件中的文案
2. 如果文案来自常量文件，则只修改常量文件
3. 不修改数据获取逻辑
4. 不修改页面布局
5. 不修改接口调用

验证方式：
1. 本地启动页面，确认空状态文案显示正确
2. 如果有组件测试，运行相关测试
3. 检查 diff，确认只改了文案相关内容

看完计划，要明确说出下一步：

文件依据、范围、验证都清楚 → 批准
缺少关键信息               → 要求补充
范围过大或涉及高风险区域   → 暂缓，缩小或更换任务

说明判断时，指出依据来自哪个文件、会影响哪里、怎样验证。验证方式有时也叫 verifier，官方最佳实践的建议是给 Claude 一个能跑出“通过或失败”的检查，计划里的验证方式就是在提前定下这个检查。

再往下查一步，调查发现首页和搜索页都用了 EmptyState，而这次只改首页。先看组件是否允许页面传入提示语：

核对调用关系后，验证范围也就清楚了：让首页进入无数据状态，看新文案；再到搜索页，确认原提示保留。只动一个共享文件，也可能影响多个页面。判断方案是否足够小，要看这些实际影响，文件数只是参考。