Dbs Jtbd

作者 dontbesilent2025564a794ffa8d无许可证10K 个星标收录于 2026年10月8日更新于 2026年10月8日仓库今天更新

用 Jobs to Be Done 识别具体情境中用户想推进的进展、切换方案的力量和选择标准,解释产品、服务或内容为何被选择。用户要求分析顾客任务、购买动机、替代方案或明确用 JTBD 重写提示词时使用;普通任务验收标准澄清无需套用该框架。

AI 生成的概览

用 Jobs to Be Done 识别用户在具体情境中想推进的进展,以及切换方案背后的力量。

功能
引导智能体完成一次 Jobs to Be Done 分析:区分表面请求与真实任务,写出包含情境、进展与结果的任务陈述,并检查功能、情绪与社会三个层次。它还会梳理推力、拉力、焦虑与习惯四种力量,提炼三到五条可观察的选择标准,并输出一份紧凑的 JTBD 判断模板,附下一步与待确认项。产出为分析判断,必要时也包括重写的提示词或设计建议。
适用场景
当用户要求分析顾客任务、购买动机、替代方案或切换行为,或明确希望用 JTBD 视角重写提示词时使用。它不适用于普通任务验收标准的澄清。
运行要求
无需脚本或特殊工具,仅为指令型技能。若环境中已安装 /dbs 命令,可在用户明确询问下一步时作简短提示。

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 协作中的任务澄清。

来源与署名

来源:dontbesilent2025/dbskill位于skills/dbs-jtbd提交564a794

许可证: 无许可证

内容归原作者所有。SourceWeft 从公开仓库中收录这些内容。

举报或申请下架