《互联网产品的 AI 架构·平台化与治理》前言

这一卷解决什么问题

卷一回答「一个能力的边界在哪」，卷二回答「同样边界下怎样更便宜更快」，卷三回答「多个能力怎样协同完成一个任务」。

卷四面对的是第四个问题：很多条链路、很多团队、很多租户，怎样在同一套规则下共存。

这个问题不是把卷三的编排复制几份就能解决。一条链路成立，靠的是团队内部对齐；一百条链路成立，靠的是跨团队的契约。前者可以靠人，后者必须靠字段、判据与流程。

卷四的十三章围绕四类对象展开：能力、调用方、租户、版本。每一章至少给出一个可运行模块、一组确定性数据、一份带取舍的 ADR，或者一条可判定的治理判据。

全书结构如下。

第 1 章定义对象与边界，第 2–4 章处理「有多少」（能力、版本、额度），第 5–7 章处理「值不值」（质量、事故、成本），第 8–10 章处理「能不能」（合规、安全、自助），第 11–13 章处理「谁来负责、往哪走」。

十三章的一条主线

十三章不是十三个孤立话题，而是一条从「对象」到「基线」的线。

对象   1 治理问题与边界
        │
目录   2 能力目录与所有权
        │
版本   3 版本与兼容治理
        │
配额   4 多租户与配额
        │
评测   5 评测平台 ── 6 质量运营
        │
成本   7 成本治理的组织视角
        │
合规   8 合规与数据治理 ── 9 安全治理
        │
平台  10 平台工程 ── 11 组织与流程
        │
演进  12 长期演进
        │
收口  13 卷四收口与全书回顾

读图的方式：

• 第 1 章是地基。对象没定义，后面的目录、配额与版本都没有挂载点。
• 第 2–4 章是「静态治理」：能力怎么登记、版本怎么兼容、额度怎么分。
• 第 5–7 章是「动态治理」：质量、事故与成本在运行中如何被观测和分配。
• 第 8–9 章是「约束治理」：合规与安全给出不可逾越的边界。
• 第 10–11 章是「执行治理」：平台与组织决定规则由谁落地。
• 第 12–13 章是「时间治理」：换代、技术债与基线，回答规则能活多久。

箭头不是严格的前置依赖。第 6 章可以单独读，第 9 章也可以先看。但跳过第 1、2 章直接做配额或平台，通常会得到一套无法解释的规则。

每章的四段式

每一节保持相同结构，便于对照，也便于团队分工。

1. 问题与判据：这一节回答什么问题，什么算达标，判据能不能被测试。
2. 机制与取舍：为什么这样设计，代价是什么，备选方案为什么不选。
3. 可运行片段：ai-lab 中的模块与测试，展示判据如何落成代码。
4. 边界与错误：什么时候不适用，常见误用是什么。

每章第三节固定是实验章：把前两节的判据合成一个可运行的检查、报告或基线。

四段式不是形式主义。它强迫每一节都回答三个问题：判据是什么，代价是什么，怎么验证。缺任何一项，这一节就退化成了概念介绍。

实验工程：src/gov 模块地图

卷四沿用前三卷的 ai-lab 工程，新增 src/gov/。

模块之间可以互相引用，也可以引用卷一、卷二、卷三的 src/core/、src/perf/、src/orch/，但不修改它们。

所有新增代码只用 node: 内置模块，零第三方依赖。本地导入带 .ts 后缀，测试放在 test/gov/ 下。

两级可运行性

卷四只承诺 L1 与 L2。

L1 验证一条规则是否自洽：给定输入，是否得到预期判定，边界值是否正确。L2 验证一组规则能否串起来：一次调用从目录查条目、从配额扣额度、从版本矩阵选版本、把结果写进审计记录，整条路径是否闭环。

L3 不在本书范围内。真实计费、真实合同、真实法务通知依赖具体组织，写进书里会很快过期，也会让读者误以为照抄即可上线。

不承诺 L3 有三层含义。第一，模型调用由 mock 供应商模拟，延迟、失败率与单价是可配置参数。第二，计费、账单、审批、通知全部是进程内模拟。第三，权限与合规只做到判据可执行、记录可复现，不覆盖真实账号体系与监管申报。

这不是回避复杂度，而是把可复现的部分写死，把与组织强绑定的部分留给读者。L1、L2 能验证判据是否成立；L3 才能验证你的组织是否真的能执行这套判据。

代码块的三行头

每个 TypeScript 代码块以三行注释开头。

// file: src/gov/quota.ts
// tier: L1
// verify: node --test test/gov/quota.test.ts

三行的含义：

• file 是相对 ai-lab 的路径，正文代码块与该文件逐字节一致。
• tier 标明该文件的最低验证级别，L1 或 L2。
• verify 给出可复现的验证命令。

这样做的好处是：书里的每个片段都能在工程里找到原文，改一处必须同时改两处，避免「书上能跑、仓库里跑不了」。

卷四的大量内容是表格、判据与流程，因此多数代码块是 text 或 sh，用来说明结构、命令与输出。需要展示实现时才会出现 ts 块，且必定带三行头。没有三行头的 ts 块视为错误。

案例「回声」的三条链路

「回声」是内容社区 + IM + 轻交易的产品。卷四沿用卷三的三条链路，但把它们放进多团队、多租户、多版本的环境。

三条链路共用五个能力：chat.reply、search.rerank、content.summarize、moderation.classify、support.assist。卷四不新增能力，只改变这些能力的调用方数量、租户数量与版本数量。

案例的组织方式是：能力不变，环境变复杂。这样读者可以把注意力放在治理机制上，而不是记一套新的业务名词。

共享数字口径

书里的数字遵循统一口径。

• 成本单位是整数微元；延迟单位是毫秒；成功率与配额必须写明分母。
• 平均延迟必须与 P95 一起出现；只给平均值视为不完整。
• 成本对比必须写明对照基线与统计窗口。
• 模拟数据必须标注「示例样本上的运行结果」。
• 没有测量就写「需要实测」，不用「约」「大概」掩盖。

贯穿全书的基准数字如下。

这些数字来自卷三的三能力示例样本与卷四的配额示例，不是生产实测。换一套 token 结构、单价或团队规模，绝对金额会变；分配算法、回本线与拒绝判据不变。

阅读节奏建议

十三章、三十九节，不必一次读完。一个务实的节奏是每周一章。

八周是参考，不是承诺。只有一条链路时，可以压缩到三周；多租户、多版本时，可能更久。节奏可以调，顺序尽量别跳：对象与目录是所有后续动作的地基。

三条阅读路径

按问题选路径。

1. 建设路径：1.1 → 2.1 → 3.1 → 4.1 → 4.3 → 5.1 → 7.1 → 13.1。适合第一次把多团队能力收进一个目录。
2. 排障路径：4.2 → 6.1 → 6.2 → 9.3 → 10.3 → 12.1。适合已经遇到额度挤占、事故定级争议、模型换代失控。
3. 治理路径：1.3 → 8.1 → 9.1 → 11.1 → 11.2 → 12.3 → 13.2。适合要建立评审机制与长期规则的负责人。

三条路径可以交叉。排障时如果发现目录缺字段，回到第 2 章；治理时如果发现配额算不清，回到第 4 章。路径是入口，不是轨道。

如果只读一章，读第 1 章。对象与边界决定了后面所有规则有没有作用域。

怎么验证书里的代码

每个代码块都能在 ai-lab 中找到同名文件。验证分三步。

1. 按代码块头部的 // verify: 命令运行单模块测试。
2. 用 node --test 跑 test/gov/ 全量，确认改动没有破坏其他章节的假设。
3. 对照正文数字，确认它们来自测试输出而不是手工填写。

三步有任何一步对不上，以脚本输出为准。书是静态的，脚本是活的。

书中不提供「复制到生产就能用」的完整治理系统。实验工程刻意省略了持久化、鉴权、真实供应商连接、财务系统对接与审批流引擎。这些部分与具体环境强绑定，写进书里会很快过期。

如果你的运行结果与书中不同，先检查三件事：Node 版本是否一致，单价与配额参数是否一致，统计分母是否一致。三者都一致仍然不同，那可能是一个值得记录的差异。

三个本卷不做的事

不做通用平台产品的选型与部署教程。 能力目录、评测平台、计费系统都有成熟的商业与开源产品，版本迭代快，配置项与具体版本强绑定。卷四给的是判据：目录必须有哪些字段，评测门禁在什么阈值拒绝，配额借用如何回收。判据可以迁移到任何产品，配置不能。

不做真实计费、合同与法务流程。 账单、分摊、供应商通知、数据出境申报全部由模拟器执行。书里会讨论分摊算法、通知时限与审计记录，但不会连接任何真实财务系统、合同系统或监管接口。真实流程的后果由组织承担，不适合用书本示例直接试。

不做组织效能的因果结论。 卷四会给出所有权、评审委员会、文档传递的结构与判据，但不会声称「这样组织一定更快」。组织效果依赖人、历史与激励，单靠一本书无法验证。书里能给的是一组可观察的检查项，不是一套包治百病的组织方案。

三件事有共同点：它们都依赖具体环境，换个公司、换个版本就失效。卷四只写不随环境变化的部分：对象、字段、判据与取舍。

团队怎么用

建议按「一次只加一条规则」的节奏使用本书。

1. 用第 1 章统一「什么算一个治理对象」的口径。
2. 用第 2 章给每条能力补所有者、档位与退役计划。
3. 用第 3 章建立契约、模型、提示三套版本的对应表。
4. 用第 4 章把总额拆成份额，再拆成单次上限。
5. 用第 5、6 章建最小评测集与事故分级。
6. 用第 7、8 章做成本分摊与数据分级。
7. 用第 9–11 章补风险登记、自助边界与所有权。
8. 用第 12、13 章做一次换代演练与治理评审。

不要一次加五条规则。五条同时生效，越界时无法判断是哪一条拒绝的，团队会开始绕过整套机制。

自检清单

读完卷四后，你应该能回答：

• 治理的四类对象是什么，各自最少需要哪些字段？
• 平台团队与业务团队的职责边界画在哪一层？
• 一条能力条目缺少所有者时，目录应该允许发布吗？
• 契约版本、模型版本、提示版本之间如何建立对应关系？
• 弃用窗口结束前多少天必须通知调用方，通知记录存在哪里？
• 三层配额分别是什么，借用额度由谁回收？
• 两个租户同时打到峰值时，公平性按什么排序？
• 评测集被污染时，历史回归结果还有效吗？
• 质量事故分为几级，每一级的响应时限是多少？
• 成本分摊应该按调用次数、token 还是成功交付计？
• 数据分级的依据是什么，哪些级别不允许出域？
• 平台的自助边界应该允许业务改哪些配置？
• 模型换代时，迁移计划最少包含哪几个阶段？
• 治理做得好不好，应该看哪几个数，而不是看流程数量？

答不上来的条目，对应章节需要重读。

勘误与反馈

书中的代码与数字都可以复现。如果发现代码无法运行、数字与脚本不符，以仓库中的脚本输出为准，并在勘误中记录命令、环境与输出。

欢迎指出判据不成立的反例，这比指出错别字更有价值。尤其是那些「在示例里成立、在多团队环境里不成立」的治理假设，它们是卷四最需要修正的部分。

小结

卷四不是「建一个 AI 平台」的教程，而是一套把多团队、多租户、多版本共存问题变成可设计、可拒绝、可评审的方法。

方法的核心只有一句：先让能力、调用方、租户、版本四类对象进入同一套契约，再谈平台与流程。对象不进契约，规则越多，绕过越快。

下一章从「回声」的规模化现场开始，把这四类对象落到具体冲突上。