JTBD / ODI：AI Use Case 选择
JTBD/ODI 用于 AI use case 选择, 不是为了把用户故事写得更漂亮, 而是为了避免“有 AI 能力, 所以找个地方塞进去”。AI 是否值得介入, 要看用户要完成的 job、当前 outcome 是否 underserved、AI 是否能改善该 outcome, 以及自动化边界是否在风险可承受范围内。
Jobs-to-be-Done / Outcome-Driven Innovation for AI Use Case Selection 解读
本篇为经典方法论精读（历史回顾/经典打底定位）：主线锚点是 JTBD/ODI 经典框架（HBR 2016-09 等），机制正文以原始框架为锚点；最新进展见文末「SOTA 检查」。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| HBR: Know Your Customers' Jobs to Be Done | https://hbr.org/2016/09/know-your-customers-jobs-to-be-done | 参考 Christensen 等对 JTBD 的产品创新视角（发布 2016-09） |
| Strategyn: Jobs-to-be-Done / ODI | https://strategyn.com/jobs-to-be-done/ | 参考 outcome-driven innovation、job map 和 outcome statements（长期维护页，访问日期: 2026-07-01） |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把 AI automation boundary 和风险治理连接到 Map / Measure / Manage（AI RMF 1.0 发布 2023-01；GenAI Profile NIST-AI-600-1 发布 2024-07） |
| Product Talk: Opportunity Solution Tree | https://www.producttalk.org/opportunity-solution-tree/ | 将 JTBD outcome 与机会树和实验学习连接（长期维护页，访问日期: 2026-07-01） |
核心导读
JTBD/ODI 用于 AI use case 选择, 不是为了把用户故事写得更漂亮, 而是为了避免“有 AI 能力, 所以找个地方塞进去”。AI 是否值得介入, 要看用户要完成的 job、当前 outcome 是否 underserved、AI 是否能改善该 outcome, 以及自动化边界是否在风险可承受范围内。
这篇的核心判断是: AI use case 优先级不应由 demo 热度、部门预算或模型能力决定, 而应由 outcome opportunity、AI fit、复用潜力和风险惩罚共同决定。
问题定义
企业 AI 需求常被描述成:
我们需要一个 AI 助手。
我们要做一个智能客服。
我们希望用 AI 提高效率。
这些表达缺少四个关键要素:
- 用户在什么上下文中要完成什么工作。
- 当前工作结果哪里不满意, 且这个不满意有多重要。
- AI 介入后改善的是速度、质量、风险、体验还是认知负载。
- 哪些步骤可以自动化, 哪些步骤只能辅助、建议或升级人工。
JTBD 把“做功能”改写为“改善工作结果”。ODI 进一步要求把 outcome 写成可衡量、可排序、可验证的陈述。
核心原理/方法
一个 AI job statement 应包含:
When [context],
the user needs to [job],
so they can [desired outcome],
without [risk / cost / burden].
以 AML alert triage 为例, 不应只写“分析师需要 AI 助手”, 而应写:
当 analyst 面对一个新 alert 时,
需要快速判断是否存在值得升级的可疑模式,
并形成可审计的调查理由,
同时避免遗漏关键证据或过早关闭高风险 case。
ODI 的 outcome statement 可表达为:
Minimize / increase [metric] when [context], without [constraint].
AI outcome 示例:
| 场景 | Outcome Statement |
|---|---|
| 客服 | Minimize time to locate the correct policy when handling exception cases, without increasing misleading commitments. |
| AML | Increase completeness of evidence review when triaging alerts, without increasing missed high-risk escalation. |
| 信贷 | Minimize applicant effort to understand missing documents, without implying approval likelihood. |
| 财富 | Increase quality of advisor meeting preparation, without crossing personalized investment advice boundary. |
机会评分可以从 ODI 开始:
Opportunity = Importance + max(Importance - Satisfaction, 0)
AI 场景还要叠加:
AI Fit = data readiness + model feasibility + risk controllability + workflow adoption
Priority = opportunity score x AI fit x strategic reuse - risk penalty
系统/架构模型
AI use case selection 应转化为一条从 job 到系统边界的 trace:
Job statement
-> Job map
-> Outcome statements
-> Opportunity score
-> AI fit assessment
-> Automation boundary
-> Product workflow
-> Architecture capability
-> Eval and guardrails
-> Value and risk metrics
Job map 可使用:
Define -> Locate -> Prepare -> Confirm -> Execute -> Monitor -> Modify -> Conclude
以信贷申请为例:
| Job Step | 用户工作 | AI 机会 | 自动化边界 |
|---|---|---|---|
| Define | 理解要申请什么产品 | eligibility explanation | 信息解释, 不暗示批准 |
| Locate | 找到所需材料 | document checklist | 可自动生成清单 |
| Prepare | 准备收入、身份、资产证明 | missing document detection | 可检测缺失, 需解释依据 |
| Confirm | 确认材料是否符合要求 | pre-submission check | 可辅助, 不作最终资格判断 |
| Execute | 提交申请 | assisted form completion | 可预填, 用户确认 |
| Monitor | 跟踪状态 | status explanation | 可自动解释状态 |
| Modify | 补件或纠错 | personalized next action | 可建议, 高风险转人工 |
| Conclude | 理解决策结果 | adverse action explanation | 必须与真实决策逻辑一致 |
架构上, job step 决定是否需要 RAG、规则引擎、工具调用、人工队列、证据链和 eval 类型。
关键机制与取舍
AI 介入方式不应只有“自动化/不自动化”二元选项:
| Job Step 类型 | AI 角色 | 取舍 |
|---|---|---|
| 信息查找 | retrieve / summarize | 高价值低风险, 重点是来源和权限 |
| 重复综合 | draft / synthesize | 可减少认知负载, 但要防事实遗漏 |
| 低风险分类 | classify with review | 可提高吞吐, 但要监控 false negative |
| 高风险判断 | decision support | 保留人工判断和证据链 |
| 客户权益影响 | explain / recommend with control | 需要披露、申诉和 reason trace |
| 资金或账户动作 | constrained action with approval | 需要 least privilege、幂等、回滚 |
| 监管敏感 | assist / escalate | 避免越界建议和未经授权承诺 |
真实取舍包括:
- 效率机会大但风险不可控的 use case, 不应优先自动化。
- 数据准备差的 use case, 可能先做流程和知识治理, 再做 AI。
- 高复用平台能力可优先投资, 即使单一业务线 ROI 不突出。
- 内部员工场景不天然低风险; 如果影响客户权益、合规证据或运营决策, 仍需高等级控制。
证据与控制
AI use case selection 的证据包应包括:
| 证据 | 目的 |
|---|---|
| Job statement | 确认不是从技术能力出发 |
| Job map | 定位 AI 介入的具体步骤 |
| Outcome catalog | 明确要改善的速度、质量、风险、体验或负载 |
| Importance / satisfaction evidence | 支撑 underserved outcome 判断 |
| AI fit assessment | 评估数据、模型、风险和 adoption 可行性 |
| Automation boundary matrix | 明确 assist、recommend、decide、act 的边界 |
| Eval plan | 将 outcome 和风险转成可测试指标 |
| Decision log | 记录优先级、放弃理由和反转条件 |
控制重点是防止 use case pipeline 被“最响亮的需求”占据。评审时应要求每个候选 use case 同时解释业务 outcome、AI fit、风险边界和证据强度。
AI产品/金融零售场景
AML analyst
核心 job 是判断 alert 是否需要升级并形成可审计调查理由。underserved outcomes 包括减少跨系统找证据时间、增加证据完整性、降低遗漏高风险 typology、减少 rationale 写作负担。AI fit 上, evidence retrieval 和 draft rationale 较高; auto close alert 风险过高, 应保留人工判断和 QA 抽样。
客服异常处理
核心 job 是在客户情绪、政策例外和合规边界下给出准确可升级答复。AI 可以检索政策、总结客户历史、生成建议话术和提示升级路径; 不应承诺未授权赔付, 不应把投诉和欺诈疑似留在自动化闭环中。
AI 平台内客户
平台团队的客户是业务 AI 产品团队。它们的 job 是在不重复造基础设施的情况下, 安全、快速、可审计地上线 use case。underserved outcomes 包括降低模型接入时间、降低 eval gate 设置成本、降低审计证据准备成本和提高供应商替换能力。这能指导平台优先做 gateway、EvalOps、evidence capture 和 golden path。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Persona theater | 只写用户画像, 不理解 job | 写 job statement 和 job map |
| AI everywhere | 每个步骤都塞 AI | 按 outcome、风险和责任定 automation boundary |
| Feature bias | 从“助手/agent”开始 | 从 underserved outcome 开始 |
| Efficiency-only business case | 只计算省时 | 加质量、风险、信任、人工负载 guardrail |
| Demo-driven prioritization | 谁的 demo 好看谁优先 | 用 opportunity、AI fit、reuse 和 risk 排序 |
| Platform without internal JTBD | 平台列功能清单 | 分析业务团队上线 AI 的 job-to-be-done |
最终心智模型
JTBD/ODI for AI 的最终心智模型是:
不是选择“哪里能放 AI”,
而是选择“哪个重要工作结果被严重低满足,
且 AI 能在可控风险内持续改善它”。
AI use case 选择的成熟度体现在边界感: 知道哪些 job step 适合检索、摘要、草稿和建议, 哪些只能提供证据支持, 哪些在当前风险、数据或组织能力下不该做。真正高级的 AI 产品决策, 往往是清楚地决定不自动化什么。
SOTA 检查 (2026-07-01)
- "少而精"的 use case 选择已被 2025-2026 大样本数据实证支持：McKinsey State of AI 2025 显示 88% 的组织已在至少一个业务功能使用 AI（三年前为 50%），但仅约 6% 属于"AI 高绩效者"（AI 贡献 EBIT 超过 5%）；Deloitte State of AI 2026 报告进一步给出：高 ROI 企业平均只重点投入 3.5 个 use case（低回报企业为 6.1 个），且领先梯队预期 ROI 是同行的 2.1 倍。这直接验证本篇"按 opportunity × AI fit × reuse − risk penalty 严选、而非 AI everywhere"的核心论点——集中优于撒网。
- 2025-2026 的企业级 AI use case 优先级框架本质上是 ODI 变体：市面上已有十余个竞争框架（来自 OpenAI、Google、Microsoft、EY、Capgemini 等），主流形态是 Impact/Effort 矩阵和加权评分模型，评分维度普遍为 business value + technical feasibility + strategic fit + risk/compliance + data readiness——与本篇的
Priority = opportunity × AI fit × strategic reuse − risk penalty公式同构。本篇给出的 job statement → job map → outcome statement → opportunity score 这条 trace 是这些框架的方法论底座，属于不随模型版本过时的框架性结论。 - 风险治理锚点已从 AI RMF 1.0 扩展：本篇引用的 NIST AI RMF 1.0（2023-01）仍是现行基线，未被替代；但 automation boundary 相关内容今天应叠加 Generative AI Profile（NIST-AI-600-1，2024-07 发布）——它把生成式 AI 特有风险（confabulation、信息完整性等）映射进 Map/Measure/Manage，比 RMF 1.0 更贴合本篇"assist / recommend / decide / act 分级边界"的落地。
- 2026 的增量变化是 agent 化：use case 选择的对象从"生成式辅助功能"扩展到"多步 agent 工作流"，业界已出现面向 AI agent 的 use case roadmap 优先级框架（2025-2026）；对本篇的影响是 automation boundary 矩阵中 "constrained action with approval" 一行的权重上升——但 JTBD/ODI 的判断逻辑（underserved outcome + 风险可控性决定介入深度）不变。
- 库内实操落点：本篇框架已在本仓库落地为 AML Copilot 的产品发现笔记
docs/aipa/day1-aml-copilot-product-discovery-jtbd.md（AIPA-120 D1，2026-06），用同一套 job statement / outcome / automation boundary 方法推导 AML alert triage 的 AI 介入边界，可作为本篇的应用范例对照阅读。