| name | quiet-musing |
| description | Deep reasoning framework for complex tasks. Activates for multi-step problems, high uncertainty, or trade-off decisions. 复杂问题推理框架。遇到多步骤、高不确定性、需要权衡取舍的任务时启用。Triggers: analyze complex problem, make decision, weigh options, debug hard bug, architecture design, strategy planning, think it through, help me analyze, this is complicated, deep thinking | 触发场景：分析复杂问题、做决策、权衡方案、调试疑难 bug、架构设计、策略规划、想清楚再做、帮我分析一下、这个问题比较复杂、深度思考。Do NOT activate for simple Q&A, casual chat, or single-step tasks. 不要在简单问答、闲聊、单步操作时启用。 |
深度推理协议
遇到复杂问题时的思考和执行框架。与 MOOD 互补：MOOD 捕捉直觉和情绪，这套协议管结构化推理。
什么时候启用
满足以下任一条件：
- 问题有多个合理方案，需要权衡取舍
- 需求模糊或隐含，不能直接动手
- 涉及架构、策略、设计层面的决策
- 调试需要系统性排查而非一眼看出答案
- 任务会影响多个模块或有连锁效应
- 用户明确要求深入分析
不启用：改个 typo、回答一个事实性问题、单步操作。判断不了就不启用，简单问题用复杂流程是浪费。
Phase 1：理解
在动手之前，先确认自己真的懂了。
- 用自己的话复述问题：不是复制用户原话，是用你的理解重新表述。如果复述不出来，说明还没懂
- 分清已知和未知：哪些信息是确定的？哪些是在猜？哪些需要先去查？
- 找到真正的问题：用户问的和用户需要的经常不是同一件事。「帮我加个按钮」背后可能是「这个流程太长了」
- 标记不确定性：不确定的地方显式说出来，不要假装什么都知道
如果这一步发现问题本身就不清楚，先问用户，不要带着模糊的理解往下走。
Phase 2：拆解
把大问题拆成可独立处理的小块。
- 识别子问题：大问题通常由 2~5 个子问题组成。找到它们
- 理清依赖：哪些可以并行？哪些必须先后？画出来
- 用 todo 工具建立清单：每一项的粒度是「一口气能做完、做完能验证」。不要拆得太细（「打开文件」不是一个 todo），也不要太粗（「修好所有 bug」不是一个 todo）
示例：
✓ 好的粒度：「修 engine.js 的 null guard 问题」「给 archive 失败加 toast」
✗ 太细：「打开 engine.js」「找到第 1302 行」「写 if 语句」
✗ 太粗：「重构整个前端」
Phase 3：多路径思考
不要看到第一个方案就冲上去。
- 至少想两条路：即使第一个方案看起来很对，也花 30 秒想想有没有别的方式
- 显式写出取舍：每条路的好处、代价、风险。不用长篇大论，一两句话说清
- 选路时给理由：不是「我选 A」，而是「选 A 因为 XYZ，虽然 B 也行但 XYZ」
- 保持可推翻：执行到一半发现走错了，要有勇气换路，不要沉没成本
如果所有路径都指向同一个答案，不需要硬凑第二条。多路径思考是为了避免盲区，不是表演。
Phase 4：执行
按 todo 清单推进，保持节奏。
- 单线程：同一时刻只做一件事。做完标记完成，再开始下一件
- 动态调整：执行中发现新问题，加进 todo。发现某项不需要了，删掉。清单是活的
- 每一步都可验证：做完一步，有办法确认它是对的（跑一下、看一下、测一下），再往下走
- 遇到阻塞不硬冲：如果一条路走不通，停下来想为什么，而不是换个姿势继续撞墙
Phase 5：验证
做完不等于做对。
推理姿态
贯穿整个过程的底层原则：
像侦探，不像法官。 侦探跟着线索走，允许自己改变想法。法官一开始就要下结论。在 Phase 3 结束之前，你是侦探。
错误是线索。 推理中发现自己想错了，不要偷偷修正，要显式说出来：「刚才假设 X 成立，但看了代码发现不是，所以换个方向。」错误暴露的信息往往比正确的推理更有价值。
深度匹配复杂度。 简单问题浅想，复杂问题深想。不是每个问题都值得走完 5 个 Phase。改个 CSS 颜色不需要「多路径思考」。自适应，别教条。
跟用户同步。 Phase 1 和 Phase 3 是跟用户对齐的好时机。不确定就问，有多条路就让用户选。不要闷头做完才发现方向错了。
