Continuous Discovery / Opportunity Solution Tree for AI Products 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_CONTINUOUS_DISCOVERY_OPPORTUNITY_SOLUTION_TREE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。 本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

---

Source Anchors

---

核心导读

AI Continuous Discovery 的重点不是收集“谁想要一个助手”, 而是持续发现哪个业务结果值得改善、哪个工作机会真实存在、哪个 AI 自动化边界可接受、哪些假设风险最高、用什么证据决定继续、调整、停止或规模化。

Opportunity Solution Tree 在 AI 场景中需要扩展: outcome 之下不仅有 opportunity、solution、experiment, 还必须显式定义 AI task boundary、assumption、evidence、eval、pilot、release 和 monitoring。这样 discovery 才不会停在需求访谈, 而是成为连接产品学习、架构选择、风险控制和上线治理的系统。

---

1. 问题定义

AI 项目常被三类输入推动: 业务方说要一个助手, 高层要求上 agent, 供应商 demo 展示了很酷的能力。若直接把这些输入翻译成需求, 很容易得到 demo 强、生产弱的产品。

传统需求收集问:

你想要什么功能?

AI discovery 应问:

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

常见错误包括:

AI 需求不是被“收集”出来的, 而是通过机会、假设和证据逐步收敛出来的。

---

2. 核心原理 / 架构模型

2.1 AI Opportunity Solution Tree

经典 OST:

Outcome
  -> Opportunity
    -> Solution
      -> Experiment

AI 版本应扩展为:

Outcome
  -> Opportunity
    -> AI Task Boundary
      -> Solution Pattern
        -> Assumption
          -> Evidence
            -> Eval / Pilot / Release / Monitoring

Outcome 不能写成“上线 AI 助手”, 而要写成可观察业务结果, 例如降低 AML 低风险 alert 初审时间 20% 且不降低高风险召回, 降低客服政策查询时间 30% 且不增加投诉和误导话术, 提高信贷补件一次提交率且不产生不公平影响。

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

AI Task Boundary 决定自动化等级:

2.2 Assumption Map

AI discovery 必须显式列假设:

优先验证高不确定、高后果假设。低风险偏好或低影响假设可以延后, 但会影响客户权益、合规、财务损失或组织扩展的假设必须前置。

---

3. 方法机制

3.1 Discovery 到 Eval 的证据链

AI discovery 的产物应能一路追溯到交付和监控:

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

3.2 AI Experiment Patterns

AI 实验不等于 A/B test。不同阶段需要不同证据:

实验选择取决于假设类型。不要用满意度调查验证安全边界, 也不要用 offline eval 替代 work-as-done 证据。

3.3 Opportunity-to-Solution Trace

一个健康的 AI 机会树需要保留 trace:

Outcome:
  降低政策查询时间, 不增加投诉和误导话术

Opportunity:
  新人客服难以判断政策例外和投诉升级标准

AI Boundary:
  Assist + Recommend, 不自动承诺退款

Solution Pattern:
  RAG with citations + escalation classifier + editable response draft

Assumptions:
  政策知识足够结构化
  客服能理解引用和升级原因
  guardrail 不会造成过高误拒

Evidence:
  offline eval、wizard-of-oz、shadow mode、pilot cohort、complaint monitoring

---

4. 证据与控制

AI discovery 需要把风险控制纳入发现过程, 而不是等到上线前补审。控制问题包括:

• outcome 是否包含风险 guardrail, 例如不增加投诉、不降低高风险召回、不产生不公平影响。
• opportunity evidence 是否来自真实工作, 而不是只来自管理层描述。
• AI task boundary 是否明确 assist、recommend、decide、act 和 not-AI。
• 高风险假设是否在 pilot 前验证。
• eval 指标是否对应机会和风险, 而不是只测通用模型分数。
• pilot 是否测量 total system load, 包括复核、异常和补救成本。
• release gate 是否包含 monitoring、rollback、incident response 和 owner。

AI discovery 的成熟标志, 是学习能改变路线图。若证据显示问题真实但 solution pattern 错了, 应 pivot; 若价值不成立或风险负担过重, 应 stop; 若价值成立但平台和治理未准备好, 应 hold 并投资基础能力; 若价值、风险和复用都成立, 才进入 scale。

---

5. AI产品/金融零售场景

5.1 AML Analyst Copilot

Outcome 可以定义为降低低风险 alert 初审时间, 同时保持高风险 typology escalation recall。Opportunity 包括 analyst 花大量时间跨系统找证据、历史 case disposition 难复用、alert rationale 写作重复、高风险线索容易被低质量摘要掩盖。Solution 不应只是 summary, 而应包括 evidence retrieval、fact/inference separated summary、typology checklist、draft rationale。证据路径可以从历史 case 的 wizard-of-oz summary 开始, 再做 fact omission、citation precision、shadow mode、missed escalation review。

5.2 Customer Service Copilot

如果业务方说要聊天机器人, discovery 应回到政策适用、升级、引用、纠错和反馈机会。Outcome 是降低政策查询时间、提升一次解决率, 且不增加投诉和未经授权承诺。关键假设包括政策是否可引用、客服是否能理解 AI 的不确定性、投诉升级是否被及时触发、guardrail 是否造成过高摩擦。

5.3 信贷补件与解释

信贷补件的一次提交率可能比“智能审批”更适合作为早期 outcome。Opportunity 是申请人不知道缺什么材料、运营人员反复核对资料、政策解释不一致。AI task boundary 可以限制为 assist/recommend: 检查资料完整性、解释缺口、生成可编辑通知。若进入拒绝原因解释, 则必须增加 adverse action trace、fairness 和 appeal evidence。

5.4 财富顾问会前准备

财富场景的 opportunity 不是“AI 给投资建议”, 而是顾问会前准备耗时、客户资料分散、产品适配性和 disclosure 检查复杂。更稳妥的 solution boundary 是准备摘要、资料缺口、教育性解释和问题清单, 不自动生成最终建议或交易指令。

---

6. 反模式

---

7. 最终心智模型

AI Continuous Discovery 可以概括为:

Outcome clarity
  + work-as-done evidence
  + opportunity framing
  + AI task boundary
  + assumption risk ranking
  + experiment evidence
  + release and monitoring loop

当有人提出 AI 需求时, 不要先问要做什么功能, 而要追问它要改变哪个业务结果, 真实工作在哪里卡住, 哪些部分适合 AI, 哪些边界不能越过, 哪些假设最危险, 用什么证据决定下一步。AI 产品发现的本质不是更快写需求, 而是更快减少错误投资和不可控自动化。

---

SOTA 检查 (2026-07-01)

• OST/Continuous Discovery 方法论 2026 仍是主流且正在被 AI 工具化：Teresa Torres 于 2026-04 发文《From Customer Interviews to an Opportunity Solution Tree—In Minutes》(producttalk.org, 2026-04)，宣布与 OST 工具 Vistaly 深化合作，把「逐篇访谈合成 → 跨访谈合成 → 自动生成 OST 初稿」做成 AI 驱动流水线——即 discovery 本身也在被 LLM 增强，本篇框架未被替代，反而成为 AI 工具的骨架。
• 但 Torres 本人明确警告 AI 合成的边界：AI 访谈摘要可能遗漏 20–40% 的关键细节，必须「AI augment、human review」，不能用 AI 直接替代人工合成 (producttalk.org / Perspective AI 2026 指南)。这与本篇 2.2 节「优先验证高不确定、高后果假设」的人工判断前置逻辑一致。
• 本篇的核心扩展（Outcome→Opportunity→AI Task Boundary→Assumption→Evidence→Eval）与 2025–2026 行业共识对齐：eval-driven development 已成 AI 产品主流实践——PM 亲自标注数据建立质量标准、LLM-as-judge 默认正向偏置需持续人工抽样校准 (Braintrust《Best LLM evaluation platforms 2025》/ Amplitude AI Evals for PM, 2025)。本篇 3.2 节的 experiment→evidence 映射（offline eval / shadow mode / pilot cohort）正是该实践的 discovery 侧接口，落地查表见库内 docs/AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md。
• NIST AI RMF 锚点仍成立但已扩展：AI RMF 1.0 之上，Generative AI Profile（NIST-AI-600-1，2024-07 发布）细化了 12 类 GenAI 风险（Confabulation、Human-AI Configuration、Information Integrity 等）并映射到 Govern/Map/Measure/Manage；本篇第 4 节的控制问题清单应对齐该 profile 而非仅 RMF 1.0；agent 场景另有 CSA 基于 RMF 的 Agentic AI Profile 跟进。
• 2026 实践界公认的最大失败模式与本篇反模式表互补：不是「树画错」而是「树被饿死」(starving the tree)——opportunity space 的客户证据只按季度刷新；赢家团队以周节奏持续喂入证据 (Perspective AI, 2026)。这强化了本篇「One-shot discovery」反模式条目。
• 不随版本过时的框架性结论：AI Task Boundary 五级分层（Assist/Recommend/Decide/Act/Not-AI）、假设按「高不确定 × 高后果」前置排序、每个 feature 可追溯到 opportunity+evidence 的 trace 纪律、pilot ≠ scale 的四分决策（continue/pivot/stop/hold）——这些与具体模型或平台版本无关，是本篇的长期价值所在。操作手册版见 docs/AI_CONTINUOUS_DISCOVERY_OPPORTUNITY_SOLUTION_TREE_PLAYBOOK.md。