开篇：一个没有回答的问题
我在《语义生长：从管"长什么样"到管"意味着什么"》篇中展开讲了设计系统负责人在语义令牌定义、语义域划分、约束显化规则中的评审职责。文中的评审对象是**"语义定义"**，一份关于"这个场景下必须表达什么语义"的判断。
《编译确认：从"规则被写下"到"规则被正确翻译"》篇则是针对设计系统负责人在YAML契约评审、编译产物确认中的确认职责展开。文中的确认对象是**"语义编码"，一份关于"人定义的语义是否被机器正确理解"的保真检查**。
两篇下来悬出一个问题：
《语义生长》篇评审的语义定义，是谁翻译成机器可读形态的？ 《编译确认》篇评审的YAML契约，是谁写的？文中确认通过的四种编译产物，评审之后交给了谁？
如果答案是"由某个专门岗位负责"，那这个角色篇系列就需要再写一篇"生产者"的长文，但这就落回了专人专岗的思路。但这不是 Schema-As-Code把设计规范写成代码格式 的生长原则。
如果答案是"由设计系统负责人自己包办"，那又与《编译确认》篇明确声明的边界矛盾，"这不是替谁写契约，也不是替工程团队做编译"。
正确的答案：是"输入输出契约"的问题。
设计系统负责人在工作流中的位置，不是流水线上的一个工位，而是上下游节点之间的"契约恒定执行者"：上游任何人在任何节点提交的任何输入，只要进入这条链路，就必须满足同一份输入契约；下游任何人以任何方式消费任何产物，都必须沿着同一条反馈路径回流。本篇展开的就是这两份契约的内容。
全篇第1章展开上游输入契约 （三个翻译动作、三条准入条款、退回机制），第2章展开下游输出契约 （四种产物的消费者、三条消费约定、反馈回流机制），第3章展开这套契约的最小可行生长路径。
第 1 章：上游输入契约，什么样的输入，才进入评审
1.1 上游是三个翻译动作
设计系统负责人上游存在的是三个翻译动作，每个动作都有明确的输入、输出和及格线，至于动作由谁完成，取决于组织处在哪个生长阶段。
| 翻译层级 | 动作（输入→输出） | 可能由谁完成 | 评审什么 |
|---|---|---|---|
| 第一层： 直觉→证据 | 把"我觉得不对"变成6字段语义快照（产品/组件类型/界面证据/用户困惑点/出现场景） | 设计师、产品经理、前端、任何人，包括设计系统负责人自己 | 格式完整性+至少1个真实产品实例 |
| 第二层： 证据→规则 | 把语义快照变成7字段YAML契约草稿 | 具备翻译能力的协作者，组织初期通常是设计系统负责人自己 | 7字段完整性+只引用字典已注册项+无自创语义 |
| 第三层： 规则→产物 | 把YAML契约编译成四种消费格式（Prompt前缀/JSON Schema/Checklist/CI规则） | 编译管线（机器） | 抽样语义一致性 |
三个层级对应的翻译能力，我在前文已有完整拆解：能力宣言篇讲翻译本质，操作日常篇讲日常动作，规则流转篇讲一条规则要经过的每一站。
注意这张表的一个关键设计，第三层（规则→产物）在表格里，但不在"上游"里。 因为第三层由机器完成，机器的输入输出契约由编译管线和编译前置校验恒定执行，不需要设计系统负责人逐次评审。设计系统负责人的上游要求，实际只对前两个层级生效，这两个层级是"人"的动作，人需要及格线。
1.2 翻译能力的归属基于工作流节点
这是本篇最重要的一个判断值得单独展开。
组织初期，三个翻译层级可能全部由设计系统负责人自己完成：自己记录快照、自己写契约草稿、机器编译、自己评审。同一个人走完所有节点，但节点之间的输入输出契约一个不少。 快照仍然要满足6字段，契约仍然要满足7字段，引用仍然必须是字典已注册项，不会因为"反正都是我一个人"就降低任何一站的标准。
这不是效率问题是标准问题 。当组织生长，快照开始由设计师提交、契约草稿开始由协作的任何人起草时，每个节点的验收标准早已存在。设计系统负责人需要做的，是把"评审我自己"换成"评审他们提交的输入"，标准一字不改。
这就是翻译能力的生长性：它不限于任何岗位描述，而是基于工作流上每个节点的输入契约。 谁在那个节点，谁就暂时承担这段动作；但动作的及格线，由评审这一站恒定执行。
组织将"翻译能力"赋予每一个岗位：任何一个带着问题直觉进入这条链路的人，都能在入口处拿到同一份格式要求；任何一个提交契约草稿的人，都能在评审前就知道三条准入条款。
1.3 三条准入条款：格式、语义、证据
上游输入进入评审队列之前，必须满足三条准入条款。任何一条不满足，退回，不评审。
条款一：结构条款（机器可读是入场券不是加分项）
语义快照必须包含全部6个字段，YAML契约必须包含全部7个字段。 这个要求听起来像是在卡格式，实际是卡**"翻译是否发生"**。
一份写着"删除按钮的红色不够醒目"的走查意见，无论多么正确，都不是翻译，它没有把直觉变成机器可读的证据。6字段快照要求记录产品、组件类型、界面证据、用户困惑点、出现场景，就是在强迫提交者完成**"直觉 → 证据"**这一跳。
结构预检由机器在提交瞬间完成。机器拦不住的，是格式合规但内容空洞的输入，这正是评审存在的意义。
条款二：语义条款（只引用字典已注册项禁止自创）
契约草稿中的每一个覆盖层、每一个语义绑定、每一个场景映射，必须引用语义字典中已注册的项。 这个要求的联邦意义在《语义生长》篇已经展开过：字典是组织级唯一信源，允许团队自创语义，就是允许组织回到"每个团队一套术语"的碎片化状态。
**这道闸机器查一半，人查另一半。**引用未注册项，机器在提交瞬间直接阻断。但有一种自创机器查不出：给已注册项赋予字典中没有的含义 ，比如把 status.warning 用在资金冻结场景，论证"这个状态对我们团队来说就是警告级别"。引用合法，机器放行。
这是设计系统负责人评审的核心地带：判断这个挪用是"合法场景扩展" （批准，并要求补充场景映射注册），还是"绕开字典的自定义"（退回，并要求先走令牌评审流程）。
条款三：证据条款（至少关联1个真实产品实例）
这条准入条款最容易被忽视，也最能区分"治理"和"想象"。 一份契约定义，必须至少关联一个真实产品的真实界面实例，一张截图、一条用户投诉、一段走查记录。不允许为"想象中可能出现的需求"定义语义。
**这条准入条款来自语义漂移研究的基本前提：**语义断层是观察出来的，不是推理出来的。规则来源于证据网，而不是来源于某个人觉得"我们应该也需要一条这样的规则"。证据条款把"需求"和"漂移"区分开：前者是产品规划语言，后者是治理对象的入场券。治理只处理已经被观察到的语义漂移，不为想象中的世界立法。
1.4 退回不是拒绝：翻译能力的把关动作
上游输入不满足三条准入条款时，设计系统负责人的动作是退回，不是否决，更不是代写。退回时必须说明缺什么。三类退回的标准话术：
- 格式退回： "快照缺少
user_confusion字段，无法判断用户困惑的具体指向。补齐后重新提交。" - 语义退回： "
status.alert不是字典已注册项。请判断该场景应复用status.warning（并提交场景映射注册申请），还是应新增令牌（走令牌评审流程）。" - 证据退回："该契约未关联任何产品实例。请补充至少1个真实界面证据，或说明该需求与已归档漂移模式（如 ERR-001错误状态诊断）的关系。"
退回记录本身有独立价值： 它构成组织内的**"翻译能力错题本"**。
连续三次因同一字段被退回的快照提交者，说明入口处的格式说明需要改写；连续出现语义挪用的团队，说明该团队的场景理解需要一次对齐讨论。设计系统负责人通过退回记录的聚类分析，把"个体错误"升级为"入口契约的改进信号"，这是上游要求持续进化的机制，不是一套静态的死规矩。
1.5 关键决策点：机器不确定时，多义性抉择的留痕原则
上游评审中，机器预检全部通过、但语义编码存在多义性的场景，是设计系统负责人的关键决策点。
场景示例： 一份契约草稿为"限流提示"（Retryable 级别）设计了两种 user_action 方案。方案 A 只提供"等待倒计时"，方案 B 提供"等待倒计时 + 升级套餐"。两种方案格式都合规、引用的令牌都已注册、都有真实产品实例支撑。机器无法判断哪个方案更符合组织当前的业务策略，这是设计系统负责人基于业务理解做出的判断。 这个判断一旦发生，就成为同类场景的未来参照，下次再出现多方案抉择时，可以对照本次的判断逻辑，而不是重新争论。
多义性决策的一个纪律：判断结论必须附带理由，并写入评审记录。 因为这类决策的本质是"把业务策略翻译成规则偏好"，理由不记录下来，下次组织换人或策略调整时，规则就变成了没有出处的黑箱。
1.6 校准依据：两类典型的输入失真
以下两个案例，是三条准入条款的真实校准来源。它们说明准入条款不是文档里的规定，而是被真实输入反复考验后沉淀下来的判别标准。
案例口径：以下案例为推演案例，非组织实测记录。来源是公开产品语义断层诊断中反复出现的失真模式，推演到组织工作流的输入形态。团队与产品为合成场景，但每一类失真都能在公开界面截图中找到原始样本。
案例一：格式合规但证据空洞的快照
某团队提交了一份完整的6字段快照，指向后台管理系统的"批量操作失败提示"。所有字段齐全，
user_confusion字段写着"用户不知道操作是否成功"。
评审时追问证据来源，提交者承认： 这是他在评审设计稿时"觉得可能会让用户困惑"的推测，实际产品上该提示是内部测试环境的边缘场景，没有真实用户接触过。
处理：证据退回。 该快照描述的是推测性困惑，不是观察到的困惑。治理资源有限，优先处理已观察到的语义漂移。建议上线收集真实反馈后，再视情况提交。
这个案例的教训：结构条款可以机器检查，证据条款只能人工追问。 这也是为什么上游评审不能只依赖自动化预检。
案例二：合法引用掩盖的语义挪用
某金融业务团队提交契约，在"理财产品到期提醒"场景绑定了
status.info（信息级别），同时在llm_constraints中写明"文案必须包含'本金可能受损'的警告"。
机器预检通过：引用合法、字段完整。 但评审发现语义冲突：status.info 的定义是"中性信息，无风险含义"，约束却要求携带风险警告，用合法令牌做语义挪用，实质上需要一个介于info与warning之间的状态。
处理：语义退回，附两个选项。 选项一，按"中性信息附带风险提示"拆分处理；选项二，若到期未赎回对本金有实质影响，升级绑定至 status.warning 并重新核对场景映射。团队选择选项二，评审通过。
这个案例的教训：语义条款的难点不在"引用是否存在"，在"引用的含义是否被忠实使用"。 这是评审这一站不可替代的原因。
1.7 机器执行面：三道预检与人工介入边界
上游输入的把关由三道预检构成，机器执行两道，人执行一道：
| 预检 | 执行者 | 检查内容 | 拦截时机 |
|---|---|---|---|
| 格式预检 | 机器（提交瞬间） | 快照6字段/契约7字段完整性，YAML语法合法性 | 提交即出结果，不过不入队 |
| 引用预检 | 机器（提交瞬间） | 覆盖层存在性、绑定存在性、场景一致性 | 提交即出结果，不过即阻断 |
| 证据与语义预检 | 人（评审时） | 至少1个真实产品实例、引用含义忠实度、多义性判断 | 进入评审队列后处理 |
前两道预检的通过率本身就是度量信号： 格式预检频繁失败的团队，说明入口说明对它不可读；引用预检频繁失败的团队，说明它对字典的理解需要培训。每月看一次通过率分布，就把**"上游质量"从感觉变成了数据**。
第 2 章：下游输出契约，产物给谁用，反馈怎么回来
2.1 四种产物 & 四个消费者 & 一条回流路径
《编译确认》篇确认了编译产物包含四种格式。本章要明确的是：这四种格式从评审队列放行之后，各自流向不同的消费者，进入不同的工作流，产生不同的消费反馈。
先说共同的回流路径：四种产物的消费问题，统一标注"消费侧反馈"回到评审队列。 设计系统负责人对下游的要求，本质上是规定好两件事：产物到手之后怎么用，以及用出问题之后修订什么。
| 产物 | 消费者 | 消费方式 | 消费侧常见问题 | 回流后修订对象 |
|---|---|---|---|---|
| Prompt前缀 | AI工程师 | 注入AI编程工具的 system message，约束AI生成 | AI仍生成错误语义，或生成内容被过度约束影响可用性 | **规则定义 **（约束条款的覆盖度） 不是Prompt文案的措辞 |
| JSON Schema | 前端工程师 | 组件Props类型定义，编译期校验 | 校验误报频繁，正常代码被类型系统拒绝 | **约束的可执行性 **（类型表达vs语义表达的差异）不是放宽校验标准 |
| Checklist | 设计师 / DesignOps | 设计稿完成后的逐项语义走查 | 清单与实际场景脱节，走查流于形式 | **契约的场景覆盖度 **（清单项是否对应真实走查动作）不是强推流程 |
| CI规则 | 前端团队 | 代码提交时的自动化拦截 | 阻断影响交付节奏，团队产生绕过动机 | 拦截分级（BLOCK/WARN是否用对场景）不是关闭拦截 |
这张表有一列需要单独强调：回流后的修订对象。
下游反馈到达评审队列时，一个危险的直觉是"下游嫌麻烦，那就放松标准"。
恒定执行的标准恰恰相反：回流的落点是评审队列，但修订的对象从来不是评审标准本身 ，而是标准上游的东西，规则定义是否完整、约束是否可执行、场景是否被覆盖、分级是否正确。一条不可变边界被抱怨"卡得太死"，正确的响应不是降级它，而是检查它的定义是否可执行、是否遗漏了合法的例外场景；例外应通过显式豁免清单处理，而不是放松规则。
这条纪律的联邦意义在于： 评审标准是组织级契约的恒定部分，消费侧的局部不适，通过规则细节的修订来吸收，而不是通过标准松动来吸收。标准一动，全组织的语义一致性就失去了锚点。
2.2 三条消费约定：自动更新、可追溯阻断、清单一一对应
下游的四个消费者活在四种不同的工作习惯里，设计系统负责人对他们的要求收敛为三条约定，每条对应一个工作流的要害。
约定一（对AI工程师）：前缀必须自动更新，不允许人工复制粘贴旧版本
要害只有一句：人工复制的Prompt前缀必然过期，过期的约束等于没有约束。 前缀的更新必须由SDK或插件机制在工具启动时自动完成，不由工程师自觉保证。
约定二（对前端工程师）：CI阻断报告必须能追溯到契约条款ID
要害在于：一份只说"语义校验失败"的阻断报告，会迫使前端工程师猜测规则含义，猜测就会出错。 报告明确写出"违反 action.destructive 的不可变边界第二条：缺少 confirmation_step"，前端才能精准修复。这条约定把"拦截"从惩罚变成了指导。
约定三（对设计师与DesignOps）：清单项必须与契约条款一一对应
设计师走查的工作流要害在于：走查项超出契约，设计师会困惑"按清单改了为什么还被拦截"；走查项少于契约，清单就失去了存在的意义。 对应关系由编译管线自动生成，人对清单的评审只需抽样核对。
2.3 关键决策点：消费侧反馈相互矛盾时，双向挤压的分级诊断
下游要求中最难处理的场景：两个消费者的反馈指向相反方向。
场景示例： AI工程师反馈"Prompt前缀约束太严，文案频繁被BLOCK"；几乎同时，前端工程师反馈"CI拦截太松，上周漏过了一个无二次确认的删除按钮"。
两个反馈都回到评审队列。判断流程只有三步：验证真实性 （调出BLOCK与放行记录，确认两边说的都属实）→ 判断是否同一条规则 （通常是AI侧被卡的是推荐约束，前端侧漏放的是不可变边界，两者本就不是同一严格程度，问题出在分级标注错位）→ 修订分级 （高频误伤的推荐约束降级为生成建议，漏放暴露的不可变边界补上CI检查项）。两个反馈都通过分级修订吸收，标准本身不动。
这类"双向挤压"场景的通用处理原则：消费侧反馈的冲突，几乎都是分级问题的信号，而不是标准问题的信号。 先查分级，再查条款，最后才轮到讨论标准。
2.4 校准依据：两次由反馈驱动的规则修订
以下两个案例，是下游契约的真实校准来源。它们说明回流纪律不是想象中的流程，而是被真实消费问题反复验证过的修订路径。
案例口径：与1.6相同，以下案例为推演案例，基于"如果这套上下游契约有真实团队接入，反馈最可能以什么形态出现"的假设推演。修订路径经过编译管线机制验证，触发案例的团队事件为合成场景。
案例一：CI误报聚类暴露的"类型表达陷阱"
前端团队连续反馈： JSON Schema频繁误报，正常编写的表单组件被类型系统拒绝。根查发现：契约
user_action的本意是"致命错误应提供恢复路径，桌面端两个、移动端可只提供一个"，但Schema编译把这个"应提供"变成了"必须全量"，移动端只实现了一个动作，全量编译失败。
这是语义意图与类型表达之间的翻译失真 ，和《编译确认》篇"契约语义失真"案例同构，只是失真发生在编译层而非编写层。
修订：约束改写为分层表达 ，声明各端差异，Schema编译规则同步增加上下文条件。修订后CI误报归零，而约束的语义本意没有放松一分钱。
教训：下游反馈的价值不在"抱怨"，在"抱怨的聚类位置"。 误报集中在同一字段，指向的是编译映射规则，不是契约标准。
案例二：沉默清单暴露的场景覆盖缺口
Checklist的消费追踪显示： 某条契约编译出的走查清单，连续四周"错误状态分级核对"整组检查项零勾选，不是没有走查，是设计师主动跳过了。
追问发现：该团队的错误状态走自研组件库，不走标准Alert，清单项描述的标准组件走查动作对它不适用。清单不是没人用，是对这个团队不可执行。
处理： 不动清单的标准项，推动该团队补交自研组件的适配映射。映射注册后，同一契约编译出该团队的专属清单，检查项自动替换为自研组件的对应走查动作。
教训：消费数据的"零"有两种，没人消费，和消费了但不可执行。 区分二者只能靠追问，但发现"哪里在归零"靠的是消费追踪 。这就是坚持"每种产物必须有消费追踪"的原因，不是为了监控人，是为了定位契约与真实工作流的缝隙。
2.5 机器验证面：消费追踪四信号
设计系统负责人对下游提出的所有要求，自动更新、可追溯阻断、清单一一对应、反馈回流，是否被执行，最终由消费追踪数据回答。核心看四个信号：
| 信号 | 数据来源 | 异常时的含义 |
|---|---|---|
| Prompt前缀自动更新率 | SDK拉取日志中"最新版本占比" | 出现大量过期版本拉取 → 有团队在人工复制旧前缀 |
| CI阻断可追溯率 | 阻断报告中附带契约条款ID的比例 | 低于100% → 编译映射规则有遗漏，阻断报告模板需修 |
| Checklist勾选分布 | 各清单项的勾选频次热力图 | 某组检查项集中零勾选 → 存在场景覆盖缺口，触发案例二式的追问 |
| 反馈回流闭环时长 | 消费侧反馈提交到修订发布的平均时长 | 持续拉长 → 评审队列拥堵，需要区分"可机器预检的反馈"与"必须人工判断的反馈"，把前者挡在队列外 |
阶段说明： 四信号的自动化采集与月度审阅，是下游生长阶段之后的配置。一人闭环-上游生长没有追踪系统，对应动作靠手动完成，案例一中的"消费追踪数据确认"，在上游生长阶段就是"翻一翻聊天记录里几次误报反馈"。信号的形式变了，"看聚类、找缝隙"的判断逻辑不变。
四个信号全部由机器自动采集后，设计系统负责人按月审阅分布，而不是逐条盯数据。这也回应了本篇的底层原则：上下游的所有要求，最终都被设计成了"机器可验证的契约"，包括要求本身。
第 3 章：最小可行生长，从走通一条完整链路开始
设计系统负责人承担上下游要求，不需要等任何基础设施齐备。最小可行起点不要求任何协作者，上下游的所有动作可以由同一人完成，但每一站的契约标准完整执行。
3.1 阶段 0：单人闭环
第一周的动作清单：
- 从组织内已存在的规范中找一个Design Token（如错误色），按《语义生长》篇"追问语义"的三问补充第一条语义定义，这是上游第一层动作的雏形。
- 把这条定义写成6字段快照+7字段契约草稿，提交给评审队列，自己写、自己收。
- 跑通编译前置校验，确认四种产物的语义抽样一致性，即《编译确认》篇的确认动作。
- 把Prompt前缀手动发给一位AI工程师同事试用，一周后收集反馈，这是下游的第一次反馈回流，手动完成，没有追踪系统。
一人闭环阶段的里程碑不是"有人消费"，是"整条链路走通，且契约通过编译"。 这个里程碑证明的是工作流标准自洽，上下游的每一份契约在理论上成立。消费是上游生长阶段的事，不需要等待。
3.2 阶段 1：上游长出第一个人
当第一份快照模板和退回说明被写出来（一人闭环阶段的副产品），就可以邀请设计师或产品经理提交第一份由他人完成的语义快照。
生长信号： 第一份他人提交的快照通过格式预检、进入评审队列。设计系统负责人第一次执行"退回"动作（大概率会发生，格式合规但证据不足是最常见的首次错误），并把这次退回写成公开的修订说明。
这个阶段的关键产出不是通过了多少份快照，是"入口契约被外人理解并遵守"的证据。 一份按退回说明补齐后重新提交、并通过评审的快照，就是翻译能力在组织内第一次自然生长的证据。
3.3 阶段 2：下游长出第一个人
当第一份契约通过编译，邀请一位前端工程师在一个组件上消费JSON Schema，或一位AI工程师在Prompt中加载前缀。
生长信号： 第一次消费侧反馈回流。哪怕反馈内容是"这个Schema拦住了我的正常代码"，误报反馈也是有效反馈，它启动了2.4案例一式的问题定位流程。
这个阶段的关键产出是反馈回流的闭环跑通： 消费 → 反馈 → 定位 → 修订 → 重新发布 → 消费者确认。这条闭环一旦跑通一次，下游要求就从"写在文档里的规定"变成了"被验证过的机制"。
3.4 生长路径全景与兼任声明
| 阶段 | 上游状态 | 下游状态 | 核心动作 | 投入 |
|---|---|---|---|---|
| 阶段 0：一人闭环 | 全部自给 | 无消费 | 走通节点、建立模板、写出退回说明 | 每周 2-4 小时 |
| 阶段 1：上游生长 | 他人提交快照与草稿 | 手动分发产物 | 执行退回、维护入口契约、校准格式说明 | 每周 4-8 小时 |
| 阶段 2：下游生长 | 稳定来料 | 首批消费者 + 首批反馈闭环 | 处理消费侧反馈、修订分级与映射规则 | 每周 1-2 人天 |
| 阶段 3：多团队流动 | 多团队来料 | 多团队消费、追踪数据可采 | 按月审阅四信号、主持规则迭代评审 | 投入与规则量成正比 |
兼任声明：一人闭环阶段至下游生长阶段的全部动作，都可以由现有设计系统负责人在本职工作中兼任完成，不需要组织新增任何编制。多团队流动阶段的投入增长与组织内规则数量、消费团队数成正比，是自然生长，不是编制扩张。
结语：我不定义岗位，我定义节点间的契约
本篇补全了承上启下两篇之间的缝隙。三篇连起来，设计系统负责人的完整位置清晰了：
- 《语义生长》篇：在语义定义阶段确认**"这个场景下必须表达什么语义"**，上游是业务场景的语义直觉，产出是评审结论。
- 《编译确认》篇：在语义编码阶段确认**"人定义的语义被机器正确理解"**，上游是契约草稿与编译产物，产出是放行信号。
- 本篇 ：定义上下游的流转契约，上游输入的三条准入条款、下游产物的消费约定与回流纪律，产出是整条链路的可生长性。
三个关键决策点在上下游视角下的完整映射：
| 决策点 | 上游（本篇 · 第 1 章） | 编码（《编译确认》篇） | 下游（本篇 · 第 2 章） |
|---|---|---|---|
| 机器不确定时 | 多方案契约的语义抉择（附理由入档） | 契约编码多义性裁决 | 双向挤压反馈的分级诊断 |
| 机器没见过时 | ---（入口契约已预先覆盖） | 新消费格式的映射规则确认 | 新业务形态的场景覆盖追问 |
| 机器发信号时 | 预检通过率异常的团队对齐 | 对抗测试失败、语义分叉 | 消费追踪四信号的月度审阅 |
翻译能力在整条链路上的最终归属：它分布在每一个工作流节点上，每个节点的输入契约就是能力的及格线。
设计系统负责人的特殊位置在于，自己是唯一同时看见上游来料和下游消费的人，所以这份及格线的恒定执行，落在自己身上。
上游的下一份快照来自谁？可能是任何发现问题的人。
下游的下一份产物给谁？可能是任何接入的团队。
设计系统负责人不需要预先知道他们是谁，他们进入链路的那一刻，契约已经在入口处等着了。
这不是一条流水线的终点，而是规则流转的一个中转站。
规则流转的第一棒，发生在离评审队列最远的地方：设计师与产品经理的日常。 一份"我觉得这个提示不对"的直觉，如何变成评审队列可接收的6字段语义快照？快照提交后由谁诊断、直觉与证据的边界在哪里？这是后续《设计师与产品经理》篇要展开的内容。
上游的第一份合格来料，永远是规则流转的起点。
