# Task Clarify Heuristic

> 用户任务描述模糊、缺目标、缺约束、缺输出标准或边界时使用。通过分层启发式多轮提问（每轮 1-2 个问题），区分业务目标与手段，补齐输入/输出/约束/验收标准，最终输出结构化 Agent 任务规约。触发词：帮我做XX、帮我分析XX、帮我写XX、任务说不清楚、需求澄清、任务规约。适用于 Dify/WorkBuddy/OpenCode 等任何 Agent 平台的任务下发前置澄清。

- Skill: `luoxianqiang158/task-clarify-heuristic` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add luoxianqiang158/task-clarify-heuristic`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luoxianqiang158/task-clarify-heuristic/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: luoxianqiang158 (https://skillmd.com/u/luoxianqiang158)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/luoxianqiang158/task-clarify-heuristic

---


# 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](./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 输出字段

```yaml
task_purpose:        # 业务目标，为什么做
task_audience:       # 受众，给谁看/给谁用
task_success_criteria:  # 成功/验收标准
task_out_of_scope:   # 明确不在范围内的事
```

## 阶段 2：输入、输出、约束、资源澄清

**目标**：聚焦「怎么做、产出长什么样、有什么限制」。阶段 1 基本明确后才进入本阶段。

### 启发提问模板（每轮选 1-2 条）

- 输入材料 / 参考信息有哪些？是否有文档、链接、数据、历史上下文？
- 期望输出格式是什么？Markdown / 表格 / PPT 大纲 / JSON / 代码 / 自然语言报告？输出长度大概要求？
- 有什么硬性约束：时间、字数、风格、合规、技术限制？
- 是否有参考样例或范例可以参照？
- 是否允许 Agent 主动调用工具、搜索外部信息？还是只能基于给定上下文？

### 阶段 2 输出字段

```yaml
input_context:       # 可用输入、参考资料
output_format:       # 输出格式、结构、长度风格
hard_constraints:    # 硬性约束
allow_tools: true/false  # 是否允许调用工具
reference_example:   # 参考范例（可选）
```

## 阶段 3：生成完整 Agent 任务规约并确认

把阶段 1 + 阶段 2 收集到的信息整理成一份完整、可直接喂给执行 Agent 的任务规约，再向用户确认。

### Before / After（直观感受产出物）

**Before（未澄清）** —— 用户：「帮我写个竞品分析。」
> Agent 直接输出一篇泛泛的「行业三大玩家对比」，没有你的业务视角，看完用不上。

**After（经本 Skill 澄清）** —— 结构化任务规约：

```text
# Agent 任务规约【经澄清确认】
## 业务目标：评估是否自研 vs 采购 OCR 能力，支撑 Q4 选型决策
## 受众与用途：给技术 VP 与采购总监的选型参考
## 验收成功标准：给出明确推荐结论 + 成本/能力二维对比表
## 不在本次任务范围：不做 POC 实测、不写招标文档
## 可用输入上下文：现有供应商清单（无公开数据，可联网）
## 输出要求：格式=Markdown 报告；约束=含 TCO 测算；参考=无
## 工具权限：允许调用工具=true
```

### 任务规约输出模板

```text
# 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/code-task.md) —— 代码功能任务（「帮我加个导出功能」）
- [`examples/content-task.md`](./examples/content-task.md) —— 内容创作任务（「帮我写篇公众号推文」）
- [`examples/research-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](./LICENSE).