luoxianqiang158 Task Clarify Heuristic（任务目标澄清助手）
EN: A heuristic, multi-turn questioning workflow that turns vague agent tasks into executable, well-scoped task specs. Platform-agnostic — works on Dify, WorkBuddy, OpenCode, or any agent runtime. See README_EN.md.
Overview
把「模糊任务描述 → 可执行的 Agent 任务规约」的过程工程化。核心信条：用户给 Agent 的任务跑偏，90% 不是因为 Agent 笨，而是因为任务定义本身缺了目标、边界和验收标准。
本 Skill 不一次性抛出大问卷，而是分阶段递进澄清：先搞清「为什么做」，再搞清「做什么、怎么做、做到什么程度」，最后输出一份可直接喂给任何执行 Agent 的结构化任务规约。
为什么需要它（核心差异化）
| 没有澄清 | 用了本 Skill | |
|---|---|---|
| 用户说 | 「帮我写个竞品分析」 | 同上 |
| Agent 反应 | 直接开写 → 泛泛而谈、不对路、返工 | 先澄清目标/受众/格式 → 精准交付 |
| 结果 | 来回改 3 遍，双方都烦 | 1 轮澄清 + 1 次确认，一次到位 |
三个差异化设计（市面 prompt 少见）：
- 区分「手段」与「业务目标」 —— 用户说「写 PPT」，真实目标可能是「说服客户采购」。目标不清，手段全白做。
- 自动猜测补全 —— 信息不足时主动给假设让用户确认，而非把问题全抛回去。减少用户负担。
- 跨平台可移植 —— 产出是纯文本任务规约，可直接复制给 Dify / OpenCode / 任何 Agent。不绑定单一平台（见
platforms/）。
When to Use
- 用户任务描述模糊：缺少目标、范围、输出格式、约束条件
- 用户说「帮我做 XX」「帮我分析 XX」「帮我写 XX」，但信息不完整
- 用户需求里有明显的「手段当目标」迹象（详见核心原则 1）
- 任务要转交给 Dify / OpenCode / 其他 Agent 平台执行，需要一份清晰的任务定义
NOT for：任务描述已经完整清晰（目标、输出、验收标准都明确）、纯闲聊、简单查找类问答。
核心设计原则（必须全部遵守）
- 区分「手段」与「业务目标」：用户经常把实现方式当成目标。例：用户说「帮我写一份 PPT」，真实目标可能是「给客户做方案汇报，说服客户采购」。目标不清，手段全是白做。这是本 Skill 第一优先级。
- 每轮提问 ≤ 2 个，拒绝大问卷：一次问太多，用户会草草回答甚至敷衍。相关度高的问题可以合并为一轮，但每轮最多 2 个。
- 优先抓高影响项：目标 > 输出 > 约束 > 排除项 > 细节。信息不够时先补高影响项，细节可以后置。
- 自动猜测补全：信息不足时主动给出假设让用户确认/修正，而不是把问题全部抛回给用户。猜测必须显式标注「这是我的假设」，让用户容易反驳。
- 阶段边界灵活：用户回答中顺带提供了后续阶段的信息，直接收下记录，不做强行分阶段。三个阶段是「补齐式追问」，不是「隔离式问卷」。
流程总览（DAG）
用户原始任务输入
↓
[阶段 0] 复杂度预检：任务是否已足够清晰？
├─ 足够清晰 → 直接进入阶段 3 生成规约
└─ 模糊/缺关键项 → 进入阶段 1
↓
[阶段 1] 意图与目标澄清（目标 vs 手段、受众、验收标准、排除项）
├─ 信息足够 → 进入阶段 2
└─ 不足 → 每轮 ≤2 个问题追问
↓
[阶段 2] 输入、输出、约束、资源澄清（材料、格式、硬约束、工具权限、参考样例）
├─ 信息足够 → 进入阶段 3
└─ 不足 → 每轮 ≤2 个问题追问
↓
[阶段 3] 生成结构化 Agent 任务规约 + 向用户确认
├─ 用户确认 → 交付给执行 Agent（或执行）
└─ 用户修改 → 回到对应阶段补信息
阶段 0：复杂度预检（必做，30 秒内完成）
先判断任务需要多重的澄清流程，不要对 trivial 任务走完整三阶段：
| 预检结果 | 判断依据 | 动作 |
|---|---|---|
| 直通 | 目标、受众、输出格式、验收标准用户已经说清 | 直接进阶段 3 生成规约，只做 1 次确认 |
| 标准澄清 | 目标大致有，但缺输出格式/约束/验收标准中的 2 项以上 | 走完整流程 |
| 深度澄清 | 用户只说「帮我做个 XX」，连业务目的都没说 | 走完整流程，且阶段 1 必须问透 |
| 升级出口 | 任务本质是「新建系统/功能/代码架构」，需要设计决策 | 转 brainstorming 类设计流程（见「与下游 Skill 衔接」） |
向用户声明路径（一句话）：例如「这个任务我先确认几个关键点再动手，每轮最多问 2 个，很快」。
阶段 1：意图与目标澄清（最重要）
目标：搞清楚「为什么要做」，而不是只看「做什么」。
通用启发提问模板（每轮选 1-2 个，不要全抛）
- 这个任务最终想达成什么业务结果？（业务目标，不是手段）
- 这份输出是给谁看 / 给谁用的？受众是谁？
- 完成之后，怎么判断任务「算做好了」？简单说下验收标准。
- 有没有什么是不希望做的？哪些事情不在本次范围内？
分类题库（按任务类型补充专用问题）
根据任务类型，在通用模板之外追加对应问题：
| 任务类型 | 追加的专用澄清问题 |
|---|---|
| 内容创作（文章/报告/PPT/文案） | 调性与风格？（如犀利/严谨/轻松）；发布渠道与篇幅要求？；是否有参考样例或品牌规范？ |
| 代码开发（功能/Bug/重构） | 技术栈与运行环境？；验收标准是否含测试用例？；需兼容哪些浏览器/版本/历史代码？ |
| 研究分析（调研/竞品/数据） | 分析视角与立场？；结论给谁用、要落到什么决策？；数据来源是否需联网、深度要求？ |
| 设计（UI/产品/流程） | 目标用户与使用场景？；风格参考（可附链接）？；交付物是原型/稿/规范？ |
| 运营增长（活动/增长/投放） | 核心指标是什么（GMV/留存/转化）？；周期与节奏？；受众与渠道？ |
内置猜测机制
信息不足时主动给假设：
「我先做一个假设：本次目标是输出一份面向管理层的销售问题诊断报告，不需要复杂图表。是否正确？不对请纠正我。」
猜测必须：①显式标注是假设；②给用户足够的反驳空间；③用户修正后立即采纳。
阶段 1 输出字段
task_purpose: # 业务目标，为什么做
task_audience: # 受众，给谁看/给谁用
task_success_criteria: # 成功/验收标准
task_out_of_scope: # 明确不在范围内的事
阶段 2：输入、输出、约束、资源澄清
目标：聚焦「怎么做、产出长什么样、有什么限制」。阶段 1 基本明确后才进入本阶段。
启发提问模板（每轮选 1-2 条）
- 输入材料 / 参考信息有哪些？是否有文档、链接、数据、历史上下文？
- 期望输出格式是什么？Markdown / 表格 / PPT 大纲 / JSON / 代码 / 自然语言报告？输出长度大概要求？
- 有什么硬性约束：时间、字数、风格、合规、技术限制？
- 是否有参考样例或范例可以参照？
- 是否允许 Agent 主动调用工具、搜索外部信息？还是只能基于给定上下文？
阶段 2 输出字段
input_context: # 可用输入、参考资料
output_format: # 输出格式、结构、长度风格
hard_constraints: # 硬性约束
allow_tools: true/false # 是否允许调用工具
reference_example: # 参考范例（可选）
阶段 3：生成完整 Agent 任务规约并确认
把阶段 1 + 阶段 2 收集到的信息整理成一份完整、可直接喂给执行 Agent 的任务规约，再向用户确认。
Before / After（直观感受产出物）
Before（未澄清） —— 用户：「帮我写个竞品分析。」
Agent 直接输出一篇泛泛的「行业三大玩家对比」，没有你的业务视角，看完用不上。
After（经本 Skill 澄清） —— 结构化任务规约：
# Agent 任务规约【经澄清确认】
## 业务目标：评估是否自研 vs 采购 OCR 能力，支撑 Q4 选型决策
## 受众与用途：给技术 VP 与采购总监的选型参考
## 验收成功标准：给出明确推荐结论 + 成本/能力二维对比表
## 不在本次任务范围：不做 POC 实测、不写招标文档
## 可用输入上下文：现有供应商清单（无公开数据，可联网）
## 输出要求：格式=Markdown 报告；约束=含 TCO 测算；参考=无
## 工具权限：允许调用工具=true
任务规约输出模板
# Agent 任务规约【经澄清确认】
## 业务目标
{task_purpose}
## 受众与用途
{task_audience}
## 验收成功标准
{task_success_criteria}
## 不在本次任务范围（禁止做）
{task_out_of_scope}
## 可用输入上下文
{input_context}
## 输出要求
格式：{output_format}
约束：{hard_constraints}
参考样例：{reference_example}
## 工具权限
允许调用工具：{allow_tools}
请严格遵守以上全部约束执行任务，不要擅自扩大范围。
确认话术
「我整理出本次任务完整定义如上，请确认是否准确。如果有地方不对，请直接修改对应部分，或者告诉我需要调整的点。确认无误后就开始执行。」
HARD GATE：未获得用户明确确认前，不得开始执行任务本体。
与下游 Skill 衔接（Escalation）
- 任务规约确认后：直接执行，或在用户要求下把规约文本交付给目标 Agent 平台（Dify/OpenCode 等）。
- 阶段 0 升级出口触发时（任务本质是新建系统/功能/代码架构）：澄清到目标明确后，必须转设计流程（如 WorkBuddy 的 brainstorming skill），不直接产出规约了事。
- 代码改动类任务：规约确认后，按正常开发流程执行（TDD 适用），无需写 plan 文档。
- 简单可行性探测（「能不能做 X」）：按 Spike 处理，2-3 句话说明要试什么，点头后快速验证，产出结论不产代码。
注：以上 WorkBuddy 专属衔接仅适用于 WorkBuddy 环境。其他平台见
platforms/目录的适配说明。
完整示例
examples/ 目录提供三种任务类型的完整对话演示：
examples/code-task.md—— 代码功能任务（「帮我加个导出功能」）examples/content-task.md—— 内容创作任务（「帮我写篇公众号推文」）examples/research-task.md—— 研究分析任务（「帮我分析下这个市场」）
反模式（Red Flags）
| 借口 | 现实 |
|---|---|
| 「任务简单，不用问直接干」 | 简单任务跑偏的代价一样大；至少给 1 次确认 |
| 「一口气把问题全问了，节省来回」 | 大问卷 = 用户敷衍 = 澄清失败。每轮 ≤ 2 个 |
| 「用户说要 PPT，那就是做 PPT」 | 手段 ≠ 目标。先问为什么，再问怎么做 |
| 「用户没说，那我就不管了」 | 信息缺口要主动给假设，让用户确认，不是静默跳过 |
| 「先干起来，边干边澄清」 | 目标未确认前的执行是浪费。HARD GATE 不可跳过 |
| 「这是代码任务，我直接写」 | 新系统/架构类任务必须先走设计流程 |
MUST NOT
- MUST NOT 一次性抛出 3 个以上问题
- MUST NOT 在用户未确认任务规约前开始执行任务本体
- MUST NOT 把用户说的手段直接当成业务目标
- MUST NOT 静默猜测 —— 所有假设必须显式标注并请求确认
- MUST NOT 对已足够清晰的任务重复追问（阶段 0 预检就是防这个）
© 2026 老罗 (Luo). Released under the MIT License.