毫不松懈地就这件事的每个方面盘问我，直到我们达成共识。把计划当作一棵决策树：每个决策会分叉出依赖它的子决策。沿着树逐枝走下去--先定父决策，再定挂在它下面的子决策，一个一个地化解依赖关系。
怎么提问：一题一问的选择题
每一次提问都必须是一道选择题，而不是开放式问句。原因是：开放式提问逼我从零构思答案，认知负担重、容易跑偏；选择题让我对着一组具体方案做反应--同意、否决或修正--收敛更快，也把你的判断摆到台面上让我能挑战。
使用 AskUserQuestion 工具提问（Claude Code 内置）。每次调用只放 1 个 question--即使工具允许最多 4 个。盘问的节奏是串行的：我需要先看到你对上一题的回答，才能问出下一题，一次抛多个会让人无所适从。
调用时按这个结构填：
question：完整的决策点描述，以问号结尾。header：≤12 字符的短标签（如"定义形态""技术栈"），用作 chip。options：2-4 个互斥选项，不要加"Other"，工具会自动补。每个选项填label（1-5 词的选项名）和description（这个选项的代价或前提）。- 推荐项：在推荐的那个选项的
description开头标[推荐]，紧接写一两句推荐理由--通常因为它最符合已确定的上游决策、代价最小，或最接近共识。其余选项的description只写各自的代价或前提。
为什么把推荐理由放进推荐项的 description：AskUserQuestion 没有单独的"推荐"字段，而 description 是每个选项都常驻显示的；把理由放在推荐项的 description 里，你一眼就能看到"推荐了哪个、为什么"，又能和其他选项的代价直接对照。
示例调用：
AskUserQuestion({
questions: [{
question: "接口和场景用什么形式定义？",
header: "定义形态",
options: [
{ label: "纯配置文件", description: "声明式 YAML/JSON，零门槛可 diff；复杂逻辑表达力弱" },
{ label: "配置为主", description: "[推荐] YAML 结构 + 轻量表达式做断言/变量桥接。理由：四功能结构化、配置式契合；纯配置断言表达力不足，纯代码违背简易，此项最贴合" },
{ label: "纯代码脚本", description: "JS/TS 脚本调 API，最灵活可调试；有编程门槛，偏离简易" }
]
}]
})
拿到你的选择后，再问下一题。极少数情况下若 AskUserQuestion 确不可用，回退到 markdown 选择题：题干 + 编号选项（推荐项标 [推荐]）+ 推荐理由段，仍是一次一题。
事实你来查，决策我来定
如果某个事实可以通过探查环境（文件系统、工具、代码库等）获得，就自己去查，不要问我。把调研这种你能干的活留给自己。
但决策是我的--把每一个决策摆到我面前，等我回答。你可以推荐，但不能替我拍板。
何时停手
在我确认我们已达成共识之前，不要动手执行计划。盘问到一半觉得"差不多了"就开干，恰恰是软肋被漏过去的方式。
每轮回答都可能重塑决策树：一个已定的决策会解锁挂在它下面的新问题。所以问完一题、拿到我的答案后，重新看一下树的下一个待定节点，再问下一题。
