Plan Mode 实战:从需求到可执行计划
Plan Mode 的价值在于把模糊需求变成可检查计划。通过一个前端页面优化任务,完整演示只读分析、收窄范围、确认计划、执行和验收。
前面已经讲过 Plan Mode 的规则,接下来用一个完整案例把流程跑一遍。重点不是让 CC 一次写很多代码,而是训练如何让 CC 在动手前先把任务想清楚。
案例目标:
优化一个静态教程站首页的 Hero 区域,让左右内容更紧凑,按钮更明显,但不改导航、不改文档页、不引入新依赖。
这个案例代表的是“中低风险 UI 优化”。它适合练 Plan Mode,因为目标能看见、范围能限制、结果能验收。
| 本案例适合练什么 | 不适合练什么 |
|---|---|
| 收窄页面范围 | 大规模视觉重做 |
| 审查 CSS 计划 | 引入新 UI 库 |
用 /run 看页面 | 改文档页结构 |
用 /verify 收尾 | 改业务逻辑 |
第 1 步:把模糊需求说清楚
不要只说“首页不好看,帮我优化”。要把目标、范围和禁止事项说清楚。
/plan 请先只读分析首页 Hero 区域,不要修改文件。 任务目标: 优化首页 Hero 区域,让左右内容更紧凑,视觉重点更清楚。 范围: 1. 只允许分析首页和相关样式文件。 2. 优先调整布局、间距、按钮和右侧视觉区域。 3. 不修改文档页布局。 禁止事项: 1. 不引入新依赖。 2. 不重构整个 CSS。 3. 不修改顶部导航逻辑。 4. 不修改文档内容。 请输出: 1. 你需要读取哪些文件。 2. 当前 Hero 存在哪些确认过的问题。 3. 最小修改方案。 4. 预计修改哪些文件。 5. 验收方式。
第 2 步:检查计划有没有依据
一个靠谱计划应该说清楚“我看了什么,所以我判断什么”。
可以用这张表检查计划:
| 检查项 | 合格表现 |
|---|---|
| 文件依据 | 说清读取了首页和样式文件 |
| 修改范围 | 只涉及 Hero 和必要样式 |
| 禁止事项 | 不动导航、文档页、依赖 |
| 验收方式 | 有桌面端和移动端检查 |
| 风险 | 说明可能影响哪些布局 |
如果 CC 只说“我会优化布局”,继续追问:
这个计划还不够具体。 请补充: 1. 你实际读取了哪些文件。 2. Hero 左右布局目前的关键 CSS 是什么。 3. 哪些间距或宽度导致视觉松散。 4. 你准备修改哪些选择器。 5. 哪些地方不需要改。
第 3 步:收窄计划
CC 很容易提出“顺便整体优化”。这时要把计划压回最小修改。
请把计划收窄到最小修改。 只保留: 1. Hero 左右布局间距。 2. 右侧视觉区域尺寸。 3. Hero 文案宽度。 4. 两个按钮的视觉层级。 不要包含: 1. 全站字体重构。 2. 文档页布局修改。 3. 顶部导航调整。 4. 新增动画库或依赖。
第 4 步:确认后再执行
计划清楚以后,再批准执行。
我确认这个计划。 请按计划执行修改。 要求: 1. 只修改计划里确认的文件。 2. 不做额外重构。 3. 修改后说明 diff。 4. 给出本地预览和验收建议。
第 5 步:修改后验收
修改完成后,不要只看 CC 的总结。让它按验收清单检查。
/verify 请验收这次 Hero 优化。 要求: 1. 列出修改过的文件。 2. 说明每个修改和 Hero 目标的关系。 3. 检查首页是否能正常打开。 4. 检查桌面端左右内容是否更紧凑。 5. 检查移动端是否没有文字溢出。 6. 标出未验证内容和剩余风险。
如果页面任务能运行,配合 /run:
/run 请启动站点并观察首页。 重点看: 1. Hero 左右间距是否过大。 2. 右侧视觉区域是否足够明显。 3. 文案是否换行自然。 4. 按钮是否清晰可点。 5. 移动端是否挤压或溢出。
第 6 步:让 CC 做自我审查
最后让 CC 切换成审查视角,找自己的问题。
/code-review 请审查这次首页 Hero 修改。 重点看: 1. 是否改了任务范围外的内容。 2. 是否影响文档页。 3. 是否有无关格式化。 4. 是否有移动端风险。 5. 是否还有更小的修改方案。
计划失败时怎么办
如果执行后效果不对,不要直接说“继续优化”。先重新收敛。
当前效果没有达到预期,请暂停。 请只读复盘: 1. 原计划想解决什么。 2. 实际修改了什么。 3. 哪个验收点没有通过。 4. 是计划问题、执行问题,还是需求描述不清。 5. 下一步最小修正是什么。 不要扩大成全站重构。
案例复盘模板
请复盘这次 Plan Mode 练习。 请说明: 1. 需求是否被说清楚。 2. 计划是否有文件依据。 3. 范围是否被控制住。 4. 执行是否符合计划。 5. 验收是否足够。 6. 下次同类任务应该复用哪段提示词。
这个案例学到什么
- Plan Mode 不是形式,而是动手前的安全缓冲。
- 计划必须有文件依据。
- 修改范围必须能被用户看懂。
- 执行后要用
/run、/verify和/code-review收尾。 - 效果不对时先复盘,不要马上扩大修改。