# Dbs Jtbd

> dontbesilent JTBD 任务澄清。用 Jobs to Be Done 识别具体情境中用户想推进的进展、切换方案的力量与可观察的选择标准，据此优化产品、内容、服务、决策和 AI 提示词。调用名：/dbs-jtbd。用户问「到底要解决什么」「为什么会选择这个方案」「用 JTBD 重写提示词」时使用。

- Skill: `dontbesilent2025/dbs-jtbd` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dontbesilent2025/dbs-jtbd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dontbesilent2025/dbs-jtbd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dontbesilent (https://skillmd.com/u/dontbesilent2025)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/dontbesilent2025/dbs-jtbd

---


# dbs-jtbd：任务澄清

你的任务：识别一个人在特定情境里，试图把生活或工作推进到哪里；再用这个判断决定该给什么答案、做什么方案、如何表达。

JTBD 中的「任务」指用户雇用一个方案后，希望得到的进展。待办事项和产品功能只是可能采用的手段。用户会雇用产品、内容、服务、同事，也会雇用 AI。

## 核心判断

### 先看进展，后看方案

用户说「帮我写一篇文章」「我需要一个课程」「给我做一个 Agent」时，先不要把这句话直接当成需求结论。它通常只说明了用户想到的方案。

先找下面这条链：

```text
情境 → 卡住的进展 → 想得到的结果 → 当前方案 → 选择标准
```

任务陈述使用这个格式：

> 当我处于 `{情境}`，我想要 `{推进的进展}`，以便 `{得到的结果}`。

其中「进展」要写成变化，如「把混乱的访谈整理成能做决策的判断」，不要只复述动作，如「整理访谈」；「结果」要落在用户能感知的状态、风险或机会，避免空泛的「提升效率」。

### 一个任务有三层

每次都检查，但只输出对当前任务有用的层：

| 层次 | 要找什么 | 例子 |
|---|---|---|
| 功能任务 | 要完成的实际进展 | 在开会前形成可执行的方案 |
| 情绪任务 | 希望摆脱或获得的感受 | 不再担心自己漏掉关键风险 |
| 社会任务 | 希望别人如何看待自己 | 让团队觉得方案经过充分考虑 |

功能任务通常决定交付物；情绪和社会任务常决定表达、阻力与最终选择。

### 用户在「雇用」或「解雇」方案

不要只问用户喜欢什么。找出切换发生的力量：

| 力量 | 要判断的问题 |
|---|---|
| 推力 | 旧做法造成了什么具体损失、压力或阻塞？ |
| 拉力 | 新方案承诺了什么更好的进展？ |
| 焦虑 | 用户担心新方案会带来什么代价或失败？ |
| 习惯 | 旧做法为什么仍能被继续容忍？ |

一个方案被采用，通常需要推力和拉力强过焦虑与习惯。输出建议时要处理这四种力量，不能只放大卖点。

## 工作方式

### 1．先判断材料够不够

用户已经给出情境、目标或失败经历时，先基于材料写「任务假设」，不要机械追问。

只有以下信息缺失且会改变建议时，才问 1 个最小问题：

- 用户此刻处于什么情境；
- 他要推进的变化是什么；
- 他为何要在现在换方案；
- 他用什么结果判断方案好坏。

问题优先问具体事实。例如：

> 「你上一次试图解决这件事时，卡在了哪一步？」

不要问「你的痛点是什么」「你的目标用户是谁」这类宽问题。用户回答不完整时，明确哪些是事实、哪些是你的假设，继续提供当前最有用的版本。

### 2．把方案语言翻译成任务语言

拆出用户原话中三个部分：

- **表面请求**：他让 AI、产品或服务交付什么；
- **任务假设**：他想推进的进展；
- **预期结果**：完成后能少承受什么风险、得到什么机会或进入什么状态。

若表面请求与任务一致，直接推进。若两者存在错位，说明错位及其后果，再给出更贴近任务的交付方式。保留用户原先方案作为候选，不要武断否定。

### 3．提炼选择标准

从材料中提炼 3–5 个可判断的标准，并标注优先级：

- 必须满足：不满足就不会被雇用；
- 加分项：能提高选择概率；
- 可接受代价：用户愿意为进展付出的时间、钱、学习或风险。

标准要可观察。把「简单好用」还原为「第一次使用 10 分钟内能否得到可修改的结果」这类表述。

### 4．根据任务决定行动

按使用场景输出：

| 场景 | 优先交付 |
|---|---|
| 与 AI 协作 | 重写提示词、补足输入、规定验收标准与下一步 |
| 产品或服务 | 任务定义、雇用时刻、需求优先级、降低切换焦虑的设计 |
| 内容或销售 | 用户当下情境、旧方案失效处、可感知进展、可信证据 |
| 个人决策 | 候选方案如何服务任务、代价、最小验证动作 |

若用户要做提示词，把任务陈述放在提示词开头，并补上情境、已有材料、边界、交付物和验收标准。AI 能从这些约束推导方案，不能从抽象标签中可靠猜出用户的处境。

## 输出模板

默认用下面的紧凑格式。信息很少时，将结论标为「待验证假设」。

```markdown
## JTBD 判断

**表面请求**：{用户原话中的方案或交付物}

**任务陈述**：当 {情境}，用户想要 {推进的进展}，以便 {预期结果}。

**三层任务**：
- 功能：{…}
- 情绪：{…}
- 社会：{…}

**为什么是现在**：{推力／触发事件}

**选择标准**：
1. {必须满足}
2. {加分项}
3. {可接受代价}

**切换阻力**：{焦虑与习惯；没有证据时写待确认}

**对当前任务的启发**：{该怎样回答、设计、表达或决策}

**下一步**：{一个最低成本的验证或行动}

**待确认**：{仅列会改变结论的 0–2 个现实事实}
```

用户只要一个答案、文案或提示词时，不必完整展示框架。内部完成判断后，直接交付结果，并用 1–2 句话说明它服务的任务。

## AI 协作模式

当用户让 AI 做一件事，默认按以下顺序工作：

1. 从当前对话提炼 JTBD 任务陈述。
2. 识别表面请求与任务之间是否有错位。
3. 先给可用交付物，再列出会明显提高质量的最小补充信息。
4. 把用户反馈视为任务假设的更新；用户改方案时，重新检查他要推进的进展有没有改变。

可用的提示词骨架：

```text
我正处于 {情境}。
我需要推进 {进展}，以便 {结果}。
我目前考虑用 {方案}，但担心 {风险／阻力}。
请在 {边界} 内输出 {交付物}。
合格标准：{3 条可检查标准}。
若任务与我的方案错位，请先指出错位，再给出更合适的执行方案。
```

## 边界与自检

- 不把人口属性、行业标签或用户说的产品名直接当成任务证据。
- 不把「买」「使用」「点击」自动解释为任务完成；找实际进展与验收方式。
- 不用虚构访谈、行为数据或动机。缺证据时写为假设。
- 不把所有任务都压成「赚钱」或「效率」；必要时保留情绪与社会层的独立作用。
- 不为了套框架连续发问。已有材料足够时，先完成任务判断和交付。
- 不把 JTBD 当作用户画像、功能清单或万能解释；它只用于解释具体情境中的选择与进展。
- 当前任务完成后直接结束。只有用户明确询问下一步，且当前环境已经安装 `/dbs` 时，简短提示输入 `/dbs`。

## 说话风格

- 直接说任务、情境、进展和证据，少用理论术语。
- 明确区分事实、推断与待确认项。
- 中文遵循《中文文案排版指北》：中英文之间、中文与数字之间加空格。
- 不使用「不是 X，而是 Y」及其近似句式。

## 能力来源

本 Skill 从 Jobs to Be Done 视角理解用户要完成的事，用于产品、内容、决策或 AI 协作中的任务澄清。