有人真正解决了AI生成的UI在会话之间漂移的问题吗？好奇人们如何为编码代理构建设计规则

一直在尝试弄清楚为什么每次Vibe Coding会话最终都会产生略微不一致的UI，即使项目已经有一个设计系统文档记录在某个地方。我通常遇到的失败模式：让代理创建一个按钮。第一次它选了#3B82F6。第二次会话，#2563EB。第三次会话，bg-blue-500。都是蓝色，但没有一个是相同的蓝色。间距标记（1rem vs 16px vs gap-4）和字体大小（text-xl vs 1.25rem vs 20px）也是如此。事后看来，根本原因很明显：代理没有结构化的调色板可以参考。你给它的规则文件（CLAUDE.md / AGENTS.md / .cursor/rules）只是自然语言，所以即使你写了“品牌颜色是#1A1C1E”，模型在生成时仍然需要猜测选择哪个标记。自然语言对于工作流程规则来说没问题，但作为标记表的替代品却非常糟糕。我在比较的几种方法：纯CLAUDE.md / AGENTS.md，将调色板内联为Markdown表格。适用于一次性项目，但模型在几次交互后仍然会漂移，因为它每次都会重新解析相同的文本。将tailwind.config.js作为事实来源，然后告诉模型去读取它。更好——它是结构化的——但Tailwind配置只覆盖了Tailwind支持的内容，而且模型不知道颜色存在的原因，所以它会选择错误的语义标记（在应该使用主色的地方使用了强调色）。一个专用的设计系统规范文件，将结构化标记（YAML）与说明何时使用每个标记的散文配对。Google Labs最近发布了一个名为design.md的文件，正是这样做的——YAML前置元数据用于标记，Markdown正文用于“何时使用”，外加一个带有WCAG对比度检查的CLI。目前是alpha版本，但结构感觉是对的。选项3似乎最接近我实际想要的，但我怀疑它能否在真实项目中存活下来。我还没有弄清楚的一些事情：一旦代码库演进超过规范，如何防止规范腐烂？有人在CI中对tailwind.config.js运行lint吗？对于已经在使用Figma标记 / Style Dictionary的团队，是否有理由在此基础上再添加一种格式，还是说这严格来说不如直接将现有的tokens.json喂给模型？代理真的会遵循CLAUDE.md中的“先阅读此规范”指令吗，还是只有当提示中提到颜色名称时才会拉取它？对于那些解决了这个问题的人——是通过更好的规范文件、一个向每个UI相关提示注入标记的钩子，还是其他完全不同的方法？真的很好奇什么对你们有效。“每次都要解释我的品牌颜色”这个循环快让我崩溃了。