AI 底层逻辑 / 经典论文
Wardley Mapping：AI 产品与平台战略
一句话:
268 行ai-foundations/papers/68-wardley-mapping-ai-product-platform-strategy.md
Wardley Mapping / AI Product & Platform Strategy 解读
面向对象: AI PM / Platform PM / Product Architect / Enterprise Architect / Strategy Lead / Senior BA。 核心问题: AI 战略经常被讲成“我们要拥抱 AI”“建设企业 AI 平台”“引入智能助手”。这些表述缺少地形感: 用户真正需要什么? 价值链有哪些组件? 哪些是未成熟探索, 哪些已经商品化? 哪些该自研, 哪些该购买, 哪些该平台化? 学习目标: 用 Wardley Mapping 的用户需求、价值链和演化轴, 把 AI 产品战略从口号转成可讨论的战略地图、平台边界和 build-buy-partner 决策。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| Wardley Maps Book / Simon Wardley | https://learnwardleymapping.com/book/ | 参考 Wardley Mapping 的 user need、value chain、evolution、doctrine 和 strategic play |
| Simon Wardley Mapping Material | https://medium.com/wardleymaps | 参考 Wardley Maps 的战略地图和演化思维 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把 AI 战略地图连接到风险、度量、治理和持续管理 |
| Team Topologies | https://teamtopologies.com/ | 把平台边界和团队交互模式纳入战略执行 |
一句话:
Wardley Mapping for AI 是把用户需求、AI 价值链组件和组件成熟度画在同一张地图上, 用来判断哪些能力要探索、产品化、平台化、采购或外包。
1. 为什么 AI PM 需要地图
没有地图的 AI 战略容易变成:
- 供应商 roadmap 变成企业 roadmap。
- 各部门都建自己的 RAG。
- AI 平台团队做了一堆没人采用的通用能力。
- PM 只比较模型价格, 不比较价值链位置。
- 架构师只讨论技术栈, 不讨论战略演化。
Wardley Mapping 强迫团队回答:
- 用户是谁, 真实 need 是什么？
- 满足这个 need 的价值链组件有哪些？
- 每个组件处在 genesis、custom-built、product/rental、commodity 哪个阶段？
- 哪些组件决定差异化？
- 哪些组件应该标准化或外部采购？
- 哪些位置适合平台化？
- 演化趋势会如何改变架构投资？
2. AI Value Chain
以企业客服 Copilot 为例:
User Need:
客服在复杂政策和客户情绪下, 更快给出合规、准确、可升级的答复。
Value Chain:
Customer context
-> Intent detection
-> Policy retrieval
-> Response generation
-> Citation / evidence
-> Human edit / approval
-> CRM update
-> Feedback / monitoring
-> Knowledge update
将组件放到演化轴:
| 组件 | 演化状态 | 战略含义 |
|---|---|---|
| Foundation model API | Product / Utility | 通常不应作为核心差异化自研 |
| Model gateway | Productizing | 适合企业平台化, 控制供应商、成本和策略 |
| Domain policy corpus | Custom / Productizing | 高差异化, 需要内部治理 |
| Intent taxonomy | Custom | 与业务流程和客户场景强绑定 |
| RAG infrastructure | Productizing | 可平台化, 但知识治理需业务拥有 |
| Human review workflow | Custom | 与风险、组织和 SLA 强相关 |
| Eval set | Custom | 关键差异化资产 |
| Observability | Productizing | 平台能力, 与业务指标连接 |
3. Evolution Axis
Wardley Mapping 的核心不是画流程, 而是看组件演化:
Genesis -> Custom Built -> Product / Rental -> Commodity / Utility
AI 组件例子:
| Genesis | Custom Built | Product / Rental | Commodity / Utility |
|---|---|---|---|
| 新型 agent 协议 | 业务专属 workflow agent | SaaS Copilot | 通用模型 API |
| 新监管解释能力 | AML typology eval set | RAG platform | 向量库基础能力 |
| 新人机协作模式 | 信贷 adverse action assistant | AI gateway | GPU capacity |
架构决策要匹配演化位置:
- Genesis: 小规模探索, 不要过度治理和平台化。
- Custom: 强业务差异化, 需要领域专家和快速迭代。
- Product: 建立标准接口、复用模式和 vendor strategy。
- Commodity: 追求成本、稳定、替换性和治理。
4. Build / Buy / Partner
| 决策 | 适合场景 | AI 例子 |
|---|---|---|
| Build | 高差异化、高风险、强业务耦合 | AML eval set、信贷 policy reasoning、客户投诉升级逻辑 |
| Buy | 商品化、非差异化、供应商成熟 | 基础模型 API、OCR、通用 transcription |
| Partner | 需要外部专业能力但内部要控制边界 | 模型供应商、审计工具、specialized risk data |
| Platformize | 多 use case 重复使用 | model gateway、RAG ingestion、EvalOps、tool gateway |
| Retire | 地图显示已无差异化或成本过高 | 部门自建重复 RAG、孤立 prompt 工具 |
关键判断:
自研不等于差异化。
购买不等于没有架构责任。
平台化不等于所有场景统一。
5. Platform vs Product Boundary
AI 平台应该提供“通用、可复用、可治理”的能力:
- 模型访问。
- 成本与配额。
- 权限与审计。
- RAG pipeline。
- EvalOps。
- tool gateway。
- observability。
- release evidence。
业务产品团队应该拥有:
- 用户需求。
- 业务流程。
- domain taxonomy。
- knowledge source authority。
- golden set。
- HITL 规则。
- success metrics。
- residual risk。
如果平台团队拥有太多业务语义, 平台会变慢; 如果业务团队自建太多基础设施, 企业会失控。
6. 金融零售地图样例
6.1 AML Copilot
用户需求:
Analyst 需要更快理解 alert、证据、typology 和下一步调查路径, 同时不降低 SAR 风险识别质量。
价值链:
Alert context -> entity resolution -> transaction graph -> typology retrieval
-> evidence summary -> risk rationale -> human review -> case disposition
-> QA sampling -> feedback to rules/model
战略判断:
- transaction graph 和 typology eval set 高度差异化, 应内部主导。
- 通用 LLM 可购买。
- entity resolution 可能 build + vendor 混合。
- evidence traceability 应平台化为 risk investigation capability。
6.2 AI Gateway / EvalOps
用户需求:
多个 AI 产品团队需要安全、可控、可审计地使用不同模型和评测门禁。
战略判断:
- model gateway 是平台能力。
- eval datasets 是业务域资产。
- judge infrastructure 可平台化。
- release decision 不能完全平台自动化, 必须有风险 owner。
7. 模板: AI Wardley Map Brief
# AI Wardley Map Brief: [Use Case / Platform Capability]
## 1. User Need
- Primary user:
- Real need:
- Business outcome:
- Risk boundary:
## 2. Value Chain
| Component | Depends on | Owner | Evidence |
|---|---|---|---|
## 3. Evolution Position
| Component | Genesis | Custom | Product | Commodity | Rationale |
|---|---|---|---|---|---|
## 4. Strategic Decision
| Component | Build / Buy / Partner / Platformize / Retire | Reason |
|---|---|---|
## 5. Architecture Implication
- Platform services:
- Product-owned domain assets:
- Vendor dependencies:
- Risk controls:
- Roadmap moves:
8. 反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Model-first strategy | 先定模型, 后找价值链 | 从 user need 和 value chain 开始 |
| Platform maximalism | 所有能力都想平台统一 | 区分 commodity、product 和 custom |
| Vendor theater | 供应商功能表替代战略地图 | 标出组件位置和替换成本 |
| Commodity custom-build | 自研无差异化基础能力 | 购买或使用开源, 重点治理 |
| Strategic blindness | 不看组件演化趋势 | 定期重画地图, 更新 build-buy 决策 |
9. 面试回答
Q: 你如何决定 AI 能力是自研、采购还是平台化？
30 秒版本:
我会用 Wardley Mapping 先从用户需求和价值链出发, 再判断每个组件的演化阶段和差异化程度。商品化组件倾向购买或标准化, 高业务差异化和高风险组件倾向内部主导, 多场景重复能力适合平台化。这样 build-buy 不是偏好, 而是地形判断。
Q: AI 平台团队和业务产品团队边界怎么划？
30 秒版本:
平台团队拥有通用、可复用、可治理能力, 例如 model gateway、EvalOps、tool gateway、observability; 业务团队拥有 domain semantics, 例如用户需求、流程、知识源、golden set、HITL 和风险接受。边界错了, 要么平台变慢, 要么业务重复造轮子。
10. 作品集交付物
- AI Wardley Map。
- AI Value Chain Component Inventory。
- Evolution Position Table。
- Build / Buy / Partner Decision Matrix。
- Platform vs Product Boundary Memo。
- Vendor Dependency Risk Map。
- Roadmap Move Narrative。
这套材料能证明你具备 AI Product Strategist / Platform PM / Product Architect 的能力: 不是追功能, 而是能读懂 AI 产品和平台的战略地形。