CCClaude Code中文喂饭教程

Plan Mode：先计划再动手

Plan Mode 是正式修改前的安全缓冲。它的作用不是“让 CC 想久一点”，而是让 CC 先读项目、找事实、圈范围、说风险，等计划靠谱后再动手。

新手默认规则：只要不是一眼能看懂的小改动，都先用 Plan Mode。计划看不懂，就不要批准执行。

什么时候必须先用 Plan Mode

Plan Mode 要产出什么

一个合格计划至少应该包含 6 个东西：

  1. 读取了哪些文件，哪些结论来自文件。
  2. 任务相关的真实现状是什么。
  3. 最小修改方案是什么。
  4. 准备改哪些文件，为什么非改不可。
  5. 有哪些风险、权限和不确定点。
  6. 完成后怎么验收。

可以把计划当成“开工前合同”。它不需要很长，但必须能回答：为什么改、改哪里、怎么证明没改坏。

计划内容合格标准
已读文件能说清读了什么，以及为什么读
已确认事实来自文件、日志或用户描述，不把猜测当事实
修改范围文件数量尽量少，和目标直接相关
风险判断说明权限、数据、配置、兼容性风险
验收方式能执行检查，或给出人工验收步骤

直接复制

/plan

请先研究这个任务，不要修改文件。

任务目标：
【写清楚要解决什么】

请输出：
1. 你需要读取哪些文件。
2. 当前项目里和任务相关的事实。
3. 你建议的最小修改方案。
4. 需要修改哪些文件，为什么。
5. 需要哪些权限，风险是什么。
6. 验收方式是什么。
7. 哪些地方不确定，需要先确认。

更专业的版本

/plan

请进入 Plan Mode，只读分析，不要修改文件。

背景：
【描述当前需求或问题】

我希望你按下面结构输出：

## 已确认事实
- 只写从项目文件、错误信息或用户描述中确认的内容。

## 需要进一步读取的文件
- 每个文件说明读取目的。

## 最小方案
- 用最少文件、最少改动完成目标。
- 不要包含顺手重构。

## 风险和权限
- 哪些操作需要我批准。
- 哪些操作建议拒绝或延后。

## 验收方式
- 需要运行什么检查。
- 如果不能运行，人工怎么验收。

## 等待我确认
- 在我明确同意前，不要修改文件。

判断计划是否靠谱

不同任务的计划重点

任务类型Plan Mode 重点
前端 Bug复现步骤、页面位置、响应式、交互状态
后端接口调用链、入参出参、异常分支、兼容性
文档教程学习顺序、导航、链接、SEO 和口吻
数据库相关迁移方式、备份、回滚、影响范围
构建失败第一处 error、错误分类、最小修复点
重构行为不变证据、测试覆盖、分批策略

同样是 /plan，不同任务要看的重点不一样。计划如果没有覆盖任务本身的风险点，就还不能执行。

看到这些计划要拦住

计划不靠谱时

这个计划还不能执行。

请重新收窄：
1. 只保留和任务直接相关的文件。
2. 删除无关重构。
3. 明确哪些结论来自项目文件。
4. 把验收方式写得更具体。
5. 如果仍然不确定，请先提问，不要猜。

如果计划太长、看起来很专业但落不到文件，也要收窄：

这个计划太宽泛，请改成可执行版本。

请只保留：
1. 本次必须修改的文件。
2. 每个文件对应的任务目标。
3. 不改哪些文件。
4. 第一轮最小修改步骤。
5. 第一轮验收方式。

批准执行时怎么说

我确认这个计划。

请按“最小方案”执行。
限制：
1. 只修改计划中列出的文件。
2. 不要安装新依赖。
3. 不要提交 Git。
4. 如果执行中发现必须扩大范围，先停下来说明原因，等我确认。
5. 完成后请解释 diff，并进入验收。

批准时不要只说“开始吧”。要把边界再说一遍，避免计划执行中漂移。

执行中跑偏怎么拉回来

先暂停，不要继续扩大修改。

请回到刚才确认的计划：
1. 列出已经修改的文件。
2. 标记哪些改动属于计划内。
3. 标记哪些改动超出了计划。
4. 给出撤回超范围改动的最小方案。
5. 在我确认前不要继续写代码。

Plan Mode 的完成标准

计划阶段结束时，应该得到一个清楚结论：

结论下一步
可以执行按最小方案批准
需要补信息先补页面、日志、截图、接口路径等信息
风险过高拆小任务或换成只读分析
目标不清重新定义验收标准
方案太大收窄到第一步

如果计划没有结论，只是一堆分析，就让 CC 重新输出“建议是否执行”。

验收结果

下一篇：第一次修改代码