开篇：从"读文档"到"产物到达"
《规则消费》篇展开了语义令牌、语义域、约束显化在工程工作面上的投影：语义令牌是你代码里的枚举值，语义域是你类型系统里的Props约束，约束显化是你提交时的CI拦截报告。三层设计你都不生产，但你都是它们的终端执行面。
《规则消费》篇还留下了一个分工判断：同一约束在两层各落一次，载体层概率引导，产物层确定拦截。本篇要展开的，是两层各自的"到达通道"：这些产物是怎么到达你的？ 枚举值为什么是最新版？CI规则为什么和上周的契约变更同步？AI生成工具的上下文里为什么会有约束？
这不算一个小问题。传统规范的失效方式，你我都见过：规范文档更新了，发通知，@全员，两个月后抽查，2/5 的产品线还在用旧版，没人撒谎，只是没人看到通知。分发环节的损耗，比编写环节的失真更致命：规则写得再对，到达不了消费端，等于没写。
本篇展开规则到达你的全部通道：编译产物四格式、版本自动同步机制、载体层的契约引用块，以及一条容易被忽略的承重判断，载体本身不承重，载体与信源的关系才承重。
一、YAML 契约：你不读契约，你读编译产物
1.1 角色消费场景：唯一信源与四个出口
关于契约本身，你只需要知道一件事：它是你消费的所有产物的唯一来源。
| 你消费的产物 | 它是什么 | 你怎么用它 |
|---|---|---|
| JSON Schema | 组件Props的类型校验规则 | 挂在构建里，类型错误编译期报出 |
| CI规则 | 代码提交时的语义门禁 | 挂在流水线，违规提交被阻断并附条款定位 |
| Prompt前缀 | 注入生成工具上下文的约束文本 | 由SDK或插件在会话启动时自动注入 |
| Checklist | 设计走查的语义核对清单 | 验收时逐项核对；场景视图另有用法（上下游篇第3章） |
你不需要打开契约原文。契约的7个冻结字段、semantic_tokens 的语义包、immutable_boundaries 的红线，经过编译管线翻译后，以各自最适合的形态到达你的工具链。
读契约原文不会给你任何编译产物里没有的信息，如果给了，说明编译产物失真，那是要反馈的缺陷，不是你该养成的习惯。 这条约定保护的是唯一信源原则：契约库是唯一事实来源，产物是唯一消费界面，中间不允许出现"我看过原文所以我按原文写"的私有通道。
1.2 三道闸对你是透明的，但你受益全部三道
| 防线 | 守什么 | 你的感知 |
|---|---|---|
| 入口防呆 | 契约写不出错——表单生成、字典下拉、必填未全提交按钮灰色 | 无感知 |
| 入库安检 | 错的契约进不了库——5项机器安检，任一不过即退回 | 无感知 |
| 同步对账 | 产物不变质——版本声明对账、手改产物五分钟内告警 | 只在告警时感知 |
三道闸的全部收益你都在享受，全部成本你都不承担。 这就是"轻消费"的完整含义。
📎 关键设计详情：《YAML契约：设计意图的接口定义，编译即规则》；《契约的机器防线：契约不是文档，是机器执行的拦截规则》
二、编译管线：版本自动抵达，你只需要"不锁定旧版"
2.1 角色消费场景：契约变了，你手里的东西怎么知道变了
没有编译管线时，同一套语义靠四个角色各自人工翻译，每个翻译都在损耗：前端把YAML翻成JSON时丢了约束，AI工程师的Prompt和手头的Schema对不上，CI规则版本漂移。同一种约束，四个消费者手里四个样子。
编译管线的承诺是一句话：契约变更 → 自动重编译 → 四种产物同时换版 → 消费端按版本声明对账。
一个已经存在的工程类比：Figma内部那套PM工作流仓库，也是一个父仓库加众人各自的子仓库，每次会话启动时自动检查父仓库有没有新版，几十个人的版本一致性靠一个hook维持，不靠自觉。 父仓库加个人工作区、启动时对账，这套结构已经被日常使用验证可行。本节的版本机制是它的确定执行版：版本关系写在机器可读的声明里，对账由扫描执行，不靠hook的善意。
2.2 三条消费约定里，与你直接相关的两条
约定一：产物必须自动更新，不允许人工复制粘贴旧版本。
这是对你的唯一主动性要求，而且它以"什么都不用做"的形态出现：Schema由包管理或构建插件自动拉取最新版，Prompt前缀由SDK在会话启动时自动注入最新版，引用块由编译管线随契约版本重写。
你要避免的唯一动作，是把某次拿到的产物复制到本地长期使用。 人工复制的产物必然过期，过期的约束等于没有约束，"先用手头这份"的妥协，是同步对账机制的主要拦截对象。
约定二：CI 阻断报告必须能追溯到契约条款编号。详情可见《规则消费》篇第三章约束显化：提交时的那一次拦截。
2.3 （真的发生过吗）人工复制的产物必然过期
某团队AI工程师在接入初期，把Prompt前缀复制进了自己的会话模板。三个月后契约从 v1.0.0 升到 v1.3.0，字典新增了降级文案禁令，他的模板里还是旧版。期间AI生成的告警文案两次触发线上投诉，排查结论是"AI没遵守约束"，实际是约束根本没到场。
问题诊断：
- 语义层：规则本身是对的，错在分发，人工复制的副本与信源断开了同步
- 根因：缺了版本声明与对账机制，过期副本没有任何机制能发现自己过期
- 修复：前缀改为SDK自动注入，会话启动即拉取最新版；存量人工副本由同步对账扫描清除
这个案例说明：三层校验防的是"今天"，版本同步闭环防的是"三个月后"。 消费侧最危险的状态不是"没用规则"，是"用着过期的规则还以为在用新版"。
案例口径：本案例为推演案例，非组织实测记录。来源是工程协作中"人工副本漂移"的反复出现模式，推演到契约消费场景。
2.4 编译产物的输出过程：一次契约升版，四产物同步换版
把"契约变更 → 自动重编译 → 四种产物同时换版"从承诺变成一段可见的过程。以 ERR-001（后果差异未分级）从 v1.2.0 升到 v1.3.0 为例，本次变更只动了一行：degraded 级新增一条 LLM 约束"必须说明预计完全恢复时间"。
第一步，契约变更走评审、合并入库（唯一的规则变更入口）：
# contracts/ERR-001.yaml
- version: "1.2.0"
+ version: "1.3.0"
degraded:
llm_constraints:
- "必须说明哪些功能仍然可用"
+ - "必须说明预计完全恢复时间"
第二步，Git 钩子触发编译管线，四个产物同时换版。每个产物头部的版本声明是对账的锚点：
ERR-001-prompt-v1.3.0.md 头部：source: ERR-001 v1.3.0 · 编译时间 2026-11-08 10:31
ERR-001-schema-v1.3.0.json 头部：source: ERR-001 v1.3.0 · 编译时间 2026-11-08 10:31
ERR-001-checklist-v1.3.0.md 头部：source: ERR-001 v1.3.0 · 编译时间 2026-11-08 10:31
ERR-001-ci-v1.3.0.yml 头部：source: ERR-001 v1.3.0 · 编译时间 2026-11-08 10:31
第三步，消费侧按版本声明对账。你什么都不用做，Schema由构建插件拉取新版，Prompt前缀由SDK在下次会话启动时注入新版，CI规则下次提交生效；同步对账扫描全库引用块的注释头，产出对账结果：
[SYNC] 对账完成 / contract ERR-001
v1.3.0 已发布。消费侧状态：
Schema 构建插件 已拉取 v1.3.0 ✓
Prompt 前缀 SDK 注入中，2 个活跃会话待下次启动 ✓
CI 规则 下次提交生效 ✓
仓库引用块 ×7 3 个已自动重写 / 4 个待同步，告警已发
注意第三步的最后一行： 7个挂载了引用块的仓库，3个已自动重写、4个待同步且告警已发。这就是"到达"的完整含义，不只发出去，还要确认到场；没到场，信号会找到人。
2.5 （一直在工作吗）版本新鲜度的机器保证
| 检查项 | 机制 | 你的动作 |
|---|---|---|
| Schema是否最新版 | 构建插件拉取日志 + 版本声明对账 | 无；过期时收到告警再处理 |
| Prompt前缀注入版本 | SDK上报注入的contract版本 | 无；注入失败时收到告警再处理 |
| 引用块时效 | 同步对账扫描仓库内引用块版本 | 无；被标记时清除手改痕迹、重新拉取 |
| CI规则版本 | 流水线每次执行携带版本号 | 无；阻断报告中可见 |
注意这张表的共同点：你的动作全是"无"。 版本新鲜度由机器保证，你只在收到告警时处理异常。其余时间，机器在跑。
📎 关键设计详情：《编译管线：一份YAML契约，编译出Prompt/Schema/CI规则》；《契约消费追踪双重闭环验证：机器闭环 + 角色闭环》
三、契约引用块：让契约进入 AGENTS.md / CLAUDE.md / Skill
3.1 角色消费场景：你的工作台上还有一类规则载体
前面两章讲的都是编译产物的"标准通道"。但AI编码工具的工作台上，还有一类规则载体不在四格式之内：
- AGENTS.md：仓库根目录的协作约定文件，Codex、Copilot等工具进入仓库时自动读取
- CLAUDE.md：Claude Code的项目记忆文件，每次会话自动加载
- Skill 文件：各类Agent工具的技能包，声明"执行某类任务时遵循什么"
这些文件就是你的工作台。 你的团队大概率已经在用它们写约束："删除按钮必须二次确认""错误提示不要一律用红色"。这些约束有一个共同的结构性失效方式，它们靠模型自觉执行，是概率性的。写在 CLAUDE.md 第37行的"必须二次确认"，模型可能在第三周就"忘了"，而没有任何机制会发现它忘了。
契约引用块就是为这类载体准备的答案。
3.2 它不是第五种编译产物
先划清概念边界，避免一个必然的误读。
编译产物仍然是四种（Prompt前缀 / JSON Schema / Checklist / CI规则），引用块不是第五种。引用块是Prompt前缀的载体形态，同一份编译产物，打进文档级指令载体的文件格式里，附带契约编号与版本声明。
区别在于：
| Prompt前缀（原生形态） | 契约引用块（载体形态） | |
|---|---|---|
| 消费方式 | SDK在会话启动时注入上下文 | 工具读取仓库时随文件加载 |
| 到达时刻 | 每次会话 | 每次进入仓库 |
| 宿主 | AI生成工具的会话 | AGENTS.md / CLAUDE.md / Skill文件 |
| 内容 | 契约编译的完整约束文本 | 契约ID + 版本号 + 注入约束摘要 |
为什么需要摘要而不是全文？ 因为载体文件的上下文预算由工具管理，完整Prompt前缀可能超出载体文件的合理体积；摘要保留"必须/禁止"的边界条款，完整语义包以契约库为准，这正是注释头里 check 字段存在的理由。
3.3 引用块的完整格式解剖
<!-- schema-as-code:contract-ref
contract_id: ERR-001
version: 1.2.0
source: 契约库 · 编译管线自动生成，禁止手改
check: 对账系统按 contract_id + version 校验时效 -->
## 语义约束（契约引用 · ERR-001 错误状态分级）
本仓库的界面生成代码受契约 ERR-001 v1.2.0 约束：
- 错误状态必须按 error_severity 四级表达（fatal / transient / retryable / degraded），
禁止所有错误共用同一种视觉表达；
- fatal 级状态必须以警示级视觉映射表达，文案必须包含"不可恢复"语义，
必须提供恢复路径；禁止以"出了点小问题"等中性或降级文案表达；
- 可恢复类状态（transient / retryable）禁止使用警示级视觉映射，
必须给出恢复预期（等待时长或重试入口）。
完整条款以契约库当前版本为准。本引用块由编译管线随契约版本自动更新，
手改将在同步对账时被标记。
逐部分拆解：
| 组成部分 | 内容 | 作用 |
|---|---|---|
| 注释头 | schema-as-code:contract-ref 标记 + contract_id + version + source + check |
机器可识别的锚点，对账系统据此校验时效；对人不可见，不干扰阅读 |
| 标题 | 契约引用 + 契约名 | 让读文件的人知道这一段是托管内容 |
| 正文 | 注入约束摘要（必须/禁止条款） | 模型实际消费的约束文本，措辞与契约原文严格程度一致 |
| 时效声明 | "以契约库当前版本为准" | 指明信源，防止摘要被当作独立规则 |
两个格式要点：
- 注释头是机器契约，正文是人机共读。 对账系统只认注释头里的
contract_id + version；AI工具只读正文。两部分各司其职，缺一不可，只有正文没有注释头，版本对账无从谈起；只有注释头没有正文，AI读不到约束。 - 摘要的措辞严格程度必须与契约一致。 "禁止"在引用块里不允许写成"建议"，措辞弱化是最隐蔽的分叉，引用块随契约重编译时由机器保证一致，手改是唯一的失真来源，这正是约定一存在的原因。
3.4 为什么注释头是承重的：载体失效没有症状
前面说过，载体层的约束是概率执行，模型大概率遵守，漏网无感。这句话还有下半句：载体层的失效也是概率性的、无症状的。
一份 AGENTS.md 里的约束从某天起不再被遵守，系统不会报错，模型不会道歉，没有任何告警，它安静地失效，直到某个用户撞上一个本该被拦住的错误。
行业对照样本里这个属性清晰可见：那套PM工作流仓库有几十个人在使用，维护者刻意不做使用统计，代价是"哪些skill在被用、哪些已经失效"没有答案，规则的收敛靠定期的集中吐槽大会，而不是任何读数。 这不是批评那个体系，它证明了载体层可以支撑几十人每天使用，它说明的是一个结构事实：没有锚点的载体，失效不可观测。
注释头就是让这个结构事实翻面的装置。
contract_id + version 两行注释，把一段散文约束变成了一条可以被机器对账的记录：版本落后，扫描发现；内容被手改，比对发现；契约退役，反向定位到每一个挂载它的仓库。载体本身依然不承重，AGENTS.md随手可写可换；注释头声明的关系承重，它让"失效"从一种状态变成一种信号。 这就是三级承重标准里"横梁"与"饰面"的分界线：文件是饰面，关系是横梁。
3.5 三种载体的挂载差异
| 载体 | 挂载位置 | 注意事项 |
|---|---|---|
| AGENTS.md | 仓库根目录，文件任意章节（建议置于"项目约定"类章节内） | 多仓库需逐个挂载；monorepo 可在子包目录分别挂载不同契约的引用块 |
| CLAUDE.md | 仓库根目录，同上 | 与团队已有的项目记忆共存，引用块追加即可，不覆盖既有内容 |
| Skill文件 | Skill的指令区（instructions 段） | Skill管"怎么生成"，引用块管"什么不能生成"，引用块追加在Skill指令末尾，成为其不可突破边界 |
用法只有一个动作：把这个块放进对应文件。 之后AI编码工具每次进入这个仓库，上下文中就带着这份契约摘要；契约升版时，编译管线重写引用块，同步对账校验版本，你持有的引用块过期，告警会到达。
3.6 两条约定
约定一：引用块由编译管线生成，禁止手改内容。
要改约束，改契约，走评审。手改引用块在同步对账时被标记为失效——手改的内容与契约库对不上，对账系统会把它当作"来源不明的规则"处理。这条约定与"编译产物禁止手改"是同一条约定在载体层的延伸。
约定二：载体约束是概率执行，契约产物是确定执行。
引用块管的是"生成时往正确的方向偏"，JSON Schema与CI规则管的是"跑偏了必被拦"。两者是同一契约的两层落地，前者不替代后者：
- 引用块在AGENTS.md里写了"fatal 禁止中性文案"，模型大概率遵守，但"大概率"不是"一定"
- 同一约束编译进CI规则，提交时确定拦截，漏网之鱼在这里被接住
文档级指令载体与结构化契约的分工边界，就压在这一句话里：Skill管"怎么生成得更好"，契约管"什么不能生成"；引用块是前者里的契约回声，CI是后者里的最终防线。
3.7 失效场景与告警
| 失效场景 | 机器发现方式 | 你的动作 |
|---|---|---|
| 引用块版本落后于契约库 | 同步对账按注释头 contract_id + version 扫描 | 收到告警，重新拉取 |
| 引用块被手改 | 对账内容与契约摘要不一致 | 清除手改，恢复生成版 |
| 仓库有AI工具但无引用块 | 消费追踪显示该仓库零约束消费 | 接入挂载，一次动作 |
| 契约归档退役 | 对账显示引用的 contract_id 已 deprecated | 按退役指引移除引用块 |
3.8 常见误会
"我直接在 CLAUDE.md 里手写约束，不挂引用块，行不行？"
手写约束是L2层载体的原生用法，本身没有错，它的问题是三个：无版本（契约升了你不知道）、无对账（写错了没人发现）、无信源（与契约库不一致时以谁为准说不清）。引用块不是禁止你写，是给"写"接上信源、版本与对账。你自己团队的补充约定可以继续手写，涉及契约已覆盖的语义边界，用引用块。
"挂了引用块，是不是就不用挂Schema和CI了？"
不是。引用块是概率执行，Schema与CI是确定执行，两者是同一契约的两层落地。只挂引用块，等于只有"引导"没有"拦截"，模型大概率遵守，漏网的部分没有任何机制接住。
"摘要会不会漏掉关键约束？"
摘要由编译管线从契约生成，覆盖全部"必须/禁止"级条款（不可变边界与LLM约束）；细节性内容（完整语义包、视觉映射表）以契约库为准。如果你发现某个生成场景需要更细的约束在引用块里出现，提交消费侧反馈，摘要的详略是编译规则的一部分，可以修订。
"多仓库都要挂，维护成本是不是上去了？"
挂载是一次性动作，之后的更新由编译管线完成。维护成本不在"挂载多少仓库"，在"有没有人绕过"，而绕过由同步对账兜住。
3.9 最小接入：一个仓库，十分钟
- 从契约库取一份已评审通过契约的引用块（如 ERR-001 v1.2.0）；
- 粘贴进仓库根目录的AGENTS.md（或 CLAUDE.md / Skill 指令区）；
- 用该仓库的AI编码工具发起一次相关生成（如"生成一个错误提示组件"），观察输出是否遵守引用块约束；
- 故意反向验证：临时把引用块移除，重跑一次同任务，对比两次输出，确认引用块在起作用。
验收标准：不是"AI从此不犯错"，是"有无引用块的输出差异可复现"。 这一步同时是最小化的A/B验证：B组是视觉惯性，A组是契约约束，差异就是规则的价值。
3.10 （一直在工作吗）引用块的机器保证
| 检查项 | 机制 | 频率 |
|---|---|---|
| 版本时效 | 同步对账扫描注释头 contract_id + version | 契约每次升版后 |
| 内容保真 | 对账比对引用块摘要与契约条款 | 契约每次升版后 |
| 消费存在性 | 消费追踪统计各仓库约束消费状态 | 持续 |
| 退役清理 | 契约 deprecated 时反向定位引用仓库 | 契约退役流程内 |
引用块的全部约定可以收成一句话：它是编译产物，不是文档。 文档靠人维护，产物由管线维护；你对待它的正确方式，和对待 package-lock.json 一样，不读、不改、不手动同步，只消费它带来的确定性。
四、关键决策点：本篇的完整映射
| 决策点 | 本篇场景 | 你的动作 |
|---|---|---|
| 机器不确定时 | 摘要覆盖不到你的细分场景，生成方向存疑 | 提交消费侧反馈，申请摘要详略修订 |
| 机器没见过时 | 团队首次引入某类文档级载体（新工具、新文件形态） | 上报载体形态，等待编译管线支持该载体的引用块格式 |
| 机器发信号时 | 版本对账告警：产物过期 / 引用块被手改 / 契约退役 | 处理异常：拉取最新版、清除手改、按退役指引移除 |
其余时间，机器在跑。
五、回到开篇的问题
为什么产物必须自动更新，不允许人工复制？
因为人工复制的副本与信源断开了同步，而过期的约束等于没有约束。问题从来不是"复制的那一份对不对"，是三个月后没有任何机制能发现它过期了，消费侧最危险的状态不是"没用规则"，是"用着过期的规则还以为在用新版"。
为什么引用块不是第五种编译产物？
因为产物仍然是四种（Prompt前缀 / JSON Schema / Checklist / CI规则），引用块是Prompt前缀的载体形态，同一份编译产物，打进 AGENTS.md / CLAUDE.md / Skill 的文件格式里，附带契约编号与版本声明。说成"第五种"，编译管线的口径就崩了，四格式的维护约定也会跟着松。
为什么注释头是承重的，而载体文件本身不是？
因为载体失效没有症状，AGENTS.md 里的约束从某天起不再被遵守，系统不会报错。注释头里的 contract_id + version 把一段散文约束变成可被机器对账的记录：版本落后，扫描发现；内容被手改，比对发现。文件随手可换，文件与信源的关系必须可核对。
六、结语：到达，是规则生命的另一半
《规则消费》篇回答了"你消费的规则里装着什么"，本篇回答了"它怎么到达你"：
- 编译产物四格式是标准通道，你不读契约，你读产物；
- 版本自动同步是保鲜机制，人工复制的产物必然过期，你的唯一约定是"不锁定旧版"；
- 契约引用块是载体延伸，不是第五种产物，是Prompt前缀打进 AGENTS.md / CLAUDE.md / Skill的形态，概率执行管引导，确定执行管拦截，两层落地，各司其职；
- 注释头是载体层的承重件，它不改变载体的执行性质，但它让载体的失效第一次变得可观测。
传统规范的失效多半不发生在"写错了"，而发生在"到不了"。编译管线与引用块解决的，是规则生命的另一半：不但要被写对，还要一直到达，到达之后还要让自己失效时发出信号。
产物到达之后，你消费它产生的遥测与反馈流向哪里、由谁接住；以及上线之前，怎样让机器按你的检查清单把场景跑一遍，是下一篇的内容。
本文由作者@魏雯，授权发布于平台，未经许可禁止转载。
1920.png.png
