设计系统负责人如何把评审会上反复强调的'绝对不能'变成机器能拦截的规则？本文提出最小可行方法：找到出现频率最高的那条禁令，补全三个答案，写成结构化边界定义，让AI和CI自动执行。从口头禁令到机器规则，只需翻译1条，就能建立约束显化的评审能力。

前一篇《在1个组件的2个场景上练习核对》讲了设计系统负责人怎么从1个组件开始，建立”核对语义边界”的评审能力：选2个场景，问一句”这个组件在这里是谁”，写成域绑定说明。

这篇我们走到最后一块，把镜头对准规则：设计系统负责人最少做多少，就能开始建立”把口头禁令变成机器规则”的评审能力？

答案是：找到你们评审会上出现频率最高的那条”绝对不能”，把它翻译成1条机器能拦截的规则。仅此而已。

一、为什么要从1条”绝对不能”开始

很多设计系统负责人看到”约束显化”这个词，第一反应是：”这是不是意味着我要把整本设计规范都改写成代码？”

不是的。

约束显化不是把规范全部代码化，而是先解决最痛的那一条：你在评审会上反复说、工程师反复忘、AI根本不知道的那条”绝对不能”。

每个设计系统负责人都有这样的保留曲目：

• “删除按钮绝对不能做成普通蓝色按钮，用户会误触的。”
• “致命错误绝对不能只给一行文字，必须提供恢复路径。”
• “限流提示绝对不能用红色，用户会恐慌性刷新。”

这些规则的问题不是没人认同，而是它们只活在评审会的空气里。人散会散，三个月后另一条产品线照样踩坑。AI介入后问题更直接：AI听不到评审会，它只消费显式输入，规则不在输入里，它就按概率生成最常见的样式。

为什么只翻译1条？因为组织对抗往往来自”又要搞一套新规范体系”的疲惫感。但如果告诉你：”不需要改任何流程，只需要把1条你已经说了三年的话，写成机器能执行的格式”，门槛就低了很多。

二、翻译1条禁令：从”绝对不能这样”到”违反了怎么办”

打开你的评审记录，找到出现频率最高的那条”绝对不能”，通常是和危险操作、致命状态相关的。我们以”删除按钮必须有二次确认”为例。

翻译动作只有一步：给这条规则补上三个机器需要的答案。

顺手做一次分类，效果更好。约束显化规则分两类：

你的动作：把那条”绝对不能”按三个答案补全，并明确它属于不可变边界还是推荐约束。注意，你要判断的是：这条约束是否属于”绝对不能”（不可变边界）还是”最好不要”（推荐约束）？是否可执行（机器能判断是否违反）？是否与现有规范冲突（如与某团队的特殊需求矛盾）？

三、把翻译结果写成”机器能拦截”的格式

翻译完三个答案后，你手里有了一条“人懂的”禁令。下一步是把它写成“机器能拦截”的格式，不是让你写代码，而是写一段结构化的边界定义，让下游的语义翻译设计师能直接把它编码成YAML契约。

翻译前（口头禁令）：

“删除按钮绝对不能没有二次确认。”

翻译后（结构化边界定义）：

你的动作：把这份边界定义，贴在你们设计规范的对应规则旁边。不需要写YAML，只需要写到这个颗粒度，下游的语义翻译设计师会把它编码成契约。机器拿到这份定义后，规则就活了：AI生成前它被注入上下文，代码提交时它被CI执行，违反即阻断。

四、一个你可以在自己组织里验证的案例

你们组织里一定有这样的情况：同样一条”绝对不能”，有的产品守住了，有的产品没守住，而你只能事后发现。

你可以做的验证动作：

1. 打开你们的主产品，执行一次”清空回收站”或”删除全部”操作
2. 截图，记录：按钮样式是什么、有没有二次确认、文案写的是什么
3. 再用你们的AI生成工具（或让新同事按规范文档）生成一个同样的界面
4. 对比：生成的界面，守住了那条”绝对不能”吗？

大概率你会发现：

这就是一个真实发生过的漂移类型：某AI生成工具生成”清空回收站”界面时，按钮文案为”确认”，样式为蓝色实心，无有效二次确认。根因是约束定义太笼统，只规定了”必须包含 confirmation_dialog”，没规定”按钮文案不能为’确认'”。约束不具体，机器就会在字面上满足、在语义上偏离。

你的动作：把这几张截图并排放在一起，在团队群里发一句：”我们的’绝对不能’，机器好像根本不知道？”，这就是约束显化的起点。

五、怎么让这条规则持续生效

翻译完1条禁令、写成边界定义后，最怕的是：规则入库了，但没人知道它还在不在工作，直到下次事故。

最小可行的保鲜机制：

你的动作：先在日历上设一个每月提醒，”看看这条规则的拦截记录”。只需要5分钟，扫一眼拦截日志：拦住了什么、误拦了什么。机器负责每次提交、每次生成的自动验证，你只在机器发信号时在场：

六、从1条禁令到组织级的规则资产

翻译1条”绝对不能”只是起点。设计系统负责人的约束显化能力，会沿着这条路径自然生长：

关键原则：不是”等规范全部代码化再开始”，而是”从1条禁令开始，在翻译中建立标准，在标准中完善规则”。

结语

前两篇讲了怎么从1个Design Token开始追问语义、从1个组件开始核对边界。那些是”定义”，让你知道颜色和组件意味着什么。

这篇讲的是”底线”的第一步：不需要把整本规范改写成代码，只需要找到你说了三年的那条”绝对不能”，补全三个答案，管谁、违反了怎么办、机器怎么判断，把它写成机器能拦截的边界定义。

显化本身就是评审。 当你开始把”绝对不能”写成”违反即阻断”，你就已经从”靠嗓子守住底线”生长到了”靠规则守住底线”。

希望能帮到你。如果你在翻译过程中发现了有趣的案例（比如你们组织里同一条”绝对不能”有五种不同的执行版本），欢迎在评论区分享，这些真实的混乱，正是语义治理最好的起点。

至此，我在假期用三篇短篇走完了一个完整的最小闭环：追问1个Token（语义令牌）、核对1个组件（语义域）、翻译1条禁令（约束显化）。下一步，这些被你定义出来的规则将进入YAML契约、进入编译管线、进入四种消费格式。承上篇的启下篇会展开：设计系统负责人如何确认契约语义的准确性、如何验证编译产物的语义一致性。从”定义规则”到”确认规则被正确翻译”，我们下一篇见。