前端与AI工程师：产物的流转，产物从哪来，反馈往哪去，上线前谁在跑场景

规则消费的最后一环，是回答“产物从哪来、反馈往哪去”。本文拆解上游输入契约与下游输出契约，用症状定位表、三类反馈回流和消费遥测，帮你把“反馈进黑洞”的失落感变成可追溯的闭环。你不是规则的读者，而是规则的终端。

《规则消费》篇展开了你消费的规则里装着什么：枚举值、域约束、拦截报告。《产物到达》篇展开了规则以什么形态到达你：四种编译产物、版本自动同步、契约引用块。

有一个体系性问题：这些产物在被你消费之前，从哪里出发？你消费之后产生的东西，拦截记录、误报标注、覆盖缺口，又流向哪里？

这个问题必须回答，因为消费端最常见的失落感是”反馈进了黑洞”：提交了误报标注，石沉大海；上报了场景缺口，没有下文。两周后同一个问题再次出现，你开始怀疑”反馈到底有没有用”。链路的两端都在盲跑，是消费侧最大的信任杀手。

答案是：这不是”谁负责”的问题，是输入输出契约的问题。你的上游有明确的来料标准，你的下游有明确的回流通道，两边都是契约，都不依赖某个具体的人是否自觉。

本篇分两章展开：第 1 章，上游输入契约：产物从哪来，出了问题怎么定位到哪一环；第 2 章，下游输出契约：你产出什么回流、回流被谁接住、接住之后发生什么。

第 1 章：上游输入契约，产物从哪来

1.1 你消费的每一份产物，上游都经过同一条链路

了解这条链路不是为了理解上游的辛苦，是为了定位问题。当你手里的产物出了错，你能判断错在哪一环，这直接决定你的反馈有没有用。

1.2 症状定位表：错了找哪一环

反馈的及格线只有一条：带上现场。 不带现场的反馈，”这个规则有问题””这个校验太烦”，和没有结构化的走查意见一样，无法被消费。症状定位表存在的意义，是让你用最小的描述成本，把问题钉到链路的正确环节上。

1.3 三个翻译动作，你不是其中任何一个的承担者

对照上游的三层翻译动作，你的位置更清晰：

注意你的特殊位置：你是全链路中唯一一个“默认不承担翻译动作”的角色。 这不是被排除在外，是刻意的设计，翻译成本集中在上游，是为了让终端执行面保持轻。你唯一被邀请参与的翻译动作，是可选的第一层：当你在使用产品的过程中发现语义问题，你也可以按 6 字段提交快照，工程师视角的快照往往质量极高，因为你离实现现场最近。

关键设计详情：《编译工作流中的上下游要求》三条准入条款与三个翻译动作的完整定义；《快照的流转》快照一侧的上下游契约。

第 2 章：下游输出契约，你的产出往哪去

2.1 你的三个日常动作

三个动作之后，你在体系里的产出是两类回流数据。

2.2 第一类产出：消费遥测（你无感知）

由工具链自动上报，不需要你做任何事：

这些数据进入消费追踪，回答”这条规则活着吗”。消费追踪四信号中与你直接相关的是前两个：自动更新率（有没有团队在用过期产物）与阻断可追溯率（拦截报告是否都能定位到条款）。

一个反直觉的结论：你的“零拦截”记录可能是坏消息。 一条长期零拦截的规则有两种解释，规则完美，或者规则根本没在场（没挂载、被绕过、产物过期）。消费追踪的存在，就是让这两种状态可区分。你什么都不做，系统就能发现”你的仓库零消费”这个异常。

2.3 第二类产出：消费侧反馈（你唯一的主动动作）

三类反馈，统一标注”消费侧反馈”回到评审队列：

回流的落点是评审队列，但修订的对象从来不是评审标准本身，是规则定义是否完整、约束是否可执行、场景是否被覆盖、分级是否正确。标准恒定，消费侧的不适靠修订规则细节吸收，不靠放松标准。合法的例外通过显式豁免清单处理，不通过放松规则处理。

2.4 反馈之后会发生什么（每一步都有回音）

反馈闭环的最后一环是“产物自己变了”。 你不需要追问”我的反馈处理了没”，如果它被采纳，你工具链里的产物会在下一次对账时换版。产物版本号的变化，就是反馈的回执。

2.5 关键决策点：双向挤压时的消费侧位置

下游最难处理的场景：两个消费者的反馈指向相反方向，AI 工程师反馈”约束太严”，设计师反馈”走查太松”。这类冲突的处理原则是先查分级，再查条款，最后才轮到讨论标准。

对你的含义：当你提交“太严”类反馈时，最有力的论据不是感受，是分布，”这条推荐约束本周在本团队拦截 17 次，其中 15 次是误报”比”太严了”有力得多。拦截日志是你的论据库，反馈时引用它。

真的发生过吗：绕过枚举的代价

某团队前端为赶迭代，把 Schema 中 error_severity 的枚举校验改为 string 类型，”先上线，下周改回来”。三周后该模块新增告警场景，AI 生成的代码使用了字典中不存在的 severity: “urgent”类型校验不再拦截，走查未发现，上线后该告警的视觉映射为空，渲染为基础样式。

问题诊断：

• 语义层：urgent 不是字典已注册项，无任何视觉映射与行动约束背书
• 根因：枚举校验被临时放开，”下周改回来”没有发生，绕过一旦发生，恢复靠自觉
• 修复：恢复枚举校验，存量 urgent 实例按场景归入 retryable 或 fatal，补充映射；同步对账此后覆盖”产物被手改”场景

这个案例说明：绕过枚举省的是两分钟，断的是整条证据链。临时放开没有临时，只有遗忘。

案例口径：本案例为推演案例，非组织实测记录。来源是工程协作中”临时绕过变永久”的反复出现模式，推演到契约消费场景。

一直在工作吗：消费侧的机器保证

最小可行：一个人的项目怎么跑通

不要求组织，不要求基建。一个独立项目，一条契约，走完消费侧全链路：

1. 从《YAML契约的模板》取一份已评审通过的契约（如 ERR-001 错误状态分级契约）；
2. 取其编译产物中的 JSON Schema，挂到项目构建流程，一次动作；
3. 取其契约引用块，放进仓库根目录的 AGENTS.md，一次动作；
4. 触发一次构建与一次 AI 生成，观察：Schema 校验是否报出、生成结果是否受引用块约束；
5. 故意写一处违规（如 fatal 场景用中性文案），观察 CI 拦截报告是否可追溯；
6. 提交一条消费侧反馈（哪怕是演练性质），确认回流通道存在。

验收标准：不是“规则改变了什么”，是“产物挂载成功、版本声明可见、拦截报告可追溯、反馈通道存在”。 这条链路一个人半小时走完，走完即证明消费侧契约自洽。

兼任声明

前端与 AI 工程师在本体系中的全部动作，挂载、看报告、按映射渲染、提交反馈，都是现有工程动作的延伸，不构成任何新职责，更不需要新增编制。消费遥测由工具链自动上报，版本新鲜度由机器保证。投入不随组织规则数量增长而增长：规则从 1 条变 100 条，你的动作不变。

轻消费不是优待，是分工：把语义判断的成本交给上游，把确定性的执行留给机器，把人留在真正需要判断的异常上。

结语：消费端的终点，是治理闭环的起点

三篇连起来，前端与 AI 工程师在体系中的完整位置清晰了：

1. 《规则消费》：你消费的规则里装着什么，令牌是枚举值，域是类型约束，约束显化是拦截报告
2. 《产物到达》：规则以什么形态到达你，四种编译产物 + 契约引用块，版本自动抵达
3. 本篇：产物从哪来、反馈往哪去，上游是三条准入条款守住的来料标准，下游是遥测与反馈两类回流数据

三个关键决策点收束成一句话：误报要标注、缺口要上报、告警要处理，其余时间，机器在跑。

如果读完这三篇你的感受是”我要做的原来这么少”，那正是这套设计存在的证明：消费侧的无感知，是上游所有角色工作的验收标准。

规则在你的代码里被执行，在你的反馈里被修正。你不是规则的读者，是规则的终端。