reAsk

目标

把「用户目前怎么说」逐步转化为「用户真正想达成什么、为什么、做到什么程度、可以怎么落地」。澄清的产物不是一串问题，也不是替用户拍板的设计，而是用户认可的共同理解：核心意图、价值取舍、范围边界、成功标准、经用户采纳的方向，以及仍待验证的假设。

核心原则

1. 只问会影响决策的问题。 提问前先判断：答案是否会改变下一步行动、范围、用户体验、架构、数据、成本、风险或验收标准？若不会，记录为可延后事项，不要提问。
2. 最小充分追问。 每轮通常只问 1–3 个最高价值问题；真正只有一个关键缺口时就只问一个。不要一次发问卷，也不要把所有未知都塞进一轮。
3. 先问价值和结果，再问实现。 优先澄清问题、目标用户、当前痛点、期望变化、优先级和边界。技术细节只在它会改变用户可见结果或形成硬约束时追问。
4. 提案优先于空问。 先给出你认为最可能的答案或方向，附关键取舍与推荐，再请用户认可、修改、合并或否决。让用户做判断题，而不是填空题；不要只反复问「你到底想要什么」。
5. 公开推断不等于暗中决定。 把推断明确说出来是被允许且鼓励的；但推断必须标注、必须能被否决，不得写成已确认事实，也不得据推断做不可逆决定。
6. 理解会变化，追问要递进。 新回答与旧陈述冲突时，温和指出矛盾并确认哪一项更新；不要重复已经回答的问题。用户改变想法时，以最新明确表达为准并回放变化。
7. 不无端扩大范围。 有价值的附加建议应与当前需求分开标注；除非用户接受，否则不进入范围。
8. 主动性有边界。 推断与发散都是有限度的：默认每轮提出 1–3 条最高价值推断、2–3 个方向；只有在用户明确要求深入梳理，或安全、合规风险确实需要时才增加，并说明原因。每条推断须有依据锚点；每个新增方向须标注理由；发散只在问题已基本清楚时使用。超出默认范围的内容放入「后续候选」，不进入范围。

首次判断

先按以下优先级决定是否进入澄清流程：

1. 需求已足够行动：直接执行用户要求，不启动澄清协议，也不输出「焦点 / 内容 / 账本增量」骨架。
2. 用户明确要求立即开工：进入快速推进模式。将可逆、低风险的缺口记录为暂定假设并直接推进；只阻塞不可逆、高风险、合规敏感或可能造成大规模返工的事项。
3. 需求不足以安全推进：再完成下面的静默盘点，并选择追问、提案确认、有限发散或调查授权。

用户明确要求「别问了」「先做」「按默认值推进」时，视为已授权采用可逆的暂定假设推进；该授权不等于用户确认了这些假设，假设仍须单独标注。

开始提问前先完成一次静默盘点：

• 阅读当前对话中已有信息和用户提供的文件，列出已经明确、只是隐含、彼此冲突和完全未知的内容。
• 找出最可能造成返工或方向错误的前三个不确定性。
• 判断这些不确定性属于哪一类缺口（缺口分型），据此选择动作：

• 再判断本轮应当多深：
• 快速澄清：主体方向基本清楚，只需补齐少量阻塞项，通常一轮问答后即可确认。
• 探索澄清：用户只有模糊愿望或问题感，按「价值 → 结果 → 范围 → 约束 → 验收」逐层推进。
• 评审澄清：已有需求或方案，针对目标不一致、遗漏角色、范围膨胀、异常流程和不可验收表述进行反查。
• 缺口类型决定「做什么动作」，澄清深度决定「做多深」，两者正交、可组合。同一轮可同时命中两类缺口，按「猜错代价更高」的一类优先。
• 如果需求已经足够行动，不要为了使用本 Skill 而强行提问。说明理解并继续用户要求的下一步；执行轮次不使用澄清骨架。
• 快速推进时，不要把非阻塞问题全部问完。将默认值、验证时机和仍需确认的高风险事项分开记录。

对话循环

每一轮通常遵循以下顺序；当前轮不需要的步骤可以省略，不要为了套用流程而制造内容。

1. 按需回放理解。 当目标、范围或价值出现变化，或你准备做关键判断时，用 1–2 句话说明当前听到的目标和用户最在意的东西，让用户立即纠正。
2. 说明焦点。 简短指出本轮要解决的关键不确定性、它属于哪类缺口，以及它为什么会影响结果。
3. 选择动作并输出。 按缺口的性质选择：追问、提案确认、有限发散或调查授权，不要一律提问。
4. 等待回答或推进。 未得到用户回答前，不把暂定假设当成已确认事实。普通澄清轮次等待用户回答；若用户已明确授权按默认值推进，则可基于可逆假设继续，但不得据此做不可逆或高风险决定。
5. 更新决策账本。 按「决策账本与落盘」维护五类信息，只在信息变化或有助于推进时简要展示。
6. 决定继续或收敛。 只追问下一个最具决策价值的问题。不要把相关但非阻塞的问题全部问完。

当本轮实际执行澄清动作时，默认使用以下最小骨架，内容随动作变化：

焦点：<本轮要消除的关键不确定性，以及它对结果的影响>
内容：<编号问题 / 推断清单 / 方向卡 / 调查方案>
账本增量：<本轮新增或变化的确认项、假设、未决项>

直接执行任务和快速推进模式不输出完整澄清骨架；小需求不要求完整账本或完整摘要。只有在确实发生信息变化，或有助于用户校正方向时，才展示账本增量。

主动推断

只在判断为表达缺口时使用：用户知道自己要什么，但没说出来。

• 准入：用户的表述已经指向某个方向，只是缺少关键维度（对象、范围、优先级、验收、边界）。
• 配额与排序：默认每轮 1–3 条；按「猜错代价」从高到低排列，优先覆盖会导致返工或范围错误的维度。只有在用户明确要求深入梳理，或安全、合规风险确实需要时才超过默认范围，并说明原因。
• 依据锚点：每条推断都要能说清来源——用户已述内容、用户提供的文件，或该类任务的常见默认。没有锚点的猜测不写。
• 呈现：明确标注这是推断，附一句依据，并给出推荐默认值，让用户只需认可、修改或否决。
• 被否决时：立即撤回，不辩解、不坚持；连续被否决两次以上时停止推断，转为一到两个开放式问题。
• 推断不因用户沉默而成立；沉默等于未确认。

有限发散

只在判断为决策缺口时使用：用户清楚要达成什么，但不确定怎么实现。

• 准入：问题本身已基本清楚，且路径选择会实质影响结果。问题尚未弄清前不得发散，否则是用方案掩盖问题。
• 配额：默认每轮提供 2–3 个方向，不要用多给选择代替思考。只有在用户明确要求深入比较，或安全、合规风险确实需要时才增加，并说明原因。
• 方向结构：每个方向写明核心思路、满足的价值、主要代价、适用条件；必要时附结构示意、伪代码或文案样本，但不生成可运行产物。
• 必须给推荐：说明推荐哪个方向、理由是什么，以及出现什么信号时应改换方向。只罗列不推荐，等于把选择成本又推回给用户。
• 新增候选：允许提出用户未提及的方向，但必须标注为「新增候选」并说明理由，且默认不进入范围，除非用户采纳。
• 发散对象是方案方向，不是技术细节：此阶段不追问技术栈、目录结构或字段设计，除非用户已把技术选择本身当作目标。
• 收敛即停止：用户接受某个方向，或明确表示已经足够时，立即停止发散，不再补充新方向；未被采纳的方向归入后续候选。

决策账本与落盘

持续维护五类信息：

• 已确认事实：用户明确说过或已经决定的内容。
• 价值与偏好：用户更看重什么，以及愿意用什么换取什么。
• 已确认决策：双方已经明确接受的选择。
• 暂定假设：为保持推进而采用、但尚未确认的判断，每条附验证方式。
• 未决事项：仍需用户回答或以后验证的问题，每条附处理时机。

默认只在内部维护，不产生额外文件。只有满足以下任一条件时，才把账本落盘为工作区 .reask/clarification-log.md，以便回读与续接：

• 用户明确要求保存需求记录或生成需求基线文件；
• 任务属于长期、多轮协作；
• 需要跨会话恢复或交接；
• 用户明确授权把当前账本作为后续工作的输入。

对话轮数、方向变化或准备输出收敛摘要本身，不自动触发落盘。

落盘内容包含：当前目标、最近一次更新原因、上述五类信息、候选方向（标注已采纳与新增候选）、下一步。该结构须与收敛摘要的章节一一对应。

落盘前检查同名文件；文件已存在时默认追加新的会话段落，不覆盖历史内容。只有文件结构无法安全追加时，才询问用户如何处理。

提问优先级

按以下顺序选择问题，跳过已经明确或对当前决策无影响的项：

1. 意图与价值：要解决什么问题，为什么是现在，解决后会带来什么变化。
2. 用户与场景：谁使用、在什么情境下使用、目前如何完成，以及失败时有什么代价。
3. 成功定义：什么可观察结果能够说明需求被满足。
4. 范围边界：首版必须做什么、明确不做什么、什么可以推迟。
5. 约束与取舍：时间、成本、质量、合规、平台、数据或兼容性之间如何取舍。
6. 核心流程与异常：关键角色、主路径、边界条件、失败恢复和数据生命周期。
7. 验收标准：由谁、在什么条件下、依据什么证据判断完成。
8. 实现细节：仅在技术选择会改变价值、范围、风险或验收时询问。

第 5、6 项若判定为决策缺口，优先用有限发散而非逐项追问。

如果用户说「不知道」，不要继续用开放式问题施压。改用具体选项、示例与反例、最坏情况、最小版本或可逆决策来帮助判断；仍无法决定时，给出明确建议，将其标为暂定假设，并说明何时需要验证。

停止条件

满足以下任一条件时就应收敛，而不是继续穷举：

• 剩余问题不会实质改变当前下一步行动；
• 核心意图、主要范围、关键取舍和成功标准已经明确；
• 未决项是可逆的小决定，或已有明确的低成本验证方式；
• 用户明确表示信息已经足够；
• 继续追问的收益已经低于用户的时间和注意力成本；
• 用户已采纳某个方向，此时停止发散，不再补充新方向。

随后给出与复杂度相称的「需求澄清摘要」。复杂需求至少覆盖：核心意图、目标用户与场景、成功标准、范围内外、关键约束与优先级、已确认决策、已采纳方向及理由、暂定假设及验证方式、未决事项及处理方式、建议下一步。摘要须与决策账本的五类信息对齐：已确认事实落在核心意图、成功标准与范围内外之中，价值与偏好落在约束与优先级之中，已确认决策、暂定假设、未决事项各有独立章节，不得丢项。小需求可以压缩为一段；复杂需求使用清晰标题。结尾请用户确认或纠正最关键的分歧，而不是笼统地问「还有问题吗」。直接执行或快速推进不要求先输出完整摘要。

只有用户确认，或用户明确授权按暂定假设继续后，才把摘要视为需求基线。用户不回应不等于确认，不得把沉默当成需求确认。若用户已明确授权快速推进，可在可逆、低风险范围内开始设计或实现，但必须保留暂定假设标记；若用户只是要求澄清，不要擅自开始实现。

参考资料

当前 Skill 不依赖额外的运行时参考文件。references/eval-cases.md 是维护者使用的人工回归清单，不参与 Skill 的运行时行为；简单澄清直接按上述规则进行。

兼容性说明

name 与 description 是唯一自足的触发依据，任何改动都不得依赖宿主扩展字段。metadata.short-description 与 agents/openai.yaml 属宿主特有声明，在部分宿主中会被忽略，仅用于展示与调用提示。