AI 扩展计划 / Playbooks

AI Platform PM Playbook

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

389 行AI_PLATFORM_PM_PLAYBOOK.md

AI Platform Product Operating Model Playbook

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

1. AI 平台产品化的核心问题

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

重复问题	单点项目做法	平台化做法
每个团队重复接模型	各自写调用代码	统一 model gateway
每个团队重复做 RAG	各自建向量库	统一 knowledge ingestion + retrieval service
每个团队不知道怎么评测	上线靠主观体验	统一 eval harness + release gate
成本不可控	账单后知后觉	quota、budget、cost dashboard
权限和审计不一致	各项目临时补	identity、policy、audit log 平台能力
Prompt 和配置不可追溯	复制粘贴	prompt/config registry
业务难 adoption	做完没人用	adoption analytics + enablement

AI 平台产品化的职责是把这些横向能力做成可复用、可治理、可度量的企业能力，让业务 AI use case 从一次性项目变成可重复交付能力。

2. 平台能力地图

Layer	Platform capability	Product operating question	Architecture design concern	Process / evidence fact
Use case intake	AI idea intake and prioritization	哪些 use case 值得进入 discovery？	intake workflow、scoring data model	业务目标、流程痛点、baseline
Model access	Model gateway	哪些模型能用、谁能用、用在哪类任务？	routing、fallback、quota、logging	使用场景、风险等级
Prompt/config	Prompt and policy registry	prompt 变更如何审批和回滚？	versioning、environment、approval	业务规则、合规话术
Knowledge	Knowledge ingestion and retrieval	哪些知识源可信、如何更新？	connectors、metadata、chunking、rerank	文档 owner、更新频率、权限
Tooling	Tool gateway	AI 能调用什么系统和动作？	tool catalog、RBAC、HITL、idempotency	流程动作、异常路径
Eval	Eval harness	怎样证明质量足够上线？	golden set、rubric、judge calibration	验收标准、错误成本
Safety	Policy and guardrails	哪些行为必须禁止或升级？	policy engine、content filters、risk rules	风险场景、审批规则
Observability	AI telemetry	线上如何知道系统坏了？	traces、metrics、feedback、incident logs	用户反馈、SLA、业务指标
Cost	Cost governance	谁为成本负责，成本如何归因？	token accounting、budget、cache	使用量预测、价值指标
Adoption	Enablement and analytics	用户是否真正改变工作方式？	usage analytics、training hub	角色、阻力、培训需求

3. 平台产品边界

3.1 平台应该做什么

应该平台化	原因
model gateway	统一模型接入、日志、成本、fallback、合规控制
RAG ingestion / retrieval	知识治理和权限过滤必须一致
eval harness	所有 AI 应用都需要可比较的上线门禁
prompt/config registry	变更可追溯，便于 rollback 和 audit
tool gateway	高风险行动必须统一鉴权、审计和人工审批
AI observability	线上质量、成本、延迟、失败模式要统一看
policy guardrails	企业统一安全和合规底线
adoption dashboard	平台价值不能只看 API 调用量

3.2 不应该过早平台化

不宜过早平台化	原因	更好的做法
所有业务流程编排	流程差异大，容易做成低价值大平台	先沉淀 2-3 个高频 workflow pattern
所有 domain ontology	需要领域验证，过早统一会误伤业务	先按 case 建 domain glossary
自研 foundation model	成本高，收益不确定，人才和数据要求高	先用 model gateway 管理多模型
全自动 agent marketplace	风险和治理复杂	先做受控 tool catalog 和 approval flow
统一 UI builder	使用场景未稳定	先提供 API、组件和 reference app

4. MVP 范围设计

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

MVP capability	最小版本	证明指标
Model gateway	统一调用 2-3 个模型，记录 request/response metadata	80% 新 AI POC 通过 gateway 接入
Prompt registry	prompt 版本、owner、环境、审批记录	prompt 变更可回滚
RAG starter kit	文档 ingestion、metadata filter、citation、basic eval	2 个业务知识助手复用
Eval harness	golden set、rubric、批量运行、release threshold	每次 release 有 eval report
Cost dashboard	按 use case、team、model 归因	月度成本可解释

第一版不做：

不做复杂 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 product and process analyst
- 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

Priority	Feature	User story	Acceptance criteria
P0	Model gateway	App teams need one API to access approved models	requests logged, model chosen, fallback recorded, cost attributed
P0	Prompt registry	As a release owner, prompt versions need review, approval and rollback	version diff, owner, approval, environment, rollback
P0	Eval runner	Release owners need to run eval before deployment	golden set upload, rubric, threshold, report
P0	Cost dashboard	Sponsors need cost visibility by use case	model, team, use case, token, cache, monthly trend
P1	RAG ingestion	Knowledge owners need documents indexed with metadata	source, owner, version, permission, freshness
P1	Retrieval eval	Architects need to measure retrieval quality	recall@k, freshness, citation accuracy
P1	Audit log	Risk reviewers need to inspect AI actions	input metadata, context sources, tool calls, human approval
P2	Tool catalog	App teams need approved tools with risk tiers	tool owner, read/write, risk, approval requirement
P2	Feedback loop	Operators need users to flag bad answers	feedback category, triage owner, fix loop

6.2 Developer experience backlog

Feature	Why it matters	Example
SDK templates	降低接入成本	`create-ai-use-case` starter
reference apps	让团队知道怎么做	policy assistant、case summarizer
local eval runner	开发阶段就能测	sample golden set
tracing viewer	debug RAG/agent failures	prompt、retrieval、tool、output trace
cookbook	复用模式	RAG, summarization, extraction, triage

6.3 Governance backlog

Feature	Governance value
use case risk tiering	决定审批、eval、HITL 强度
model allowlist	控制模型来源和数据边界
policy guardrail library	复用合规规则
release approval workflow	让上线责任可追踪
incident workflow	线上问题可分类、分派、关闭

7. 平台指标体系

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

Dimension	Metric	Bad interpretation	Better interpretation
Adoption	active use cases	use case 多就是成功	看 use case 是否进入真实流程
Adoption	weekly active users	用户打开过就是成功	看目标角色是否重复使用
Quality	eval pass rate	分数高就能上线	看 critical failure 是否为 0
Quality	human override rate	override 高说明 AI 差	结合任务风险和 reviewer reason
Value	time saved per case	直接换算裁员	转成 capacity、SLA、rework reduction
Risk	incidents / near misses	低就是安全	检查检测覆盖是否足够
Cost	cost per task	越低越好	要结合成功率和业务价值
Platform	time-to-first-pilot	快就是好	不能牺牲 eval 和 control

8. 多租户和权限设计

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

Area	设计要求
Tenant	team / business unit / use case 可以作为 tenant 维度
Identity	用户、服务账号、agent identity 要区分
Knowledge permission	retrieval 前做权限过滤，不能靠生成后过滤
Tool permission	tool call 必须按 user + agent + use case 授权
Cost attribution	request 必须带 use_case_id / team_id / environment
Audit	trace 要能追到模型、prompt、context、tool、approval
Data boundary	dev/test/prod 数据和 prompt config 分环境

9. Model gateway 设计要点

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

Capability	Why
model routing	根据任务、成本、延迟、风险选择模型
fallback	主模型失败时降级
quota	防止成本失控
redaction	调用前处理敏感字段
logging	支持 debug、audit、eval replay
policy enforcement	阻止未授权模型和高风险调用
latency/cost metric	支持 SLO 和预算

一个简化 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 然后聊天”。它至少要管理：

Component	Platform responsibility
source registry	文档来源、owner、更新频率、有效期
ingestion	parsing、chunking、metadata、version
permission	ABAC/RBAC before retrieval
retrieval	hybrid search、rerank、filter
citation	answer 必须能回溯 source
freshness	过期知识不能默认使用
eval	retrieval recall、citation accuracy、no-answer behavior
feedback	用户标错能回到文档和索引修复

11. Eval platform 设计要点

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

Eval capability	Platform provides	Business team provides
golden set format	schema、runner、report	题目、正确答案、来源
rubric	scoring dimensions	domain thresholds
judge calibration	sample comparison、human review flow	SME labels
regression testing	batch run、diff、history	release decision
production monitoring	trace sampling、feedback dashboard	triage owner

上线门禁示例：

Gate	Threshold
critical hallucination	0
permission leakage	0
citation accuracy	>= 95% for policy answers
no-answer correctness	>= 90%
high-risk HITL bypass	0
latency p95	within use case SLO
monthly cost forecast	within approved budget

12. AI 平台组织模型

Role	Responsibility
Platform product lead	platform roadmap、user research、adoption、business case
Platform Architect	reference architecture、gateway、RAG、tooling、security
EvalOps Lead	eval standards、golden set process、release gates
AI Risk / Compliance	policy, approval, incident classification
Data / Knowledge Owner	source quality、metadata、access、freshness
Developer Experience Lead	SDK、templates、docs、support
Business Product Owner	use case goals、workflow adoption、ROI
Operations Owner	monitoring、incident、change management

13. 平台 rollout 路线

Phase	Goal	Exit criteria
Phase 0 Discovery	找到 2-3 个真实 use case	有 baseline、owner、data、risk tier
Phase 1 MVP	打通 gateway + prompt registry + eval runner	2 个 pilot 使用平台能力
Phase 2 Shared RAG	知识 ingestion/retrieval 可复用	2 个知识助手复用同一 RAG pipeline
Phase 3 Governance	release gate 和 audit 成为默认流程	所有 pilot 有 eval report 和 risk signoff
Phase 4 Scale	开发者体验和成本治理完善	新 use case onboarding 时间下降
Phase 5 Optimization	形成平台运营节奏	有 roadmap、SLO、cost review、incident review

14. 与 ABPA 模板的连接

Platform activity	ABPA artifact
use case intake	`templates/01-ai-opportunity-canvas.md`
stakeholder alignment	`templates/02-stakeholder-evidence-map.md`
workflow analysis	`templates/03-bpmn-pain-metrics.md`
eval definition	`templates/04-requirements-to-eval-matrix.md`
risk control	`templates/05-ai-control-pack.md`
executive approval	`templates/06-executive-decision-memo.md`
data readiness	`templates/07-data-readiness-pack.md`
architecture decision	`templates/08-ai-architecture-adr-set.md`
operating ownership	`templates/09-operating-model-raci.md`
adoption tracking	`templates/10-adoption-dashboard.md`
investment logic	`templates/11-business-case.md`
evidence synthesis	`templates/12-portfolio-evidence-map.md`

15. Platform Operating Model Narrative

AI 平台的核心不是模型调用后台，而是企业共享控制面：模型接入、RAG、prompt 管理、tool gateway、eval、成本、权限、审计和 adoption。平台价值来自让业务团队不用重复从零开始，同时按统一标准把 AI use case 从 discovery 推到 pilot、release 和 scale。

系统叙事顺序：

flagship use cases
-> repeated control points
-> platform capability boundary
-> paved road and exception path
-> eval and release evidence
-> adoption and cost telemetry
-> operating review cadence

平台 MVP 应从真实 use case 出发。AML、客服知识助手、支付争议等场景会反复需要模型接入、知识检索、权限过滤、eval、日志、成本归因和人工审批。第一阶段优先提供 model gateway、prompt registry、RAG starter kit、eval harness、cost dashboard 和 audit log；复杂 agent 编排、全知识图谱和无代码 UI builder 应等到重复模式被验证后再进入路线图。

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

Architecture challenge	Operating answer
各业务团队是否可以自己接模型	探索期可以分散；进入 pilot/release 后必须通过 gateway，统一模型选择、日志、成本、权限、数据边界和 incident response。
平台是否会变成瓶颈	平台应提供 paved road、自助 SDK、模板、reference app 和清晰 SLA；低风险 use case 自助接入，高风险 use case 进入强化 gate。
如何证明平台价值	用交付效率、质量风险和业务 adoption 三类指标证明：onboarding 时间下降、eval 覆盖率提升、成本可归因、incident 降低、目标用户持续使用、业务流程指标改善。

16. 练习任务

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

Step	Output
1	标出该 case 需要哪些平台能力
2	把能力分成 P0/P1/P2
3	写 model gateway routing rule
4	写 RAG source registry 样例
5	写 eval release gate
6	写 cost attribution rule
7	写 adoption dashboard 指标
8	写一页 platform MVP funding memo

17. 掌握标准

能够把 AI 平台讲清楚，意味着能够稳定解释以下判断：

Capability judgment	Mastery signal
Platform starting point	AI 平台不能从“统一大平台”开始，而要从重复 use case 和控制点沉淀。
Boundary choice	能区分必须平台化的 gateway、eval、observability、policy 和应留给业务的 workflow 细节。
Gateway depth	能说明 model gateway 与普通 API proxy 在 routing、fallback、cost、policy、trace 和 release control 上的差异。
RAG governance	能解释 metadata、permission、freshness、source owner 和 citation validation 为什么是 RAG 平台核心。
Eval credibility	能把 eval harness 连接到 golden set、critical failure、release gate、drift monitoring 和 incident review。
Cost ownership	能按 team、use case、model、token、cache、environment 和 successful task 做成本归因。
Adoption evidence	能区分 curiosity usage、habit usage、workflow completion、quality improvement 和 business outcome。
Platform roadmap	能用 flagship cases、capability reuse、risk tier 和 operating review cadence 决定下一批平台能力。

高风险 tool call 应该如何审批和审计？
平台指标为什么不能只看调用量？
怎么用 2-3 个 flagship use cases 驱动平台 roadmap？
什么时候应该停止一个平台 feature？

18. Stop Rules

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

Signal	Decision
连续两个季度没有业务 use case 复用	停止新增平台能力，回到 use case discovery
平台接入时间比业务自建还长	简化 onboarding 和 SDK
eval reports 不影响 release 决策	重设 gate 和责任人
成本 dashboard 无法归因到 use case	暂停 scale，修复 tagging 和 accounting
高风险项目绕开平台上线	升级 governance 和 architecture review
开发者只复制 reference app 不理解风险	增加 enablement 和 review

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