root-review

# root-review — 复盘与根因分析 从问题出发，找到根本原因，产出可执行的改进方案。适用于任何场景——开发需求、项目管理、个人生活、兴趣爱好。 **核心理念**：复盘不是列问题清单，而是穿透表象找到根因。解决了根因，一堆表面问题同时消失。 ## 触发时机 - 手动：`/root-review` - 场景触发：需求阶段完成后、发现问题想分析时、需要总结经验时、文档混乱需要整理时 ## 输入 用户提供以下一项或多项： - 遇到的问题 / 不满 / 观察 - 想要的效果 / 理想状态 - 相关材料（文档、数据、目录路径） - 复盘范围（某个需求、某段时间、某个事件） --- ## Phase 1: 问题收集 > 不急着分析，先把问题都摊开来。 ### 1a. 提取问题 从用户输入中提取所有问题和不满。如果用户提供了目录/文档路径，主动读取并发现问题。 每个问题用一句话描述，附带具体表现： ``` 问题：<一句话> 表现：<具体证据/例子> ``` ### 1b. 确认预期 对每个问题，追问"理想状态是什么"： - 用户说"文档太乱" → 理想状态："文档有清晰目录，按阶段组织，找东西不超过30秒" - 用户说"总是加班" → 理想状态："按时下班，工作在预期内完成" 如果用户已经描述了理想效果，直接提取；如果没有，主动问。 ### 1c. 确认清单 把问题清单 + 理想状态展示给用户确认： - 有没有遗漏？ - 优先级怎么排？哪个最痛？ --- ## Phase 2: 归类分析（Fishbone） > 把散乱的问题归入维度，看见结构。 按以下维度对问题归类。不是所有维度都会有问题，空的跳过： | 维度 | 含义 | 例子 | |------|------|------| | **人** | 自己或他人的行为、决策、沟通 | "产品没说清楚需求"、"我没及时同步进度" | | **方法/流程** | 做事的方式、步骤、工具 | "没有做路径分解就直接写代码"、"没有固定复盘节奏" | | **环境/外部** | 不可控的外部因素 | "第三方接口突然限流"、"上游需求频繁变更" | | **信息/资源** | 获取了什么、缺了什么 | "没读完代码就开始改"、"缺少测试环境" | | **认知/心理** | 预期偏差、认知盲区、情绪影响 | "低估了复杂度"、"焦虑导致赶工" | 归类后，标注哪些是"可控"的（自己能改变），哪些是"外部"的（只能应对）。 重点放在**可控因素**上——这是后续找根因的重点。 --- ## Phase 3: 根因挖掘（5 Whys） > 这是整个复盘最关键的一步。表面问题只是症状，根因才是病灶。 对 Phase 2 中优先级最高的 2-3 个可控问题，逐个做 5 Whys 分析： ``` 问题：文档散落在多个文件里，找不到关键信息 → 为什么？写文档时没有统一模板 → 为什么？当时没有定义文档规范 → 为什么？觉得"先做完再整理" → 为什么？低估了文档混乱对后续效率的影响 → 根因：缺乏"文档是开发过程的一部分"的认知 ``` **追问技巧**： - 每次问"为什么"时，聚焦于**可控的、具体的原因** - 如果答案变成"因为xxx不行"（推卸给外部），引导回自己能做什么 - 到达"认知层面"或"流程缺失层面"时，通常就是根因了 - 不一定刚好 5 次，3-7 次都正常 **根因的判断标准**： - 解决它之后，多个表面问题同时消失 - 它属于自己可以改变的范畴 - 它是"做法"或"认知"层面的，不是"态度"层面的（"不够努力"不是根因） --- ## Phase 4: 行动方案 > 根因找到了，方案要具体到"下次遇到同样情况，我会做什么不同的事"。 ### 4a. 针对根因出方案 每个根因对应 1-2 个具体行动： ```markdown | 根因 | 行动 | 衡量标准 | |------|------|---------| | 缺乏文档即开发的认知 | 每个需求开始时先建 00-路径分解.md | 是否有路径分解文件 | ``` **行动的标准**： - 可执行：是具体动作，不是态度宣言（"更认真" ✗ → "每天 standup 前花5分钟检查" ✓） - 可验证：能判断是否做了 - 限制数量：每次复盘最多 3 个行动项，否则都会落空 ### 4b. 领域特定动作（按需） 如果复盘的是**开发需求**，可能涉及： - 文档重组：git mv 文件、创建 archive、更新 MANIFEST - 经验沉淀：更新 memory/long/ - 流程改进：更新 skills 或 rules 如果复盘的是**个人生活/兴趣**： - 习惯调整：记录到 todo 或日历 - 认知更新：记录到 memory/long/ 的对应领域文件 ### 4c. 确认与沉淀 向用户展示完整的复盘结果： 1. **问题全景**：问题清单 + 归类 + 优先级 2. **根因链**：每个关键问题的 5 Whys 链 3. **行动方案**：根因 → 具体行动 → 衡量标准 4. **需要他人配合的事项**（如有） 等用户确认后，执行相关改动（如果有文件操作的话）。 --- ## 质量标准 - [ ] 问题收集完整，用户确认无遗漏 - [ ] 每个问题有具体表现（不是抽象感受） - [ ] 归类覆盖了可控 vs 不可控的区分 - [ ] 根因分析至少追问 3 层，到达认知/流程层面 - [ ] 行动项具体可执行，不超过 3 个 - [ ] 行动项聚焦可控因素，不是"希望别人改变" ## 常见陷阱 - **问题即方案**：用户说"需要加个监控"——这是方案不是问题，追问"为什么需要监控？出了什么事？" - **归因外部化**：所有原因都是别人的问题——引导回"在这个约束下，我能做什么不同" - **行动太泛**：保持"更加注意"——不是行动，追问"具体做什么？" - **贪多**：一次提 8 个改进——砍到 3 个最关键的