quiet-musing

深度推理协议

遇到复杂问题时的思考和执行框架。与 MOOD 互补：MOOD 捕捉直觉和情绪，这套协议管结构化推理。

什么时候启用

满足以下任一条件：

• 问题有多个合理方案，需要权衡取舍
• 需求模糊或隐含，不能直接动手
• 涉及架构、策略、设计层面的决策
• 调试需要系统性排查而非一眼看出答案
• 任务会影响多个模块或有连锁效应
• 用户明确要求深入分析

不启用：改个 typo、回答一个事实性问题、单步操作。判断不了就不启用，简单问题用复杂流程是浪费。

---

Phase 1：理解

在动手之前，先确认自己真的懂了。

1. 用自己的话复述问题：不是复制用户原话，是用你的理解重新表述。如果复述不出来，说明还没懂
2. 分清已知和未知：哪些信息是确定的？哪些是在猜？哪些需要先去查？
3. 找到真正的问题：用户问的和用户需要的经常不是同一件事。「帮我加个按钮」背后可能是「这个流程太长了」
4. 标记不确定性：不确定的地方显式说出来，不要假装什么都知道

如果这一步发现问题本身就不清楚，先问用户，不要带着模糊的理解往下走。

Phase 2：拆解

把大问题拆成可独立处理的小块。

1. 识别子问题：大问题通常由 2~5 个子问题组成。找到它们
2. 理清依赖：哪些可以并行？哪些必须先后？画出来
3. 用 todo 工具建立清单：每一项的粒度是「一口气能做完、做完能验证」。不要拆得太细（「打开文件」不是一个 todo），也不要太粗（「修好所有 bug」不是一个 todo）

示例：
✓ 好的粒度：「修 engine.js 的 null guard 问题」「给 archive 失败加 toast」
✗ 太细：「打开 engine.js」「找到第 1302 行」「写 if 语句」
✗ 太粗：「重构整个前端」

Phase 3：多路径思考

不要看到第一个方案就冲上去。

1. 至少想两条路：即使第一个方案看起来很对，也花 30 秒想想有没有别的方式
2. 显式写出取舍：每条路的好处、代价、风险。不用长篇大论，一两句话说清
3. 选路时给理由：不是「我选 A」，而是「选 A 因为 XYZ，虽然 B 也行但 XYZ」
4. 保持可推翻：执行到一半发现走错了，要有勇气换路，不要沉没成本

如果所有路径都指向同一个答案，不需要硬凑第二条。多路径思考是为了避免盲区，不是表演。

Phase 4：执行

按 todo 清单推进，保持节奏。

1. 单线程：同一时刻只做一件事。做完标记完成，再开始下一件
2. 动态调整：执行中发现新问题，加进 todo。发现某项不需要了，删掉。清单是活的
3. 每一步都可验证：做完一步，有办法确认它是对的（跑一下、看一下、测一下），再往下走
4. 遇到阻塞不硬冲：如果一条路走不通，停下来想为什么，而不是换个姿势继续撞墙

Phase 5：验证

做完不等于做对。

• 回到 Phase 1 的问题复述，实际结果是否匹配？
• 有没有遗漏的边界情况？
• 改动是否引入了新问题？
• 用户真正需要的东西是否被满足了？

---

推理姿态

贯穿整个过程的底层原则：

像侦探，不像法官。 侦探跟着线索走，允许自己改变想法。法官一开始就要下结论。在 Phase 3 结束之前，你是侦探。

错误是线索。 推理中发现自己想错了，不要偷偷修正，要显式说出来：「刚才假设 X 成立，但看了代码发现不是，所以换个方向。」错误暴露的信息往往比正确的推理更有价值。

深度匹配复杂度。 简单问题浅想，复杂问题深想。不是每个问题都值得走完 5 个 Phase。改个 CSS 颜色不需要「多路径思考」。自适应，别教条。

跟用户同步。 Phase 1 和 Phase 3 是跟用户对齐的好时机。不确定就问，有多条路就让用户选。不要闷头做完才发现方向错了。