《互联网产品的 AI 架构·平台化与治理》目录与学习路径

这一卷在四卷中的位置

《互联网产品的 AI 架构》四卷：

前三卷分别解决一个能力、一条链路、一条多能力链路；卷四解决它们共存时的所有权、版本、配额、评测与合规。它不引入新的模型技术，而是把前三卷的产物变成可运营的制度。

全书结构

13 章 39 节，按“对象 → 目录 → 版本 → 配额 → 评测 → 运营 → 收口”组织：

逐章篇目

第 1 章 治理问题与边界

一条链路变成很多条链路之后，问题不再是“怎么跑通”，而是“谁负责、按什么版本跑、配额给谁”。本章定义治理的四个对象与平台/业务的职责边界。

• 1.1 从一条链路到很多条链路：回声的规模化现场
• 1.2 治理的四个对象：能力、调用方、租户、版本
• 1.3 平台与业务的职责边界

第 2 章 能力目录与所有权

能力目录是治理的第一份事实。条目字段、提供方与调用方的契约，以及能力退役的完整流程，决定了多团队复用能不能长期成立。

• 2.1 一条能力条目的最小字段
• 2.2 提供方与调用方的契约
• 2.3 能力退役与迁移

第 3 章 版本与兼容治理

版本是治理最容易失控的地方。契约兼容规则、模型与提示版本的联动、版本矩阵与弃用窗口，三者必须一起设计，否则每次升级都是一次全员排查。

• 3.1 契约版本与兼容规则
• 3.2 模型与提示版本的联动
• 3.3 版本矩阵与弃用窗口

第 4 章 多租户与配额

多租户下，预算不再是单条链路的上限。三层配额、公平性与优先级、借用与回收，决定资源紧张时平台先保谁。

• 4.1 三层配额：总额、份额、单次
• 4.2 公平性与优先级
• 4.3 借用、回收与隔离

第 5 章 评测平台

评测平台是质量治理的基础设施。评测集的版本与污染、自动化回归门禁、人工评审与仲裁，构成一条可审计的验收链。

• 5.1 评测集的治理：版本、来源与污染
• 5.2 自动化回归与门禁
• 5.3 人工评审与仲裁

第 6 章 质量运营

线上质量不是一条曲线。质量信号与抽检、事故分级与响应、季度复盘，把“感觉变差了”变成可追踪的治理动作。

• 6.1 线上质量信号与抽检
• 6.2 质量事故的分级与响应
• 6.3 质量报告与季度复盘

第 7 章 成本治理的组织视角

成本治理在组织层的核心是分摊与优先级。预算、账单与归因如何分工，内部计价怎么避免扯皮，优化组合如何排序。

• 7.1 预算、账单与归因的分工
• 7.2 成本分摊与内部计价
• 7.3 优化优先级与投资回报

第 8 章 合规与数据治理

合规不是上线前的一次检查。数据分级与出域、留存删除与审计、供应商合规与模型变更通知，都是持续义务。

• 8.1 数据分级与出域
• 8.2 留存、删除与审计
• 8.3 供应商合规与模型变更通知

第 9 章 安全治理

安全治理面对的是持续演化的对手。风险登记、红队与滥用检测、事故响应与披露，要形成可重复的流程而不是一次性项目。

• 9.1 提示与工具的风险登记
• 9.2 红队与滥用检测
• 9.3 事故响应与披露

第 10 章 平台工程

平台自身也是产品。自助服务边界、SDK 与配置分发、平台 SLO 与容量，决定治理能不能被规模化使用。

• 10.1 平台的自助服务边界
• 10.2 SDK、CLI 与配置分发
• 10.3 平台自身的 SLO 与容量

第 11 章 组织与流程

治理最终落在人与流程上。能力归谁所有、评审委员会如何决策、文档与培训如何传递，决定了平台能否被正确使用。

• 11.1 谁拥有 AI 能力：平台团队与业务团队
• 11.2 评审委员会与决策记录
• 11.3 培训、文档与知识传递

第 12 章 长期演进

模型会换代，技术债会累积。迁移计划、退出条件与治理度量，回答“这套治理是否还在起作用”。

• 12.1 模型换代与迁移计划
• 12.2 技术债与退出条件
• 12.3 治理的度量：不是流程数量

第 13 章 卷四收口与全书回顾

把前十二章合成一条可执行基线：回声的平台化清单、一次跨团队治理评审，再回顾全书并给出继续阅读的方向。

• 13.1 治理基线：回声的平台化清单
• 13.2 一次跨团队治理评审
• 13.3 全书回顾与继续阅读

三条阅读路径

• 第一次做平台化：
• 正在接管多租户：
• 准备治理评审：

第一条用于从零搭建治理骨架，第二条用于接管多租户与配额，第三条用于准备一次治理评审。

读完卷四应能回答的十五个问题

1. 这条链路归谁所有？变更是谁批准的？
2. 能力目录里的每条能力，最少的必填字段是哪些？
3. 调用方可以覆盖哪些参数？覆盖后的质量与成本由谁承担？
4. 契约的哪些变更算破坏性变更？版本如何弃用？
5. 模型换代时，提示与评测集如何一起升级与回滚？
6. 三层配额如何扣减？超限时是拒绝、排队还是降级？
7. 资源紧张时，哪个租户或任务优先？
8. 评测集多久更新一次？如何避免训练或调优污染？
9. 自动化门禁拦住什么？谁来豁免？
10. 质量事故如何分级？多久必须响应？
11. 成本如何分摊到团队？内部计价的单位是什么？
12. 数据在哪个节点出域？留存多久？删除如何证明？
13. 供应商模型变更通过什么渠道通知，多久内必须评估完？
14. 平台自身的 SLO 是多少？谁来为平台故障负责？
15. 这套治理的度量是什么？哪些流程应该被删除？

答不上来的问题，就是下一季度治理计划的输入。

实验工程 ai-lab

卷四在卷一至卷三基础上新增 src/gov/：治理对象、能力目录、版本矩阵、配额、评测平台、质量运营、成本分摊、合规、安全治理、平台工程、组织流程与演进。

# 在抽取后的 ai-lab 目录内
node --test test/gov/*.test.ts

每章的产出物

每节怎么读

1. 问题：这一节要解决的治理冲突是什么。
2. 判据：哪些条件可判定，哪些只是案例值。
3. 代码：把模块抽到 ai-lab 跑测试，看断言是否复现文中数字。
4. 边界：本节不适用的组织规模与业务形态。

治理章节的价值不在结论，而在可执行的制度与可验证的字段。

常见问题

治理是不是就是多写流程？ 不是。流程只是载体；卷四要求每个流程都有字段、判据与负责人，跑不动的流程应该被删除。

小团队需要这一卷吗？ 可以只读第 1、2、4、13 章。团队规模扩大后，其余章节的问题会依次出现。

为什么反复强调能力目录？ 目录是所有权、版本、配额、计费与退役的共同锚点。没有目录，其余治理只能靠口头约定。

版本与口径

• 运行时：Node 26.5.0，直接运行 .ts，依赖类型剥离。
• 限制：禁用 enum、namespace 与构造函数参数属性；本地导入带 .ts 后缀；零第三方依赖。
• 成本：整数微元；延迟：毫秒；成功率、配额与复用率写明分母。
• 除明确标注为本机测试输出的数字外，一律是案例假设值。

小结

卷四只做一件事：让很多条链路、很多团队、很多租户在同一套契约下长期共存。

所有权决定谁负责，版本决定谁能升级，配额决定谁先被保护，评测与合规决定什么可以上线。四件事都有字段与判据，治理才不是流程堆叠。