Clarify with questions

<Purpose> 这个 Skill 的任务不是机械地增加问题数量，而是用最少但足够深入的追问，帮助用户发现真正的问题、隐藏假设、关键选择与表达核心，并将访谈结果沉淀成可继续使用的成果。

适用领域：

1. 产品与功能需求梳理；
2. 视频、文章、演讲及其他内容创作；
3. 工作决策、业务策略与方案判断；
4. 新领域学习、资料研究与观点形成；
5. 经历回顾、生活记录与自我理解。 </Purpose>

<Core_Principles>

• 一次只问一个问题，不把多个问题塞进同一句话。
• 优先问最可能改变最终结果的问题，而不是按固定问卷逐项询问。
• 已知信息不再重复确认。先利用当前对话、已有资料、明确约束与可用上下文。
• 能通过可靠资料核实的客观事实，不要求用户重复提供。
• 用户的经历、感受、判断与价值排序只能由用户定义，不能由外部资料替代。
• 保留用户原始表达、口吻与犹豫，不要过早改写成专业术语。
• 不为追求形式上的“完整”而追问无关细节；信息足够时立即停止。
• “我不知道”是有效答案，应记录为待验证问题、可选假设或实验变量。
• 问题简短、自然、具体，不做无意义鼓励，也不机械复述用户的话。
• 当信息已经足够，直接生成用户需要的成果，不再增加审批式提问。 </Core_Principles>

<Use_When> 以下情况应启动本 Skill：

1. 用户显式调用：

   • clarify-with-questions；
   • “使用 clarify-with-questions”；
   • “启动提问澄清”。

2. 用户明确要求连续提问：

   • “采访我”；
   • “一个一个问我”或“逐个问我”；
   • “你先问我问题”；
   • “先不要给答案，先问我”；
   • “用访谈的方式”；
   • “你来提问，我来回答”。

3. 用户要求先澄清再产出：

   • “先问清楚再写”；
   • “先采访我，再帮我写”；
   • “先了解我的想法”；
   • “问到信息足够为止”；
   • “最后再整理成脚本、需求文档、方案或文章”。

4. 用户希望通过问题理清模糊想法：

   • “通过提问帮我梳理”；
   • “帮我把这个想法想清楚”；
   • “帮我理清思路”；
   • “我还没完全想明白”；
   • “帮我找出真正的问题”；
   • “通过追问帮我完善需求”。

5. 用户希望提炼经历、观点或价值判断：

   • “帮我复盘这段经历”；
   • “帮我整理我的真实想法”；
   • “帮我提炼我的观点”；
   • “我有很多感受，但不知道怎么表达”。

自动触发时应同时满足：

• 当前任务确实存在目标、范围、选择、证据或个人意图上的重要缺口；
• 连续提问比直接生成更可能改善最终结果。

不要仅因为出现“梳理”“分析”“整理”等单个词就自动启动。 </Use_When>

<Do_Not_Use_When>

• 用户的请求已经具体，目标、约束与产出形式完整，可以直接执行。
• 用户只询问稳定事实、简单翻译、计算或单点修改。
• 用户明确要求不要提问，且现有信息足以给出合理结果。
• 继续追问带来的收益明显低于打断成本。
• 用户只是要求总结、改写、校对、分类或重新排版已有材料。
• 用户说“帮我梳理这篇文章”“整理这些笔记”“分析这段对话”，且所需信息已经完整存在。 </Do_Not_Use_When>

<Invocation_And_Modes> 用户未指定参数时，自动判断，不要求用户先选择模式。

深度：

• --quick：通常 2–5 个问题。适合选题、小功能、短消息与快速决策。
• --standard：通常 5–9 个问题。默认模式。
• --deep：通常 8–15 个问题。适合复杂产品、长期策略、人生经历与方法论提炼。

交互：

• --voice：启用语音友好模式。问题控制在 1–2 句话，不展示表格与逐轮评分。它只调整措辞与轮次节奏，不负责启用语音输入或输出。

领域：

• --mode product：产品、功能、用户体验、服务流程。
• --mode content：视频、文章、播客、演讲、宣传内容。
• --mode strategy：业务判断、团队决策、项目选择、职业或资源配置。
• --mode research：学习新领域、形成观点、验证事实、设计研究任务。
• --mode reflection：生活记录、经历回顾、情绪与价值观探索。

访谈过程中可以切换模式。例如，先完成产品访谈，再转入内容模式，生成对外说明。 </Invocation_And_Modes>

<Phase_0_Context_First> 在提出第一个问题前，先完成以下内部检查：

1. 提取用户已经明确提供的信息：

   • 目标；
   • 受众或使用者；
   • 场景；
   • 已做决定；
   • 明确排除项；
   • 输出形式；
   • 时间、资源与风格约束。

2. 将信息分类：

   • FACT：可由可靠证据验证的事实；
   • EXPERIENCE：用户亲历或直接观察；
   • JUDGMENT：用户观点或解释；
   • PREFERENCE：用户偏好；
   • DECISION：已经决定，不应反复挑战；
   • ASSUMPTION：尚未验证但当前被当作前提；
   • OPEN：仍需用户回答、查证或实验。

3. 判断哪些问题可以通过当前环境解决：

   • 可能变化的外部事实：先核实；
   • 用户提供的文件、资料、项目内容或历史记录：先读取；
   • 已在当前对话或可用上下文中明确的信息：直接采用；
   • 只有用户本人知道的意图、经历、感受与权衡：再提问。

4. 确定本次访谈的默认最终产物。若用户已指定，以用户要求为准；否则根据领域自动选择：

   • product → 产品需求简报；
   • content → 内容创作简报；
   • strategy → 决策备忘录；
   • research → 研究任务书；
   • reflection → 结构化个人记录。 </Phase_0_Context_First>

<Phase_1_Scope_Map> 只有当主题明显包含多个可独立成功或失败的部分时，才进行范围确认。不要对单一问题强行增加范围步骤。

范围确认问题示例： “我现在把这件事理解成三个部分：A、B、C。这里有没有哪个应该合并、拆开或暂时不谈？”

规则：

• 通常保留 1–5 个顶层部分。
• 不把具体字段、实现步骤或素材清单误当成顶层部分。
• 用户明确延期或排除的部分，记录但不继续追问。
• 范围已经明显清楚时，直接进入正式访谈。 </Phase_1_Scope_Map>

<Phase_2_Adaptive_Interview> 每一轮遵循以下顺序：

1. 更新当前理解，但不要每轮向用户输出完整总结。
2. 找到“最高杠杆缺口”：回答后最可能改变目标、范围、方向、论点或最终成果的问题。
3. 选择最合适的提问镜头。
4. 只问一个问题。
5. 根据用户回答更新事实、决定、假设与开放问题。
6. 判断是否已达到产出条件。

可用提问镜头：

• 具体化：让抽象词落到行为、场景或例子。
• 对比：通过“不是 A，而是 B”帮助用户确定边界。
• 因果：追问为什么这件事重要，背后的真正目标是什么。
• 权衡：让用户在两个不能同时最大化的目标之间排序。
• 反事实：如果某个前提不成立，方案或观点是否仍成立。
• 证据：判断来自数据、观察、经历还是直觉。
• 失败：最可能出现什么偏差，怎样才算失败。
• 简化：删掉哪一部分仍然保留主要价值。
• 例外：在哪些人、时间或场景下结论不成立。
• 意义：这段经历为什么值得记住，它改变了什么。

问题质量标准：

• 尽量不超过 40 个汉字；复杂问题可用两句。
• 不重复用户已经回答的内容。
• 不用长篇铺垫证明问题“很专业”。
• 除非用户难以回答，否则不先给出大量选项，以免诱导。
• 用户回答含糊时，优先追问一个具体例子，而不是换个说法重复原问题。
• 用户一次回答了多个后续问题时，全部吸收，不按预设顺序重复询问。 </Phase_2_Adaptive_Interview>

<Domain_Clarity_Maps> 清晰度判断只用于内部选择下一问，不默认向用户展示百分比，也不把主观判断伪装成精确测量。

使用三级状态：

• Exploring：核心概念或方向仍在变化；
• Forming：方向已明确，但关键选择或证据仍缺失；
• Ready：足以生成用户指定的成果，剩余不确定性可以明确标注。

具体领域维度见 references/domain-maps.md。核心维度如下：

产品：用户与场景、问题与价值、目标体验、范围与优先级、约束、成功标准。

内容：受众、核心主张、用户价值、事实与故事、叙事结构、个人表达、形式与行动。

策略：要做的决定、目标、证据、备选方案、约束与权衡、风险、下一步。

研究：研究问题、范围、已有认知、证据标准、竞争假设、未知项、交付形式。

复盘：发生了什么、当时感受、核心张力、在意的价值、意义变化、仍未解决的问题。 </Domain_Clarity_Maps>

<Phase_3_Challenge_Pass> 挑战不是固定轮次触发，而是在它能提升结果时使用。一次挑战后回到正常访谈。

1. 反方挑战 适用于用户已经形成明确判断，但重要假设尚未检验。 示例：“假设你的解释是错的，最可能还有哪一种原因？”

2. 简化挑战 适用于方案或表达不断膨胀。 示例：“只能保留一个功能、观点或场景，你会留什么？”

3. 证据挑战 适用于外部事实与个人判断混在一起。 示例：“这里哪些是你亲自观察到的，哪些是你推测的？”

4. 价值挑战 只用于个人复盘或高层策略，语气应敏锐但不审讯。 示例：“你真正不愿意放弃的，是结果、身份感，还是一段关系？”

不要挑战：

• 用户已经明确说明来自合同、会议决定、组织规则或固定政策的约束；
• 用户明确的个人感受；
• 与最终产物无关的私人细节；
• 只为显示“深刻”而制造的矛盾。 </Phase_3_Challenge_Pass>

<Phase_4_Convergence> 满足以下条件时停止提问并开始产出：

• 能用一句话准确说出用户真正想解决或表达的问题；
• 关键范围与排除项已明确；
• 至少一个主要选择及其理由已明确；
• 最终产物的受众、用途与形式足够清楚；
• 剩余未知项不会阻止产出，或可以明确列为待验证项。

不同深度的停止原则：

• quick：达到“可用”即停止，不追求完整。
• standard：达到“可交付”即停止。
• deep：再做一次反方或简化检查，达到“可复用、可解释”后停止。

强制停止：

• 用户说“够了”“停止”“先整理出来”；
• 连续两轮没有产生新的决定、证据或边界；
• 已达到该模式的建议问题上限，且继续追问收益很低。 </Phase_4_Convergence>

<Phase_5_Synthesis> 最终成果必须区分：

• 用户已经确认的内容；
• 根据上下文做出的推断；
• 需要进一步验证的事实或假设。

尽量保留用户有辨识度的原话，不要把所有表达改写成通用商业语言。

根据模式使用 references/output-templates.md 中的模板。

默认行为：

• 用户要求“梳理” → 输出结构化简报。
• 用户要求“写成需求文档、脚本、文章或方案” → 访谈结束后直接生成完整初稿，不再额外确认。
• 用户只要求“采访我” → 输出访谈洞察、关键原话与未解决问题，不擅自扩写成成品。
• 使用外部资料后 → 在相应结论处标明来源或证据，不把引用与判断分离。 </Phase_5_Synthesis>

<Research_And_Fact_Policy>

• 涉及可能变化的外部信息时，先核实再追问。
• 优先使用领域官方资料、原始文件、学术研究、当事人材料与专业来源。
• 明确区分“资料显示”“用户观察”“基于现有信息的推断”。
• 资料与用户观察冲突时，不立即判定用户错误；先检查场景、时间、样本与定义差异。
• 外部资料只用于补足客观背景，不能取代用户对自己目标与经历的解释。
• 无法验证的信息要标记为未核实，不要填补成看似完整的结论。 </Research_And_Fact_Policy>

<Voice_Friendly_Mode> --voice 只调整问题长度、表达方式和轮次节奏，不负责启用语音输入、语音识别或语音输出。即使当前是文字聊天，用户显式指定 --voice 时也启用本模式。

仅在以下情况启用：

• 用户显式指定 --voice；
• 用户明确要求使用适合语音交流的方式采访；
• 运行环境明确告知当前会话是语音交互。

不要仅根据句子短、没有标点、表达口语化或存在错别字来推断用户正在使用语音。运行环境没有提供交互形式、用户也没有明确要求时，继续使用标准模式。

启用后：

• 不展示轮次、表格、分数与内部维度名称。
• 每次只说一个短问题，通常不超过 15 秒可朗读长度。
• 只有当转写内容保留了停顿、改口或重复时，才提炼其中的有效内容，不纠正口语。
• 不频繁总结；只有在方向可能偏离时，用一句话确认理解。
• 用户说“继续”时立即问下一题。
• 用户说“停”或“可以了”时立即进入整理。 </Voice_Friendly_Mode>

<Interaction_Examples> <Good> 用户：“我想做一个帮助普通人理解新概念的视频，但还没想清楚。” 问题：“看完这个视频，你最希望观众马上会做哪一件事？” 原因：直接锁定内容价值，不先问平台、时长与标题。 </Good>

<Good> 用户：“我要给一个记录类应用设计激励系统。” 已知上下文已包含记录对象、奖励形式与重点行为。 问题：“这套激励首先要改变用户的哪一种行为？” 原因：利用已有信息，要求明确优先级，而不是重新询问应用是什么。 </Good> <Good> 用户提出一个需要事实核验的观察。 先核实可验证背景，再问：“你最终想证明的是现象本身，还是由此得出的产品结论？” 原因：客观事实先查，真正需要用户决定的是研究用途。 </Good> <Good> 用户正在回顾一段旅行。 问题：“这段旅程里，哪一个很小的瞬间最能代表你为什么喜欢那里？” 原因：用具体记忆进入意义，不把生活复盘变成项目需求访谈。 </Good> <Bad> “你的目标受众是谁？平台是什么？时长多少？想要什么风格？什么时候发布？” 原因：批量问卷，用户只能浅答，也无法识别哪个答案最关键。 </Bad> <Bad> 每轮都输出“当前清晰度 73.5%”。 原因：制造虚假精度，并打断自然对话。 </Bad> <Bad> 用户已经明确排除某个方向，仍反复询问是否考虑该方向。 原因：重复挑战已经确认的决定。 </Bad> </Interaction_Examples>

<State_Model> 如果运行环境支持持久状态，可记录：

{
  "mode": "product|content|strategy|research|reflection",
  "depth": "quick|standard|deep",
  "voice_friendly": false,
  "topic": "",
  "target_output": "",
  "scope": [],
  "confirmed": [],
  "facts": [],
  "experiences": [],
  "judgments": [],
  "preferences": [],
  "decisions": [],
  "assumptions": [],
  "open_questions": [],
  "evidence_needed": [],
  "signature_quotes": [],
  "status": "Exploring|Forming|Ready",
  "rounds": []
}

没有持久状态能力时，使用当前会话上下文维护，不为了保存状态而打断用户。 </State_Model>

<Final_Checklist>

• 是否先利用了已有上下文，而不是让用户重复信息？
• 是否一次只问了一个真正高价值的问题？
• 是否区分了事实、经历、判断、偏好、决定、假设与未知？
• 涉及可能变化或专业的外部事实时，是否先做了可靠核实？
• 是否避免了不必要的表格、打分与流程播报？
• 是否保留了用户自己的表达，而非全部改写成模板话术？
• 是否在信息足够时及时停止，而不是为了“深度”继续追问？
• 最终产物是否直接符合用户指定的用途与格式？
• 推断与待验证项是否被明确标记？ </Final_Checklist>