AI Continuous Discovery & Opportunity Solution Tree Playbook

定位：面向高级 AI PM / AI BA / Product Architect / AI Solutions Architect 的持续发现与机会树手册。目标不是重新讲“需求收集”，而是把 AI 产品从 stakeholder idea、模型能力、流程痛点和风险假设，转成可验证的 outcome、opportunity、solution、assumption、eval 和 pilot decision。 适用对象：金融零售 AI 产品负责人、AI 转型负责人、企业 AI 平台 PM、风控/合规/运营场景 AI PM、已具备成熟 BA/产品经验但需要升级 AI 产品判断的人。 核心问题：如何判断一个 AI use case 是否值得做、应该做成 copilot / RAG / agent / workflow automation / 平台能力，如何证明它在受监管业务中真的创造价值且风险可控。 作品集定位：本文可直接转化为 AI Discovery Portfolio，包括 Opportunity Solution Tree、Assumption Map、Eval Contract、Pilot Protocol、Learning Decision Record、Financial Retail AI Case Pack 和 30 天训练资产。 边界说明：本文不是基础 BA 教材、法律意见、合规意见、模型验证报告或监管解释。正式金融零售 AI 项目必须由 business owner、risk、model risk、legal、compliance、privacy、security、data owner、operations owner 和 architecture review 共同确认。

---

Source Anchors

这些来源作为方法论和风险管理锚点。本文将其转成 AI 产品发现、机会树、假设测试、评估和金融零售 pilot 的工作语言。

---

1. One-Sentence Positioning

一句话：

AI Continuous Discovery =
持续识别真实业务机会、用户工作流机会、AI 可行性假设和风险控制假设，
用 Opportunity Solution Tree 明确 outcome、opportunity、solution、assumption，
再通过 prototype、eval、shadow、pilot 和 production learning 决定 scale、iterate、pivot、stop 或 platformize。

更短的面试版：

AI 产品发现不是把业务方想要的 AI 功能写成需求，而是持续证明：哪个高价值工作流机会值得 AI 化，哪种 AI 形态最合适，关键假设是否被证据支持，风险是否能被 eval、控制和运营闭环管理。

1.1 高级 AI PM 的发现责任

1.2 适用场景

---

2. 为什么 AI 产品发现不是需求收集

对已成熟的 BA / PM 而言，真正的升级点不是“多问用户需求”，而是把 AI 的不确定性前置管理。

2.1 需求收集默认会犯的 AI 错误

2.2 AI 产品发现的五个新增变量

2.3 从需求文档到发现系统

Stakeholder request
  -> outcome hypothesis
  -> workflow story evidence
  -> opportunity taxonomy
  -> opportunity solution tree
  -> solution alternatives
  -> assumption map
  -> prototype / eval / pilot learning plan
  -> scale / stop / platform decision

高级判断：

• 如果一个 AI idea 不能写成 outcome，就还不是产品机会。
• 如果一个 opportunity 只有一种解决方式，它多半是 solution disguised as opportunity。
• 如果一个 solution 没有 assumption tests，就只是交付赌注。
• 如果一个 pilot 没有 eval contract、guardrail 和 learning decision rule，就只是生产环境试用。
• 如果一个平台 backlog 没有多个 use case 的重复证据，就可能是过早平台化。

---

3. AI Continuous Discovery Operating Model

AI continuous discovery 不是一次 workshop，而是一个常设学习系统。

3.1 Discovery Cell

传统 product trio 在 AI 金融零售场景通常要扩展成 discovery cell。

3.2 Cadence

3.3 Evidence Types

AI discovery 不能只看访谈，也不能只看日志。需要多证据合成。

---

4. AI Opportunity Taxonomy

机会不是“做一个 AI 功能”。机会是某个 outcome 下，真实用户、业务流程或控制系统中尚未满足的需要、痛点或愿望。

4.1 AI Opportunity 的合格表达

For [role / customer segment],
when [workflow moment / decision context],
they struggle to [job / decision / control],
because [evidence-backed constraint],
which affects [business / customer / risk outcome].

示例：

4.2 Opportunity Taxonomy

4.3 Opportunity Scoring

AI opportunity 优先级不只看价值，还要看风险可控性、可评估性和复用潜力。

决策建议：

---

5. OST for AI Products

Product Talk 的 Opportunity Solution Tree 用 outcome、opportunity、solution、assumption tests 可视化 discovery。AI 场景要额外加入 risk、data、eval、HITL 和 platform reuse 维度。

5.1 AI OST 基本结构

Outcome
  -> Opportunity space
      -> workflow opportunity
      -> knowledge / data opportunity
      -> decision quality opportunity
      -> control / trust opportunity
      -> platform reuse opportunity
  -> Target opportunity
      -> Solution option A
          -> Assumptions
          -> Tests
      -> Solution option B
          -> Assumptions
          -> Tests
      -> Non-AI / process option
          -> Assumptions
          -> Tests
  -> Learning decision
      -> scale / iterate / pivot / stop / platformize

5.2 Outcome at the Top

AI OST 顶部不能写“上线 AI 助手”。应该写可观测 outcome。

5.3 Opportunity Space 分层

AI OST 的机会空间建议按 workflow moments，而不是按组织部门或技术模块分。

5.4 Solution Space 不只放 AI 功能

每个 target opportunity 至少比较 3 类 solution，其中至少包含一个非 AI 或低 AI 方案。

5.5 AI OST 示例：AML

Outcome:
  AML case preparation median cycle time -25%;
  critical evidence omission = 0;
  SAR decision remains human-owned.

Opportunities:
  O1 Analyst must search transactions, KYC, alerts and prior cases across systems.
  O2 Analyst struggles to connect entity relationships and red flags quickly.
  O3 Narrative drafting quality varies by analyst experience.
  O4 Reviewers spend time finding missing evidence rather than judging risk.
  O5 Audit team needs evidence lineage and rationale trace.

Target opportunity:
  O2 Analyst struggles to connect entity relationships and red flags quickly.

Solutions:
  S1 Entity graph + red-flag summarizer.
  S2 Checklist-based evidence assistant.
  S3 Senior analyst review template and training.

Assumption tests:
  A1 Red flags can be detected from available transaction / KYC / case data.
  A2 Analysts trust AI only when every claim links to evidence.
  A3 Reviewer defect rate improves without increasing false comfort.
  A4 Tool can avoid suggesting SAR decision and stay in evidence support boundary.

---

6. Assumption Mapping

Assumption mapping 是 AI discovery 的核心。AI solution 的风险通常不是“能不能写代码”，而是业务、模型、数据、控制和 adoption 假设是否成立。

6.1 AI Assumption Categories

6.2 Risk x Uncertainty x Evidence Cost

优先测试的不是最容易测的假设，而是高风险、高不确定、低到中等测试成本的假设。

6.3 Assumption Map Template

## Assumption Map

**Outcome:** [可观测业务/客户/风险结果]
**Target opportunity:** [证据支持的机会]
**Solution option:** [待验证的方案]
**Risk tier:** [Low / Medium / High / Critical]

| Assumption | Category | Why it matters | Risk | Uncertainty | Evidence now | Test | Pass signal | Fail signal | Decision impact |
|---|---|---|---|---|---|---|---|---|---|
| Analysts will trust generated AML red flags only when every claim links to transaction evidence. | Adoption / Trust | Without trust, usage will stay superficial. | High | Medium | 4 analyst interviews, 2 case audits | Prototype with citation trace on 8 cases | 6/8 analysts can explain and use evidence trace | Analysts ignore output or cannot verify claims | Redesign UX or stop summarizer path |

6.4 金融零售常见 Riskiest Assumptions

---

7. Prototype / Eval / Pilot Learning Loop

AI discovery 的学习循环不能停在原型。原型回答“人是否理解和愿意用”，eval 回答“系统是否达到质量和风险门槛”，pilot 回答“真实流程是否产生可控价值”。

7.1 Learning Loop

Opportunity evidence
  -> solution alternatives
  -> assumption map
  -> prototype test
  -> offline eval
  -> shadow / replay
  -> controlled pilot
  -> learning decision
  -> OST update

7.2 Prototype Types for AI

7.3 Eval Contract

Eval contract 是 AI 产品需求的验收形式。

## Eval Contract

**Use case:** AML Case Evidence Copilot
**Workflow boundary:** Evidence gathering and narrative draft only; no SAR decision.
**Risk tier:** High
**Primary quality metric:** Evidence completeness score >= 4/5 on SME rubric
**Critical failure classes:** unsupported claim, missing mandatory red flag, wrong citation, SAR recommendation, PII leakage
**Critical threshold:** 0 critical failures in release set
**Golden set:** 80 historical cases, stratified by typology, complexity, customer segment and alert type
**Reviewer:** AML SME + model risk reviewer
**Release decision:** pass / limited pilot / fail / exception
**Monitoring:** override reason, reviewer defect, citation issue, hallucination report, cycle time, incident

7.4 Pilot Protocol

7.5 Learning Decision Record

## Learning Decision Record

**Date:** 2026-06-29
**Use case:** Customer Service Fee Dispute AI Assistant
**Decision:** Limited scale to two more queues

**Evidence reviewed:**
- 1200 pilot conversations, 84% eligible exposure
- First-contact resolution +8.7% versus baseline
- Wrong policy answer 0.4%, below 0.5% guardrail
- Complaint misclassification 0 critical failures in sampled audit
- Cost per successful resolved contact $0.18

**What we learned:**
- Retrieval works well for fee policy when source has effective date metadata.
- AI still struggles with hardship language and should escalate earlier.
- Agents trust cited answers but ignore confidence badges; citations matter more.

**Decision rationale:**
- Business value is positive and risk within appetite for fee dispute queue.
- Hardship and complaint branches remain excluded from scale until new eval passes.

**Next action:**
- Expand to two fee-related queues.
- Add hardship detection cases to eval.
- Update opportunity tree: split "fee policy confusion" and "financial hardship escalation".

---

8. Financial Retail Case Pack

以下案例按 discovery 资产组织，不是完整 PRD。重点是高级判断：何时 AI 值得做，哪里必须限制，如何验证，何时停止。

8.1 AML Investigation Copilot

OST snippet:

Outcome: Reduce AML case preparation cycle time while preserving evidence quality.
Opportunity: Analyst struggles to connect red flags across transaction and KYC evidence.
Solutions: entity graph summary / evidence checklist / senior analyst review template.
Assumptions: evidence can be grounded; analyst trusts citations; SAR boundary is enforced.
Tests: 20 case replay, red-team SAR prompts, SME blind scoring.

8.2 Customer Service AI for Regulated Servicing

8.3 Credit Underwriting / Loan Memo Copilot

8.4 Wealth Advisor Copilot

8.5 Enterprise AI Platform Discovery

---

9. Templates

这些模板可直接用于作品集或项目材料。每个模板都要求填写真实证据，不接受空泛结论。

9.1 AI Discovery Brief

# AI Discovery Brief

## 1. Outcome
- Business / customer / risk outcome:
- Baseline:
- Target:
- Time horizon:
- Guardrail:

## 2. Workflow Scope
- Role:
- Workflow moment:
- Current pain:
- Current workaround:
- Existing system / data:

## 3. Opportunity Statement
- For:
- When:
- They struggle to:
- Because:
- Which affects:
- Evidence:

## 4. Solution Alternatives
| Option | Type | Why it may work | Why it may fail | First test |
|---|---|---|---|---|

## 5. Risk and Controls
| Risk | Severity | Control | Eval / monitoring |
|---|---|---|---|

## 6. Learning Plan
- Prototype:
- Eval:
- Shadow / pilot:
- Decision rule:

9.2 Story-Based AI Interview Guide

# Story Interview Guide

## Opening
- Tell me about the last time you handled [specific workflow / case type].
- What triggered the work?
- What were you trying to accomplish?

## Workflow Detail
- What systems, documents or people did you use?
- Where did you slow down, double-check or ask for help?
- What did you copy, rewrite, summarize or interpret?
- What could go wrong if this step is done poorly?

## Judgment and Risk
- What parts require expert judgment?
- What signals make you escalate?
- What decisions are you not allowed to delegate?
- What evidence do reviewers or auditors expect?

## AI Reaction
- If AI produced [specific output], how would you verify it?
- What would make you trust or distrust it?
- What mistake would be unacceptable?
- What would you still want a human to own?

## Evidence Capture
- Quote:
- Workflow artifact:
- Opportunity:
- Assumption:
- Follow-up test:

9.3 AI Opportunity Card

# AI Opportunity Card

**Outcome:**
**Opportunity:**
**Role / segment:**
**Workflow moment:**
**Evidence:**
**Current workaround:**
**Business impact:**
**Customer / employee impact:**
**Risk impact:**
**AI leverage:** retrieve / summarize / classify / rank / draft / check / route / act with approval
**Non-AI alternative:**
**Top assumptions:**
**First test:**
**Decision after test:** scale discovery / revise / stop

9.4 AI OST Canvas

# AI Opportunity Solution Tree Canvas

## Outcome
- Direction:
- Target:
- Guardrails:

## Opportunity Space
| Opportunity | Evidence | Segment / role | Workflow moment | Opportunity type | Score |
|---|---|---|---|---|---:|

## Target Opportunity
- Selected opportunity:
- Why now:
- Why not other opportunities:

## Solution Space
| Solution | Type | Differentiator | Key risk | Reuse potential |
|---|---|---|---|---|

## Assumption Tests
| Solution | Assumption | Test | Pass signal | Fail signal | Decision impact |
|---|---|---|---|---|---|

## Learning Decision
- Continue:
- Change:
- Stop:
- Platformize:

9.5 Eval Rubric Template

# Eval Rubric

**Use case:**
**Task boundary:**
**Risk tier:**
**Reviewer role:**

| Dimension | 1 - Fail | 3 - Acceptable with issues | 5 - Strong |
|---|---|---|---|
| Grounding | Unsupported claims or missing sources | Mostly grounded but incomplete evidence | All key claims supported by approved evidence |
| Completeness | Misses required facts or steps | Covers main facts, minor gaps | Covers required facts, exceptions and next steps |
| Boundary | Gives prohibited advice or action | Minor wording risk | Stays within role and escalates appropriately |
| Usefulness | Not actionable | Partially useful | Clear, concise, workflow-ready |
| Auditability | Cannot trace source or reviewer action | Partial trace | Source, version, reviewer and action trace complete |

## Critical Failures
- Unsupported high-impact claim
- Wrong or fabricated citation
- Prohibited recommendation / decision
- Missing mandatory escalation
- Sensitive data leakage
- Policy version error

9.6 Pilot Protocol Template

# AI Pilot Protocol

## Pilot Scope
- Use case:
- Users / teams:
- Customer / case eligibility:
- Exclusions:
- Duration:

## Controls
- Human review:
- Approval points:
- Fallback:
- Kill switch:
- Incident owner:

## Metrics
| Metric | Type | Baseline | Target / threshold | Owner |
|---|---|---:|---:|---|

## Data and Telemetry
- Exposure event:
- User action:
- AI output:
- Human edit / override:
- Feedback:
- Cost:
- Latency:

## Decision Rule
- Scale if:
- Iterate if:
- Pivot if:
- Stop if:
- Platformize if:

---

10. Review Checklist

10.1 Discovery Readiness

10.2 AI Fit Review

10.3 Risk and Governance Review

10.4 Eval / Pilot Review

---

11. Anti-Patterns

---

12. 30 天训练计划

目标：30 天内产出一个金融零售 AI use case 的完整 discovery portfolio。每天 60-90 分钟，重点训练高级判断，而不是基础需求技巧。

---

13. 面试答案

Q1：AI 产品发现和传统需求收集有什么不同？

30 秒版

AI 产品发现不是把业务方想要的 AI 功能写成需求，而是持续证明某个工作流机会是否值得 AI 化。它要同时验证 desirability、business value、data readiness、model performance、risk controls、human oversight、unit economics 和 adoption。传统需求强调“要做什么”，AI discovery 更强调“为什么这个机会值得做、哪种 AI 形态合适、哪些假设最危险、用什么 eval 和 pilot 证明”。

2 分钟版

在金融零售场景，业务方经常以 solution 表达需求，比如“做一个 AML 助手”或“做一个客服 chatbot”。我会先把它还原为 outcome 和 workflow opportunity：哪个角色、哪个流程节点、什么痛点、影响什么指标。然后用 Opportunity Solution Tree 拆出 opportunity space、多个 solution options 和 assumption tests。AI 的特殊之处是输出概率化、上下文依赖强、风险边界复杂，所以需求不能只写 acceptance criteria，而要写 eval contract、critical failures、HITL、monitoring 和 learning decision。最终目标不是交付一个 AI 功能，而是做出 scale、iterate、pivot、stop 或 platformize 的证据化判断。

Q2：你会如何用 Opportunity Solution Tree 做 AI 产品？

30 秒版

我会把 outcome 放在树顶，例如降低 AML case preparation 时间且保持证据质量。下面是 opportunity space，如证据分散、red flag 难串联、narrative 返工。选择一个 target opportunity 后，比较至少 3 个 solution，包括 AI 和非 AI 方案。每个 solution 拆成假设，再用 prototype、eval、shadow 或 pilot 测试最高风险假设。

2 分钟版

OST 的价值是防止团队直接跳到“做 chatbot”或“接大模型”。AI OST 顶部必须是可观测 outcome，并带 guardrails。机会层要来自真实 workflow evidence，而不是会议想象。解决方案层要有多选项，比如 RAG、copilot、AI reviewer、rules automation 或流程改造。AI 场景还要在每个 solution 下面挂 assumption tests，例如检索是否能找到有效政策、模型是否会编造引用、人审是否能发现错误、成本是否可接受。每一轮 prototype / eval / pilot 后更新树，保留学习痕迹，最终形成投资决策证据。

Q3：如何判断一个 AI opportunity 是否值得做？

30 秒版

我会看 10 个维度：outcome relevance、workflow pain、evidence strength、AI fit、data readiness、evalability、risk controllability、adoption likelihood、unit economics 和 platform reuse。高价值但不可评估或风险不可控的机会不应该直接进入 build。

2 分钟版

AI opportunity 的判断不能只看“能不能自动化”。金融零售尤其要看它是否能改善高优先级 outcome，是否发生在高频或高风险流程节点，是否有证据支持，AI 是否比规则或流程改造更适合。然后看数据和上下文是否可用，输出好坏是否能评估，风险是否能通过人审、guardrail、audit 和 fallback 控制。最后看用户是否会在真实流程中采纳，以及成本收益是否成立。如果多个业务场景共享同一能力，还可能进入平台化机会。反过来，如果机会只是“业务想试 AI”，没有 outcome、eval 或 risk boundary，我会先停止或重写机会。

Q4：怎么做 AI assumption mapping？

30 秒版

我把假设分成 desirability、value、usability、adoption、data、retrieval、model performance、safety、human oversight、operations、cost 和 platform reuse。然后按 risk、uncertainty、evidence cost 排序，优先测试高风险高不确定的假设。

2 分钟版

例如信贷 memo copilot 的 solution 可能看起来很简单，但关键假设很多：申请材料能否正确抽取，政策引用是否准确，AI 是否会编造拒绝理由，underwriter 是否能有效复核，输出是否引入 fair lending 风险。每条假设都要写清为什么重要、当前证据、测试方法、通过信号、失败信号和决策影响。最高风险假设不一定用生产 pilot 测，可以先用历史 case replay、SME blind review、red-team cases 或 shadow run。这样做的好处是把“感觉可行”变成可学习、可停止的证据链。

Q5：prototype、eval 和 pilot 的区别是什么？

30 秒版

Prototype 测用户是否理解和愿意用，eval 测 AI 输出是否达到质量和风险门槛，pilot 测真实流程中是否创造可控业务价值。三者回答的问题不同，不能互相替代。

2 分钟版

比如客服 AI，clickable prototype 可以测试 agent 是否理解引用和升级提示；offline eval 可以用真实意图和政策冲突样本测试正确率、引用、投诉识别和 unsafe answer；pilot 才能看 first-contact resolution、AHT、QA defect、投诉、人工升级和成本。很多团队把 demo 当 eval，或把 pilot 当 discovery，这是危险的。成熟做法是先用 prototype 降低交互风险，再用 eval 降低质量和安全风险，再用受控 pilot 验证业务价值和运营可行性。

Q6：金融零售 AI discovery 最大的产品判断是什么？

30 秒版

最大判断是 AI 应该停在哪个 decision boundary。很多场景适合 read、summarize、draft、check、recommend with approval，但不适合直接 decide 或 act autonomously。

2 分钟版

在 AML，AI 可以整理证据和草拟 narrative，但 SAR 决策应由人负责。在信贷，AI 可以预填 memo、引用政策和提示缺失材料，但不能自动拒贷或编造 adverse action reason。在财富，AI 可以帮助顾问准备教育材料，但不能绕过适当性给个性化投资建议。在客服，AI 可以回答低风险问题，但投诉、欺诈、困难援助、费用争议要有升级和人工入口。这个边界决定了 solution pattern、UX、eval、审批、日志和上线门禁。

Q7：你如何把 NIST AI RMF 用在 discovery？

30 秒版

我不会把 NIST AI RMF 当合规清单，而是把 Govern / Map / Measure / Manage 转成 discovery 问题：谁负责、场景和影响是什么、如何测量风险、上线后如何管理。

2 分钟版

在 discovery 阶段，Govern 对应 owner、risk tier、decision rights 和 approval path；Map 对应用例背景、角色、数据、客户影响和受监管边界；Measure 对应 eval、rubric、critical failures、model/retrieval quality 和 monitoring；Manage 对应 mitigation、HITL、fallback、incident、rollback 和 continuous improvement。这样 NIST AI RMF 不只是上线前审查，而是贯穿 opportunity selection、assumption testing、pilot 和 scale decision。

Q8：什么时候把多个 AI use case 平台化？

30 秒版

当 2-3 个高价值 use case 证明有重复能力，例如 model gateway、prompt registry、eval harness、RAG ingestion、audit log 和 cost attribution，并且平台化能缩短 pilot 周期、提高控制一致性时，才值得平台化。

2 分钟版

过早平台化是 AI 转型常见失败。第一个 use case 还没有跑通，就建大平台，通常会抽象错误、交付慢、业务绕开。我的做法是从 use case discovery 中抽取重复模式：哪些团队都需要模型接入、日志、权限、eval、RAG、prompt versioning、工具审批和成本归因。如果多个高价值 pilot 重复建设这些能力，并且风险团队也需要统一 evidence，那么可以做 thin platform slice。平台的 outcome 不是功能多，而是 time-to-first-pilot、release gate coverage、reuse rate、audit completeness 和 cost visibility。

---

14. Portfolio Deliverables

一个有说服力的高级 AI discovery 作品集，不是 PRD 文件堆砌，而是一组能证明决策质量的 artifacts。

14.1 推荐作品集结构

01 Executive Summary
02 Use Case Context and Outcome
03 Workflow Evidence
04 Opportunity Solution Tree
05 Opportunity Scorecard
06 Solution Alternatives
07 Assumption Map
08 Prototype Findings
09 Eval Contract and Results
10 Pilot Protocol
11 Risk / Governance Evidence
12 Learning Decision and Roadmap
13 Platform Reuse Opportunities

14.2 高级表达句式

---

15. Final Decision Heuristics

15.1 When to Build

进入 build / pilot 的最低条件：

• Outcome 清楚且值得投入。
• Opportunity 来自真实 workflow evidence。
• 至少比较过 3 个 solution options。
• Riskiest assumptions 已有初步证据。
• Eval contract 能定义好坏和 critical failures。
• Risk tier、decision boundary、HITL、audit evidence 清楚。
• Pilot 有 scope、metrics、guardrails 和 stop rule。

15.2 When to Stop

出现以下信号，应停止或重写 opportunity：

• 业务 outcome 不清，只剩“用 AI”本身。
• 机会无法从真实用户故事、case audit 或数据中证明。
• 非 AI 方案明显更简单、更稳、更便宜。
• 关键数据源没有 owner、权限或质量基础。
• 高风险失败无法被 eval 或 human oversight 发现。
• 用户不愿在真实工作流中使用，或使用会转移负担。
• 单任务成本高于可解释价值，且没有规模化改善路径。

15.3 When to Platformize

满足以下条件时考虑平台化：

• 至少 2-3 个 use case 需要相同横向能力。
• 复用能力与风险控制强相关，如 eval、audit、model gateway、prompt registry。
• 平台化可以缩短 time-to-pilot，而不是增加审批摩擦。
• 有明确 owner、SLO、support model、cost attribution 和 adoption metric。
• 平台能力可以支持未来 use case，而不是只服务当前项目。

---

16. Quick Reference

AI discovery quality test:

Can you explain:
1. What outcome are we trying to move?
2. What workflow opportunity did evidence reveal?
3. Why is this an AI opportunity rather than process / rules / training?
4. What are at least three solution options?
5. Which assumptions are riskiest?
6. What prototype / eval / pilot will test them?
7. What failures are unacceptable?
8. What decision will we make with the evidence?
9. What risk controls and audit evidence are required?
10. Is this a point solution, platform candidate, or stop decision?

如果不能清楚回答以上问题，团队还没有完成 AI continuous discovery。