设计师与产品经理的消费路径：从被动遵守到主动走查

开篇：从"生产设计稿"到"消费规则产物"

上一篇《角色专题｜设计师与产品经理的语义养成：从画对界面到标对语义》讲了设计师与产品经理在语义层做的三个标注动作：把"这个地方要醒目"的直觉标注为语义令牌，把"这个弹窗是阻断性的"的判断标注为场景与域的绑定，把"这个绝对不能这样"的口头强调转化为约束意图描述。标注把意图变成了机器可引用的坐标，但坐标本身还不是规则。 这些标注交给谁、怎么变成规则、规则又如何回到设计师手里、反向服务于设计工作，这正是本篇要回答的问题。

设计师习惯的设计流程是：画稿 → 评审 → 交付。引入语义层之后，这条流程多了两个动作：设计前"查规则" 、设计后"走查" 。

先交代两个可能陌生的词。YAML契约（把设计意图写成机器能执行的接口文件，固定7个字段，写法是"查字典填表格"，不是自由写作文）；编译产物（这份契约被机器自动翻译出来的四种可用格式）。设计师不需要读契约原文，日常消费的是其中一种产物，Checklist（给设计师走查用的清单）。

关键认知转变， Checklist不是额外的审批流程，而是机器替设计师记住所有"绝对不能" 的外置记忆。

过去，设计师记住"删除必须有二次确认"靠的是个人经验和评审会上的口头传承，换了人、隔了半年，规则就丢了。现在这些"绝对不能"被显化成约束、编译成Checklist，设计师每次走查面对的不再是依赖个人记忆的"好像有这么一条"，而是"清单上白纸黑字写着这一条，且永远是最新版"。

规则不再是设计师的额外负担，而是设计师的外置记忆。 本篇展开两条消费路径：语义快照如何成为契约的原材料，以及规则变更如何自动抵达消费端。每条路径都按同一个思路讲：先给你一个有场景的日常画面，再看痛点卡在哪里，然后摊开关键设计，最后落到设计师可实现的最小解决路径。

一、YAML契约（主题行④）：语义快照是契约的原材料

1.1 有场景：提交的与消费的

设计师提交的：6字段语义快照。

设计师消费的：Checklist，契约编译的四种产物之一，专为设计走查生成。

📎 协作埋点：快照进入翻译与评审后发生什么，见《设计系统负责人的编译确认》。

1.2 有痛点：一句话感受为什么不是证据

先看清快照要变成什么。快照的终点是YAML契约（把设计意图写成机器能执行的接口文件），比如 ERR-001错误状态契约，把"错误状态分四级"写成7个字段：意图编号、版本、描述、语义域、适用产品、语义令牌、机器约束与不可变边界。

为什么非写成字段不可？

看一句典型的规范原文："错误状态要分级显示。严重的用红色，文案要写清楚，高危操作要二次确认。"

这份文档本身没问题，问题是机器读不懂："严重"是形容词，机器不知道什么算严重；"写清楚"是主观标准，走查时各执一词；全程没有一条"绝对不能碰"的红线。颜色、文案、图标在机器世界里各有独立的语义定义，自然语言把它们糊成了一句话。机器拿到这段话，只能"渲染成文字"，不能"执行规则"。

所以快照也不能是一句感受。"这个报错不对"无论多么正确都不是证据，它没有把直觉变成机器可读的记录。

1.3 解决方法：6字段快照就是"直觉→证据"这一跳的及格线

6字段快照的意义，就是强迫提交者完成 "直觉→证据" 这一跳：

• visual_record 强迫你留下证据，而不是口头转述
• user_confusion 强迫你写清"用户误判成了什么"，而不是"不好"
• context 强迫你定位场景，而不是泛泛而谈"体验不好"

快照格式就是翻译能力的及格线。 这条及格线与下游评审的三条准入条款完全一致：结构条款（机器可读是入场券）、语义条款（只引用字典已注册项）、证据条款（至少关联1个真实产品实例），从提交那一刻就恒定执行。

1.4 关键决策点：快照被退回时

快照被退回的三种典型情况：格式不完整、证据不足、描述模糊。退回说明本身就是翻译能力训练，退回不是拒绝，是及格线。

1.5 （真的发生过吗）一句话感受被退回之后

某设计师提交了一条快照，user_confusion字段只写了一句话："这个报错不对。"

机器格式预检通过，但评审队列退回：描述模糊，无法判断用户困惑的具体指向。

设计师补齐6字段： visual_record附上了用户录屏，用户看到黄色提示后立刻刷新页面并重复提交了三遍同样的表单；user_confusion改写为"用户把可恢复错误（网络抖动）误判成了系统故障"；context标注了具体场景。

这条快照被归入已有漂移模式 ERR-001 错误状态诊断（后果差异未分级） ，支撑了该模式的确认。更重要的是：ERR-001 编译出的Checklist从此进入这位设计师的日常工作流，每一次走查都在核对自己的困惑是否已经被规则覆盖。

结构化让个人困惑变成了组织资产。 一句话感受会流失在聊天记录里，一条6字段快照会沉淀在规则体系里。

1.6 （一直在工作吗）契约的机器防线

快照提交瞬间，三道预检机器自动执行：

设计师在提交瞬间就能拿到格式预检结果；被退回时，退回说明自动生成。机器拦不住的（格式合规但内容空洞），正是评审存在的意义。

放大到契约全生命周期，机器防线是三道闸，设计师只需知道结论，不需要守过程：

• 入口防呆（错误写不出来）：契约用表单生成，选项全部来自语义字典下拉框，不可自创；必填项没填完，提交按钮是灰的；
• 入库安检（错的进不来）：手写契约入库前过5项机器安检，覆盖层存在性、绑定存在性、场景一致性、字段完整性、结构合法性，任一不过即退回，不存在"先入库后修复" ；
• 同步对账（进来的不变质）：每个编译产物头部自带版本声明，下游拿着过期版本在用、或有人手改产物，机器5分钟内告警并阻断。

一句话：契约不是文档，是机器执行的拦截规则。 文档靠人读，契约有机器守。

📎 关键设计详情：《④ YAML 契约：设计意图的接口定义，编译即规则》，契约与自然语言规范的对照表、四种机器形态与四层拦截推演；《④ 字段层差异：颜色、文案、图标各自有独立的语义定义》，为什么"严重的用红色"机器读不懂，逐字段差异对照；《④ 契约的机器防线：契约不是文档，是机器执行的拦截规则》，三道闸的完整对抗用例。

二、编译管线（主题行⑤）：规则变更如何自动抵达消费端

2.1 有场景：Checklist的自动版本同步

设计师消费的Checklist的自动版本同步：契约变更 → Git Diff → Checklist自动更新 → 下次走查永远使用最新版。

设计师不用关心契约的版本号，不用订阅规则仓库的变更日志。编译管线保证只要契约变了，设计师手里的 Checklist就是最新的。

这正是下游消费约定在设计师身上的直接体现：

• 约定一"产物必须自动更新，不允许人工复制粘贴旧版本"，Checklist永远自动同步，不需要任何手动维护；
• 约定三"清单项必须与契约条款一一对应"，核对的每一项检查项，背后都有契约条款撑着。

两条约定都只需要消费，不需要维护。

2.2 有痛点：同一套语义，四种人工方言

没有编译管线时，同一套语义靠四个角色各自人工翻译，每个翻译都在损耗：

• 前端看不懂YAML，自己翻成JSON，把 status.critical 理解成了 "color": "red"；
• AI工程师手写Prompt前缀，写成"用红色表示严重"，和设计师说的 status.critical 不是同一个东西；
• DesignOps手动维护走查清单，漏了"不可恢复"文案这一项，上线后用户投诉；
• CI校验规则自己写，和契约版本对不上，拦了不该拦的、漏了该拦的。

评审时才发现： "你说的Critical和我说的Critical不是同一个东西。" 这不是谁不认真，而是缺一个"机器翻译层"，把契约自动编译为每种角色能直接消费的格式，并验证四种格式说的是同一件事。

2.3 关键设计铺开：编译管线是什么

编译管线（把一份契约自动翻译成四种消费格式的"机器翻译层"）只做一件事：设计师写一次，机器编译四次，四个角色各拿各的。

四份产物不是"各自为政"，而是同一语义的不同表达：Prompt前缀里的 status.critical 和JSON Schema里的 status.critical 指向语义字典中的同一个绑定，机器做交叉比对而非人眼扫一遍，四种格式表达同一语义，无分叉。

编译过程过四层验证：结构验证（YAML合不合法）→ 语义验证（引用是否在字典注册、约束是否可判定，"文案要友好一点"这类形容词会被打回重写）→ 一致性验证（四种格式两两交叉比对）→ 产物验证（每种格式能否被对应角色直接消费）。任一不过即阻断，错误定位到具体字段路径。

同步靠版本声明 + 自动重编译：契约提交到Git，钩子自动触发重编译，四种格式全部换新版；每个产物头部嵌入版本声明（源契约、版本、编译时间），下游加载时自动核对，过期5分钟内告警。设计师感知到的只有一件事：下次打开Checklist，它永远是最新的。

组织存在多个业务团队时，编译管线是"组织级基线 + 团队级扩展 → 团队专属产物"的合并编译：基线不可覆盖，团队可自治扩展，产物物理隔离互不污染，这一条设计师无感知，但保证了清单在多团队环境下依然同源。

📎 关键设计详情：《⑤ 编译管线：一份YAML契约，编译出Prompt/Schema/CI规则》，四层编译验证、版本对账与团队隔离编译的完整链路。

2.4 解决方法：从"查规则"到"被规则服务"

设计前的"查规则"：

• 这个场景该引用哪个语义令牌？查语义字典
• 这个组件在该场景下属于哪个域？查域声明
• 这个场景有什么"绝对不能"？查约束条目

设计后的"走查"：

• 设计稿是否违反了Checklist上的任何一条？逐项核对
• Checklist上没有的盲区，是否值得提交一条新快照？发起反馈

设计师感知的Prompt前缀对AI生成工具的反向约束：设计稿标注的语义令牌，通过Prompt前缀影响AI生成结果。标注的"这个场景是 transactional 域"，最终会出现在AI生成工具的 system message 里，约束它生成的组件样式与行为。

翻译能力在这里表现为双向：向上，语义快照是规则的原材料；向下，规则产物是设计师的外置记忆。

2.5 关键决策点：走查发现Checklist覆盖不到的盲区

走查时最常遇到的场景：Checklist覆盖不到的盲区，新场景、新组件形态、新交互模式。此时设计师有两个选择：

• 绕过走查："清单上没有这一条，那就算了"
• 发起新快照："清单覆盖不到，说明规则体系也覆盖不到，这正是应当提交快照的时刻"

正确的选择永远是后者。Checklist的盲区，就是规则体系的盲区；设计师是第一个看见盲区的人，也是最应该按下反馈按钮的人。

2.6 （真的发生过吗）规范进化的方向从消费端长出来

契约 v1.1.0 新增了"文案语义权重"约束：action.destructive的按钮文案必须包含不可逆语义词汇，禁止仅使用"确认""确定"等中性词汇。

编译管线自动执行：契约变更 → Git Diff → Checklist更新。设计师下次打开走查清单时，多出了一条检查项："删除类按钮文案是否包含不可逆词汇？"

这位设计师在走查存量设计稿时，发现了3处违规，三个删除按钮的文案都是"确认"。

问题诊断：

• 语义层：旧版契约只约束了"必须有二次确认弹窗"，未约束文案语义权重
• 修复：3处违规设计稿全部改写文案（"永久删除""清空回收站"），新版本发布
• 回流：这次走查记录被引用为"文案语义权重"约束有效性的证据，进入该约束的对抗测试用例集

规范进化的方向是从消费端长出来的。 规则不是坐在办公室里想出来的，是设计师在走查中一寸一寸摸出来的。

2.7 （一直在工作吗）消费追踪的个人视角

机器在自动追踪每一份产物的消费情况，构成双重闭环：

• 机器闭环（机器盯产物）：每种格式的加载次数、引用次数、使用次数全部被记录。连续30天零消费的规则会被标记为"沉默规则"，不是惩罚，而是防止"写了没人用的规则"持续占用维护成本，规则负责人须选择唤醒修订或归档废弃，选择留痕；
• 角色闭环（反馈回流规则生产）：设计师的走查记录、退回记录、盲区记录回流为快照，进入模式库，孵化下一条契约。

设计师可以从个人视角看到：

• 走查记录被多少条契约引用
• 发起的快照孵化出了多少条规则
• 提交的快照结局分布：归入已有模式 / 孵化新契约 / 被标记重复 / 被退回

快照不是黑洞，每一条都有结局，结局都是反馈。消费追踪让设计师看清自己在这条链路中的位置：不是规则的被动遵守者，而是规则的活水源头。

📎 关键设计详情：《⑤ 消费格式差异：同一份契约的四角色消费格式》，四种格式的字段级对照与消费方式；《⑤ 契约消费追踪双重闭环验证：机器闭环 + 角色闭环》，消费热力图、沉默规则唤醒与双重闭环的验证口径。

三、从消费到反馈：角色闭环

两条消费路径合起来，构成设计师的完整角色闭环：

查规则（设计前）
  → 画设计稿（标注语义令牌 + 场景 + 约束意图）
  → 走查（Checklist逐项核对）
  → 发现盲区
  → 提交新快照
  → 回到规则生产（快照进入模式库，孵化下一条契约）

这个闭环的核心定位：设计师是语义规则的第一个消费者，也是最后一个反馈源。 规则好不好用，设计师最先知道；规则缺了什么，设计师最先看见。

设计系统负责人确认规则的保真，编译管线保证规则的自动执行，但规则的方向感，"该往哪里长"，来自设计师在消费端的每一次走查和每一次快照提交。

结语：消费路径的终点

本文展开了两条路径：

• 向上供证据：6字段语义快照是契约的原材料，格式就是"直觉→证据"这一跳的及格线
• 向下消费产物：Checklist是机器替设计师记住所有"绝对不能"的外置记忆，且永远是最新版

设计师与契约的关系是双向的。这种双向关系产生了一个更深的问题：快照提交之后，经过哪些节点、由谁完成翻译动作、反馈怎么回来？见下一篇《快照的流转》。

本文由作者@魏雯，授权发布于平台，未经许可禁止转载。