需要在具体情境中澄清用户到底要推进什么进展时，用 JTBD…

当用户说出的方案、功能或提示词可能不是真正目标时，用这套流程识别情境、进展、结果、切换力量与选择标准，据此交付更合适的答案。

适用场景

解决思路

1. 先不要把用户说的「帮我写一篇文章」「我需要一个课程」「给我做一个智能体」等表面请求直接当成需求结论；它通常只说明用户想到的方案。
2. 先找出链条：情境 → 卡住的进展 → 想得到的结果 → 当前方案 → 选择标准。
3. 用任务陈述格式：「当我处于 {情境}，我想要 {推进的进展}，以便 {得到的结果}。」
4. 把「进展」写成变化，例如「把混乱的访谈整理成能做决策的判断」，不要只复述动作，如「整理访谈」。
5. 把「结果」落在用户能感知的状态、风险或机会，避免空泛的「提升效率」。
6. 每次都检查一个任务的三层：功能任务、情绪任务、社会任务；但只输出对当前任务有用的层。
7. 功能任务要找要完成的实际进展，例如「在开会前形成可执行的方案」；功能任务通常决定交付物。
8. 情绪任务要找希望摆脱或获得的感受，例如「不再担心自己漏掉关键风险」；情绪任务常决定表达、阻力与最终选择。
9. 社会任务要找希望别人如何看待自己，例如「让团队觉得方案经过充分考虑」；社会任务常决定表达、阻力与最终选择。
10. 找出用户在「雇用」或「解雇」方案时的切换力量：推力、拉力、焦虑、习惯。
11. 推力要判断旧做法造成了什么具体损失、压力或阻塞。
12. 拉力要判断新方案承诺了什么更好的进展。
13. 焦虑要判断用户担心新方案会带来什么代价或失败。
14. 习惯要判断旧做法为什么仍能被继续容忍。
15. 判断方案被采用通常需要推力和拉力强过焦虑与习惯；输出建议时要处理这四种力量，不能只放大卖点。
16. 用户已经给出情境、目标或失败经历时，先基于材料写「任务假设」，不要机械追问。
17. 只有缺失以下信息且会改变建议时，才问 1 个最小问题：用户此刻处于什么情境、他要推进的变化是什么、他为何要在现在换方案、他用什么结果判断方案好坏。
18. 问题优先问具体事实，例如「你上一次试图解决这件事时，卡在了哪一步？」；不要问「你的痛点是什么」「你的目标用户是谁」这类宽问题。
19. 用户回答不完整时，明确哪些是事实、哪些是你的假设，继续提供当前最有用的版本。
20. 把方案语言翻译成任务语言：拆出表面请求、任务假设、预期结果。
21. 表面请求是他让人工智能、产品或服务交付什么；任务假设是他想推进的进展；预期结果是完成后能少承受什么风险、得到什么机会或进入什么状态。
22. 若表面请求与任务一致，直接推进。
23. 若表面请求与任务存在错位，说明错位及其后果，再给出更贴近任务的交付方式；保留用户原先方案作为候选，不要武断否定。
24. 从材料中提炼 3–5 个可判断的选择标准，并标注优先级：必须满足、加分项、可接受代价。
25. 必须满足的标准：不满足就不会被雇用；加分项：能提高选择概率；可接受代价：用户愿意为进展付出的时间、钱、学习或风险。
26. 标准要可观察；把「简单好用」还原为「第一次使用 10 分钟内能否得到可修改的结果」这类表述。
27. 根据任务决定行动：与人工智能协作时，优先重写提示词、补足输入、规定验收标准与下一步。
28. 产品或服务场景优先输出：任务定义、雇用时刻、需求优先级、降低切换焦虑的设计。
29. 内容或销售场景优先输出：用户当下情境、旧方案失效处、可感知进展、可信证据。
30. 个人决策场景优先输出：候选方案如何服务任务、代价、最小验证动作。
31. 若用户要做提示词，把任务陈述放在提示词开头，并补上情境、已有材料、边界、交付物和验收标准；人工智能能从这些约束推导方案，不能从抽象标签中可靠猜出用户的处境。
32. 默认用紧凑输出模板：## JTBD 判断；**表面请求**；**任务陈述**；**三层任务**（功能、情绪、社会）；**为什么是现在**（推力／触发事件）；**选择标准**（必须满足、加分项、可接受代价）；**切换阻力**（焦虑与习惯；没有证据时写待确认）；**对当前任务的启发**；**下一步**；**待确认**（仅列会改变结论的 0–2 个现实事实）。
33. 信息很少时，将结论标为「待验证假设」。
34. 用户只要一个答案、文案或提示词时，不必完整展示框架；内部完成判断后，直接交付结果，并用 1–2 句话说明它服务的任务。
35. 当用户让人工智能做一件事，默认按以下顺序工作：从当前对话提炼 JTBD 任务陈述。
36. 识别表面请求与任务之间是否有错位。
37. 先给可用交付物，再列出会明显提高质量的最小补充信息。
38. 把用户反馈视为任务假设的更新；用户改方案时，重新检查他要推进的进展有没有改变。
39. 可用提示词骨架：「我正处于 {情境}。我需要推进 {进展}，以便 {结果}。我目前考虑用 {方案}，但担心 {风险／阻力}。请在 {边界} 内输出 {交付物}。合格标准：{3 条可检查标准}。若任务与我的方案错位，请先指出错位，再给出更合适的执行方案。」
40. 不把人口属性、行业标签或用户说的产品名直接当成任务证据。
41. 不把「买」「使用」「点击」自动解释为任务完成；找实际进展与验收方式。
42. 不用虚构访谈、行为数据或动机；缺证据时写为假设。
43. 不把所有任务都压成「赚钱」或「效率」；必要时保留情绪与社会层的独立作用。
44. 不为了套框架连续发问；已有材料足够时，先完成任务判断和交付。
45. 不把 JTBD 当作用户画像、功能清单或万能解释；它只用于解释具体情境中的选择与进展。
46. 当前任务完成后直接结束；只有用户明确询问下一步，且当前环境已经安装 `/dbs` 时，简短提示输入 `/dbs`。
47. 说话时直接说任务、情境、进展和证据，少用理论术语。
48. 明确区分事实、推断与待确认项。
49. 中文遵循《中文文案排版指北》：中英文之间、中文与数字之间加空格。
50. 不使用「不是 X，而是 Y」及其近似句式。
51. 本 Skill 从待完成工作（Jobs to Be Done）视角理解用户要完成的事，用于产品、内容、决策或人工智能协作中的任务澄清。

适用边界 · 注意事项

• 缺少证据时不要虚构访谈、行为数据或动机；只能写成假设。
• 已有材料足够时不要为套 JTBD 框架连续发问；应先完成任务判断和交付。
• 不要把 JTBD 当作用户画像、功能清单或万能解释；也不要把人口属性、行业标签、产品名或「买／使用／点击」直接当作任务证据。