当设计意图必须变成机器能读懂的规则时，一个全新的角色——语义翻译设计师应运而生。本文从一次语义漂移的判断出发，深入解析如何通过YAML契约将模糊直觉编码为机器断言，并借助编译管线与三道闸门，让规则在组织内持续运转。这不仅是个人能力的升级，更是组织翻译机制的构建。

在前面四个主题行中，我完成了 Schema-As-Code把设计规范写成代码格式 框架从”发现问题”到”定义规则”的闭环前半段：

① 语义令牌与字典：把”红色代表致命”这种模糊直觉，编码为 status.critical 这样的离散语义令牌，建立了组织级唯一信源。但它只回答了”词汇是什么”，没回答”怎么造句”。

② 语义域：把组件从”自带语义”变成”空容器”，语义由场景外赋。它只回答了”语法结构是什么”，没回答”怎么写文章”。

③ 约束显化：把”文案要准确”这种自然语言规范，变成机器可读的断言。它只回答了”写作方法是什么”，没回答”谁能持续产出作品”。

④ 语义契约：把设计意图翻译成YAML的7个冻结字段，经过入库三道闸，成为可版本管理、可 Diff 追溯的资产。但它仍然聚焦在”个人怎么写一份契约”，一个人，一台电脑，一份文件。

到这一步，规则可以写出来了，但还停在个人工具层面：一个人写，一个人用，一个团队内部消化。

⑤ 编译管线开始回答”规则怎么被组织消费“：一份YAML编译出Prompt前缀、JSON Schema、Checklist、CI规则，自动分发给前端、AI工程师、DesignOps。但它回答的是”机器怎么分发”，没回答”谁来触发分发、谁来监控消费、谁来处理团队间的语义冲突”。

当组织里有5个团队、10个产品、20名设计师时，“个人写得好”不等于”组织运转得好”。同一个语义，团队A叫”严重”，团队B叫”Critical”；同一份契约，前端说Schema没更新，AI工程师说Prompt前缀没收到；规则写了30条，其中12条三个月没人用，成了“沉默规则”。

从“个人翻译能力”到“组织翻译机制”，中间缺一个枢纽角色，不是写代码的工程师，不是画界面的设计师，而是专门负责”把设计意图翻译成机器规则，并让这个规则在组织内持续运转”的人。

这个角色，就是具备语义翻译能力的设计师。

本文是这个角色的能力宣言：不讲系统架构，不讲组织治理，只讲这个角色自身的能力模型，从一次语义漂移的判断开始，到一份YAML契约的产出，再到规则在组织内的消费与验证。

一、什么是翻译能力？人懂的直觉，机器读的规则

1.1 定义：在直觉和规则之间架一座桥

这种能力，不写代码，也不画设计稿。它只做一件事：把‘设计意图’翻译成‘机器规则’

1.2 起点：四种错误共用一种红，问题出在哪？

这个角色的经验，通常从一个判断转折开始。

面对一个AI对话产品的错误状态界面：至少四种错误，”Error in message stream””network error””Something went wrong””Too many requests”，全部是红色。但后果完全不同：有的是对话上下文丢失，有的是网络抖动会自动恢复，有的是限流等一小时就好。用户看到红色就刷新，把还能自动恢复的网络抖动，刷成了真正的对话丢失。

当时的判断：这不是视觉问题，颜色本身没做错；这是语义问题，红色没有区分后果的严重程度。

为什么这样判断：如果是视觉问题，修正色值就能解决；但用户做出错误行动（不该刷新时刷新）的根源，是界面没有传达“这个错误意味着什么后果”。视觉层是完整的，语义层是缺失的。

经验沉淀：语义漂移的第一个信号，不是”界面不好看”，而是”用户看到界面后，做出了错误的行动决策“。这个信号后来成为这个角色识别一切语义问题的入口。

回头看，这正是前三个主题行各自缺一块的地方：

1.3 价值：从“口头说”到“机器执行”，解决了什么

二、语义契约：一份让机器“听话”的文件

一份契约要能让机器”听话”，必须回答七个不可省略的问题。不是拍脑袋定的，是我们踩过坑后逐步收敛出来的。七个字段，每个对应机器执行时的一个信息缺口：详见④主题行《YAML 契约：设计意图的接口定义，编译即规则》

七个字段中，真正能约束机器的是 llm_constraints。它把”给人读的规范”变成”给机器执行的规则”：

description 是给人读的，机器无法判定”准确”还是”不准确”

visual_mapping 只管视觉渲染，不管文案内容对不对

llm_constraints 才是注入AI生成流程的断言，分三类，机器直接执行：

1. 必须型：”必须显示倒计时” → 机器检查字段是否存在
2. 禁止型：”禁止用’严重’替代 Critical” → 机器做字符串匹配
3. 限制型：”只能使用 outline_danger” → 机器检查值是否在枚举范围

没有 llm_constraints，契约只是”给人看的规范”；有了它，契约才是”给机器执行的规则”。

2.1 一份源文件，十份编译产物：为什么不能手改

这个角色产出的11个交付件里，只有1个是源文件：语义契约（YAML）。其余10个全部是它的编译产物：

为什么禁止手改：手一改，版本就分叉。前端改Schema，AI工程师改Prompt前缀，契约一更新，团队A的Schema是 v1.1，团队B的Prompt还是 v1.0。同一个语义，两套版本。当时我们就判断：下游版本分裂，就是“四种错误共用红色”在组织层面的翻版，语义一样，表达不同，机器和工程师只能跟着做错。

2.2 七个字段，七问七答：机器必须知道什么

7个字段，到 v1.0 正式冻结，只增不减。其中 llm_constraints 是必填子字段，它是契约真正能约束机器的入口。没有它，契约就只是“给人看的规范”，而不是“给机器执行的规则”。

这个道理，是我踩过坑才真正明白的，

2.3 第一份契约：当“错误状态诊断”变成机器能读的规则

这个角色翻译的第一个模式，通常就是”错误状态后果差异未分级”：

翻译成YAML（机器读的），四个关键翻译动作：

反向验证：机器若只读到 error_severity: fatal，能自动推导出“红色脉冲 + 八边形图标 + 刷新按钮 + 不可恢复文案”吗？能。因为视觉映射和用户行动早已写死在契约里，不需要任何二次解释。经验沉淀成一句话：翻译的本体，是“直觉变成断言”；而断言，天生不需要二次理解。

一份契约的结构性骨架（ERR-001错误状态诊断 示例）

契约不是代码，是一份”设计意图的身份证”。7个顶层字段，每个字段回答一个特定问题：详见④主题行《YAML 契约：设计意图的接口定义，编译即规则》

三、YAML契约：不是文档格式，是机器接口

3.1 写在文档里的规范，为什么AI看不见

3.2 YAML能做到什么：可读、可管、可校验、可分发的四重能力

3.3 关键设计：从”一段话”到”一组断言”

同样是”分级”，前者是一段话，后者是一组断言。这就是这个角色存在的理由。

四、谁来翻译？，语义翻译设计师

当设计意图必须变成机器能读懂的规则时，谁来做这件事？答案是：团队里往往会长出一个叫“语义翻译设计师”的角色。他们不写代码，也不管像素，只专注一件事：确保机器能准确理解设计意图。

但这活儿一开始并不需要专人专岗，它往往是从各个角色手里自然长出来的。

五、三道闸门：工作流的三个阶段

三道闸不是抽象概念，是我每次提交契约时必须跑完的完整检查链：

三道闸环环相扣：格式正确 → 语义一致 → 生成合规。前一闸不过，后一闸不启。人只出现在两端，我写契约，我看效果。中间所有检查、翻译、分发、拦截，全部由机器按规则自动执行。

六、五个团队、一个标准：规则怎么在组织里统一

当只有一个人写规则时，没有治理问题。当5个团队、10个产品时，问题出现了：

同一个语义，三种表达。治理的四个设计：

1. 统一基线 + 团队扩展：组织级规范手册强制继承，团队只能增加不能删减；
2. 机器校验代替人工审批：规则写在 schema/intent-schema.json，任何人提交跑同一套检查，不因人而异；
3. 消费追踪与沉默规则唤醒：30天零消费自动标记，通知语义规则负责人；
4. 效果驱动的基线迭代：多个团队申请同一扩展 → 规范评审组评估是否升级为基线。

编译管线是这套治理的规则分发中枢：输入基线+扩展，按团队隔离编译，输出4种格式，消费数据回流。它让”统一基线、团队自治、无感知接入”从架构宣言变成可运行的工程机制。

七、数据说话：这套能力到底值不值

这个角色第一次用数据证明规则有效，是契约入库一周后打开消费追踪面板（演示环境数据）：

三层度量面板的结构性概括：

个人层（语义翻译设计师）

• 回答：我写的规则有人用吗？拦住了多少问题？
• 核心指标：规则消费率（30天内被加载次数）、拦截归因数（本月因我的规则被拦住的漂移次数）
• 看板：Steward工作台

团队层（DesignOps/前端TL）

• 回答：我们团队接入了吗？返工降了吗？
• 核心指标：基线规则继承率（已接入/应接入）、语义返工率（从30%→5%）
• 看板：团队治理健康度周报

组织层（管理层）

• 回答：这件事投入产出比如何？要不要继续投？
• 核心指标：语义一致性得分（目标95%）、返工成本节省（盈亏平衡点：产品>3且组件>50）
• 看板：季度投入产出报告

所有数字在 Phase 0 为”数据模型推演”，Phase 1 试点实测，Phase 2 全域统计。

八、写在最后：你的翻译能力从哪里开始

意图设计的翻译能力，是AI时代设计角色的进化方向。当AI可以生成 80% 的界面时，这个角色的核心价值不再是”画得更好看”，而是”告诉AI这个场景下必须表达什么语义、不能突破什么边界”。

这个角色的经验从一次语义漂移的判断开始。你的可以从下篇开始，那里有完整的操作步骤、6个模板和30天上手路径：《角色专题 ④｜语义翻译设计师：操作手册》。

系列阅读指引：

• 想了解”怎么发现语义问题并提交给翻译者”，见角色专题①《设计师与产品经理》
• 想了解”怎么消费规则、怎么接入约束”，见角色专题②《前端与 AI 工程师》
• 想了解契约的字段设计逻辑、语义层与视觉层分离、入库三道闸，见④主题行三篇：《YAML 契约》《字段层差异》《契约的机器防线》