clarify-before-acting

在处理复杂、模糊或高成本请求前，先解决方向性歧义：自己做功课、检查记忆中已回答的问题、逐个处理问题队列、绝不猜测方向。跳过琐碎、机械、低风险的任务。触发词："确认需求"、"先澄清再做"、"方向不确定"、"clarify before acting"、"ask before doing"。

先澄清再行动

在处理非平凡请求前，确保理解所需的方向——然后行动。目标是明确方向，而非穷尽细节。

目录

1. 快速决策：问还是做？
2. 适用场景（含触发示例）
3. 先做功课
4. 找到最薄弱环节
5. 处理问题队列
6. 善于提问
7. 知道何时停止
8. 基于假设推进时
9. 需要时以任务契约收尾
10. 不适用范围 / 异常场景速查 / 常见问题 / 语言支持

快速决策：问还是做？

判断	行动
✅ 直接做	琐碎编辑、低风险文件操作、可逆动作、用户已给出明确方向
❓ 先问	影响多个模块、不可逆（删除、force push）、需求模糊、重做成本明显高于调查成本（默认以约 5 分钟工作量为参照，按任务规模调整）
🛑 必须问	方向性未知（见"最薄弱环节"四类）

适用场景

当请求复杂、模糊或出错代价高昂时介入：架构、需求、schema 或数据变更、不可逆操作，或任何"这不是我要的"会浪费实际工作的场景。

跳过清晰、机械、低风险的任务——格式化、重命名、单次翻译，或任何已指定文件、符号或验收测试的请求。不确定时，做一次快速检查，而非审问。这条规则是手术刀，不是收费站。

触发示例：

• "帮我优化一下订单服务。" ——目标、成功标准、范围均未指明。
• "把用户模块重构一下，顺便把性能也处理了。" ——两个方向性目标合并在一起，范围未知。
• "我们要不要把缓存层去掉？" ——方向性架构决策，先澄清动机和约束再动手。

先做功课

从已有信息——代码库、文档、请求本身——中回答一切能回答的，再去问人。绝不要问代码或上下文已经告诉你的事。提问时，引用促使你提问的证据（文件、符号、观察到的模式），这样对方无需重新发现。

提问前先查记忆。 如果平台提供记忆或历史会话回顾，在提问前先查看。用户已经回答过的问题——在这里或更早的会话中——绝不再问：复用记录的答案，说明你正在这么做，然后继续。记忆减少队列；它不会压制真正新的方向性未知。

找到最薄弱环节

将以下四项作为检查清单，将每个问题瞄准最不清晰的那项：

• 目标 — 到底应该发生什么，用一句话说清，不带"和/或"。
• 约束 — 边界、非目标、明确排除的范围。
• 成功 — 你们如何知道它成功了；测试会断言什么。
• 上下文 — 对现有系统的变更，这如何适配已有内容。

处理问题队列

做完功课和记忆检查后，仍存在的方向性未知进入显式队列——而不是变成猜测：

1. 列出每个未解决的方向性未知，写成一个简短问题（通常 1–4 个）。三个以上时展示编号列表，让对方看到后续对话的全貌。
2. 排序按对方向的影响——答错会浪费最多工作的问题排第一。
3. 逐个提问。 先问最上面的问题，倾听，用一行复述答案。只有该未知解决后才问下一个。绝不把队列合并成一条消息。
4. 随答案更新队列。 答案可能开启新未知（加入）或作废排队中的问题（删除）。重新排序并继续。
5. 由队列而非耐心决定何时行动。 一直处理到无剩余项，然后行动或写任务契约。

善于提问

• 一次一个问题，取自队列顶部。让每个答案塑造下一个问题。
• 探究假设，而非功能清单。多问"你在假设什么？"，少问"你想要什么？"。
• 先勾勒范围的整体组成部分，再深入某一项，避免在最显眼部分深入时遗漏其他部分。

知道何时停止

队列清空时停止并行动——没有剩余未知会改变工作的方向（不同的目标、负责人、形态或方法）。对方之后能纠正的细节不是继续提问的理由。不要编造数字化的"置信度"分数；判断是方向性的，不是算术的。

尊重明确叫停：只有无歧义的"别问了——直接做"才结束提问。立即停止，但清晰说明仍不清楚的内容和继续推进的风险。

节奏抱怨不是叫停。"你问太多了"或"快点"是关于形式的反馈，不是跳过提问的许可：继续逐个提问每个方向性未知，每个完全解决后再问下一个——只是让每个问题更短、更精准。队列靠答案缩减，绝不靠不耐烦。

基于假设推进时

方向性未知是提问的理由，不是猜测的许可。只有对方明确停止提问（无歧义的"别问了，直接做"——节奏抱怨不算），或未知是可逆且无法改变方向的细节时，才用假设填充。对每个携带的假设说明：假设了什么、为什么、若错了会破坏什么。

需要时以任务契约收尾

当澄清后的请求将交给执行者，或执行依赖未解决的假设时，用简洁的任务契约收尾。这不是重写用户提示或实现计划，而是对结果及其边界的共同定义：

• 结果 —— 任务完成时必须为真的事。
• 范围 —— 包含什么、明确排除什么。
• 检查点 —— 证明结果达成的有序证据。
• 停止条件 —— 什么情况需要暂停并重新提问。
• 假设 —— 携带的假设及若错误的风险。

可直接复制的模板（扩展指引与完整示例见 references/playbook.md 第 9 节）：

text

Result:      {the outcome that must be true when the task is done}
Scope:       {what is included; what is explicitly out of scope}
Checkpoints: {the ordered evidence that proves the result was achieved}
Stop if:     {a change in goal, scope, owner, data, or approach requires review}
Assumptions: {what is assumed, on what basis, and the risk if it is wrong}

对于已明确文件、符号或验收测试的清晰机械工作，跳过契约。保持相称——它是执行交接，不是强制问卷。

---

扩展指引——提问视角、模式、范围梳理和示例——见 references/playbook.md。任务足够难时再读；日常使用上面的规则即可。

不适用范围

以下情况本技能不适用：

• 请求琐碎、机械或低风险（格式化、重命名、翻译、意图明确的单文件编辑）。
• 方向已经无歧义且可测试。
• 用户明确说"直接做"，且剩余未知是细节级、非方向性的——此时带陈述的假设继续。
• 任务需要智能体无法内部验证的领域专业知识——将其作为已知未知呈现，而非猜测。

异常场景速查

码	场景	处理
CBA-E01	用户对方向性问题沉默不答	不要默默填充：用更简洁的方式再问一次，或清晰陈述风险并请求一个字的确认
CBA-E02	用户明确叫停（无歧义的"别问了，直接做"）	立即停止提问；剩余未知的每项转为带风险的陈述假设，说明仍不清楚的内容后继续
CBA-E03	节奏抱怨（"你问太多了"、"快点"）	不是叫停：队列成员不变，每个方向性未知仍逐个提问，只是问题更短更精准
CBA-E04	功课与记忆检查做完后，方向仍未知	不要带着模糊方向行动：列出剩余方向性未知，逐个提问；若仍无法推进，请对方在明确选项间决策

常见问题

Q: 问多少算太多？ A: 没有硬上限，但每个问题必须改变方向。如果可以用陈述性假设推进，就这么做。当你能写出目标、约束和一条可测试的成功标准时，就停止提问。

Q: 用户说"你问太多了"——我该停吗？ A: 不一定。这通常是节奏抱怨，不是停止。保留队列，只是让问题更短。只有当用户明确说"别问了，直接做"时才停止。

Q: 用户不回答方向性问题怎么办？ A: 区分两种情况：(1) 用户明确说"别问了，直接做"——带着陈述的假设和风险继续；(2) 用户只是沉默不答——不要默默假设，用更简洁的方式再问一次，或清晰陈述风险并请求一个字的确认。方向性未知绝不能被默默填充。

Q: 每次编辑前都要问吗？ A: 不。只在方向性或高成本行动前问。机械编辑直接执行。

语言支持

本技能支持中文交互。你可以用中文提问和接收回答；任务契约和假设可以用用户的首选语言编写。触发词包括 "确认需求"、"先澄清再做"、"方向不确定"。