JTBD 在 slide 上看着简单，落地几乎都跑偏：团队写的”job 句”其实是功能描述，访谈跳过切换触发，JTBD 沦为头脑风暴前的暖场，而不是决策过滤器。下面 12 个 Prompt 把严谨逼回来——切换触发访谈设计、四力分析、经得起推敲的 job 句、功能 / 情感 / 社会三层拆解，以及用 JTBD 真去 backlog 上砍功能。锁好 job 之后，配合 特性优先级 Prompt 继续往下推。
TL;DR
- 处理逐字稿要用长上下文模型：截至 2026 年 6 月，Claude Sonnet 4.6 与 Gemini 3.1 Pro 都是 1M token 上下文，一段 60 分钟访谈（约 9,000–11,000 字英文）能一次性贴进去还留得下指令空间。ChatGPT Plus 应用内大约只到 320 页，完整 1M 上下文只在 200 美元的 Pro 档。
- JTBD 有三大流派，下面的 Prompt 都照顾到了：Bob Moesta 与 Chris Spiek 的切换访谈（时间线 + 四力）、Tony Ulwick 的结果驱动创新 ODI（一个功能 job，配多条可量化的结果陈述）、Alan Klement 的 job story（“When… I want… so I can…”，不带 persona）。
- job 陈述句点出客户想取得的进展；job story 多了情境和情感背景。两者都不是功能。
- 信任一个模式之前先做 10–15 场切换访谈——Moesta 的经验法则是这个量足以覆盖客户群里绝大多数可行动的模式。
- 这里杠杆最高的是 #7（功能筛）：JTBD 只有在砍掉工作时才回本，而不是又生成更多工作。
先选对模型
这些 Prompt 都吃又长又乱的访谈文本，要模型把整条时间线放在工作记忆里。这里上下文窗口比裸跑分更重要。
| 模型（2026 年 6 月） | 上下文 | 在本流程里最适合 |
|---|---|---|
| Claude Sonnet 4.6 | 1M token | 逐字稿分析（#12）、长替代地图；结构化抽取很稳 |
| Gemini 3.1 Pro | 1M token | 同上；API 最便宜，每百万 token 进 / 出 2 / 12 美元 |
| Claude Opus 4.7 | 1M token | 最难的判断题——哪个 job 句经得起推敲（#2）、买方 vs 用户冲突（#9） |
| GPT-5.5（ChatGPT Plus） | 应用内约 320 页 | 起草与发想（#1、#6、#11）；逐字稿分段贴 |
逐字稿类 Prompt（#3、#8、#12）跑在 1M 上下文模型上，就不用把一段访谈从中间切开。把 Opus 4.7 留给那些要模型去选而不是抽的题。
这套 Prompt 适合用在哪
- MVP 前客户发现
- 老产品重定位
- 锐化 landing 文案
- 功能优先级
- 销售 call 结构
1. JTBD 访谈题库
为刚注册 / 流失 / 推荐的 {产品} 客户生成 15 道 JTBD 访谈题。覆盖：触发、评估、决策瞬间、预期结果、他差点选的替代。2. Job 句撰写
下面是访谈笔记。请按 "When {situation}, I want to {motivation}, so I can {outcome}" 给 3 个候选 job 句。挑最经得起推敲的；说另外两个为何错（例如：它描述的是功能，而不是进展）。
{粘贴}3. 切换触发分析（四力）
我的客户刚从 {替代} 切到我。请按 JTBD 切换访谈走一条时间线：第一念头（被动观望）、触发事件（主动找）、评估、决策（购买）、初期使用。再映射进展的四力：旧情境的推力、我产品的拉力、切换的焦虑、习惯 / 惯性。按时间线顺序输出问题。4. 替代地图（不止竞品）
为 job 句 {粘贴} 列真实替代：直接竞品、间接工具、手工 workaround、"什么也不做"、雇人代做。各自何时赢、何时输，以及是哪股力（推 / 拉 / 焦虑 / 惯性）把客户留在那。5. 功能 / 情感 / 社会 三层 job
下面是我的 JTBD。请拆分为功能、情感、社会三层。每层给访谈里 2 条具体线索。标出我现在产品忽略的是哪一层。
{粘贴}6. JTBD → 定位
为 job {粘贴} 写定位句：点出情境、想要的进展、我们独特的交付方式。再给 3 个变体。禁用"行业领先 / 同类最佳"这类空话。7. JTBD → 功能筛
下面是我 backlog 里 15 项 + 主 JTBD。请把每项评为：推进 JTBD / 边缘 / 完全是另一个 job。低于"推进"的剔除，每项一行说明为什么。
{粘贴}8. JTBD 错位检测
下面是我现在的 landing page + 一段客户描述他 job 的访谈。请找出我的页面在解决"不同的 job"的所有处，每处给一条具体改写。
{粘贴}9. B2B 的买方 job vs 用户 job
为我的 B2B 产品分开：买方 job（公司为什么买）与用户 job（个人每天为什么用）。输入 {粘贴}。输出：两个 job、冲突点、信息中如何在不让任一受众糊涂的前提下兼顾。10. Job 分群
我觉得我的产品只做 1 个 job，但客户群异质。下面是客户描述。请判断是否有 2-3 个 job 在并行，并建议该聚焦一个还是分群表达。
{粘贴}11. Job story 写法
把这个 JTBD 转为 5 条 job story，格式："When {情境 + 情感背景}, I want to {motivation}, so I can {outcome + meta-outcome}"。不带 persona。每条恰好暗示 1 个功能。
{粘贴}12. JTBD 访谈转录分析
下面是 60 分钟 JTBD 访谈逐字稿。请抽取：触发、考虑过的替代、决策标准、"必须现在找点办法"瞬间、预期结果。标出客户说出口的四力。输出 1 页结构化总结。
{粘贴}job 句 vs job story（团队最容易混的地方）
这两个不能互换，用错是 JTBD 最常见的翻车点。
| job 句（Ulwick 风格） | job story（Klement / Wodtke） | |
|---|---|---|
| 形式 | 动词 + 宾语 + 情境：把报销提交的时间降到最低 | When [情境], I want to [动机], so I can [结果] |
| 带情感？ | 不带——保持一维、可度量 | 带——情境和情感背景正是重点 |
| 带 persona？ | 不带 | 不带（刻意区别于 user story） |
| 最适合 | 在问卷里量化被低估的结果 | 设计某个具体功能或页面 |
Ulwick 反对把一切塞进一条 job story，理由是：那样以后就没法度量客户到底在哪里被低估了。Klement 的反驳是：正是情境和动机让一个功能显得”理所当然”。两种你都该有；Prompt #2 产出陈述句，Prompt #11 产出 story。
容易踩的坑
- job 句写得像功能描述（“用户可以筛选……”），而不是描述进展
- 不画替代地图——假装”什么也不做”和”手工 workaround”不算竞品
- B2B 把买方 job 和用户 job 混在一起，最后哪头都不讨好
- 跳过切换触发——JTBD 没有触发事件，就是签语饼上的话
- 把 JTBD 当头脑风暴前的暖场，而不是 backlog 上的砍刀
- 异质客户群硬塞一个 job 句，应该拆成 2-3 个分群
- 3 场访谈就信一个模式——行动前先做 10–15 场切换访谈
FAQ
JTBD 访谈到底要做几场？
Bob Moesta 的经验法则是 10–15 场切换访谈，足以浮现客户群里绝大多数可行动的模式。少于这个数就是在噪音里凑模式；多很多则收益递减。招募近期切换者（过去 60–90 天内购买或流失的人），时间线在记忆里还新鲜。
job 句和 job story 有什么区别？
job 句点出进展（“把报销提交的时间降到最低”），保持一维以便度量。job story 多了情境和情感背景（“当我半夜落地只想睡觉时，我想两下就把报销提交完，这样我就不用再揣着纸质发票”）。陈述句用来排优先级，story 用来做设计。Prompt #2 和 #11 各管一种。
Prompt #3 里的”四力”是什么？
进展的四力来自 Moesta 与 Spiek 的切换模型：现状的推力（对现状的不满）、新方案的拉力（想象中更好的未来）、切换的焦虑（担心和不确定）、留住人的惯性 / 习惯。只有当推力 + 拉力压过焦虑 + 惯性时，切换才会发生。四力都要映射，否则你会读错别人为什么买。
这些 Prompt 能在免费档跑吗？
短 Prompt 可以，但逐字稿类（#3、#8、#12）需要长上下文。截至 2026 年 6 月，Claude 免费档给有限的 Sonnet 4.6 访问，Google AI 免费档给有限的 Gemini 访问——测试都够。要把整段 60 分钟逐字稿一次贴进去，付费档上的 1M 上下文模型（Sonnet 4.6、Gemini 3.1 Pro）更稳。
JTBD 能取代用户画像吗？
job story 流派（Klement、Wodtke）认为可以——persona 是用人口统计属性堆出来的想象客户，解释不了因果；而 job 关注的是情境和动机。实践中很多团队保留轻量 persona 用于招募，把 JTBD 用在真正的产品决策上。两个都想要，就先用这些 Prompt 生成 job，再对照你的 用户画像 Prompt 校验一遍。
相关阅读
标签: #Prompt #产品创业 #User Story