开篇：
《规则消费》篇展开了你消费的规则里装着什么：枚举值、域约束、拦截报告。《产物到达》篇展开了规则以什么形态到达你：四种编译产物、版本自动同步、契约引用块。
有一个体系性问题：这些产物在被你消费之前，从哪里出发？你消费之后产生的东西，拦截记录、误报标注、覆盖缺口，又流向哪里？
这个问题必须回答，因为消费端最常见的失落感是"反馈进了黑洞"：提交了误报标注，石沉大海；上报了场景缺口，没有下文。两周后同一个问题再次出现，你开始怀疑"反馈到底有没有用"。链路的两端都在盲跑，是消费侧最大的信任杀手。
答案是：这不是"谁负责"的问题，是输入输出契约的问题。你的上游有明确的来料标准，你的下游有明确的回流通道，两边都是契约，都不依赖某个具体的人是否自觉。
本篇分两章展开：第 1 章，上游输入契约：产物从哪来，出了问题怎么定位到哪一环；第 2 章，下游输出契约：你产出什么回流、回流被谁接住、接住之后发生什么。
第 1 章：上游输入契约，产物从哪来
1.1 你消费的每一份产物，上游都经过同一条链路
6 字段语义快照（任何人提交）
│ 三条准入条款：结构条款 / 语义条款 / 证据条款，不满足即退回
▼
7 字段 YAML 契约（起草 + 评审）
│ 编译前置校验 5 项安检
▼
编译管线 → 四种产物 + 载体引用块
│ 版本声明 + 同步对账
▼
你的工具链 ★ 你在这里
了解这条链路不是为了理解上游的辛苦，是为了定位问题。当你手里的产物出了错，你能判断错在哪一环，这直接决定你的反馈有没有用。
1.2 症状定位表：错了找哪一环
| 症状 | 大概率出问题的环节 | 反馈怎么写 |
|---|---|---|
| 枚举值缺了一个业务上存在的级别 | 语义字典未注册该令牌 | "场景X需要令牌Y，当前字典无注册项" |
| Schema 校验误报频繁 | 契约约束的可执行性不足 | 附上报错的代码片段与场景说明 |
| CI 拦截报告看不懂、找不到条款 | 编译映射规则有遗漏 | 附上阻断报告全文，标注"不可追溯" |
| Prompt前缀注入了但AI仍生成错误语义 | 规则定义的覆盖度不够 | 附上输入、输出、期望三样 |
| 引用块内容与契约不一致 | 载体摘要失真或版本漂移 | 附上引用块与契约条款的差异点 |
反馈的及格线只有一条：带上现场。 不带现场的反馈，"这个规则有问题""这个校验太烦"，和没有结构化的走查意见一样，无法被消费。症状定位表存在的意义，是让你用最小的描述成本，把问题钉到链路的正确环节上。
1.3 三个翻译动作，你不是其中任何一个的承担者
对照上游的三层翻译动作，你的位置更清晰：
| 翻译层级 | 动作（输入→输出） | 承担者 | 与你的关系 |
|---|---|---|---|
| 第一层：直觉→证据 | 把"觉得不对"变成 6 字段语义快照 | 设计师、产品经理、任何人 | 你也可以提交（发现语义问题时），但这不是你的常规职责 |
| 第二层：证据→规则 | 把快照变成 7 字段契约草稿 | 具备翻译能力的协作者 | 你不承担 |
| 第三层：规则→产物 | 契约编译为四种产物与引用块 | 编译管线（机器） | 你是消费者 |
注意你的特殊位置：你是全链路中唯一一个"默认不承担翻译动作"的角色。 这不是被排除在外，是刻意的设计，翻译成本集中在上游，是为了让终端执行面保持轻。你唯一被邀请参与的翻译动作，是可选的第一层：当你在使用产品的过程中发现语义问题，你也可以按 6 字段提交快照，工程师视角的快照往往质量极高，因为你离实现现场最近。
📎 关键设计详情：《编译工作流中的上下游要求》三条准入条款与三个翻译动作的完整定义；《快照的流转》快照一侧的上下游契约。
第 2 章：下游输出契约，你的产出往哪去
2.1 你的三个日常动作
| 动作 | 内容 | 频率 |
|---|---|---|
| 挂载 | Schema 挂构建、CI 规则挂流水线、Prompt 前缀靠 SDK 注入、引用块放进仓库根目录 | 一次性 |
| 看拦截报告 | 被拦时读条款编号与修复指引，按指引修 | 被拦时 |
| 按映射渲染 | 枚举到视觉的映射查映射表，不写死色值、不自造级别 | 日常 |
三个动作之后，你在体系里的产出是两类回流数据。
2.2 第一类产出：消费遥测（你无感知）
由工具链自动上报，不需要你做任何事：
| 遥测项 | 采集什么 | 它回答什么 |
|---|---|---|
| Schema 拉取记录 | 版本号与拉取时间 | 这条契约的 Schema 活着吗 |
| Prompt 前缀注入记录 | 注入次数与版本 | 这条契约被 AI 会话真实使用吗 |
| CI 触发与拦截记录 | 校验次数、阻断次数、条款分布 | 这条规则拦住了什么 |
| 引用块对账结果 | 版本时效、内容一致性 | 载体层的约束在线吗 |
这些数据进入消费追踪，回答"这条规则活着吗"。消费追踪四信号中与你直接相关的是前两个：自动更新率（有没有团队在用过期产物）与阻断可追溯率（拦截报告是否都能定位到条款）。
一个反直觉的结论：你的"零拦截"记录可能是坏消息。 一条长期零拦截的规则有两种解释，规则完美，或者规则根本没在场（没挂载、被绕过、产物过期）。消费追踪的存在，就是让这两种状态可区分。你什么都不做，系统就能发现"你的仓库零消费"这个异常。
2.3 第二类产出：消费侧反馈（你唯一的主动动作）
三类反馈，统一标注"消费侧反馈"回到评审队列：
| 反馈类型 | 触发时机 | 必带内容 |
|---|---|---|
| 误报标注 | CI 拦截疑似误报 | 拦截报告全文 + 场景说明 + 你认为合法的理由 |
| 覆盖缺口 | 新场景无对应域定义/令牌/类型 | 场景描述 + 当前兜底方式 |
| 产物失真 | 编译产物与契约条款不一致 | 产物内容 + 契约条款 + 差异点 |
回流的落点是评审队列，但修订的对象从来不是评审标准本身，是规则定义是否完整、约束是否可执行、场景是否被覆盖、分级是否正确。标准恒定，消费侧的不适靠修订规则细节吸收，不靠放松标准。合法的例外通过显式豁免清单处理，不通过放松规则处理。
2.4 反馈之后会发生什么（每一步都有回音）
| 时点 | 你会看到什么 |
|---|---|
| 提交后 | 反馈进入评审队列，标注"消费侧" |
| 评审后 | 判定结果对你可见：误报成立（修编译规则）/ 覆盖缺口成立（排入契约修订）/ 标准维持（理由） |
| 修订后 | 契约升版，编译产物自动换版到达你的工具链，你的反馈以"产物更新"的形态闭环 |
反馈闭环的最后一环是"产物自己变了"。 你不需要追问"我的反馈处理了没"，如果它被采纳，你工具链里的产物会在下一次对账时换版。产物版本号的变化，就是反馈的回执。
2.5 关键决策点：双向挤压时的消费侧位置
下游最难处理的场景：两个消费者的反馈指向相反方向，AI 工程师反馈"约束太严"，设计师反馈"走查太松"。这类冲突的处理原则是先查分级，再查条款，最后才轮到讨论标准。
对你的含义：当你提交"太严"类反馈时，最有力的论据不是感受，是分布，"这条推荐约束本周在本团队拦截 17 次，其中 15 次是误报"比"太严了"有力得多。拦截日志是你的论据库，反馈时引用它。
真的发生过吗：绕过枚举的代价
某团队前端为赶迭代，把 Schema 中 error_severity 的枚举校验改为 string 类型，"先上线，下周改回来"。三周后该模块新增告警场景，AI 生成的代码使用了字典中不存在的 severity: "urgent"类型校验不再拦截，走查未发现，上线后该告警的视觉映射为空，渲染为基础样式。
问题诊断：
- 语义层：
urgent不是字典已注册项，无任何视觉映射与行动约束背书 - 根因：枚举校验被临时放开，"下周改回来"没有发生，绕过一旦发生，恢复靠自觉
- 修复：恢复枚举校验，存量
urgent实例按场景归入 retryable 或 fatal，补充映射；同步对账此后覆盖"产物被手改"场景
这个案例说明：绕过枚举省的是两分钟，断的是整条证据链。临时放开没有临时，只有遗忘。
案例口径：本案例为推演案例，非组织实测记录。来源是工程协作中"临时绕过变永久"的反复出现模式，推演到契约消费场景。
一直在工作吗：消费侧的机器保证
| 检查项 | 机制 | 你的感知 |
|---|---|---|
| 反馈是否被消费 | 评审队列状态可见 | 提交后可见处理状态 |
| 修订是否到达 | 产物版本随对账换版 | 版本号变化即回执 |
| 你的仓库是否零消费 | 消费追踪自动标记 | 被标记时收到提醒 |
| 产物是否被手改 | 同步对账扫描 | 五分钟内告警 |
最小可行：一个人的项目怎么跑通
不要求组织，不要求基建。一个独立项目，一条契约，走完消费侧全链路：
- 从《YAML契约的模板》取一份已评审通过的契约（如 ERR-001 错误状态分级契约）；
- 取其编译产物中的 JSON Schema，挂到项目构建流程，一次动作；
- 取其契约引用块，放进仓库根目录的 AGENTS.md，一次动作；
- 触发一次构建与一次 AI 生成，观察：Schema 校验是否报出、生成结果是否受引用块约束；
- 故意写一处违规（如 fatal 场景用中性文案），观察 CI 拦截报告是否可追溯；
- 提交一条消费侧反馈（哪怕是演练性质），确认回流通道存在。
验收标准：不是"规则改变了什么"，是"产物挂载成功、版本声明可见、拦截报告可追溯、反馈通道存在"。 这条链路一个人半小时走完，走完即证明消费侧契约自洽。
兼任声明
前端与 AI 工程师在本体系中的全部动作，挂载、看报告、按映射渲染、提交反馈，都是现有工程动作的延伸，不构成任何新职责，更不需要新增编制。消费遥测由工具链自动上报，版本新鲜度由机器保证。投入不随组织规则数量增长而增长：规则从 1 条变 100 条，你的动作不变。
轻消费不是优待，是分工：把语义判断的成本交给上游，把确定性的执行留给机器，把人留在真正需要判断的异常上。
结语：消费端的终点，是治理闭环的起点
三篇连起来，前端与 AI 工程师在体系中的完整位置清晰了：
- 《规则消费》 ：你消费的规则里装着什么，令牌是枚举值，域是类型约束，约束显化是拦截报告
- 《产物到达》 ：规则以什么形态到达你，四种编译产物 + 契约引用块，版本自动抵达
- 本篇：产物从哪来、反馈往哪去，上游是三条准入条款守住的来料标准，下游是遥测与反馈两类回流数据
三个关键决策点收束成一句话：误报要标注、缺口要上报、告警要处理，其余时间，机器在跑。
如果读完这三篇你的感受是"我要做的原来这么少"，那正是这套设计存在的证明：消费侧的无感知，是上游所有角色工作的验收标准。
规则在你的代码里被执行，在你的反馈里被修正。你不是规则的读者，是规则的终端。
1920.png.png
