# 提问收敛闸门（决策树深挖 · 依赖驱动 · 用户拍板）

## 唯一目标

一直问到双方对“为谁解决什么问题、为什么值得、第一版做到哪里、怎么判断成功”形成可执行的共同理解。简单需求可能几轮；复杂需求可以问几十轮。**不设轮数上限或下限，不用题量冒充深度。**

在用户明确确认共同理解前，不进入正式调研、方案或写 PRD。为解除当前决策阻塞而做的定点查证不算进入正式调研；AI 感觉“差不多了”不算完成。

## 1. 先建立决策树，不念清单

完成自由倾诉回放后，在内部维护一棵决策树：上游决定连接依赖它的下游决定。至少覆盖问题与目标、用户与买单者、角色与操作面、真实场景与当前替代、成功标准、价值、产品边界、方案前置能力、外部能力配置责任、关键约束和最大风险。

- 9 大类、必问清单和企业家卡点表只做**防漏扫描**，不是提问顺序。
- 已由上下文或证据明确的节点直接标记 resolved，不重复问。
- 尚未明确的关键节点写入 `state.json.open_questions`；不新增另一份访谈文档。
- 每次回答后更新场景锚点、假设清单和未决节点，再重新计算下一轮前沿。

“当前可问的问题”是前置依赖已经解决、现在回答不需要猜测其他未决答案的节点；这些节点共同组成当前的**决策树前沿**。每次回答后都要更新状态并重新计算前沿。

## 2. 严格区分事实和决策

### 事实由 AI 查

代码、文件、现有系统、公开资料或工具能够查明的事实，先做**足以解除当前节点阻塞的定点查证**，不要让用户替 AI 做检索工作。

竞品全景、行业扫描等系统性研究留到阶段 3；阶段 1 不提前展开整套调研。如果某项外部事实会阻塞产品方向，就只查这一项并记录来源；不阻塞的则登记为后续研究任务或显式假设。

只有用户亲历的场景、组织内部信息等确实只掌握在用户手里的事实，才向用户询问；这类问题允许开放回答，不要硬塞成选择题。

事实被确认“当前未知”后，不再换种说法重复询问。立即把它转成事实未决节点，指定真正能查明它的 `owner`、所需证据、可接受阈值和截止时间；能由 AI 查的立即查。阻塞节点在证据返回前保持未决，不能只写一句“后续验证”。

### 决策由用户拍板

用户、价值优先级、产品范围、风险接受和取舍等决定必须让用户明确拍板。AI 必须给建议，但**建议不是决定，更不能静默当成用户答案**。

- 用户说“这一题按你的推荐”属于对这一项的明确授权，记录推荐、理由和代价后继续。
- 用户说“剩下你都定”表示希望委托。先用一个问题确认**授权范围、采用的默认原则和仍需用户亲自拍板的高影响事项**；确认后，授权范围内的低/中影响决定由 AI 直接做并记录理由，不再逐题打扰。产品方向、核心用户、预算/时间硬约束、合规安全和重大风险接受默认不纳入笼统授权；用户看过代价后仍可对具体事项明确授权。
- 暂时查不到的非阻塞事实可以记录为显式假设，但必须写清依据、风险、验证方法，并让用户确认接受该风险。
- 阻塞产品方向的未知不能靠 `_TBD_`、默认值或 assumptions 伪装成已解决。

## 3. 按决策树前沿分轮提问

“前沿”是所有**前置依赖已经解决、此刻可以独立回答**的未决节点。每轮默认询问整个前沿，用简短编号列出；收到回答后先保存结果、更新决策树，再重新计算下一轮前沿。

- 同一前沿可以同时包含多个事实题和决策题；题量由真实前沿决定，**不设机械上限**，也不为凑数量加入低价值问题。
- 如果某题的问法或选项会被本轮另一题的答案改变，它就不在当前前沿，必须留到后续轮次；不得用“都相关”掩盖依赖关系。
- 发出问题前逐题做依赖预检：不仅检查题干，还要检查决策题的**推荐和选项**。只要本轮另一题的答案可能改变推荐、选项或是否该问，这道决策题就必须移到下一轮。
- 代码、文件、现有系统或公开资料能查明的事实由 AI 定点查证。能并行查就立即查；只让依赖该事实的节点等待，其他前沿节点照常询问，不让整轮被单项调查卡住。
- 只有用户掌握的内部事实、亲历场景和需要用户拍板的决定才进入提问。事实题允许开放回答；每个决策单独编号并给推荐、理由和代价。
- 每个编号只对应一个可独立关闭的节点。彼此独立的事实即使属于同一主题也分别编号，避免用户只答到复合问题的一部分；同一事实的时间、数量、对象等字段可以放在一个问题里。
- 用户明确要求逐个问或分批回答时，可以缩小本轮前沿，但仍不得越过依赖。用户只回答其中一部分时，先保存已答内容，未答节点继续保留，不重复询问已经解决的项。

一条高质量决策题包含：

1. **依据**：从用户原话、项目文件或证据中读到了什么；
2. **影响**：这一题会改变哪个范围、指标、成本或风险；
3. **推荐**：给出推荐答案，以及为什么推荐、放弃了什么；
4. **拍板**：提供 2–3 个清晰选项并允许自定义，然后等待用户选择。

优先使用当前工具可用的结构化提问能力；不可用时用纯文本。询问真实经历或补充事实时用开放问题，不编造选项、动机或经历替用户回答。

## 4. 让问题落到真实行为

下面是提高答案质量的微型技巧，不是新的必问清单。只在出现对应信号时使用：

- **行为证据优先**：用户表达的意愿与真实行为可能不一致时，追问最近一次具体发生了什么、现在如何绕过、已经投入过什么时间或金钱；不把“我觉得会”直接当作需求证据。
- **镜像模糊词**：回答很短或含糊时，只复述其中的关键词并问“你这里具体指什么？”先让用户补全，不急着分析或替他解释。
- **精确追问链**：抽象判断依次落到“最近一次真实案例 → 当时采取的动作 → 造成的结果 → 最小可接受条件”。链上的后续问题存在依赖，必须跨轮推进，不能一次全问。
- **一次可证伪重定义**：同一节点反复兜圈时，可以明确标成“我的一个假设”，提出一次能被事实证伪的重定义，请用户确认或否定；被否定后回到证据，不继续套心理解释。
- **问完即停**：普通访谈轮次以当前前沿的问题作为最后内容，不在问题后追加教学、结论、行动卡或下一轮预告，等用户回答。

## 5. 角色、方案前置能力与外部配置条件分支

角色不是职位清单。扫描所有直接使用者、买单者、客户管理员、内部运营/审核/客服和平台管理员；只要目标、可执行操作、可见数据范围或流程责任不同，就拆成不同角色。若这些维度相同则合并，禁止为了显得完整硬拆。关闭该分支前必须明确得出“单角色 + 不拆理由”或“多角色 + 各角色边界”；不直接使用产品的买单者也要标成间接角色，不能伪造用户故事。

评估中的候选方案只要依赖外部服务、平台账号、资质、证书、硬件或组织资源，就先创建“方案前置能力”事实节点，再把“是否采用该方案”作为依赖它的决策节点。AI 先定点查证平台规则、接入条件等公开事实；只向用户询问现有资源、申请意愿、负责人、预算和时间等内部事实。进入 MVP 的每项前置能力必须记录当前状态、负责人、可核验证据或承诺截止时间、不可用时的替代方案、所属阶段和阻塞的 REQ。阻塞产品方向的前置能力未解决时，不得用默认值把候选方案写进 MVP。

条件触发示例只用于防漏，不是全项目清单：

- 选择短信、邮件或第三方账号注册/登录前，先确认相应通道、平台账号和运营责任是否具备；没有短信通道不等于自动改成账号密码，必须比较密码、邮件、第三方登录、邀请制、游客模式或暂不注册等真实可行方案，再让用户拍板；
- 选择 iOS/Android 原生交付前，先查证目标分发方式的公开要求，再确认开发者账号、签名/证书和发布责任是否具备；如果仅做原型或暂不发布，应把正式分发明确后置，而不是假设账号自然会出现；
- 支付、推送、地图、硬件和行业资质同理，只在候选方案真实依赖它们时触发。

识别到需要凭据或运行配置的外部能力（如 LLM、支付、短信、邮件、地图、对象存储）时，创建“外部能力配置责任”节点。AI 先根据部署和使用场景给推荐，再只让用户拍板会改变产品范围的决定。每项能力必须明确：

- 凭据由平台、客户、最终用户还是内部技术团队提供；
- 谁配置，以及作用于系统、租户、用户还是项目；
- 通过部署密钥、首次引导、普通设置页还是管理后台配置；
- 添加、验证、掩码展示、更新、删除/轮换及失效反馈中哪些是产品行为；
- 属于 MVP、后续阶段还是明确不做。

`deployment-secret` 是内部统一部署时的合法答案；客户或用户需要自助配置时，环境变量不是替代方案。不要因为“用了外部服务”就默认建设管理后台，也不要因为技术上能用环境变量就默认不做配置界面。

## 6. 沿同一分支追到清楚

关闭一个分支前，按该分支的性质检查**相关项**；不是每个回答都必须机械满足全部四项：

- **问题/场景分支要具体**：能说清谁、在什么情境、当前怎么做，最好能讲最近一次真实案例；
- **目标分支要可观察**：能说明什么变化算成功，包括基线、目标和时间窗，或明确的验证计划；
- **范围分支要有边界**：知道第一版做什么、不做什么，以及关键例外；
- **决策分支要有取舍**：知道为什么选这个、没选什么、主要代价和风险是什么。

简单事实得到可信答案即可关闭，不追问与它无关的指标、边界或取舍。只对当前分支仍缺少的相关项继续追问。

对“差不多、应该、都可以、提升体验、以后再说”等回答，不换话题、不替用户补完。根据缺口继续追问真实案例、最小可接受条件、反例、失败后果或会推翻当前判断的证据，直到该节点真正 resolved。

## 7. 停止闸门

结束前只展示一次紧凑的**闸门证据表**，列出问题/场景、用户/买单者、成功标准、首版边界、关键约束、重大假设六类的 `Clear / Partial / Missing`、依据和对应未决节点。`Clear` 必须指向用户原话、查证来源或已确认决定；不能因为 Agent 没把问题写进 `open_questions` 就自判为 Clear。证据表由现有状态生成，不新增文档。

只有同时满足以下条件，阶段 1 才能结束：

1. 问题、核心用户、决策者/买单者、真实场景和当前替代方案已经明确；
2. 成功标准有可观察结果，关键指标有基线/目标/时间窗，或有用户明确接受的验证计划；
3. 已明确单角色/多角色结论；各直接角色的目标、操作、数据边界和流程责任没有互相混用；
4. 第一版范围、明确不做、资源/时间、系统依赖和安全合规等关键约束已经明确；候选方案依赖的前置能力已有状态、负责人、证据或截止时间、替代方案、阶段和阻塞需求；涉及外部能力时，其凭据归属、配置角色、入口、作用域、生命周期和所属阶段均已决定；
5. 会改变产品方向或造成重大返工的假设，要么有证据，要么已由用户明确接受风险和验证计划；
6. `state.json.open_questions` 中没有阻塞阶段 2 的 P0/P1 未决节点；
7. AI 展示“已确认的共同理解 + 仍保留的非阻塞假设”，用户明确确认没有漏掉关键问题。

没过闸门就继续问，并具体说明“当前还没问清的是 X，它会影响 Y”。问题数量、耗时、用户一句“差不多了”或模型感觉疲劳，都不是结束理由。

用户要求暂停时，保存已确认结论、未决节点，并把本轮问题与仍在运行的事实查证写入 `state.json.next_action`；状态标记为暂停，不能标记阶段 1 已完成。