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

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

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

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

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

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

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

***

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

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

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

| 字段               | 内容          | 回答的问题    |
| ---------------- | ----------- | -------- |
| `snapshot_id`    | 快照唯一标识      | 这条记录是谁   |
| `product`        | 所属产品        | 出现在哪里    |
| `component_type` | 组件类型        | 哪个组件出了问题 |
| `visual_record`  | 界面证据（截图/录屏） | 实际长什么样   |
| `user_confusion` | 用户困惑点       | 用户误判成了什么 |
| `context`        | 出现场景        | 在什么场景下出现 |

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

📎 协作埋点：快照进入翻译与评审后发生什么，见《[设计系统负责人的编译确认](https://www.yuque.com/u222739/why7ts/egb7u5722pm4dpxs)》。

***

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

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

**为什么非写成字段不可？**

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

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

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

***

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

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

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

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

***

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

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

| 退回类型 | 典型退回说明                               | 你的动作             |
| ---- | ------------------------------------ | ---------------- |
| 格式退回 | 快照缺少`user_confusion`字段，无法判断用户困惑的具体指向 | 补齐字段，重新提交        |
| 证据退回 | 未关联真实产品实例，补充截图或说明与已归档模式的关系           | 补真实界面证据，而不是推测    |
| 语义退回 | `user_confusion` 仅写"不好"，请写清用户误判成了什么  | 把"不好"改写成可复现的误判描述 |

***

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

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

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

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

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

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

***

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

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

| 预检      | 执行者      | 检查内容              | 拦截时机         |
| ------- | -------- | ----------------- | ------------ |
| 格式预检    | 机器（提交瞬间） | 6字段完整性            | 提交即出结果，不过不入队 |
| 引用预检    | 机器（提交瞬间） | 场景与已注册模式的匹配       | 提交即出结果，不过即阻断 |
| 证据与语义预检 | 人（评审时）   | 至少1个真实产品实例、困惑点可复现 | 进入评审队列后处理    |

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

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

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

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

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

***

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

### 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前缀    | AI工程师         | 放在AI指令最前面的一段规则 | 注入AI工具上下文生成前先加载约束 |
| JSON Schema | 前端工程师         | 给代码自动校验用的类型规则  | 校验组件Props传错类型当场报错 |
| Checklist   | 设计师/DesignOps | 给设计走查用的核对清单    | 走查时逐项勾选           |
| CI规则        | 流水线           | 代码提交时自动拦截的规则   | 违规提交在合并前被自动拦截     |

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

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

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

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

📎 关键设计详情：[《⑤ 编译管线：一份YAML契约，编译出Prompt/Schema/CI规则》](https://www.yuque.com/u222739/why7ts/zr1k7vopzcd4rg63)，四层编译验证、版本对账与团队隔离编译的完整链路。

***

### 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天零消费的规则会被标记为"沉默规则"，不是惩罚，而是防止"写了没人用的规则"持续占用维护成本，规则负责人须选择唤醒修订或归档废弃，选择留痕；
*   **角色闭环**（反馈回流规则生产）：设计师的走查记录、退回记录、盲区记录回流为快照，进入模式库，孵化下一条契约。

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

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

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

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

***

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

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

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

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

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

***

## 结语：消费路径的终点

本文展开了两条路径：

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

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

***

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

![1920.png.png](https://developer.qcloudimg.com/http-save/yehe-12505371/4b124229b76ed85075819fb5a0e560a3.png)


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

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

设计师的6字段快照是契约的原材料，契约编译出的Checklist是设计师的外置记忆。规则不再靠个人经验口口相传，机器自动编译、自动同步、自动拦截，设计师从被动遵守长成主动走查，从规则的消费者长成规则的活水源头。

人工智能

从"生产设计稿"到"消费规则产物"，本文解析设计师如何通过6字段语义快照与YAML契约连接设计意图，借助编译管线自动生成Checklist外置记忆，实现规则双向闭环，让设计师从规则被动遵守者变为活水源头。

机器翻译

JSON

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

设计师与产品经理的消费路径：从被动遵守到主动走查-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐