返回 Papers
AI 底层逻辑 / 经典论文

Continuous Discovery / OST：AI 产品发现

一句话:

295 行ai-foundations/papers/71-continuous-discovery-opportunity-solution-tree-ai-products.md

Continuous Discovery / Opportunity Solution Tree for AI Products 解读

面向对象: AI PM / Senior BA / Product Architect / AI Business Architect / Product Trio / Transformation Lead。 核心问题: AI 项目很容易被“业务方想要一个助手”“领导要一个 agent”“供应商 demo 很酷”推着走。高级 AI 产品发现不是收集需求, 而是持续识别业务结果、机会、假设、方案和证据, 并把 discovery、eval、pilot、release、monitoring 连接成学习系统。 学习目标: 用 Continuous Discovery 和 Opportunity Solution Tree (OST) 思维, 把 AI 产品从 feature request 转成 opportunity portfolio、assumption map 和 evidence-driven delivery。

Source Anchors

SourceLink用途
Product Talk: Opportunity Solution Treehttps://www.producttalk.org/opportunity-solution-tree/参考 outcome -> opportunities -> solutions -> experiments 的机会树结构
Product Talk: Continuous Discoveryhttps://www.producttalk.org/continuous-discovery/参考持续客户接触、假设验证和产品团队学习节奏
NIST AI RMFhttps://www.nist.gov/itl/ai-risk-management-framework把 AI discovery 中的风险、度量和管理连接到 Govern / Map / Measure / Manage
Microsoft Human-AI Interaction Guidelineshttps://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/将 AI 交互中的期望、纠错、反馈和控制纳入 discovery 假设

一句话:

AI Continuous Discovery 是持续发现“哪个 AI 问题值得做、以什么自动化边界做、用什么证据证明值得继续”的产品学习系统。

1. 为什么 AI Discovery 不是需求收集

传统需求收集问:

你想要什么功能?

AI discovery 要问:

你在什么工作结果上被什么不确定性、信息缺口、判断负担、风险约束和系统摩擦卡住?
哪些部分适合 AI 辅助、建议、决策或执行?
我们如何证明它真的改善结果, 而不是把工作和风险转移到别处?

AI 需求收集的常见错误:

错误后果
业务方说“做 Copilot”, 团队直接写 PRD没有识别真正 opportunity
从模型能力出发demo 强, 生产弱
只访谈 manager, 不看 work-as-done真实例外和负载被忽略
只验证 desirability忽略 feasibility、viability、risk
把 pilot 成功等同于 scale 成功平台、治理、运营能力跟不上

高级 AI PM/BA 要把“需求”拆成机会和假设。

2. AI Opportunity Solution Tree

经典 OST:

Outcome
  -> Opportunity
    -> Solution
      -> Experiment

AI 版本需要扩展:

Outcome
  -> Opportunity
    -> AI task boundary
      -> Solution pattern
        -> Assumption
          -> Evidence
            -> Eval / pilot / release / monitoring

2.1 Outcome

Outcome 不能写成“上线 AI 助手”。要写成可观察业务结果:

  • 降低 AML 低风险 alert 初审时间 20%, 且不降低高风险召回。
  • 降低客服政策查询时间 30%, 且不增加投诉和误导话术。
  • 提高信贷补件一次提交率, 且不产生不公平影响。
  • 提高财富顾问会前准备质量, 且不越过投资建议边界。

2.2 Opportunity

AI opportunity 不是“模型能做什么”, 而是用户工作中的 unmet need:

Opportunity 类型示例
Information Gapanalyst 找不到完整证据链
Judgment Load客服难以判断政策适用例外
Coordination Friction二线复核与一线信息不对称
Knowledge Freshness政策变更无法及时反映到话术
Risk Ambiguity高风险 case 不知道何时升级
Repetitive Synthesis需要反复汇总多系统信息

2.3 Solution

AI solution pattern:

  • RAG。
  • classifier。
  • summarizer。
  • recommender。
  • workflow assistant。
  • agent with tool use。
  • rules + LLM hybrid。
  • human review console。

2.4 Experiment

AI experiment 不只是 A/B:

  • fake door。
  • concierge test。
  • wizard-of-oz。
  • offline eval。
  • shadow mode。
  • red-team eval。
  • pilot cohort。
  • production sample review。

3. Assumption Mapping

AI discovery 要显式列假设:

假设类型问题
Desirability用户是否真的需要 AI 支持, 还是需要流程/权限/数据修复
Feasibility数据、模型、RAG、tool、latency 是否能支撑
ViabilityROI、成本、运营负载、供应商依赖是否可接受
Usability用户能否理解、信任、纠错和接管
Risk客户权益、合规、安全、隐私、偏差是否可控
Scalability平台、治理、知识、运营是否能复用和扩展

高风险假设优先验证:

High uncertainty + high consequence -> test first
Low uncertainty + low consequence -> defer

4. Discovery 到 Eval

AI discovery 的证据链:

Discovery ArtifactEval / Delivery Artifact
OutcomeNorth Star / KPI / benefit metric
Opportunityuser journey pain evidence
Solutionarchitecture option / ADR
Assumptionrisk and evidence backlog
Experimenteval / pilot / prototype
LearningPRD update / roadmap decision
Release gaterisk-tiered launch decision
Monitoringproduction learning loop

原则:

  • 每个 AI feature 都应能追溯到 opportunity。
  • 每个 opportunity 都应有证据。
  • 每个高风险假设都应有测试。
  • 每个 pilot 都应产生继续、调整、停止或平台化判断。

5. 金融零售案例

5.1 AML Analyst Copilot

Outcome:

将低风险 alert 初审时间降低 20%, 同时保持高风险 typology escalation recall >= 98%。

Opportunity:

  • analyst 花大量时间跨系统找证据。
  • 历史 case disposition 难复用。
  • alert rationale 写作重复。
  • 高风险 typology 线索容易被低质量摘要掩盖。

Solutions:

  • evidence retrieval。
  • fact/inference separated summary。
  • typology checklist。
  • draft rationale。

Experiments:

  • 30 个历史 case 的 wizard-of-oz summary。
  • offline eval: fact omission, citation precision。
  • shadow mode: analyst time and edit distance。
  • risk review: missed escalation cases。

5.2 Customer Service Copilot

Outcome:

降低政策查询时间, 提升一次解决率, 不增加投诉和未经授权承诺。

Opportunity:

  • 政策分散。
  • 新人客服不熟悉例外。
  • 投诉升级标准模糊。
  • 话术需要合规和同理心平衡。

Discovery 不应从“做聊天机器人”开始, 而是从政策适用、升级、引用、纠错和反馈机会开始。

6. 模板: AI Opportunity Solution Tree

# AI Opportunity Solution Tree: [Use Case]

## Outcome
- Business outcome:
- Risk guardrail:
- Target segment / workflow:

## Opportunities
| Opportunity | Evidence | Frequency | Pain / risk | Owner |
|---|---|---|---|---|

## AI Task Boundary
| Opportunity | Assist | Recommend | Decide | Act | Not AI |
|---|---|---|---|---|---|

## Solutions
| Solution | Pattern | Data / model dependency | Risk |
|---|---|---|---|

## Assumptions
| Assumption | Type | Confidence | Consequence | Test |
|---|---|---|---|---|

## Experiments / Evidence
| Experiment | Evidence | Decision rule | Next move |
|---|---|---|---|

7. 反模式

反模式表现修正
AI feature factory不断接 AI 需求从 outcome 和 opportunity 反推
Demo as discovery看 demo 决定路线用真实 work-as-done 和假设测试
One-shot discovery开头调研一次建立持续客户接触和生产反馈
Eval without opportunity测模型分数但不知道业务机会eval 指标绑定 opportunity
Pilot theaterpilot 指标好看但没有 scale evidence增加运营、平台、治理和风险证据

8. 面试回答

Q: 你如何发现一个 AI use case 是否值得做？

30 秒版本:

我会从业务 outcome 和 work-as-done 出发, 用 opportunity solution tree 拆出用户机会、AI task boundary、方案和关键假设。然后优先验证高不确定、高后果假设, 用 eval、prototype、shadow 和 pilot 形成证据, 决定继续、调整、停止或平台化。

Q: 业务方说要一个 AI 助手, 你怎么办？

30 秒版本:

我不会直接写“AI 助手”需求, 会追问它要改善哪个业务结果、用户在哪些任务上卡住、哪些部分适合 AI 辅助或自动化、哪些风险不可接受。最后把需求变成 opportunity tree 和 eval contract。

9. 作品集交付物

  1. AI Opportunity Solution Tree。
  2. Work-as-Done Evidence Pack。
  3. AI Assumption Map。
  4. Experiment / Eval Plan。
  5. Pilot Learning Memo。
  6. Scale / Stop / Pivot Decision。
  7. Discovery-to-Delivery Traceability Map。

这套材料能证明你具备高级 AI PM/BA 能力: 不是把业务方想法翻译成需求, 而是持续发现、验证和治理 AI 产品机会。