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

一个能力，三种档位

「回声」的 chat.reply 在三个月里被三个团队接了进去。

内容团队用它做评论区回复建议，选的是标准档：单次成本上限 4,200 微元，超过 800ms 就降级成模板回复。客服团队用它做私信首响，选的是优先档：允许 1,500ms，失败重试一次，单次成本上浮约 18%。交易团队用它做下单前的确认话术，选的是低延迟档：P95 必须压在 600ms 以内，宁可少带一段上下文。

三个团队都没有做错。各自场景的取舍都合理，压测也各自通过。

问题出在平台团队收到的三份容量申请。同一张推理池，标准档说余量充足，优先档说必须扩容，低延迟档说需要独占一组机器。三份申请都附了数据，也都算得对，只是算的是各自的那一份。

能力目录里只有一行 chat.reply。这一行没有地方记录：标准档承诺什么，优先档多花多少钱，低延迟档砍掉了哪些上下文。三个档位在系统里是同一行，在容量会上是三份互相矛盾的承诺。

同一个峰值，两个租户

第二个月的最后一周，客服团队做拉新活动，私信量涨到日常的 2.3 倍。

平台的租户配额是这样写的：租户月度总额 1 亿微元，内容团队 4,000 万，客服团队 3,000 万，交易团队 3,000 万；单次调用另有上限，摘要 6,200 微元、回复 4,200 微元、下单 3,000 微元。

客服团队在 26 日烧完了自己的 3,000 万，系统按「共享池可借用」的规则让它继续跑。28 日凌晨，内容团队的夜间批量摘要开始收到 429；20 点，交易团队的下单咨询峰值排在队列里，P95 从 793ms 涨到 2,100ms。

三个团队都认为自己按预算办事。内容团队没有超支，交易团队没有超支，客服团队的超支也被系统允许。但预算只写在财务季度表里，没有写进调用链。借用规则存在，回收规则不存在：借出去额度以后，谁在什么时候把它还回来，没有任何一层负责。

一个租户的营销峰值，就这样打满了另一个租户的夜间批处理。

一次模型换代，三份版本

第三个月，供应商把默认模型从 v2 升到 v3，平台在灰度里把路由权重从 10% 调到 100%。

内容团队的能力契约仍然是 1.4，实际执行的模型已经变了。客服团队的提示词是针对 v2 调的语气，在 v3 上输出明显变短。交易团队的少样本示例里有一条 v2 特有的格式，v3 直接忽略，回答开始漏掉退款条件。

三份「能力版本」在目录里都显示 1.4。监控上，三条链路的成功率都还在 95% 以上，直到人工抽检发现客诉回复的平均字数从 86 降到 54，才有人把模型变更和语气变化联系起来。

版本漂移不是有人改错了配置，而是配置改了、契约没改。目录记录的是契约版本，路由执行的是模型版本，提示词仓库记录的是提示版本。三个版本各自有 owner，彼此不知道对方变了。

三个冲突的共同点

三个现场看起来分别是容量问题、配额问题、版本问题，拆开处理会得到三套互不相干的方案：加容量、调额度、锁模型。

它们有同一个结构：某个对象的承诺只存在于某个团队的文档、表格或记忆里，没有进入系统能读取、能校验、能拒绝的位置。

• 档位承诺在容量会的口头结论里，目录里只有一行能力名。
• 配额承诺在财务表里，调用链上只有一个总数。
• 版本承诺在路由配置里，契约里只写了一个语义化版本号。

治理要做的第一件事，不是再加一道审批，而是把这些承诺搬到同一个地方：让系统在调用发生的那一刻，知道这次调用属于哪个档位、哪个租户、哪个版本，以及越界时应该拒绝还是降级。

治理不是流程堆叠

很多团队一谈治理就开始加流程：需求评审、上线审批、季度审计、合规签字。流程一层层叠上去，通过越来越慢，绕过越来越多，最后治理变成一个季度填一次的表。

流程解决的是「谁签字」，契约解决的是「系统允许什么」。前者依赖人记得，后者可以在调用时被拒绝。

流程不是没用。它适合处理例外：一次性的容量申请、跨团队的优先级冲突、监管要求的专项检查。但例外不能承担常态。常态必须写进契约，否则每多一个团队，就多一轮口头对齐。

四类对象写进契约

卷四把治理对象收敛成四类。每一类都对应一组必须写进契约的字段，以及一个「不写会怎样」的现场。

四类对象不是四个文档，而是四组可以互相引用的字段。能力条目引用租户配额，租户配额引用版本矩阵，版本矩阵引用调用方的迁移状态。任何一组缺失，另外三组都会退化成静态表格。

这也是本书与「平台建设」类内容的分界：本书不讨论要不要建门户，而讨论门户背后的字段能不能支撑一次拒绝。

四卷的分工

这套书按「边界—效率—协同—治理」四层展开。

卷一优化一个节点，卷二优化一条链路的成本，卷三优化边，卷四优化面。

节点有局部指标：一个能力的 P95、单次成本、成功率。边有端到端指标：一条任务是否完成、完成得对不对、花了多少。面没有单一指标。面要回答的是：同样的能力，为什么三个团队拿到三种承诺；同样的预算，为什么一个租户能挤掉另一个；同样的版本号，为什么行为不一样。

卷四的位置：从边到面

卷三收口时给出一组基线：链路 A 成功率 96.25%、每次成功交付 3,496 微元、P95 3,523ms；链路 B 99.58%、3,804 微元、1,738ms；链路 C 95.00%、2,429 微元、793ms；合计 698/720，即 96.94%，判定为 conditional。

这组数字的成立条件很窄：单团队、单租户、单版本、固定负载。它证明一条链路可以被验收，不证明一组链路可以被治理。

把三条链路复制到三个团队、五个租户、两个模型版本之后，96.94% 不再是一个可比的数。分母变了：每条链路的重试策略不同，每个租户的配额不同，每个版本的提示不同。治理要做的，是让这些差异显式，而不是让它们互相掩盖。

卷四就站在这个位置上：它不重新教怎么优化一个能力，也不重新教怎么编排一条链路，它处理的是复制之后出现的那些问题。

本书回答什么

十三章分五段。

第一段定义边界。边界不清，后面的目录会变成资产清单，配额会变成财务口径，版本会变成发布记录。

第二段处理「有多少」。能力有多少条、版本有多少个、额度有多少钱，这三个数量决定了治理的复杂度。

第三段处理「值不值」。评测平台回答质量有没有变好，质量运营回答坏的时候怎么办，成本治理回答这笔钱该记在谁头上。

第四段处理「能不能」。数据能不能出域、工具能不能被调用、业务能不能自助，三个问题都指向同一个东西：权限边界。

第五段处理「谁来负责、往哪走」。组织与流程决定人，长期演进决定时间，最后一章把前面所有判据收成一份可以逐条打勾的基线。

数字从哪里来

书里的数字只有三个来源。

没有第四种来源。没有生产环境的数据，也不写「业内通常」。

序里出现的 4,240 → 3,786 微元、1,200 → 1,269ms、820 token、3,200 token、90% 缓存折扣、28.47% 回本线、13.02% 单步失败预算、35ms 交接延迟，都来自卷三的三能力示例样本。租户总额 1 亿微元、三个团队 4,000/3,000/3,000 万、单次上限 6,200/4,200/3,000 微元，是卷四贯穿使用的配额示例。

这些数字的任务不是预测你的系统，而是固定一套口径。换一套 token 结构、单价或团队规模，绝对数会变；分配算法、回本线与拒绝判据不变。

本书不承诺 L3

卷一建立的三级可运行性，卷四继续沿用。

卷四以 L1、L2 为主，明确不承诺 L3。

不承诺 L3 有三层含义。第一，模型调用由 mock 供应商模拟，延迟、失败率与单价都是可配置参数，不代表任何真实供应商的表现。第二，计费、账单、审批、法务通知全部是进程内模拟，不连接真实财务或合同系统。第三，权限与合规只做到「判据可执行、记录可复现」，不覆盖真实组织的账号体系、监管申报与跨境传输。

这不是回避复杂度，而是划清可复现的边界。L1、L2 能验证一条治理规则是否自洽；L3 才能验证它在你的组织里是否可行。后者依赖人、合同与监管，写进书里会很快过期。

治理判据要能拒绝

一条不能被执行的治理规则，只是一句愿望。

卷四的每一章至少给出一条可以拒绝的判据。拒绝可以发生在网关、目录、评测门禁或评审会，但必须有明确的触发条件与可复现的记录。

这些判据都可以写成测试。第 13 章会把它们收成一份治理基线，逐条标注「已执行」「仅记录」「未覆盖」。一份诚实标注了未覆盖项的基线，比一份全部打勾的清单有用。

一个反例：治理等于建门户

面对多团队，最诱人的方案是建一个门户：把所有能力挂上去，加审批流，加仪表盘，加一个「AI 治理」标签页。

门户解决「看得见」，不解决「管得住」。

看不见的档位、算不清的配额、对不上的版本，挂到门户上仍然是三份互相矛盾的承诺。门户是展示层，契约是执行层。展示层可以把矛盾排得很好看，执行层才会在越界时说不。

卷四不反对门户。第 10 章会讨论自助服务与配置分发，门户是其中一部分。但顺序必须是先有字段与判据，再有界面。反过来做，团队会得到一个很漂亮、但没人用来做决定的站点。

平台化不等于收权

另一个常见误解是：平台化就是把所有能力收归平台团队，业务只负责提需求。

这个做法在能力少的时候有效，在能力多的时候会同时压垮两边。平台团队不掌握业务语义，无法判断一段回复是否合规、一次重排是否值得；业务团队失去改动权，只能用工单表达需求，迭代速度反而下降。

卷四主张的是「平台定契约，业务定实现」：平台负责目录字段、配额算法、版本矩阵、评测门禁与审计记录；业务负责提示词、模型选择、档位取舍与事故复盘。平台可以拒绝一次越界调用，但不替业务决定回复怎么写。

这条边界会在 1.3 与 10.1 反复出现。它也是判断一次平台化是否成功的标准：业务改一个提示词，需不需要排期等平台；平台加一条判据，能不能不打断业务发布。两个答案都是「不需要」，边界才算划清。

怎么读

三条路径，按问题选。

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。适合要建立评审机制与长期规则的负责人。

三条路径都建议先读第 1 章与 2.1。对象没定义，目录没字段，后面的配额、评测与分摊都没有挂载点。

写给谁

• 已经把一条 AI 链路跑通，正在把它复制给第二个、第三个团队的负责人。
• 负责平台或中台，需要同时面对容量、配额、版本与合规诉求的架构师。
• 正在建能力目录、评测平台或成本分摊机制的平台工程师。
• 需要做治理评审，想要一套可判定标准而不是一份原则清单的管理者。

如果还没有能力契约与基础观测字段，建议先读卷一；如果还没有单链路的成本与延迟口径，建议先读卷二；如果还没有把多个能力串成任务，建议先读卷三。卷四的所有判据都建立在这三层之上。

一个可以立刻做的检查

读完这篇序，不必等读完正文，可以先挑一个自己产品里的能力，回答四个问题。

第一，这个能力有几个档位？每个档位的延迟、成本与失败语义分别承诺了什么？如果答不上来，说明档位只存在于调用方的代码里。

第二，额度写在哪一层？是财务表、网关配置，还是调用时的实时判定？借出去以后，谁负责回收？

第三，版本由谁负责？契约版本、模型版本、提示版本是不是同一个人在看？模型换代时，哪个环节会通知调用方？

第四，越界时谁说不？是网关拒绝、目录拒绝，还是月底账单出来以后才追认？

四个问题都答不上来，正说明卷四有存在的必要。它们也是后面所有治理设计的起点。

最后的提醒

平台化与治理的难点，不是把能力挂到一个页面上，而是让四类对象在同一套契约里互相约束。

一次治理是否有效，不取决于上线了多少流程，而取决于三件事：能力条目有没有档位与所有者，配额有没有借用与回收，版本变更有没有通知到调用方。

这三件事都能被写成字段，也都能被测试。卷四要做的，就是把它们从开会讨论变成可执行的判据。

小结

从一个能力被三个团队以三种档位调用，到一个租户的峰值打满另一个租户的批处理，再到一次模型换代让三份版本悄悄分叉，三个冲突指向同一个缺口：承诺没有进入契约。

治理不是流程堆叠，而是把能力、调用方、租户、版本四类对象写进可读取、可校验、可拒绝的字段。卷四沿用卷三的 96.94% conditional 基线，但不把它当成治理成绩；它要回答的是复制之后，分母变了以后，谁对承诺负责。