很多人给AI生成UI时，会附上一句“请遵守我们的设计规范”。但页面出来以后，按钮还是一套样式，卡片又是另一套；颜色看起来接近，状态和间距却没有统一。这一般是因为你的设计规范没有写成可以执行的规则。
用AI生成UI，先不急着AI生成页面，
可以做一份Design.md文件
。包含颜色、字体、圆角、阴影、侧栏和图表规则，离可用还有几步：哪些是全局约束，哪些只适用于某个组件，哪些地方存在前后不一致。这样生成的UI界面，会严格遵守设计规范。下面我举例展开说说：
以这份Design.md文件为例，基调很明确：面向中文市场的电商后台，使用清爽的薄荷绿色，界面要能承载密集数据，同时保持留白。主色是#2AAD6C，页面背景是#F7FAF8，文字使用深绿色黑，侧栏则单独使用#1E2E28。这样的描述比“做一个清爽的后台”具体得多，AI至少知道主按钮、页面背景和导航不该各自猜颜色。
颜色变量也分成了primary、secondary、muted、destructive和图表色阶。图表从深薄荷绿到浅色依次排列，错误和危险状态使用暖红色。这里有一个值得保留的边界：红色只用于破坏性操作和错误提示，不能因为想让页面更醒目，就把它拿来做普通数据卡片。
设计规范的作用是
减少需要猜的地方，不是把所有页面都规范成同一种颜色。
把用途写出来，比只列一串色值更容易被生成工具和团队成员正确理解。
文件里规定了固定侧栏加可滚动主内容区的布局，卡片和面板使用统一的内边距，表格采用一致的行高和浅色分隔线，表单字段要按关系分组。它还说明侧栏的深色只能用于导航，不能扩展到内容区域。
这些规则会直接影响AI生成后台页面的结构
，比如做一个库存管理页，侧栏应该先稳定下来，统计卡片、筛选区、表格和空状态再在主区域里排布。若只把颜色变量交给AI，没有说明布局和组件用途，生成结果仍可能把深色侧栏变成整块深色背景。
圆角也写得比较具体：默认值约为10px，卡片、输入框、按钮、标签和弹层保持一致，只有特殊徽章可以使用胶囊形。阴影使用带品牌色的轻阴影，不能换成中性的灰色投影。对于需要维护的产品，这些细节比“高级感”“现代感”更有判断价值。
这份Design.md的顶部变量写的是NotoSansSC，但后面的字体说明又使用Inter、苹方和微软雅黑的组合。两段文字各自都有道理，放在同一份规范里却会让执行者不知道哪一条优先。
只需要先确定项目的实际字体策略，再把变量名和说明统一。例如拉丁字符使用Inter，中文按系统使用苹方或微软雅黑，最后保留sans-serif作为兜底。若项目确实要使用NotoSansSC，就应把后面的描述一起改掉。
规范里出现冲突时，AI不会替团队做决定，只会在两种写法之间摇摆。
类似问题还包括颜色名称和实际用途不匹配、同一状态出现两个命名、组件变体没有说明适用条件。把这些冲突在生成前找出来，通常比生成十张页面后逐个修正更省时间。
设计规范解决的是“长什么样”，提示词还要交代“给谁用、先做什么”。例如可以这样描述一个电商运营后台：
“面向中文市场的运营人员，生成订单工作台。沿用Design.md的薄荷绿变量和固定侧栏布局，首屏优先显示待处理订单、退款金额和库存预警；表格需要覆盖空数据、加载失败、权限不足三种状态。”
在Paico里，
可以上传Design.md文件作为设计约束
，再补充页面目标、用户任务和必须出现的状态。AI生成UI界面后可以逐个检查主按钮是否使用primary、错误提示是否使用destructive、图表是否遵守色阶、侧栏是否保持独立。另外，一些作为灵感参考生成的UI界面，也可以直接提取Design.md，这样下次生成前可以作为设计规范约束。
如果团队在Pixso中已经有资源库，也可以直接用Pixso AI智能编辑，选中团队资源库，把按钮、表格、输入框和状态标签的组件一起作为依据，生成和修改设计稿。
一份能执行的设计规范Design.md不一定要很长，但颜色分别用于哪里，组件有哪些状态，页面结构怎样组织，出现例外时由谁判断要写清楚。另外，它还应该允许被修改。项目开始使用后，发现某种表格状态反复出现，就把它补回规范；发现某个规则只适用于营销页，也要标注范围。
AI生成UI的效率，
最终取决于输入的规则能不能落到画布上的按钮、表格和状态里
。把Design.md写成团队可以共同检查的文件，再让设计师保留修改和取舍的权利，规范才不会停在一份看起来完整、实际没人照着用的文档里。
