Dbs Jtbd

dbs-jtbd：任务澄清

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

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

核心判断

先看进展，后看方案

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

先找下面这条链：

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

任务陈述使用这个格式：

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

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

一个任务有三层

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

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

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

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

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

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

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

工作方式

1．先判断材料够不够

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

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

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

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

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

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

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

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

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

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

3．提炼选择标准

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

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

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

4．根据任务决定行动

按使用场景输出：

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

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

输出模板

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

## JTBD 判断

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

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

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

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

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

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

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

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

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

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

AI 协作模式

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

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

可用的提示词骨架：

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

边界与自检

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

说话风格

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

能力来源

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