AI Platform PM Playbook

目的：训练面向企业内部 AI 平台的产品经理能力，把模型、RAG、Agent、EvalOps、治理、成本、权限、开发者体验和业务 adoption 组织成可复用平台。 适用对象：AI PM、Platform PM、AI Solutions Architect、AI BA、企业 AI 转型负责人。 原则：AI 平台不是“接一个模型 API”，而是让多个业务团队能安全、低成本、可评估、可审计地构建 AI 工作流。

1. AI Platform PM 的核心问题

AI 应用可以一个一个做，但企业真正规模化时，会遇到重复问题：

AI Platform PM 的职责是把这些横向能力产品化，让业务 AI use case 从一次性项目变成可重复交付能力。

2. 平台能力地图

3. 平台产品边界

3.1 平台应该做什么

3.2 不应该过早平台化

4. MVP 范围设计

一个务实的 AI 平台 MVP 不追求“大而全”，而是解决最阻碍复用的 5 件事：

第一版不做：

• 不做复杂 agent 自动编排平台。
• 不做企业级全知识图谱。
• 不做自研大模型训练平台。
• 不做所有业务统一 UI。
• 不承诺所有 use case 都能无代码完成。

5. AI 平台 PRD 骨架

# AI Platform MVP PRD

## 1. Problem
- 当前 AI POC 分散，模型接入、RAG、eval、日志、成本、权限重复建设。
- 风险：上线门禁不一致，成本不可控，prompt 变更不可追溯，业务难复用。

## 2. Target Users
- AI app developer
- AI PM / BA
- Data / knowledge owner
- Risk / compliance reviewer
- Platform operator

## 3. Goals
- 让新 AI use case 从 discovery 到 pilot 的重复工作减少。
- 让上线前 eval 和上线后 monitoring 成为默认流程。
- 让模型调用、知识检索、工具调用、成本和审计统一可见。

## 4. Non-goals
- 不替代业务系统。
- 不承诺无代码构建所有 AI 应用。
- 不直接做高风险自动决策。

## 5. MVP Capabilities
- model gateway
- prompt registry
- RAG starter kit
- eval harness
- cost dashboard
- audit log

## 6. Success Metrics
- time-to-first-pilot
- % AI apps using gateway
- % releases with eval report
- cost per successful task
- incident count
- adoption by target teams

## 7. Risks
- 平台过度抽象导致业务不用。
- 只看调用量不看价值。
- eval 变成形式主义。
- 权限和知识治理没有 owner。

## 8. Release Gate
- 至少 2 个业务 use case 完成 pilot。
- 每个 pilot 有 eval report、business metric、risk signoff。
- 成本归因可解释。
- 关键 prompt/config 可回滚。

6. 平台 backlog

6.1 Foundation backlog

6.2 Developer experience backlog

6.3 Governance backlog

7. 平台指标体系

不要只看 API 调用量。AI 平台指标要同时覆盖 adoption、quality、business value、risk、cost。

8. 多租户和权限设计

企业 AI 平台常见失败点是“所有团队共用一套东西，但权限、知识、成本、责任没分清”。

9. Model gateway 设计要点

Model gateway 不只是代理 API。它是企业 AI 的控制面。

一个简化 routing 规则：

If task_risk = high:
  use approved_model_tier_1
  require eval_profile = high_risk
  require human_review = true

If task_type = extraction and latency_slo < 2s:
  use small_fast_model

If task_type = complex_reasoning:
  use reasoning_model
  require cost_budget_check

If data_classification = restricted:
  use private_endpoint_only

10. RAG 平台设计要点

RAG starter kit 不是“上传 PDF 然后聊天”。它至少要管理：

11. Eval platform 设计要点

平台层 eval 不是替业务写所有测试，而是提供标准能力：

上线门禁示例：

12. AI 平台组织模型

13. 平台 rollout 路线

14. 与 ABPA 模板的连接

15. 面试表达

30 秒版本

AI 平台 PM 的核心不是做一个模型调用后台，而是把模型接入、RAG、prompt 管理、tool gateway、eval、成本、权限、审计和 adoption 变成企业共享能力。这样每个业务团队不用重复从零开始，也能按统一标准把 AI use case 从 discovery 推到 pilot、release 和 scale。

2 分钟版本

我会先从真实 use case 出发，而不是先建大平台。比如 AML、客服知识助手、支付争议这类场景会反复需要模型接入、知识检索、权限过滤、eval、日志、成本归因和人工审批。平台 MVP 应该先提供 model gateway、prompt registry、RAG starter kit、eval harness、cost dashboard 和 audit log。

成功指标不能只看 API 调用量，而要看 time-to-first-pilot、release with eval report、cost per successful task、adoption by target roles、critical incident count 和业务指标变化。平台的产品挑战是控制抽象层级：太薄没有复用价值，太厚业务团队不用。所以我会用 2-3 个 flagship cases 驱动平台能力沉淀。

CTO 追问回答

Q: 为什么不让各业务团队自己接模型？

A: 初期可以允许探索，但进入 pilot/release 后需要统一 gateway，否则模型选择、日志、成本、权限、数据边界和 incident response 都会分散。平台不是限制创新，而是把重复控制面统一。

Q: 平台会不会变成瓶颈？

A: 会，所以平台要提供 paved road，而不是所有东西都审批。低风险 use case 可以自助接入，高风险 use case 才走强化 gate。平台团队应提供 SDK、模板、reference app 和清晰 SLA。

Q: 你怎么证明平台有价值？

A: 看三类指标：交付效率、质量风险、业务 adoption。比如新 use case onboarding 时间下降、release eval 覆盖率提升、成本可归因、incident 降低、目标用户持续使用、业务流程指标改善。

16. 练习任务

选择一个已有 case，例如 AML Copilot 或 KYC Policy Assistant，完成以下平台化练习：

17. 判断自己是否掌握

你能回答下面问题，才算真的理解 AI Platform PM：

1. 为什么 AI 平台不能从“统一大平台”开始？
2. 哪些能力必须平台化，哪些应该留给业务团队？
3. model gateway 和普通 API proxy 的区别是什么？
4. RAG 平台为什么必须管 metadata、permission、freshness？
5. eval harness 如何避免变成形式主义？
6. 成本归因应该按哪些维度做？
7. 高风险 tool call 应该如何审批和审计？
8. 平台指标为什么不能只看调用量？
9. 怎么用 2-3 个 flagship use cases 驱动平台 roadmap？
10. 什么时候应该停止一个平台 feature？

18. Stop Rules

平台建设也需要停止规则：

AI 平台的成熟，不在于功能列表多，而在于它让业务 AI 能更快、更稳、更可控地进入真实流程。