shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringNo API key required

任务目标澄清助手

启发式多轮提问工作流：区分业务目标与手段，补齐约束与验收标准，把模糊 Agent 任务收敛成结构化任务规约。跨 Dify/WorkBuddy/OpenCode 通用。

personAuthor: luoxianqianghubOpenAPI
downloadDownload package

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 少见）：

  1. 区分「手段」与「业务目标」 —— 用户说「写 PPT」，真实目标可能是「说服客户采购」。目标不清，手段全白做。
  2. 自动猜测补全 —— 信息不足时主动给假设让用户确认，而非把问题全抛回去。减少用户负担。
  3. 跨平台可移植 —— 产出是纯文本任务规约，可直接复制给 Dify / OpenCode / 任何 Agent。不绑定单一平台（见 platforms/）。

When to Use

  • 用户任务描述模糊：缺少目标、范围、输出格式、约束条件
  • 用户说「帮我做 XX」「帮我分析 XX」「帮我写 XX」，但信息不完整
  • 用户需求里有明显的「手段当目标」迹象（详见核心原则 1）
  • 任务要转交给 Dify / OpenCode / 其他 Agent 平台执行，需要一份清晰的任务定义

NOT for：任务描述已经完整清晰（目标、输出、验收标准都明确）、纯闲聊、简单查找类问答。

核心设计原则（必须全部遵守）

  1. 区分「手段」与「业务目标」：用户经常把实现方式当成目标。例：用户说「帮我写一份 PPT」，真实目标可能是「给客户做方案汇报，说服客户采购」。目标不清，手段全是白做。这是本 Skill 第一优先级。
  2. 每轮提问 ≤ 2 个，拒绝大问卷：一次问太多，用户会草草回答甚至敷衍。相关度高的问题可以合并为一轮，但每轮最多 2 个。
  3. 优先抓高影响项：目标 > 输出 > 约束 > 排除项 > 细节。信息不够时先补高影响项，细节可以后置。
  4. 自动猜测补全：信息不足时主动给出假设让用户确认/修正，而不是把问题全部抛回给用户。猜测必须显式标注「这是我的假设」，让用户容易反驳。
  5. 阶段边界灵活：用户回答中顺带提供了后续阶段的信息，直接收下记录，不做强行分阶段。三个阶段是「补齐式追问」，不是「隔离式问卷」。

流程总览（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/ 目录提供三种任务类型的完整对话演示：

反模式（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.