Wardley Mapping：AI 产品与平台战略
Wardley Mapping 用在企业 AI 中, 不是为了画一张战略海报, 而是为了让“自研、采购、平台化、合作、退出”这些决策有地形依据。AI 价值链中的组件成熟度差异极大: 基础模型 API 可能已经接近 utility, 但领域知识、eval set、人工复核流程、风险证据和客户信任机制仍高度定制。
Wardley Mapping / AI Product & Platform Strategy 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_WARDLEY_MAPPING_PRODUCT_STRATEGY_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
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 用在企业 AI 中, 不是为了画一张战略海报, 而是为了让“自研、采购、平台化、合作、退出”这些决策有地形依据。AI 价值链中的组件成熟度差异极大: 基础模型 API 可能已经接近 utility, 但领域知识、eval set、人工复核流程、风险证据和客户信任机制仍高度定制。
这篇的重点是把 AI 战略从“我们要建设 AI 平台”转成可讨论的地图: 用户需求是什么, 价值链由哪些组件构成, 每个组件处在什么演化阶段, 哪些能力决定差异化, 哪些能力应该商品化采购, 哪些能力必须成为共享平台。
问题定义
没有地图的 AI 战略通常会出现几类偏差:
- 供应商功能表替代企业战略。
- 各业务线重复建设 RAG、prompt、eval 和工具连接。
- 平台团队提供一堆通用能力, 但业务团队仍然绕开平台。
- 架构讨论聚焦模型和框架, 忽略价值链中真正稀缺的领域资产。
- 采购被误认为风险转移, 自研被误认为差异化。
Wardley Mapping 迫使团队回答更硬的问题:
谁有未满足的用户需求?
满足这个需求需要哪些组件?
这些组件哪些是成熟商品, 哪些仍在探索?
哪些组件会塑造竞争优势或风险边界?
哪些组件重复出现, 值得平台化?
哪些组件未来会商品化, 不值得继续重投入?
AI 战略的困难不在于“是否使用 AI”, 而在于把有限的组织能力投资到正确的价值链位置。
核心原理/方法
Wardley Map 有两个核心轴:
- 纵向: 用户可见性和价值链依赖。
- 横向: 组件演化阶段, 从 genesis 到 custom-built、product/rental、commodity/utility。
以客服 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 | 高差异化, 需要内部治理和 source authority |
| Intent taxonomy | Custom | 与业务流程、投诉类型和监管边界强绑定 |
| RAG infrastructure | Productizing | 可平台化, 但知识责任不能平台单独承担 |
| Human review workflow | Custom | 与风险、运营容量、SLA 和责任链强相关 |
| Eval set | Custom | 高价值资产, 决定质量门槛和学习速度 |
| Observability | Productizing | 平台能力, 但必须连接业务和风险指标 |
系统/架构模型
AI Wardley Map 应转化为架构分层和 ownership:
User need / business outcome
-> Product workflow and experience
-> Domain assets
-> ontology / taxonomy / policy corpus / eval set
-> Shared platform capabilities
-> model gateway / RAG pipeline / tool gateway / EvalOps / observability
-> Commodity services
-> model API / OCR / transcription / storage / compute
-> Governance capabilities
-> risk tiering / evidence / policy engine / vendor risk
地图不是替代架构, 而是指导架构边界:
| 地图判断 | 架构含义 |
|---|---|
| 低差异、成熟、供应充足 | 采购或使用托管服务, 通过 gateway 控制替换性 |
| 高差异、强领域语义 | 内部主导, 与业务流程和风险控制绑定 |
| 多场景重复出现 | 平台化, 提供 golden path、SLO 和治理接口 |
| 高风险但供应商能力强 | partner, 保留策略、证据和审批控制 |
| 正在快速商品化 | 避免重资产自研, 保持可替换接口 |
成熟企业 AI 架构不是“全自研”或“全买”, 而是在地图上明确每个组件的位置和演化预期。
关键机制与取舍
| 决策 | 适用条件 | AI 例子 | 主要取舍 |
|---|---|---|---|
| Build | 高差异化、高风险、强业务耦合 | AML typology eval set、信贷政策推理、投诉升级规则 | 慢但可控, 需要长期 owner |
| Buy | 成熟、低差异、供应商替换性强 | 基础模型 API、OCR、transcription | 快但需治理供应商、数据和成本 |
| Partner | 外部专业强, 内部仍需控制边界 | 专业风险数据、模型验证工具 | 借力外部, 但责任不能外包 |
| Platformize | 多业务线重复使用且治理要求一致 | model gateway、EvalOps、tool gateway、observability | 降低重复建设, 但要避免平台僵化 |
| Retire | 重复、低价值、成本高或已商品化 | 部门自建 prompt 工具、孤立 RAG | 释放复杂度, 但需要迁移路径 |
几个关键判断:
- 自研不等于差异化。没有独特数据、流程、eval 或控制权的自研只是成本。
- 采购不等于没有架构责任。模型、数据、日志、异常处理和退出策略仍由企业承担。
- 平台化不等于统一所有场景。平台应统一高复用能力和控制面, 业务语义必须允许配置。
- 价值链会演化。今天的定制能力明天可能商品化, 今天的供应商能力明天可能成为锁定风险。
证据与控制
AI 战略地图应形成可审查的决策证据:
| 证据 | 用途 |
|---|---|
| User need statement | 防止从模型或供应商功能出发 |
| Value chain component inventory | 明确实现价值所需组件 |
| Evolution position rationale | 说明组件成熟度和变化趋势 |
| Build / buy / partner / platformize decision log | 固化战略选择和反转条件 |
| Platform boundary map | 定义平台与业务团队各自拥有的资产 |
| Vendor dependency risk map | 记录替换成本、数据外发、合规和成本风险 |
| Roadmap movement review | 定期重画地图, 更新投资方向 |
控制重点不是让地图一次正确, 而是让战略决策可被复盘。当模型价格、监管边界、供应商能力或内部复用率变化时, 地图必须更新。
AI产品/金融零售场景
AML copilot
用户需求是 analyst 更快理解 alert、证据、typology 和下一步调查路径, 同时不降低高风险识别质量。地图判断通常是: 通用模型可购买, transaction graph、typology ontology、evidence eval set 和 SAR 质量标准应内部主导; RAG、trace、eval harness 和模型路由可平台化; entity resolution 可能需要 build 与 vendor 混合。
AI gateway / EvalOps
多个 AI 产品团队都需要安全、可控、可审计地使用不同模型和评测门禁。地图上 model gateway、eval infrastructure、observability 和 evidence capture 是重复且治理要求高的能力, 适合平台化; 但 eval datasets、业务阈值、风险接受和 release decision 仍应由业务域和风险 owner 共同拥有。
财富顾问助手
基础问答、文档摘要和会议准备可以依托共享平台; 投资建议边界、适当性规则、批准话术和顾问监督流程是高风险定制资产。地图能阻止团队把供应商“财富 AI 功能”直接等同于可上线能力。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Model-first strategy | 先选模型, 再找业务场景 | 从 user need 和 value chain 开始 |
| Platform maximalism | 所有能力都要统一平台化 | 按演化阶段和复用频率定边界 |
| Vendor theater | 供应商 demo 替代战略判断 | 标出组件位置、替换成本和责任归属 |
| Commodity custom-build | 自研无差异基础能力 | 采购或托管, 把精力转向领域资产 |
| Domain asset neglect | 忽视 ontology、eval、workflow 和 evidence | 把领域资产列为核心差异化组件 |
| Static map | 一张地图多年不变 | 用季度或重大事件触发重绘 |
最终心智模型
Wardley Mapping for AI 的最终心智模型是:
用户需求决定价值链;
价值链暴露组件;
组件演化阶段决定战略动作;
战略动作决定架构边界和组织责任;
演化变化触发重新投资、迁移或退出。
对 AI 产品和平台战略而言, 地图的价值不是给出一个漂亮答案, 而是让团队能围绕地形做更清晰的取舍: 哪些地方应该快试错, 哪些地方必须深耕, 哪些地方应该标准化, 哪些地方应保持可替换, 哪些地方必须停止重复建设。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。