从十二章回到一张表
卷四用十二章分别讲了治理对象、能力目录、版本矩阵、三层配额、评测平台、质量运营、成本分摊、合规、安全、平台工程、组织责任与演进治理。每一章都给了机制,也给了取舍。但一个准备放量的团队不会带着十二章来开会,他需要一张能当场勾选的表。
这张表就是治理基线。它不是评分卡,不追求把每项做到满分;它是一组准入判据,回答三个问题:这项治理有没有人负责、判据能不能复核、证据是不是已经拿到。三项缺一项,条目就不能算通过。
本节把前十二章压缩成 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.gate | partial | 证据不全 | 缺隐私级别标注 privacy-labels |
| compliance.retention | partial | 证据不全 | 缺删除演练 deletion-drill |
| ownership.retired | fail | 无人负责 | 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 只是口头承诺。
- 基线由平台单方面维护。没有业务与合规参与,条目会逐渐脱离真实风险。
- 把基线当成一次性项目。组织、模型与租户都会变,基线必须按季度重新冻结。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。