clarify-before-acting

--- name: clarify-before-acting slug: yumingtao-clarify-before-acting displayName: Clarify Before Acting version: 1.3.0 summary: 在处理复杂或高成本请求前，先解决方向性歧义。 license: MIT description: > 在处理复杂、模糊或高成本请求前，先解决方向性歧义：自己做功课、检查记忆中已回答的问题、逐个处理问题队列、绝不猜测方向。跳过琐碎、机械、低风险的任务。触发词："确认需求"、"先澄清再做"、"方向不确定"、"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`](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`](references/playbook.md)。任务足够难时再读；日常使用上面的规则即可。* ## 不适用范围 以下情况本技能**不**适用： - 请求琐碎、机械或低风险（格式化、重命名、翻译、意图明确的单文件编辑）。 - 方向已经无歧义且可测试。 - 用户明确说"直接做"，且剩余未知是细节级、非方向性的——此时带陈述的假设继续。 - 任务需要智能体无法内部验证的领域专业知识——将其作为已知未知呈现，而非猜测。 ## 异常场景速查 | 码 | 场景 | 处理 | |------|------|------| | CBA-E01 | 用户对方向性问题沉默不答 | 不要默默填充：用更简洁的方式再问一次，或清晰陈述风险并请求一个字的确认 | | CBA-E02 | 用户明确叫停（无歧义的"别问了，直接做"） | 立即停止提问；剩余未知的每项转为带风险的陈述假设，说明仍不清楚的内容后继续 | | CBA-E03 | 节奏抱怨（"你问太多了"、"快点"） | 不是叫停：队列成员不变，每个方向性未知仍逐个提问，只是问题更短更精准 | | CBA-E04 | 功课与记忆检查做完后，方向仍未知 | 不要带着模糊方向行动：列出剩余方向性未知，逐个提问；若仍无法推进，请对方在明确选项间决策 | ## 常见问题 **Q: 问多少算太多？** A: 没有硬上限，但每个问题必须改变方向。如果可以用陈述性假设推进，就这么做。当你能写出目标、约束和一条可测试的成功标准时，就停止提问。 **Q: 用户说"你问太多了"——我该停吗？** A: 不一定。这通常是节奏抱怨，不是停止。保留队列，只是让问题更短。只有当用户明确说"别问了，直接做"时才停止。 **Q: 用户不回答方向性问题怎么办？** A: 区分两种情况：(1) 用户明确说"别问了，直接做"——带着陈述的假设和风险继续；(2) 用户只是沉默不答——不要默默假设，用更简洁的方式再问一次，或清晰陈述风险并请求一个字的确认。方向性未知绝不能被默默填充。 **Q: 每次编辑前都要问吗？** A: 不。只在方向性或高成本行动前问。机械编辑直接执行。 ## 语言支持 本技能支持中文交互。你可以用中文提问和接收回答；任务契约和假设可以用用户的首选语言编写。触发词包括 "确认需求"、"先澄清再做"、"方向不确定"。

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本