让 AI 生成的界面严守设计令牌

在一次构建中，我发现有 127 处直接绑定了原始颜色值，而不是具名角色。每一处都通过了视觉评审。直到有人提出要支持深色模式，它们才全部暴露出来。

这个数字就是完整的论据。不是因为 127 很大，而是因为这些问题看起来没有任何异常。手动输入的值与来自系统的值，在视觉上完全一样。两者的区别，只会在接下来发生变化时显现。

问题不在于 Agent 违反规则

而在于它会扩展规则。

给 Agent 一套设计系统，让它进行构建。当遇到设计系统已经覆盖的内容时，它确实会使用这套系统——真诚而可靠。当遇到设计系统没有覆盖的内容时，它不会停下来询问，而是自行创造。它创造出的名称听起来与你已有的名称一模一样，就放在真正的名称旁边，读起来仿佛是某个人有意做出的选择。

这就是为什么仅凭肉眼很难发现问题。虚构出来的 token 并不是一个显眼的错误，而是一个看起来很合理的错误。六个月后，没人能说清它究竟是有意保留的例外，还是一次幻觉；到那时，可能已经有五个组件依赖它了。

可读并不等于封闭

让 Agent 能够访问一个组件库，可以得到它会复用的组件，但这并不能让你得到一个封闭集合。

封闭集合意味着：只有这些值存在，其他值一律不存在；任何超出集合的内容都必须明确报错，而不是悄无声息地通过。这个区别听起来有些吹毛求疵，却决定了一切。可读的系统能生成大体匹配的输出，封闭的系统才能生成可供审计的输出。

这才是我会用来检验任何 AI 设计方案的真正标准：不是看它覆盖了设计系统中的多少内容，而是看它如何处理设计系统未覆盖的内容。如果这些内容能够悄无声息地混过去，那么覆盖率就毫无意义——你只是让偏移变得更难发现了。

分层，而且不要越层访问

token 分层是有原因的。底层是基础值——也就是原始材料；上层是具名角色——说明某个值的用途。产品界面应该绑定到角色，绝不能越过这一层，直接获取原始值。

这是一条乏味的规则。但它也决定了主题切换究竟只是按一下开关，还是需要重新构建整个界面。

这条规则之所以经常被打破，是因为越层访问在当下总是有效的。屏幕看起来完全正确。只有到了以后，当某个值需要在不同上下文中表达不同含义时，这条规则的价值才会显现出来——因为文件里没有任何东西知道“这个蓝色”和“主要操作所使用的颜色”之间有什么区别。

同样的原则也适用于名称的数量。每增加一个角色，就多了一个其他人必须理解的决策。如果每当某个页面需要一点不同的东西时，系统就增加一个新名称，那么它已经不再是系统，而只是变成了一种结构非常严谨的手动输入值的方式。

从界面中提取 token，不要预先发明

在任何界面都还不存在之前，就编写一整套 token，通常会产生两个可以预见的问题：一堆永远没人使用的值，以及真正需要做出决策的地方恰好存在缺口。

从已经存在并通过评审的界面中提取系统，我得到的结果要好得多——其中的每一个值都因为确实有需要，才赢得了自己的位置。这样得到的系统规模更小，而且其中的每一项都不可或缺。

顺序比格式更重要。从真实页面中推导出来的集合知道自己是做什么的。预先编写的集合，只是一个语法写得很好的猜测。

把深色模式当作审计，而不是功能

这是整个流程中成本最低的检查方式，却几乎没有人这样使用它。

切换到深色模式之后，我们不再询问文件中的某个值“看起来是什么样”，而是开始询问它“意味着什么”。绑定到角色的值知道自己在另一种模式中应该如何表现。手动输入的值只知道如何在某一种上下文中看起来正确，因此会立刻以清晰可见的方式失效。

只需要十秒，它就能发现对几十个页面进行细致视觉评审也发现不了的问题。那 127 处问题就是这样暴露出来的：靠的不是严谨细致，而是一次模式切换。

如果你只准备从本文中记住一件事，那就是：每次完成大规模的 AI 辅助修改之后，先切换主题，然后再检查其他内容。

自检只有面对真正可能失败的标准时才有效

让模型根据一段用自然语言写成的原则检查自己的工作，你得到的只会是认同。它会确认：是的，它使用了设计系统，而且它自己也真的相信这一点。

让它根据一份允许值列表检查输出，你得到的则是一份差异清单。两者之中，一个是评审，另一个只是情绪表态。

所以，这项检查必须是机械式的：这是合法值的集合，这是输出中实际存在的内容，请列出只出现在其中一边、没有出现在另一边的内容。任何无法生成差异结果的东西，都不能算作检查。

这套方法解决不了什么

封闭集合可以阻止随意创造，但它无法告诉你这个集合本身是否足够好——如果把 Agent 限制在一套设计糟糕的系统中，你会迅速得到一致、连贯，却彻底错误的输出。

此外，还有一项人们很少提及的成本：封闭集合意味着必须有人维护它。此后，每一个真正的新需求都需要做出决策，而不能临时发挥。这正是封闭集合的意义，但同时也意味着额外工作。对于小型项目来说，这些工作的成本可能比设计偏移本身造成的成本还高。

在一个真实项目中记录完整流程

我在一个项目中，从头到尾记录了完整路径——需求简述、结构与流程、生成的页面、锁定的 token 系统、包含真实组件和变量的 Figma、可点击原型，以及开发者交付——其中也包括遇到的各种故障：

Claude AI UI/UX：从需求简述到 Figma 的完整工作流——在一个真实项目中走完同样的路径，从需求简述一直到 Figma 交付。

如果你曾经对 AI 辅助构建的项目执行过深色模式检查，我很想知道你发现了多少处问题。我的数字是 127，而这完全出乎我的意料。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。