决策盘问

一个问题：计划为什么会跑偏

复杂任务最常见的失败模式不是能力不足，而是决策顺序错了。你先选了技术栈，再想起部署目标还没定；先写了模块接口，才发现上游的数据来源根本不存在。每个决策都有父决策和子决策，跳过依赖关系直接动手，返工是大概率事件。

另一个问题是提问方式。开放式提问（“你打算怎么做？”）让对方从零构思答案，认知负担重、答案容易跑偏。而把问题收成选择题，对方只需在具体方案里做判断——同意、否决或修正——收敛速度快得多。

这个技能怎么做

核心机制是把计划当作一棵决策树：

• 每个决策是一个节点，分叉出依赖它的子决策
• 严格执行先父后子：定下父决策后，才问挂在它下面的下一题
• 一次只问一题，等对方回答完再继续，绝不一次抛多个问题

提问统一使用 AskUserQuestion 工具，且每次调用只放 1 个 question，即使工具本身允许最多 4 个。调用时的结构：

• question：完整的决策点描述，以问号结尾
• header：≤12 字符的短标签，用作 chip（如“技术栈”）
• options：2–4 个互斥选项，不加“Other”，工具会自动补
• 每个选项包含 label（1–5 词）和 description（代价或前提）

推荐项的处理方式：把 [推荐] 标在推荐项 description 开头，紧接一两句推荐理由（通常因为它最符合已确定的上游决策、代价最小）。其余选项只写各自的代价或前提。原因是 AskUserQuestion 没有单独的“推荐”字段，而 description 每个选项都常驻显示，这样一眼就能看出推荐了哪个、为什么，又能与其他选项的代价直接对照。

事实与决策的分工是另一条铁律：事实（可通过文件系统、工具、代码库探查到的）自己查，不要问；决策（需要判断和取舍的）全部摆到用户面前等他拍板。可以推荐，但不替用户决定。

何时停手：在用户确认达成共识之前，不动手执行计划。盘问到一半觉得“差不多了”就开干，恰恰是软肋被漏过的方式。另外每轮回答都可能重塑决策树——一个已定的决策会解锁新的子问题，所以每拿一题答案，都要重新看一眼树的下一个待定节点。

适用边界

• 适合多步骤、有依赖关系的规划场景；对于无依赖的原子操作，决策树是负担
• 盘问有单题往返成本，追求一次性批量确认的场景不适合
• AskUserQuestion 不可用时，回退到 Markdown 选择题：题干 + 编号选项（推荐项标 [推荐]）+ 推荐理由段，仍是一次一题