《互联网产品的 AI 架构·平台化与治理》13.1 治理基线:回声的平台化清单

前十二章分别讲了目录、版本、配额、评测、质量、成本、合规、安全与平台工程,但团队真正需要的是能勾选的一张表。本节把治理对象、目录字段、版本矩阵、配额、评测门禁、四类流程、平台 SLO 与所有权压成 12 条基线条目,每条给出判据、证据与责任人,并用确定性代码算出通过、部分、失败与总体结论,最后说明 blocking 项与非 blocking 项的区别。

从十二章回到一张表

卷四用十二章分别讲了治理对象、能力目录、版本矩阵、三层配额、评测平台、质量运营、成本分摊、合规、安全、平台工程、组织责任与演进治理。每一章都给了机制,也给了取舍。但一个准备放量的团队不会带着十二章来开会,他需要一张能当场勾选的表。

这张表就是治理基线。它不是评分卡,不追求把每项做到满分;它是一组准入判据,回答三个问题:这项治理有没有人负责、判据能不能复核、证据是不是已经拿到。三项缺一项,条目就不能算通过。

本节把前十二章压缩成 12 条基线条目,每条写清判据、责任人与所需证据,再用一段确定性代码算出单条判定与总体结论。所有数字都来自示例样本上的运行结果,不是生产实测。

一张表要回答三个问题

治理基线最容易做成「制度目录」:列一堆文件名,证明写过制度。但文件存在不等于机制生效。可用的基线必须同时覆盖对象、机制与证据三层。

层要回答的问题反例
对象治理的是谁,边界在哪只列能力,不列调用方与租户
机制用什么规则做决定写了「统一管理」,没写谁批、何时生效
证据怎么证明规则被执行只有制度 PDF,没有最近一次记录

落到条目上,一条基线至少要有七个字段:稳定 id、治理域、可复核的判据、能做出决定的责任人、判据要求的证据、当前已拿到的证据、以及是否为 blocking。缺了责任人,缺口没人关闭;缺了证据,结论只能靠口头;缺了 blocking 标记,所有条目都变成「尽量做」。

十二条基线与判据

回声的基线覆盖 11 个治理域,共 12 条。前 11 条来自前十二章的机制,第 12 条专门盯退役,因为退役是最容易被漏掉的一环。

id治理域判据责任人blocking
objects.snapshot对象四类对象可导出唯一 id 与归属平台治理是
catalog.fields目录在役能力目录含契约、默认档位、可覆盖参数、SLA 与退役日期能力目录是
versions.matrix版本契约、模型、提示三条版本线与弃用窗口可查版本发布是
quota.three-tier配额租户总额、团队份额、单次上限三层账本可对账财务平台是
evaluation.gate评测跨团队评测集标注来源、隐私级别、有效期与责任人,回归门禁可复跑评测平台否
quality.ops质量抽检比例、事故分级与季度复盘有执行记录质量运营否
cost.chargeback成本成本分摊与月度对账统一用整数微元并写明分母财务平台是
compliance.retention合规数据分级、留存、删除与供应商通知有演练记录合规否
security.risk安全风险登记、红队与漏洞披露均有最近一次记录安全是
platform.self-service平台平台 SLO、自助边界与升级通道写入对外文档平台工程是
ownership.active所有权每个在役能力都有能决定发布与退役的 owner平台治理是
ownership.retired所有权已退役能力有依赖清单与迁移完成签字平台治理否

这张表的关键不是十二条,而是每条都能被另一个人复核。判据里没有「完善」「合理」「基本具备」这类词,只有可查的对象:快照、目录、账本、演练记录、风险登记、对外文档、owner 映射。

单条怎么判

单条判定只做三件事,顺序不能反。

第一,检查责任人。owner 为空或只有空白字符,直接判失败,理由是 no-owner。没有责任人时,证据再多也没人保证它下个月仍然有效。退役条目尤其容易这样:能力下线了,owner 也跟着从组织架构里消失。

第二,检查判据。判据没有要求任何证据,直接判失败,理由是 no-criterion。这通常意味着条目写成了口号,例如「安全治理到位」,无法复核。判据可以宽,但必须能指出看什么。

第三,检查证据。一份都没有时判失败,理由是 no-evidence;只缺一部分时判部分通过,理由是 missing-evidence,并列出缺哪几份。证据用稳定 id 表示,可以是报告编号、账本快照或评审记录,不必是文件路径。

判定不读外部系统,也不做时间推断。输入什么就判什么,因此同一份快照每次得到同一结论。这是基线能被审计的前提:结论不依赖跑脚本那天的网络、缓存或权限。

总体结论三档

总体结论不是「通过率」,而是三道闸门。

结论条件含义
pass全部条目通过可以进入常规放量评审
conditional没有 blocking 项失败,但存在非 blocking 缺口只能带条件放行,缺口进入待办
blocked任一 blocking 项未通过不得放量,先补否决项

conditional 不是模糊地带。它必须同时带一份条件清单,列出哪些条目没通过、缺什么证据、由谁在什么日期前补齐。没有条件清单的 conditional,和口头说「问题不大」没有区别。

blocked 也不等于项目失败。它只说明当前快照不满足放量门槛,团队可以继续试点、继续补证据,但不能把流量一次性推上去。

基线的实现

下面的模块把条目判定、总体结论与回声样本放在同一个文件里。它不依赖网络与存储,所有判断都是确定性的。

// file: src/gov/baseline.ts
// tier: L2
// verify: node --test test/gov/baseline.test.ts

export type BaselineDomain =
  | "objects"
  | "catalog"
  | "versions"
  | "quota"
  | "evaluation"
  | "quality"
  | "cost"
  | "compliance"
  | "security"
  | "platform"
  | "ownership";

export type CheckState = "pass" | "partial" | "fail";
export type ItemReason = "no-owner" | "no-criterion" | "no-evidence" | "missing-evidence";

export interface BaselineItem {
  id: string;
  domain: BaselineDomain;
  /** 判据必须能回答“看什么、算不算过”,不能写“已治理”。 */
  criterion: string;
  /** 能做出发布与退役决定的责任主体;空串表示无人负责。 */
  owner: string;
  /** 判据要求的证据 id;一条判据可以对应多份证据。 */
  requiredEvidence: readonly string[];
  /** 当前已经拿到的证据 id。 */
  evidence: readonly string[];
  /** true 表示未通过就否决任何放量;false 只进入条件清单。 */
  blocking: boolean;
}

export interface ItemJudgement {
  id: string;
  state: CheckState;
  reason?: ItemReason;
  missingEvidence: string[];
}

/**
 * 单条判定只回答三件事:有没有人负责、判据是否可查、证据是否齐。
 * 判定不读外部系统,输入什么就判什么,保证同一快照每次结论一致。
 */
export function judgeItem(item: BaselineItem): ItemJudgement {
  if (item.owner.trim() === "") {
    return { id: item.id, state: "fail", reason: "no-owner", missingEvidence: [...item.requiredEvidence] };
  }
  if (item.requiredEvidence.length === 0) {
    return { id: item.id, state: "fail", reason: "no-criterion", missingEvidence: [] };
  }
  const present = new Set(item.evidence);
  const missing = item.requiredEvidence.filter((id) => !present.has(id));
  if (missing.length === item.requiredEvidence.length) {
    return { id: item.id, state: "fail", reason: "no-evidence", missingEvidence: missing };
  }
  if (missing.length > 0) {
    return { id: item.id, state: "partial", reason: "missing-evidence", missingEvidence: missing };
  }
  return { id: item.id, state: "pass", missingEvidence: [] };
}

export type BaselineConclusion = "pass" | "conditional" | "blocked";

export interface BaselineResult {
  total: number;
  passed: number;
  partial: number;
  failed: number;
  blockingFailures: string[];
  conditions: string[];
  conclusion: BaselineConclusion;
}

/**
 * 总体结论按两道闸门:先看 blocking 项是否全过,再看是否存在非 blocking 缺口。
 * “conditional”不是模糊地带,它带一份必须关闭的条件清单。
 */
export function evaluateBaseline(items: readonly BaselineItem[]): BaselineResult {
  const seen = new Set<string>();
  for (const item of items) {
    if (seen.has(item.id)) throw new Error(`baseline: duplicate item ${item.id}`);
    seen.add(item.id);
  }
  const judged = items.map((item) => ({ item, judgement: judgeItem(item) }));
  const passed = judged.filter((entry) => entry.judgement.state === "pass").length;
  const partial = judged.filter((entry) => entry.judgement.state === "partial").length;
  const failed = judged.filter((entry) => entry.judgement.state === "fail").length;
  const blockingFailures = judged
    .filter((entry) => entry.item.blocking && entry.judgement.state !== "pass")
    .map((entry) => entry.item.id);
  const conditions = judged
    .filter((entry) => entry.judgement.state !== "pass")
    .map((entry) => entry.item.id);
  const conclusion: BaselineConclusion =
    blockingFailures.length > 0 ? "blocked" : conditions.length > 0 ? "conditional" : "pass";
  return { total: items.length, passed, partial, failed, blockingFailures, conditions, conclusion };
}

/** 回声 2026 年 11 月的基线快照,示例数据,不是生产实测。 */
export const ECHO_BASELINE: readonly BaselineItem[] = [
  {
    id: "objects.snapshot",
    domain: "objects",
    criterion: "能力、调用方、租户、版本四类对象可导出唯一 id 与归属",
    owner: "platform-governance",
    requiredEvidence: ["snapshot-2026-11"],
    evidence: ["snapshot-2026-11"],
    blocking: true,
  },
  {
    id: "catalog.fields",
    domain: "catalog",
    criterion: "在役能力目录含契约、默认档位、可覆盖参数、SLA 与退役日期",
    owner: "platform-catalog",
    requiredEvidence: ["catalog-2026-11"],
    evidence: ["catalog-2026-11"],
    blocking: true,
  },
  {
    id: "versions.matrix",
    domain: "versions",
    criterion: "契约、模型、提示三条版本线与弃用窗口可查",
    owner: "platform-release",
    requiredEvidence: ["version-matrix-2026-11", "deprecation-window"],
    evidence: ["version-matrix-2026-11", "deprecation-window"],
    blocking: true,
  },
  {
    id: "quota.three-tier",
    domain: "quota",
    criterion: "租户总额、团队份额、单次上限三层账本可对账",
    owner: "finance-platform",
    requiredEvidence: ["quota-ledger-2026-10"],
    evidence: ["quota-ledger-2026-10"],
    blocking: true,
  },
  {
    id: "evaluation.gate",
    domain: "evaluation",
    criterion: "跨团队评测集标注来源、隐私级别、有效期与责任人,回归门禁可复跑",
    owner: "eval-platform",
    requiredEvidence: ["eval-corpus-index", "privacy-labels", "regression-run-2026-11"],
    evidence: ["eval-corpus-index", "regression-run-2026-11"],
    blocking: false,
  },
  {
    id: "quality.ops",
    domain: "quality",
    criterion: "抽检比例、事故分级与季度复盘有执行记录",
    owner: "quality-ops",
    requiredEvidence: ["quality-review-2026-q3"],
    evidence: ["quality-review-2026-q3"],
    blocking: false,
  },
  {
    id: "cost.chargeback",
    domain: "cost",
    criterion: "成本分摊与月度对账统一用整数微元并写明分母",
    owner: "finance-platform",
    requiredEvidence: ["chargeback-2026-10"],
    evidence: ["chargeback-2026-10"],
    blocking: true,
  },
  {
    id: "compliance.retention",
    domain: "compliance",
    criterion: "数据分级、留存、删除与供应商通知有演练记录",
    owner: "compliance",
    requiredEvidence: ["retention-policy", "deletion-drill"],
    evidence: ["retention-policy"],
    blocking: false,
  },
  {
    id: "security.risk",
    domain: "security",
    criterion: "风险登记、红队与漏洞披露均有最近一次记录",
    owner: "security",
    requiredEvidence: ["risk-register-2026-10"],
    evidence: ["risk-register-2026-10"],
    blocking: true,
  },
  {
    id: "platform.self-service",
    domain: "platform",
    criterion: "平台 SLO、自助边界与升级通道写入对外文档",
    owner: "platform-eng",
    requiredEvidence: ["platform-slo", "self-service-boundary"],
    evidence: ["platform-slo", "self-service-boundary"],
    blocking: true,
  },
  {
    id: "ownership.active",
    domain: "ownership",
    criterion: "每个在役能力都有能决定发布与退役的 owner",
    owner: "platform-governance",
    requiredEvidence: ["ownership-map-2026-11"],
    evidence: ["ownership-map-2026-11"],
    blocking: true,
  },
  {
    id: "ownership.retired",
    domain: "ownership",
    criterion: "已退役能力有依赖清单与迁移完成签字",
    owner: "",
    requiredEvidence: ["retirement-list", "migration-signoff"],
    evidence: ["retirement-list"],
    blocking: false,
  },
];

示例样本上的运行结果

用回声 2026 年 11 月的示例快照运行 node --test test/gov/baseline.test.ts,基线结果是 9 条通过、2 条部分通过、1 条失败,总体结论 conditional,blockingFailures 为空。

三个缺口分别是:

条目状态原因缺什么
evaluation.gatepartial证据不全缺隐私级别标注 privacy-labels
compliance.retentionpartial证据不全缺删除演练 deletion-drill
ownership.retiredfail无人负责owner 为空,且缺迁移签字

这三条都被标成非 blocking,所以结论不是 blocked。但这不意味着可以直接全量:按 13.2 的评审规则,conditional 最多允许 10% 试点,两个 blocking 待办关闭后才能重新评审全量。

样本里的 blocking 项全部通过,说明最低门槛已经具备:四类对象有快照,目录字段完整,版本矩阵与弃用窗口可查,三层配额可对账,成本对账口径一致,安全记录在最近一个月内,平台 SLO 与自助边界有文档,在役能力都有 owner。

blocking 与 advisory 分开

如果所有条目都 blocking,基线几乎永远无法通过;如果一条都不 blocking,基线就失去否决能力。划分标准是「缺口是否会直接把风险转嫁给调用方或租户」。

适合 blocking 的有五类:对象与归属、对外契约与版本、配额账本、成本对账、安全与平台 SLO。它们出问题时,调用方无法在自己的链路里补救。例如目录里没有退役日期,调用方就不知道什么时候必须迁移;配额账本对不上,季度结算一定会争议。

适合 advisory 的有四类:评测语料标注、质量复盘记录、合规演练、退役签字。它们重要,但可以在试点期间补齐,且补齐过程本身可以被监控。把它们设成 blocking,会让团队为了开会而补文档,而不是为了降低风险。

blocking 与 advisory 不是永久标签。一次事故之后,原本 advisory 的条目可以被提升为 blocking;连续四个季度稳定后,也可以降级。调整必须走评审,不能由条目 owner 自己改,否则基线会被逐渐调松。

基线怎么维护

基线本身也要版本化。建议每个季度冻结一版,记录条目增删、blocking 调整与证据有效期。证据不是永久的:一份 2025 年的风险登记不能证明 2026 年的安全状态,过期证据应当回到 no-evidence。

维护动作只有三类:新增条目、调整 blocking、更换责任人。新增条目要说明它补的是哪个已发生或可预见的风险;调整 blocking 要说明为什么当前门槛过高或过低;更换责任人要同时更新 owner 映射,不能只改表里的名字。

基线还要能回答「如果今天放量,最坏会缺什么」。做法很简单:把 conditions 按 blocking 排序,再看每条缺口的补齐日期。如果 blocking 缺口没有日期,结论就不应该是 conditional,而应该是 blocked。

小结

治理基线把前十二章压成 12 条可勾选判据,每条都有责任人、所需证据与 blocking 标记。单条判定按「责任人、判据、证据」三步执行,总体结论分 pass、conditional、blocked 三档。回声示例快照的结果是 9 通过、2 部分、1 失败,结论 conditional,三个缺口都进入条件清单。

基线的作用不是证明治理做完,而是让放量评审有一个共同事实。下一节用这份基线开一次跨团队评审,看它如何把「能不能放量」变成可执行的决议与待办。

阅读导航:上一节:12.3 治理的度量:不是流程数量 · 下一节:13.2 一次跨团队治理评审 。

常见错误与边界

  • 把基线做成制度目录。文件存在不等于机制生效,必须有最近一次执行证据。
  • 所有条目都设成 blocking。基线会永远 blocked,团队很快学会绕过它。
  • 所有条目都不设 blocking。基线退化成建议清单,无法否决任何放量。
  • 判据写成「治理到位」「基本完善」。这类词无法复核,也无法验收。
  • 证据只写文件名。文件名不能证明内容有效,至少要写报告编号与日期。
  • owner 写部门名而不是能做出决定的人。部门名看起来完整,决策仍然悬空。
  • 证据永久有效。风险登记、演练记录与评测集都有有效期,过期应回到未通过。
  • 用通过率代替结论。90% 通过可能是 9 条 advisory 加 1 条 blocking 失败,结论仍是 blocked。
  • conditional 不带条件清单。没有缺口、责任人与日期的 conditional 只是口头承诺。
  • 基线由平台单方面维护。没有业务与合规参与,条目会逐渐脱离真实风险。
  • 把基线当成一次性项目。组织、模型与租户都会变,基线必须按季度重新冻结。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「books」更多文章

  1. 《互联网产品的 AI 架构·平台化与治理》附录 C 平台化评审清单
  2. 《互联网产品的 AI 架构·平台化与治理》附录 B 能力目录与配额字段速查
  3. 《互联网产品的 AI 架构·平台化与治理》附录 A 治理角色与职责速查