计划模式：先调研、出方案，再动手改代码

计划模式（Plan Mode）的核心价值是"先想清楚、再动手改"：在不动磁盘文件的前提下收集上下文、澄清需求、拟定修改方案，由你确认后再进入实现。它是降低误改、返工与越界改动的第一道闸门。本节讲它的适用场景、标准流程与方案审阅要点；进入方式以当前版本会话界面提供的模式切换入口为准。

一、计划模式做什么、不做什么

维度	计划模式内	计划模式外（实现阶段）
主要动作	读文件、调研、提问、产出方案与步骤	编辑文件、运行命令、迭代实现
对文件系统	不进行实质性代码修改	在授权与沙箱边界内修改
产出物	改动文件清单、实现思路、验证方式、风险点	可运行的改动与测试结果
用户角色	裁决方向与边界、补充约束	审批具体动作、复核 diff 与测试

二、什么时候应先用计划模式

任务特征	建议	原因
需求或边界尚不清晰	先计划	澄清歧义、避免按误解实现
跨多个文件的改动、重构	先计划	统一改动边界，防止夹带与遗漏
涉及安全、支付、数据迁移等敏感逻辑	先计划并人工复核方案	先确认设计再执行，代价更低
一行注释、文案等极小且明确的改动	可直接实现	计划开销大于收益

三、标准操作流程

1. 明确任务与约束：先说明背景、目标、禁止改动范围与验收标准，再进入计划环节。
2. 让代理只读调研：要求它阅读相关文件、梳理依赖与现有实现，不修改代码。
3. 允许必要澄清提问：代理列出不确定点时逐一回答，补充材料与边界。
4. 审阅方案四要素：改动文件清单、实现思路、验证方式、风险与回退办法。
5. 确认或收窄方案：范围过大就明确删减；方案可行后再放行进入实现。
6. 实现阶段仍保留审批：计划只解决"做什么"，具体命令与写入仍按审批策略逐项把关。

四、审阅方案的四个关键问题

• 清单是否克制：修改文件是否都是必要项，有没有顺手重构、改名等计划外内容。
• 思路是否贴合项目：方案是否遵循现有技术栈与编码风格，而非套用通用模板。
• 验证是否可执行：是否给出可运行的测试、构建或人工检查步骤，而不是"应该没问题"。
• 失败如何回退：是否说明风险点与回退路径，确保 Git 基线干净可还原。

五、FAQ

问题	处理建议
方案被代理写得过大	直接指出"本次只做 X，Y 另立任务"，要求输出缩小后的文件清单与步骤，再确认。
计划和实际实现不一致	实现偏离方案时暂停，要求解释并回到已确认边界；不允许代理借执行扩大范围。
代理在计划阶段就开始改文件	重申"先只输出方案、不要修改"；必要时切换到保守审批档位，先杜绝写入。
计划模式能替代测试吗	不能：方案只保证设计合理，实现正确性仍靠 diff 审查与运行测试验证。

六、动手练习

• 练习：选一个中等任务，先只让代理产出"文件清单 + 步骤 + 验证方式"，对照四要素打分并收窄一次范围，再放行实现，对比先计划与直接动手的返工差异。