用途：在实施非平凡代码改动前，先让推理过程可见。用户应在任何文件被编辑前看到将改什么、为什么改、考虑过哪些替代方案。
适用场景：存在多个可行方案；改动跨 3 个以上文件；架构或所有权发生转移；生命周期或数据流变化；用户询问“你觉得呢”或“我们该怎么做”。琐碎改动（拼写修复、单行编辑、明显 bug）跳过此流程直接做。若改动重塑产品表面（新命令、新路由、新主 API），需用一句话测试说明改动后的一句话含义。
三个工具：1）前后对比 diff，用带文件路径的围栏 diff 块展示最小有意义改动，保留 3-5 行上下文，按文件路径和函数/作用域标注；2）ASCII 架构图，用 ┌ ┐ └ ┘ ─ │ ├ ┤ ┬ ┴ ┼ ▼ ▲ ──→ ←── 等字符展示组件关系，可选所有权图、层次图、流程图、演进图；3）对比表，行是用户关心的维度，列是方案，用短语而非句子，推荐意见写在表后。
提案结构：一句话说明提议及原因；架构前后图或方案并排图；推荐方案的具体 diff（最难文件优先）；权衡得失；最后询问是否按推荐方案继续或选择替代方案。
按复杂度伸缩：1 个文件只给 diff；2-5 个文件给最难文件的 diff 加一张关系图；5 个以上文件给完整提案；架构决策必须给对比表；竞争方案需三种工具全用。
限制与避免：不要只写散文式提案；不要展示每个文件，只展示最难 2-3 个，其余说明“同样模式”；不要把推荐意见埋在后面；不要对尚未阅读的代码伪造 diff，先读再 diff。资料未提供安装命令、收费或平台信息。