这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
《互联网产品的 AI 架构·平台化与治理》附录 C 平台化评审清单
把平台化治理压缩成一份可打印的评审清单：目录、所有权、版本、配额、评测、质量、成本、合规、安全、平台工程、组织、演进与收口十三组共六十五问，每组附通过判据与常见驳回，并给出三个快速判据、四十五分钟评审流程、结论模板、季度复盘表与三个常见误区，帮助评审现场把结论写成可验证的条件。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
《互联网产品的 AI 架构·平台化与治理》附录 B 能力目录与配额字段速查
把能力目录、契约、配额与版本矩阵四类字段压成可直接照抄的速查表：每个字段给出类型、是否必填、示例与缺失后果，覆盖能力条目十八字段、提供方与调用方请求响应字段、租户总额与团队份额与单次上限三层配额、契约模型提示策略评测五版本矩阵，并给出六层校验顺序、失败输出样例与最小可用条目。
《互联网产品的 AI 架构·平台化与治理》附录 A 治理角色与职责速查
把卷四的治理角色压成一页可查的职责表：平台团队、能力提供方、调用方、租户管理员、安全合规与评审委员会六类角色，逐项列出职责、决策权、明确不负责的边界与交接物，附一张十二行 RACI 表、角色与治理对象对应关系、三个真实职责冲突的裁决过程，以及交接物验收口径，便于在跨团队评审现场直接定位责任主体。
《互联网产品的 AI 架构·平台化与治理》13.3 全书回顾与继续阅读
四卷分别回答能力边界、链路性能、多能力协同与多团队治理四个问题，但它们不是四个可以随意套用的模板。本节回顾四卷的分工与各自边界，给出四组可对齐的计量口径，逐条说明这套架构在单团队、低调用量、单租户、单一供应商、短周期业务与无裁决权组织里为什么不适用，并按架构师、平台工程、安全合规与业务负责人给出继续阅读方向。
《互联网产品的 AI 架构·平台化与治理》13.2 一次跨团队治理评审
治理基线只有进入评审桌才有意义。本节还原回声 2026 年 11 月 5 日的一次真实形态评审：内容团队要把摘要与审核能力开放给创作者工具，七个参会方带来七份证据，四个争议点分别涉及重复建设、额度借用、评测隐私与放量节奏。文章给出决议规则、待办跟踪与一次反例，并用确定性代码演示基线如何把结论限定为试点。
《互联网产品的 AI 架构·平台化与治理》13.1 治理基线：回声的平台化清单
前十二章分别讲了目录、版本、配额、评测、质量、成本、合规、安全与平台工程，但团队真正需要的是能勾选的一张表。本节把治理对象、目录字段、版本矩阵、配额、评测门禁、四类流程、平台 SLO 与所有权压成 12 条基线条目，每条给出判据、证据与责任人，并用确定性代码算出通过、部分、失败与总体结论，最后说明 blocking 项与非 blocking 项的区别。
《互联网产品的 AI 架构·平台化与治理》12.3 治理的度量：不是流程数量
治理周报列了 47 个流程、12 个委员会，变更失败率却从 10% 涨到 16.67%。本节用五个结果度量替换流程数量：能力上线周期、变更失败率、配额闲置率、评审平均耗时、流程豁免率，给出分子分母、目标带与趋势判定，并说明为什么流程数量不能进入记分卡。
《互联网产品的 AI 架构·平台化与治理》12.2 技术债与退出条件
兼容层留了两年、旧提示没人敢删、两个能力永远在合并路上，技术债的问题不是记不住，而是没有退出条件。本节给出五类债与五种退出动作，把调用方、流量、静默天数与证据写成可判定条件，并说明永远不还的债如何按年化成本单独记账，让还债与做新功能能在同一张预算表上比较。
《互联网产品的 AI 架构·平台化与治理》12.1 模型换代与迁移计划
模型换代不是改一个模型 ID，而是一次跨团队迁移。本节给出迁移计划的六个字段与五个阶段（评估、影子、两档灰度、全量），用确定性代码判定推进、保持与回滚，并把灰度比例、回滚红线和旧模型下线日写成可执行条件，最后说明它如何与卷四 3.2 的版本矩阵衔接。
《互联网产品的 AI 架构·平台化与治理》11.3 培训、文档与知识传递
文档不是写完就算，培训也不是听一次课。本节把文档分为入门、操作、参考、决策四层，按槽位而不是篇数计算覆盖度，参考文档必须钉住当前主版本，受监管能力的操作与参考文档 90 天复审；培训路径按读、跟岗、受控独立、独立四阶段单调推进；新人上手用「首次独立上线且复核通过」定义，示例样本上中位数 31 天、P90 44 天。
《互联网产品的 AI 架构·平台化与治理》11.2 评审委员会与决策记录
评审委员会的价值不在开会，而在可重算的决策记录。本节定义七个席位的职责、七类议题的到会人数与否决席，给出「流会、否决、弃权、票数」的判定顺序，并用代码把 outcome 从 ballots 重算出来。示例样本上五个议题得到批准、流会与否决三种结果，四条记录中三条因结果不一致、缺条件或复查超期被拒绝。
《互联网产品的 AI 架构·平台化与治理》11.1 谁拥有 AI 能力：平台团队与业务团队
能力归属不能按组织架构图分配。本节给出平台全权、业务全权、平台管契约业务管内容三种模型，用七个现场事实排出判定顺序，并把结论落到能力目录的 owner 字段：accountable、contractOwner、contentOwner、oncall、escalation 与复查周期。配套代码校验模型、团队类型与复查节奏，示例样本上五条能力得到三种归属，三条问题条目一次返回八个错误。
《互联网产品的 AI 架构·平台化与治理》10.3 平台自身的 SLO 与容量
平台说自己 99.99% 可用，业务方却每天遇到失败。本节把平台 SLO 拆成网关、配额与评测三个部件，用整数基点定义目标、按事件数计算错误预算与燃烧率，给出正常、评审、冻结三档动作，并在示例样本上跑出健康、风险、耗尽三种状态与六个月容量规划。
《互联网产品的 AI 架构·平台化与治理》10.2 SDK、CLI 与配置分发
同一个能力，三个团队跑出三种行为。本节把问题拆成 SDK 与 CLI 的职责分界、六层配置覆盖、灰度下发与向后兼容四件事，用可运行代码解析默认值、平台、能力、租户、团队与请求六层配置，并在 200 个租户样本上跑出 5%、25%、50%、100% 四档灰度的实际分桶结果。
《互联网产品的 AI 架构·平台化与治理》10.1 平台的自助服务边界
自助服务不是把所有按钮都放开。本节把回声平台的七类请求拆成四类自助与三类人工，用准入目录、档位、额度与语料隐私四个条件判定路由，给出 24 小时、5 个工作日与 10 个工作日三档审批时限，并用可运行代码跑出 10 个示例请求的路由结果与 40% 自助覆盖率。
《互联网产品的 AI 架构·平台化与治理》9.3 事故响应与披露
安全事件响应不是一份事后复盘模板，而是分级、止血、取证、披露四条并行的时间线。本节定义 sev1 到 sev4 的确认、止血与取证时限，给出按事实分级的规则、固定顺序的止血清单、证据链要求，以及客户、监管与公众三类披露的触发条件、时间线与口径。
《互联网产品的 AI 架构·平台化与治理》9.2 红队与滥用检测
红队是计划性的证据生产，滥用检测是持续性的信号发现，两者都不能用一次总通过率代替。本节定义红队计划的范围、频率、用例集与评分，给出覆盖率、完整性、加权通过率、严重失败与逾期五个门禁条件，并定义五类滥用信号、阈值、权重与监控到停用的动作阶梯。
《互联网产品的 AI 架构·平台化与治理》9.1 提示与工具的风险登记
风险登记表不是漏洞清单，而是把提示注入、工具滥用、数据外泄与越权动作变成可评分、可复查、可追责的条目。本节定义风险类别、影响面、可能性、现有控制、剩余风险、负责人与复查日期七个字段，用确定性代码计算剩余分与复查到期，并给出红队与事件回写登记表的接口。
《互联网产品的 AI 架构·平台化与治理》8.3 供应商合规与模型变更通知
供应商换模型、改价格、调整训练策略时，通知期往往比技术方案更先决定风险。本节给出数据处理协议、区域、留存、训练用途、变更通知与安全通告六类清单字段，按数据级别收紧要求，并用可运行判定把变更分为接受、有条件接受与拒绝，同时给出通知窗口与评估流程。
《互联网产品的 AI 架构·平台化与治理》8.2 留存、删除与审计
删除请求发出后，主库删掉不等于数据消失：缓存、日志、检索索引、评测集和备份都可能是副本。本节定义各存储的留存上限与删除传播时限，用确定性回执检查每条路径，生成可复核的删除证明，并给出审计记录的最小字段与校验规则，避免删了主库却留下副本而无人察觉。