《互联网产品的 AI 架构·平台化与治理》附录 C 平台化评审清单

清单的定位

平台化评审最容易开成“目录截图讲一遍”的汇报会。截图很整齐，问题却还在：这个能力的 owner 是谁，配额超了谁负责，版本下线时调用方迁到哪。清单的作用不是让会议更长，而是让这些问题在放行前有答案。

十三组、六十五问，每组五问。不必每次问完；按方案风险挑三到五组深问。但目录、所有权、配额、合规四组建议每次必问，它们对应四类最容易在上线后暴露、上线前又最容易被跳过的缺口。

每组的“通过判据”是放行底线，“常见驳回”是评审现场最常听到的无效回答。回答不了判据，就还没有材料；只给驳回式回答，就还没有方案。

评审前的材料清单

评审不是从会议室开始，而是从材料齐不齐开始。下面八项缺两项以上，建议直接延期，不进入详细评审。

材料清单本身也是判据。提供方说“目录在平台上”，但导不出十八字段，等于没有目录；租户管理员说“额度够用”，但拿不出三层求和，等于没有配额。

一、目录

目录是治理入口。先看条目是否存在、是否可判重，再看字段是否足以支撑后续决策。

1. 每个在役能力是否都有唯一 id 与 functionKey？
2. 条目十八字段是否齐全，owner 与 ownerBackup 是否都能在十分钟内应答？
3. 同一 functionKey 下是否存在两个在役能力？合并或替代关系是否登记？
4. 目录是否记录 riskLevel、dataClass、regions 与 evalSetRef？
5. 目录更新是否由变更流程自动写入，而不是季度手工补录？

通过判据：抽样十条字段齐全；在役 functionKey 无重复；owner 可联系；最近一次更新在三十天内。

常见驳回：“目录在 wiki 上，最新版找 XX 要。”wiki 不是目录，找不到版本号的目录无法用于拦截。

二、所有权

所有权决定事故、成本与退役有没有承接人。看的是 A 是否唯一，而不是团队名字好不好听。

6. 每个能力的质量、成本、退役是否都有单一最终问责人？
7. 提供方与调用方的责任边界是否写进契约，而不是口头约定？
8. 跨团队共享能力时，SLA、值班与升级路径是否明确到团队？
9. owner 休假或离职时，backup 与交接记录是否可查？
10. 平台团队是否既制定标准又运营能力？如果是，谁审查它？

通过判据：RACI 每行一个 A；owner 与 backup 都在组织名录；责任边界写入契约。

常见驳回：“大家一起负责。”没有单一 A，冲突发生时没有人有义务拍板。

三、版本

版本治理看的是“五个版本能否绑在一行”，不是“发了几个版本”。

11. 契约、模型、提示、策略、评测集五个版本是否在同一张矩阵里？
12. 不兼容变更是否升主版本，并给出弃用窗口与 sunsetAt？
13. 调用方锁定的版本是否可回放，响应是否返回模型与提示版本？
14. 弃用窗口内是否有迁移清单、迁移率与回滚版本？
15. 是否存在 latest、stable 之类别名，导致同一引用指向不同契约？

通过判据：矩阵可查询；每个 deprecated 版本有 sunsetAt 与 migrationRef；回放能复现同一输入。

常见驳回：“直接改提示，不用发版。”提示是行为的一部分，不改版本就无法归因。

四、配额

配额看三层是否同时存在，以及求和是否成立。只有总额没有份额，团队会争抢；只有份额没有单次上限，一个请求就能打爆。

16. 租户总额、团队份额、调用方份额、单次上限四层是否都登记？
17. 份额之和是否不超过总额（4,000 万 + 3,000 万 + 3,000 万 = 1 亿）？
18. 单次上限是否按能力设定（摘要 6,200、回复 4,200、下单 3,000 微元）？
19. 借用与回收是否有审批、窗口、归还日与自动回收？
20. 配额执行点是否在网关，账单口径与执行口径是否一致？

通过判据：三层求和校验通过；超额有拒绝日志；借用有到期时间与归还记录。

常见驳回：“先放开，月底看账单。”账单是事后结果，不是配额控制。

五、评测

评测不是“跑过几个 case”，而是“版本化样本 + 阈值 + 归因”。

21. 每个能力是否有版本化评测集，是否覆盖 A/B/C 三条链路？
22. 评测集是否做过污染检查，训练数据与评测样本是否隔离？
23. 发布门禁是否同时看质量、成本、延迟，而不是只看准确率？
24. 回归失败能否定位到契约、模型、提示的具体版本？
25. 评测集多久更新一次，最近一次新增的失败模式是什么？

通过判据：evalSetRef 存在且未过期；门禁有明确阈值；失败归因可下钻到版本。

常见驳回：“上线前人工试了几个 case。”样本量、判据与版本都说不清。

六、质量

质量运营看线上信号能否按能力、版本、租户拆分，以及事故是否有分级。

26. 线上质量信号是否按能力、版本、租户三个维度拆分？
27. 抽检比例、样本量与判定标准是否写死？
28. 事故分级是否有明确阈值（S1/S2/S3）与响应时限？
29. 质量事故是否区分提供方、调用方、平台与数据原因？
30. 季度复盘是否输出可执行项，而不是“加强监控”？

通过判据：信号可下钻；事故有分级与 owner；复盘项有日期与验收人。

常见驳回：“感觉最近差评多了。”感觉不是信号，无法比较版本。

七、成本

成本看分母。分母用调用次数还是成功交付数，结果可能差一倍以上。

31. 每次成功交付成本是否以成功交付数为分母，而不是调用次数？
32. 交接、重试、人工、固定开销是否全部计入？
33. 成本能否归因到能力、版本、调用方、租户四层？
34. 优化是否按边际收益与回本线排序（复用回本线 28.47%）？
35. 预算超支时先裁谁、保留哪些下限，是否有文档？

通过判据：成功交付成本可复算；四层归因齐全；裁剪顺序有 ADR 或等价记录。

常见驳回：“单价降了 10%，所以省钱了。”单价不等于总成本，失败与重试会把省下的钱吃回去。

八、合规

合规看数据最远能到哪里，以及删除请求能否追到终点。

36. 每个能力的 dataClass、出域区域、留存期是否登记？
37. 删除请求能否追到调用日志、缓存、评测样本与供应商侧？
38. 供应商模型变更是否有通知机制与再评估流程？
39. 跨境或出域是否有评估记录、审批人与有效期？
40. 审计日志是否记录“谁在什么租户下授权了什么数据”？

通过判据：分级表覆盖全部在役能力；删除有回执；供应商变更有台账。

常见驳回：“隐私政策里写了。”政策是承诺，不是执行记录。

九、安全

安全评审看不可逆风险，不看“有没有防火墙”。

41. 提示注入、工具滥用、越权调用是否在风险登记册里？
42. 红队范围是否覆盖多能力链路与跨租户边界？
43. 工具白名单与参数校验是否在平台侧强制执行？
44. 安全事件是否有分级、止血开关与披露口径？
45. 上一次红队发现的问题是否复测通过？

通过判据：风险有等级、owner、期限；红队覆盖链路；复测有记录。

常见驳回：“内部服务不用鉴权。”编排放大了越权，一个节点被污染，整条链路都可能越界。

十、平台工程

平台工程看自助边界与可回滚性。平台越强，越要说明哪些事平台不替业务做。

46. 自助接入的边界在哪里，哪些变更必须走评审？
47. SDK/CLI 版本与契约版本是否解耦，升级是否兼容？
48. 平台自身 SLO（可用性、配额查询延迟、配置生效时间）是否公开？
49. 配置分发是否可回滚，灰度是否按租户或调用方切分？
50. 平台变更是否会破坏已有调用方，兼容测试是否覆盖？

通过判据：自助边界有清单；平台 SLO 有数字；配置可回滚且有演练。

常见驳回：“平台升级不影响业务。”没有兼容测试，这句话只是愿望。

十一、组织

组织看决策是否留痕。委员会不是审批图章，而是冲突的最终裁决场。

51. 评审委员会是否有明确席位、法定人数与决策规则？
52. 每次评审是否留下决策记录（条件、owner、复查日期）？
53. 例外是否有台账、到期时间与退出条件？
54. 培训与文档是否覆盖新接入团队，是否有回执或考核？
55. 平台、提供方、调用方的目标是否互相冲突，是否有对齐机制？

通过判据：决策记录可检索；例外有到期时间；新团队有接入回执。

常见驳回：“开会口头同意了。”口头同意无法复查，也无法追责。

十二、演进

演进看退出条件。没有退出条件的方案，上线那天就是它最后一次被认真检查。

56. 每个能力是否有退役计划与退出条件？
57. 模型换代的迁移计划是否包含灰度、回滚与成本对比？
58. 技术债是否有清单、利息估算与偿还排期？
59. 治理度量是否看事故、返工与迁移周期，而不是流程数量？
60. 未来十二个月哪些能力可能被合并或替换，影响面是否评估？

通过判据：退役与迁移有计划；技术债有排期；度量有基线。

常见驳回：“以后再说。”以后通常不会有人再说。

十三、收口

收口把评审变成可验证的条件，而不是一句“同意”。

61. 本次评审的基线（A 96.25%/3,496、B 99.58%/3,804、C 95.00%/2,429）是否可复现？
62. 结论是否写成可验证条件，而不是“同意”？
63. 每个条件是否有 owner、证据与复查日期？
64. 上线后复盘表是否预填，差异超过 20% 如何处理？
65. 本次评审暴露的系统性缺口是什么，谁来补，何时补？

通过判据：基线可复算；条件可验证；复盘表已预填。

常见驳回：“先上线，有问题再复盘。”复盘不是事后补文档，条件必须在放行前写死。

三个快速判据

时间不够时，先用三问筛掉准备不足的方案：

• 能不能用一句话说清“为什么不是单能力”？ 说不清，说明结构或目录还没成立。
• 配额超了用户看到什么，团队能否在十分钟内说清？ 说不清，说明失败路径没设计。
• 这次上线的退出条件是什么？ 说不清，说明没有回滚预案。

三问有一问答不上来，方案先回去补材料，不进入详细评审。它们不保证方案正确，但能挡掉大部分“先画一张图再说”的方案。

四十五分钟评审流程

评审的产出不是“同意”，而是“可验证的条件”。没有条件的通过，等于把风险留给上线之后。

结论模板

方案:        回声内容发布链 v4（content.summarize 3.0.0 + moderation.classify 2.2.0）
结论:        有条件通过
基线:        A 链 96.25%，每次成功交付 3,496 微元，P95 3,523ms
改动:        摘要模型换代，提示 v4 → v5，新增一次交接
预期:        成本 4,240 → 3,786 微元（-10.71%）
             延迟 1,200 → 1,269ms（+5.79%）
             单步失败预算 13.02%
条件:        1) 目录补齐 sunsetAt 与 migrationRef（owner：能力提供方）
             2) 单次上限维持 6,200 微元，不得临时突破（owner：平台团队）
             3) 灰度 10% 观察 48 小时，失败率超标自动回滚（owner：平台团队）
复查:        2026-11-19，带成功交付成本、A 链成功率与回放样本

模板里的数字是示例值，不是承诺值。评审要确认的是“这些数字怎么算出来”，而不是“数字好不好看”。

结论分级与放行规则

“有条件通过”不是“通过”。条件未关闭前，放行范围必须受限；把有条件通过当全量通行证，是评审最常见的执行偏差。

季度复盘表

复盘表在季度结束后两周内填写。差异超过基线 20% 的项目必须给出原因；给不出原因的，视为度量口径有缺陷，而不是“模型不稳定”。

常见错误与边界

误区一：把清单当打分表。 六十五问不是六十五分，答得多不代表风险低。清单的用途是排除“没有答案”的项，而不是给方案评优。一个高分方案仍可能在一个关键问题上没有答案。

误区二：只审提供方，不审调用方与租户。 配额超分、数据越界、降级体验往往发生在调用方与租户侧。只审能力实现，等于把一半风险留在门外。

误区三：评审一次就结束。 治理是持续动作。版本会漂移，配额会借用，例外会到期；没有季度复盘与到期清理，清单会变成一次性仪式。

小结

平台化评审的本质，是问四个问题：目录是否可信、所有权是否唯一、配额是否可控、风险是否收得住。六十五问只是把这四个问题拆到可回答的粒度。

不必一次问完。先问目录、所有权、配额、合规四组，大多数方案的风险会在这四组里暴露；评测、质量、成本放在第二轮；组织、演进与收口留到方案稳定之后再谈。

评审结束前，把结论写成条件，把条件写进复盘表。清单只有被下一次复盘引用，才算真正生效。