前一篇《在1个组件的2个场景上练习核对》讲了设计系统负责人怎么从1个组件开始，建立"核对语义边界"的评审能力：选2个场景，问一句"这个组件在这里是谁"，写成域绑定说明。
这篇我们走到最后一块，把镜头对准规则：设计系统负责人最少做多少，就能开始建立"把口头禁令变成机器规则"的评审能力？
答案是：找到你们评审会上出现频率最高的那条"绝对不能"，把它翻译成1条机器能拦截的规则。仅此而已。
一、为什么要从1条"绝对不能"开始
很多设计系统负责人看到"约束显化"这个词，第一反应是："这是不是意味着我要把整本设计规范都改写成代码？"
不是的。
约束显化不是把规范全部代码化，而是先解决最痛的那一条：你在评审会上反复说、工程师反复忘、AI根本不知道的那条"绝对不能"。
每个设计系统负责人都有这样的保留曲目：
- "删除按钮绝对不能做成普通蓝色按钮，用户会误触的。"
- "致命错误绝对不能只给一行文字，必须提供恢复路径。"
- "限流提示绝对不能用红色，用户会恐慌性刷新。"
这些规则的问题不是没人认同，而是它们只活在评审会的空气里。人散会散，三个月后另一条产品线照样踩坑。AI介入后问题更直接：AI听不到评审会，它只消费显式输入，规则不在输入里，它就按概率生成最常见的样式。
为什么只翻译1条？因为组织对抗往往来自"又要搞一套新规范体系"的疲惫感。但如果告诉你："不需要改任何流程，只需要把1条你已经说了三年的话，写成机器能执行的格式"，门槛就低了很多。
二、翻译1条禁令：从"绝对不能这样"到"违反了怎么办"
打开你的评审记录，找到出现频率最高的那条"绝对不能"，通常是和危险操作、致命状态相关的。我们以"删除按钮必须有二次确认"为例。
翻译动作只有一步：给这条规则补上三个机器需要的答案。
| 机器需要什么 | 追问示例 | |
|---|---|---|
| 答案1：这条规则管谁？ | 规则的适用范围 | 是所有删除按钮，还是只有"不可逆删除"？是 transactional 域里的 action.destructive |
| 答案2：违反了怎么办？ | 违约动作——这是约束显化的分水岭，不是"建议不要"，而是"如果违反，就阻断" | AI生成或代码提交违反了，是直接拦截（block）还是警告放行（warn）？危险操作必须二次确认，属于"绝对不能突破"的不可变边界，违约动作是 block |
| 答案3：机器怎么判断违反了？ | 可执行的判定条件 | 什么叫"有二次确认"？是存在 confirmation_dialog，还是用户必须输入确认词？判定条件越具体，机器越不会误判 |
顺手做一次分类，效果更好。约束显化规则分两类：
| 类型 | 违约动作 | 例子 |
|---|---|---|
| 不可变边界（Immutable Boundaries） | 违反即阻断（block） | 高危操作必须二次确认 |
| 推荐约束（LLM Constraints） | 违反即警告（warn） | 文案长度不超过50字 |
你的动作：把那条"绝对不能"按三个答案补全，并明确它属于不可变边界还是推荐约束。注意，你要判断的是：这条约束是否属于"绝对不能"（不可变边界）还是"最好不要"（推荐约束）？是否可执行（机器能判断是否违反）？是否与现有规范冲突（如与某团队的特殊需求矛盾）？
三、把翻译结果写成"机器能拦截"的格式
翻译完三个答案后，你手里有了一条"人懂的"禁令。下一步是把它写成"机器能拦截"的格式，不是让你写代码，而是写一段结构化的边界定义，让下游的语义翻译设计师能直接把它编码成YAML契约。
翻译前（口头禁令）：
"删除按钮绝对不能没有二次确认。"
翻译后（结构化边界定义）：
【不可变边界】高危删除必须二次确认
【边界类型】safety（安全边界）
【适用绑定】action.destructive（危险操作）
【规则】必须包含 confirmation_dialog
【违约动作】block（违反即阻断，CI 不通过、生成不放行）
【补充约束】
- 按钮文案必须包含"删除""清空""永久"等不可逆语义词汇
- 禁止仅使用"确认""确定"等中性词汇
- 确认弹窗必须说明后果（"删除后不可恢复"）
你的动作：把这份边界定义，贴在你们设计规范的对应规则旁边。不需要写YAML，只需要写到这个颗粒度，下游的语义翻译设计师会把它编码成契约。机器拿到这份定义后，规则就活了：AI生成前它被注入上下文，代码提交时它被CI执行，违反即阻断。
四、真的发生过吗：一个你可以在自己组织里验证的案例
你们组织里一定有这样的情况：同样一条"绝对不能"，有的产品守住了，有的产品没守住，而你只能事后发现。
你可以做的验证动作：
- 打开你们的主产品，执行一次"清空回收站"或"删除全部"操作
- 截图，记录：按钮样式是什么、有没有二次确认、文案写的是什么
- 再用你们的AI生成工具（或让新同事按规范文档）生成一个同样的界面
- 对比：生成的界面，守住了那条"绝对不能"吗？
大概率你会发现：
| 对比项 | 人工做的界面 | AI生成的界面 |
|---|---|---|
| 二次确认 | 有 | 只有一个蓝色"确认"按钮 |
| 规范触达 | 规范文档里明明写着"危险操作必须二次确认" | AI根本没读到这句话 |
| 字面满足 | —— | 就算写了 confirmation_dialog，也可能生成文案为"确认"的按钮，技术上"有弹窗"，语义上完全偏离危险警示 |
这就是一个真实发生过的漂移类型：某AI生成工具生成"清空回收站"界面时，按钮文案为"确认"，样式为蓝色实心，无有效二次确认。根因是约束定义太笼统，只规定了"必须包含 confirmation_dialog"，没规定"按钮文案不能为'确认'"。约束不具体，机器就会在字面上满足、在语义上偏离。
你的动作：把这几张截图并排放在一起，在团队群里发一句："我们的'绝对不能'，机器好像根本不知道？"，这就是约束显化的起点。
五、一直在工作吗：怎么让这条规则持续生效
翻译完1条禁令、写成边界定义后，最怕的是：规则入库了，但没人知道它还在不在工作，直到下次事故。
最小可行的保鲜机制：
| 验证层 | 机制 | 验证内容 | 频率 |
|---|---|---|---|
| 结构验证 | 编译前置校验 | 约束字段是否完整、违约动作是否合法 | 每次契约提交 |
| 语义验证 | 对抗测试用例 | 约束是否能被AI理解并遵守 | 每次契约变更后全量重跑 |
| 一致性验证 | 跨格式比对 | Prompt前缀 / JSON Schema / Checklist / CI规则是否表达同一约束 | 每次契约变更 |
你的动作：先在日历上设一个每月提醒，"看看这条规则的拦截记录"。只需要5分钟，扫一眼拦截日志：拦住了什么、误拦了什么。机器负责每次提交、每次生成的自动验证，你只在机器发信号时在场：
| 机器发的信号 | 你要判断什么 |
|---|---|
| 拦截事件上报 | 是团队理解错误（纠正），还是场景特殊需要申请豁免？ |
| 对抗测试用例失败 | 是约束定义有漏洞（补充约束），还是模型行为变了（调整Prompt前缀）？ |
| 团队扩展申请 | 是团队级合理扩展（批准），还是该升级为组织级基线（提交规范评审组）？ |
六、生长路径：从1条禁令到组织级的规则资产
翻译1条"绝对不能"只是起点。设计系统负责人的约束显化能力，会沿着这条路径自然生长：
| 阶段 | 时间 | 动作 | 产出 |
|---|---|---|---|
| 阶段 0：翻译1条禁令 | 现在 | 找到最高频的"绝对不能"，补全三个答案，写成边界定义 | 1份边界定义草稿 |
| 阶段 1：翻译3条禁令 | 1-2周后 | 把翻译方法复制到致命状态、限流提示等规则 | 1份核心边界清单 |
| 阶段 2：建立翻译模板 | 1个月后 | 把"三个答案"写成团队共享的翻译清单 | 1份《约束显化Checklist》 |
| 阶段 3：参与边界评审 | 2-3个月后 | 新契约提交时，用这份Checklist评审不可变边界 | 拦截成功率数据 |
| 阶段 4：主导边界治理 | 6个月后 | 边界的增删、违约动作的调整、豁免申请的裁决 | 不可变边界版本管理权 |
关键原则：不是"等规范全部代码化再开始"，而是"从1条禁令开始，在翻译中建立标准，在标准中完善规则"。
结语
前两篇讲了怎么从1个Design Token开始追问语义、从1个组件开始核对边界。那些是"定义"，让你知道颜色和组件意味着什么。
这篇讲的是"底线"的第一步：不需要把整本规范改写成代码，只需要找到你说了三年的那条"绝对不能"，补全三个答案，管谁、违反了怎么办、机器怎么判断，把它写成机器能拦截的边界定义。
显化本身就是评审。 当你开始把"绝对不能"写成"违反即阻断"，你就已经从"靠嗓子守住底线"生长到了"靠规则守住底线"。
希望能帮到你。如果你在翻译过程中发现了有趣的案例（比如你们组织里同一条"绝对不能"有五种不同的执行版本），欢迎在评论区分享，这些真实的混乱，正是语义治理最好的起点。
至此，我在假期用三篇短篇走完了一个完整的最小闭环：追问1个Token（语义令牌）、核对1个组件（语义域）、翻译1条禁令（约束显化）。下一步，这些被你定义出来的规则将进入YAML契约、进入编译管线、进入四种消费格式。承上篇的启下篇会展开：设计系统负责人如何确认契约语义的准确性、如何验证编译产物的语义一致性。从"定义规则"到"确认规则被正确翻译"，我们下一篇见。
1200 .png
