把模糊问题改写成 Agent 可推理、可批评…

当用户的问题模糊、只有现象或材料，或想知道某任务能否交给 Agent 自动化时，用此技能澄清问题、生成候选解释并给出最小验证动作。

适用场景

解决思路

1. 先钉现象：不要直接回答“为什么我做不好”“为什么没人买”“这个能不能做”这类大问题，先把它改写成可观察的具体现象，例如“最近 10 篇小红书笔记收藏率高，但私信咨询少”。
2. 暴露冲突：识别并写出数据冲突、行为冲突、预期冲突、资源冲突、约束冲突，让问题有可推理的张力。
3. 为 Agent 提供 5 类约束场：对象（分析谁、哪件事、哪个场景）、目标（解释、预测、改进还是决策）、变量（哪些因素可能影响结果）、约束（什么不能改变、什么必须考虑）、反馈（什么证据能验证或修正解释）。
4. 判断自动化解决时要求反馈回流：区分自动生成解释（文本推理即可）、自动生成好解释（需要清楚边界、变量和批评标准）、自动解决问题（需要行动、反馈、修正循环）。
5. 信息不足时不要装确定：先说缺什么，再给最小补充问题或最小观察动作。
6. 用户问“为什么”时先给抓手再做审计：先用 1-2 句话指出断点，再说明当前能给的解释强度；若问题已有明确断点，先给 1-2 个低置信候选解释，并标注它们只是待验证解释且写清需要什么证据。
7. 模式 A 处理模糊问题：先指出断点，给出当前问题清晰度，再改写成好问题草案；不要把评分表放在最前面。
8. 模式 B 处理现象和背景：提炼核心冲突，生成问题说明书，再判断 Agent 可解性；若材料中已有明确漏斗断点，先给低置信候选解释。
9. 模式 C 处理自动化请求：判断自动化程度，拆出可自动化部分、需人类判断部分、需要反馈回流的部分。
10. 模式 D 处理候选解释请求：生成 2-3 个候选 explanation，用难以变化（hard to vary）、可检验性、行动指向批评。
11. Phase 1 识别输入类型：判断用户给的是模糊问题、现象、材料、自动化请求，还是混合输入。
12. Phase 2 做五项检查：检查对象、目标、冲突、约束、反馈；每项 0-2 分；0 分表示没有提供，1 分表示有方向但还松，2 分表示具体、能限制推理。
13. Phase 2 解释总分：0-4 分是松问题，暂时不适合直接交给 Agent 推理；5-7 分是中等，先给低置信候选解释，再追问 1-3 个关键缺口；8-10 分是好问题，可进入候选解释和验证设计。
14. Phase 2 默认输出：对外默认不要展示完整评分表；除非用户要求严谨审计或分数能帮助推进判断，否则只写当前清晰度（低/中/高）和最大缺口一句话。
15. Phase 3 判断 Agent 可解性：按 6 个维度判断，包括边界清楚、变量可表达、反馈可获得、解释可检验、行动可执行、规律稳定；对照高自动化信号和低自动化信号。
16. Phase 3 输出档位：根据六维判断输出 A 档可高度自动化、B 档可半自动化、C 档可辅助推理、D 档暂不适合自动化，并说明原因。
17. Phase 4 改写成问题说明书：使用结构“我要分析的问题、现象、目标、核心冲突、背景事实、约束、反馈入口、请 Agent 做”；“请 Agent 做”包括生成 2-3 个候选解释、用难以变化/可检验性/行动指向批评每个解释、选出最值得验证的解释、给出一个最小验证动作。
18. Phase 4 信息不足时：不要编完整说明书，只写半成品问题说明书和最小补充问题；未知项必须写“未知”，不要为了格式完整而脑补设定。
19. Phase 5 生成候选解释：问题清晰度达到 8 分以上，或用户明确要求先做候选解释时，进入完整候选解释与批评；问题只有 5-7 分但有明确断点时，可进入低置信候选解释。
20. Phase 5 低置信候选解释：只给 1-2 个，不做大表格，不下确定结论，重点写“如果它成立，应该看到什么”。
21. Phase 5 识别明确断点：内容→主页→关注/私信/咨询断掉、流量→咨询→付款断掉、用户感兴趣→不行动、目标明确→执行停住、想自动化→关键判断无法交给 Agent。
22. Phase 5 每个候选解释必须包含：机制（A 如何导致 B）、可观察信号（如果成立应该看到什么）、排除项（排除哪个竞争解释）、行动变化（相信它以后下一步会怎么变）；候选解释不超过 3 个。
23. Phase 6 给下一步：最后只给一个最小下一步；问题太松时追问最关键的 1-3 个问题；问题中等且有断点时给低置信候选解释并补齐问题说明书缺口；问题中等但没有断点时只补齐问题说明书缺口；问题够清楚时做候选解释与批评；想自动化时拆出 Agent 可做、人要判断、反馈要回流的部分。
24. 格式 A 默认输出：依次输出 # 好问题拆解、我看到的断点、当前清晰度（低/中/高）、最大缺口、低置信候选解释（1-2 个，机制+应该看到的信号）、半成品问题说明书（我要分析的问题、现象、目标、核心冲突、约束、反馈入口）、先补这几个信息（1-3 个）。
25. 格式 B 严格问题质量审计：只有用户要求严格审计、打分、判断问题质量时使用；输出原问题、当前评分表（对象/目标/冲突/约束/反馈各 0-2 分）、总分 x/10、最大缺口、改写成好问题草案、先补这几个信息。
26. 格式 C Agent 可解性判断：输出结论 A/B/C/D 档及一句话说明、为什么表格（边界清楚/变量可表达/反馈可获得/解释可检验/行动可执行/规律稳定各高/中/低）、可自动化部分、需要人类介入的部分、最小下一步。
27. 格式 D 完整问题说明书：输出我要分析的问题、现象、目标、核心冲突、背景事实、约束、反馈入口、请 Agent 做（任务 1/2/3）。
28. 格式 E 候选解释与批评：输出当前问题、候选解释 1/2/3、Hard to Vary 对比表（候选、机制、排除项、可验证信号、行动变化、评分）、当前最强解释、仍然不确定的地方、最小验证动作。
29. 场景 1 内容转化：处理“内容有人收藏但没人咨询”时，确定对象（最近哪些内容、哪个平台）、目标（解释收藏到咨询断点）、冲突（收藏高说明保存价值，咨询少说明行动动机不足）、反馈（评论、私信、主页点击、咨询入口点击、用户访谈）、下一步（让用户提供最近 10 篇内容的曝光、收藏、私信、主页点击数据）。
30. 场景 2 内容到主页承接：处理“大 B 刷到小 B 内容但点主页没留下”时，先钉断点（内容触达更高层级用户，但主页没有承接成关注、私信、咨询或加微信）；允许先给低置信候选解释；检查内容钩子、主页首屏、置顶内容、成交入口、目标人群识别信号 5 个变量；不要直接说“信任不足”或“价值不清晰”，要问大 B 在 5 秒内能否判断你解决哪类更高层级问题；下一步让用户提供 1-3 条带来主页访问的内容、主页截图、期望动作。
31. 场景 3 商业问题：处理“我的课为什么卖不动”时，先问清楚卖给谁、价格多少、流量来源、咨询人数、成交人数；不直接生成“没有信任”“价值感不够”这类松解释；把问题改成例如“过去 30 天，私域 80 人咨询，只有 2 人付款，断点集中在价格说明后”。
32. 场景 4 Agent 自动化：处理“报销流程能不能用 Agent 自动化”时，拆文件输入、规则判断、异常处理、输出格式、审批反馈；若规则明确、样本稳定、反馈可回流，判 A 或 B；若判断只在负责人脑子里，判 C 或 D，先写规则说明书。
33. 说话风格：先钉现象再谈解释；先给抓手再指出缺口；不要用大词糊弄，定位、价值、认知、信任必须落到具体机制；一次最多问 3 个关键问题；把结论压到下一步，最后必须给一个最小动作；控制长度，默认输出不超过 5 个小节，用户继续追问时再展开评分表、完整说明书或候选解释对比表。
34. 语言：用户用中文就用中文，用英文就用英文；中文回复遵循《中文文案排版指北》。
35. 结束：完成当前任务后直接结束；只有用户明确询问下一步，且当前环境已安装 /dbs 时，简短提示“下一步不确定时，可以输入 /dbs。”

适用边界 · 注意事项

• 用户只需要直接事实回答、简单命令执行，或问题已经足够清楚且只要求直接执行时，不必做完整好问题改写。
• 用户拒绝提供任何现象、约束或反馈入口，且不接受半成品问题说明书或最小追问时，无法推进到可靠候选解释。
• 问题高度依赖线下谈判、人际博弈或一次性现场判断，且没有反馈回流入口时，不应强行判定为可高度自动化。