1. 先聊清楚AI 瞎编界面到底是在编什么如果你手头有哪怕一点点用 AI 生成网页或应用界面的经验大概率遇到过下面这些让人血压升高的场景让它做一个“用户管理后台”它直接给你画出一个带侧边栏、顶部导航、十六个数据卡片的标准模板看起来像模像样但你根本找不到“用户列表”在哪让它给三个按钮换个“现代化”的样式它把圆角调得能当轮胎用还顺手加了七层渐变投影最有意思的是它会一本正经地编造不存在的功能入口什么“AI测肤”“灵感广场”“元宇宙展厅”把一个 PDF 转表格工具做得像赛博朋克主题公园。这其实就是 AI 生成界面的核心病灶——大模型对于“界面”这个词的理解完全来自训练数据里的统计概率。它见过太多 Bootstrap admin 模板、太多 Dribbble 作品集、太多 SaaS 官网所以当你想让它做一个界面时它不是在“设计”而是在“缝合”它见过的各种组件碎片然后按照概率高低把它们堆到你面前。你说要一个登录页它十有八九先给出“欢迎回来”“邮箱地址”“密码”“忘记密码”“登录”这一套组合拳永不出错但也永远平庸。更让人头疼的是AI 输出界面的过程几乎没有任何“立场”。同一个问题换个问法它可能给你一套深色主题再换个提示词它又给你搞出毛玻璃切圆角。你问它为什么这里放了个橙色的按钮它也回答不上来因为它自己也不知道。它只是预估“橙色按钮 购买区域”在这个上下文里的概率比较高至于你的业务逻辑、你的用户习惯、你的视觉体系它一律不关心。我见过不少人为了解决这个问题拼命往提示词里塞描述——“要简洁、要高级、要科技感、颜色要蓝色系、字体要大一点”……然后 AI 输出的东西依旧不稳定。原因很简单“简洁”和“高级”这类形容词在模型眼里不过是一堆语义相近的向量它根本没有一个明确的参照物可循。这时候我意识到真正缺的不是更好的提示词而是一个能充当“视觉锚点”的东西。而这个东西最好是一个文件——一个 Markdown 文件。1.1 症状像是个很有礼貌的外行在帮你画图我习惯用一句话给这种情况定调AI 生成界面就像一位特别有礼貌但完全没审美的外行朋友你告诉他“我想要一个科技感的首页”他特别热情地给你推荐“那就来个深蓝色渐变背景加白色发光字吧”然后你还不能怪他因为你是这么要求的。但你要是给这位朋友一本“操作手册”呢手册上写清楚“首页顶部 60px 放置 logo 和导航”“首屏标题用 32px 加粗副标题用 16px 常规”“按钮统一 8px 圆角主色 #3B82F6悬停加深 10%”“不要渐变不要发光不要超过三种颜色”然后让他照着画。就算他审美再差画出来的东西也基本在可接受的范围内。原因很简单——他不需要理解设计他只需要执行规范。这就是 awesome-design-md 这一类思路的出发点不要试图让 AI 理解什么是“好看”而是把“好看”拆成一条条可执行、可量化、可校验的规则写进一个结构化的 Markdown 文件让 AI 像查字典一样去遵循它。1.2 根因大模型没有“视觉锚点”只有概率你应该听过“大模型本质是个概率模型”这种话但请注意这里的“概率”不是简单的“下一个词出现概率”它还包括了“语义空间里的邻近关系”。当你说“做一个卡片组件”时模型会在它的内部表示里找到一个区域这个区域聚集了大量和“卡片”相关的东西圆角矩形、阴影、图标、标题、描述文字、可能还有按钮。然后它按照训练时见过的频率把这些元素排列组合出来。问题在于它见过的“卡片”有十万种——带大图的有三万种、带头像的有两万种、带图标的有一万种、玻璃拟态的有一万种……它不可能知道你想要的是哪一种。所以它的输出结果就是各种特征的加权平均平均的结果往往是圆角够大但不匹配你的品牌、阴影够柔和但太泛、文字层级够分明但千篇一律。这就是为什么 AI 生成界面的观感永远“还行”但永远不够“对”。另一个隐藏的坑是大模型对“颜色”的记忆非常不准确。你让它用“品牌蓝”它大概率给你一个和你的品牌蓝八竿子打不着的蓝色。你直接给十六进制色值它倒是能输出但一旦你让它“稍微调亮一点”“换个类似的颜色”它就开始自由发挥最终产出一种脏兮兮的紫蓝色。视觉锚点的缺失让一切精细调整都变成了掷骰子。1.3 为什么偏偏是 Markdown 能救场市面上当然有其他方案——你可以用 JSON Schema、用 YAML、用设计 token 描述文件都能给 AI 提供结构化信息。但我个人非常偏爱 Markdown原因有三点。第一Markdown 是人类可读性最高的结构化格式之一。设计师、产品经理、前端工程师甚至不懂代码的老板都能看懂 Markdown 里写的是什么。这意味着这份“设计规范文件”可以成为一个团队内部的协作文档而不是只活在代码仓库里的配置文件。前端可以照着它写样式AI 可以照着它生成界面产品可以照着它评审设计同一个文件多方受益。第二Markdown 允许你用自然语言解释规则而不是把一切都压成字段。JSON 里你只能写borderRadius: 8px但 Markdown 里你可以写“按钮圆角使用 8px这是为了在视觉上和输入框保持一致不要使用圆形或胶囊形按钮”。这种带有上下文的表达恰恰是大模型最擅长理解的——它本来就是个语言模型你给它看文字说明比给它看冰冷的字段更容易激发它“按规矩办事”的模式。第三Markdown 的 token 消耗相对可控。相比一大段无序的提示词structured 的 Markdown 在同样信息量下更紧凑而且可以反复复用。你可以把这份文件放在项目的docs/目录里每次让 AI 生成界面时直接在提示词里引用它不需要每次重新描述一遍设计风格。2. awesome-design-md 的解决思路把设计意图“文本化”awesome-design-md 这个词你可以拆成两个部分理解。一部分是awesome-系列前缀这在开源社区里几乎约定俗成地表示“精选资源合集”——比如 awesome-vue、awesome-machine-learning它们都是收集了大量优质资源的列表。另一部分是design-md指的是“用 Markdown 承载设计规范”这件事。连起来的意思就是一份精心整理过的、能直接喂给 AI 用的 Markdown 设计规范以及围绕它的一套方法论。我知道网上已经有不少相关的开源项目和个人实践有些做得非常细致把整个设计系统都用 Markdown 描述了一遍连暗色模式下的颜色变量都列得清清楚楚。但更重要的不是组织列表而是理解这份文件的核心定位它是 AI 生成界面时的“第一参考资料”。2.1 一句话理解它的定位给 AI 生成界面时的传统做法是写一段包含大量形容词的提示词“请生成一个现代、简洁、有科技感的后台管理页面使用蓝色主题布局要合理卡片要有阴影整体风格要高端大气上档次。”这段提示词的问题很明显它全是主观感受没有一条是可执行的具体标准。awesome-design-md 的思路正好反过来。它把提示词里的形容词全部删掉替换成一组没有歧义的定义“现代” 使用无衬线字体、增加留白、减少装饰性元素“简洁” 每屏不超过三个视觉焦点、不使用不必要的渐变和装饰“科技感” 使用深色背景配合浅色文字、强调数据可视化的呈现“蓝色主题” 主色使用#2563EB辅助色使用#DBEAFE强调色使用#1D4ED8“卡片要有阴影” 卡片使用box-shadow: 0 1px 3px rgba(0,0,0,0.1)当所有主观描述都被“翻译”成这种可执行的规则时AI 的自由度就被限制在了合理的范围内。它不再需要猜测你要什么它只需要照着清单执行。这就是这份 Markdown 文件的定位——一份 AI 在设计时逐条照做的“施工图”。2.2 一个可复用的 Markdown 文件长什么样我个人的习惯是把这个文件命名为design.md放在项目的根目录或者docs/目录下。下面是我在实际项目里验证过可用的一个结构模板你可以直接复制修改# 项目设计规范 ## 1. 项目概述 - 项目名称XXX - 产品定位XXX一句话说清产品是干嘛的 - 目标用户XXX - 核心使用场景XXX ## 2. 视觉基础 ### 2.1 色彩系统 - 主色#4F46E5按钮、链接、选中态 - 辅助色#EEF2FF选中背景、标签背景 - 成功色#16A34A成功提示、完成状态 - 警告色#D97706需注意的状态 - 错误色#DC2626失败提示、删除操作 - 中性色—文字#111827正文 - 中性色—次级文字#6B7280辅助说明 - 中性色—边框#E5E7EB分割线、输入框边框 - 中性色—背景#F9FAFB页面底色 ### 2.2 字体排版 - 中文优先使用系统字体PingFang SC, Microsoft YaHei, sans-serif - 英文和数字使用Inter, sans-serif - 标题字号20px / 加粗 / 行高 1.4 - 正文字号14px / 常规 / 行高 1.6 - 辅助文字12px / 常规 / 颜色使用次级文字色 ### 2.3 间距体系 - 页面左右内边距24px - 模块间距24px - 组件间距16px - 内容间距8px ### 2.4 圆角与阴影 - 按钮圆角8px不要使用胶囊形按钮 - 卡片圆角12px - 卡片阴影0 1px 2px rgba(0, 0, 0, 0.05) ## 3. 组件规范 ### 3.1 按钮 - 主要按钮主色背景、白色文字、8px 圆角、高度 36px、内边距 12px 16px - 次要按钮白色背景、边框 1px 中性边框色、文字主色 - 危险按钮错误色背景、白色文字仅用于删除等破坏性操作 ### 3.2 卡片 - 白色背景、12px 圆角、1px 边框#F3F4F6、阴影按 2.4 规定 - 卡片标题16px / 加粗 - 卡片内容14px / 常规 / 次级文字颜色 ### 3.3 表格 - 表头背景#F9FAFB、文字加粗 - 单元格内边距12px 16px - 行分割线底部 1px #F3F4F6 - 悬停行背景#F9FAFB ## 4. 文案规范 - 所有文案使用简体中文 - 按钮文字必须包含明确的操作动词如“新建项目”“保存修改”“导出报表” - 禁止使用夸张宣传语和营销口吻 - 空状态文案格式“暂无{内容}”例如“暂无待办事项” ## 5. 禁止事项 - 不使用渐变作为按钮背景 - 不使用发光效果 - 不使用大于 12px 的圆角卡片除外 - 不自动生成图标图标统一使用 lucide-react 库 - 不多余添加组件页面上出现的任何元素都必须有实际功能你会发现这个文件里除了视觉规范还特意写了“文案规范”和“禁止事项”。这是很多人容易忽略的关键点——AI 瞎编界面不只是编视觉还编内容。它经常会在空列表里写“空空如也”在删除确认框里写“此操作无法撤销”在表单里写“请输入正确的邮箱”。这些都还好最烦的是它会编造功能入口和营销文案。所以你必须明确告诉它“不要干什么”这比告诉它“要干什么”往往更重要。2.3 为什么这个文件能约束 AI 的行为我曾经和一个做前端的朋友聊到这件事他第一反应是“这不就是把设计规范写成文档发给 AI 吗它真的会读吗”确实这里有个关键的认知差异。AI 不是“读”你的 Markdown 文件然后理解并执行而是在生成响应时你的文件是作为上下文的一部分被输入的。你给它多大的上下文权重它就有多大的概率遵循里面的规则。所以问题不在于“它会不会看”而在于“你怎么确保它优先看这个文件而不是凭记忆发挥”。我实际操作下来的经验是需要在提示词里明确加上类似“严格按照design.md中的规范执行文件中未定义的内容一律不要添加”这样的指令。这句话不是形式主义它真的能大幅降低 AI 自说自话的概率。另外还有一个“开关”值得打开多数大模型现在都支持系统提示词system prompt和用户提示词user prompt的分离。把 Markdown 文件的内容放进系统提示词把生成请求放进用户提示词效果比混在一起要好得多。原因也很容易理解系统提示词定义了 AI 的身份和总的行为准则用户提示词则是一次性的任务。你把设计规范放在系统提示词里等于告诉 AI“你是这个设计系统的执行者”否则它就只是一个临时接到需求的人。3. 实操三十分钟搭好你自己的设计规范文件我知道你看了上面的模板可能还是觉得有点抽象下面我详细拆一遍我实际搭建这份文件的过程。你可以把它当成一次“抄作业”参考也可以基于它改出一份属于自己的版本。3.1 准备工作先想清楚你要 AI 输出什么动手写文件之前先花五分钟回答三个问题这是什么类型的界面后台管理、官网、移动端 H5、数据看板……不同类型对应的规范差异很大。后台管理重在信息密度和布局稳定官网重在视觉冲击和品牌调性数据看板重在图表清晰和指标突出。整个产品最重要的视觉记忆点是什么比方说项目管理工具可能强调“集中”和“清爽”电商后台强调“数据”和“转化”开发者工具强调“极客”和“高效”。这个记忆点最好用一个词或一句话表达后面写文件时反复回到这个原点。哪些点是绝对不能妥协的有些人可能特别在意圆角不能太大有些人绝对不能接受渐变有些人希望所有表格都要有斑马纹。这些“禁忌”单独列出来写进“禁止事项”那一节。别小看这三个问题。我见过不少现成的 awesome-design-md 类文件写得很全面但用到自己项目上还是感觉不对劲就是因为缺少针对性。一个通用的规范文件可以约束下限但只有贴合产品定位的规范才能拉高上限。3.2 文件结构从元信息到组件清单具体写文件时我建议按照下面这个顺序组织从宏观到微观AI 理解起来会更容易项目概述告诉 AI 你这个产品是什么、给谁用、核心场景是什么。有了这个上下文AI 生成文案时会更贴切不会写出与产品定位不符的内容。设计原则用三到五句话描述视觉风格走向。这里的用语可以稍微抽象一点但最好配合具体的解释。比如“营造专业可信赖感——使用深蓝主色、稳重阴影、克制装饰”。视觉基元色彩、字体、间距、圆角、阴影。这些是整个设计系统的“原子”越精确越好。每个值都尽量给出十六进制色值、像素数字。组件规范按钮、输入框、卡片、表格、弹窗、表单、导航。不需要把每个组件都写一遍只写你这个项目里大概率用到的组件。关键参数包括尺寸、内边距、边框、圆角、颜色、状态悬停、禁用、选中。文案规范语言风格、常见格式、禁止使用的口吻。禁止事项明确列出不能做的事。参考示例放一两个标准页面的布局描述。注意是文字描述不是图片。可以写“顶部导航高度 56px左侧菜单宽度 200px主内容区白色背景页面标题 20px 加粗右上角放置主要按钮”。这里我特别想强调一点不要把所有组件都塞进一份文件里。如果你的项目很庞大比如有几十种复杂组件我建议按照页面类别拆分成多个文件——design-base.md放视觉基元design-components.md放组件规范design-pages.md放页面模板。在具体任务里按需引用省 token 不说还能避免 AI 因为上下文过长而“注意力涣散”漏掉关键规则。3.3 让 AI 严格执行的技巧约束词怎么写才有效把文件写好还不够你得会“喂”给 AI。这里分享几个我实测有效的操作方式。第一个技巧是优先级声明。在文件的顶部加一行“本文件是该项目唯一的界面设计权威参考。当其他指令与本文件冲突时以本文件为准。”这听起来像废话但真的有用。大模型在生成时会对指令的“权威性”有一定的敏感度明确宣布“唯一权威”能显著提高遵循率。第二个技巧是在用户提示词里复述关键约束。比如你想让 AI 生成一个表格页面在请求里加上“表格遵循 design.md 3.3 节的规范白底、表头浅灰、行间分割线、悬停变浅灰”。这么做相当于设置了双重保险。因为文件虽然放在上下文里但 AI 在生成长文本时可能“忘记”引用距离较远的信息你主动复述一遍它就没理由再编了。第三个技巧是要求 AI 先写“实施说明”。在生成界面代码之前让 AI 先输出一小段文字说明它将如何应用 design.md 中的规范。比如“根据 design.md我将为按钮添加 36px 的高度、8px 的圆角和 #4F46E5 的背景色。”这一步能强迫 AI 在生成前先“翻阅”一遍规范文档大幅降低遗漏的概率。说白了就是让模型先过一遍脑子再动手干活。第四个技巧是把 Markdown 文件转换成对话形式。如果你用的是支持上下文记忆的 AI 对话工具可以先把整份 design.md 发给它然后问“你理解这份设计规范了吗请概括一下其中的色彩系统和组件规则。”等它复述准确之后再让它干活。这个办法有两个好处一是确认 AI 确实“收到”了规则二是借它的复述发现你自己文件里没写清楚的地方。4. 实战案例用一份 Markdown 让 AI 生成完整后台页面前面讲了一堆理论下面用一个我最近实际做过的项目来完整演示一下。项目是一个内部用的数据报表后台功能包括数据总览、用户列表、报表导出、操作日志。这个项目的使用者都是公司内部员工对视觉效果要求不高但要求信息密度高、扫描效率好、别出幺蛾子。4.1 需求描述与初始生成效果我最早采用的是传统提示词玩法。当时的请求大概是这样的“生成一个数据报表后台首页包含顶部统计栏、图表、最近订单表格、快捷操作入口。整体风格简约现代蓝色系卡片要好看图表用柱状图和折线图。”AI 输出的第一版怎么说呢一眼看上去挺专业的深蓝色侧边栏、白色主内容区、四张渐变背景的统计卡片、两张图表区域、一个订单表格。但你仔细看就会发现一堆问题四张统计卡片的渐变都不一样看起来像四种不同风格的模板拼在一起统计卡片里的数字旁边都加了一个 icon但那些 icon 是我从未要求的而且风格不统一图表区域是真正能用的吗不是它只是给了一张 SVG 截图风格的假图侧边栏的菜单项里出现了“智能分析”“销售预测”这种我们根本没有的功能表格里的数据完全是为了占位编出来的有些用户的头像用了一堆被裁切的抽象色块这套东西你要拿给同事评审对方第一反应大概率是“这模板感太重了不像我们公司的系统。”问题就出在这里——它确实像模板因为它就是从成千上万个模板里取的平均值。4.2 加入 Markdown 规范前后的对比后来我把 design.md 写了出来关键内容大概是这样的主色定为#2563EB背景统一浅灰#F8FAFC卡片纯白统计卡片禁止使用渐变白底、12px 圆角、顶部加一条 3px 主色分隔线表格列顺序和字段名必须与需求描述完全一致不得自行增加列图表区域先留一个容器占位不要生成模拟图表图片侧边栏菜单项以需求描述中的功能列表为准不得添加未定义功能页脚区域取消不显示任何版权、技术支持信息然后把这份文件喂给 AI给出同样的生成请求。第二版的差异非常明显统计卡片统一了风格白底、细边框、左侧主色竖条信息清晰不再花里胡哨侧边栏菜单只有我列出的四个功能数据总览、用户列表、报表导出、操作日志表格列名严格对准需求“用户 ID、姓名、注册时间、订单数、总消费、操作”没有多余列图表区域放了一个带虚线边框的占位容器里面写着“图表渲染区数据由前端接入”彻底杜绝了假图表的问题最深的一个感受是第二版可能不惊艳但非常可靠。你知道它不会在某个你没留意的角落给你放一个莫名其妙的“充值会员”按钮。4.3 迭代过程中的参数与提示词调整记录写规范文件不是一次到位的我在这个项目里做了三轮调整你也可以参考我的阀值第一轮调整发生在“按钮换色”这个需求上。产品经理希望把“导出报表”按钮做成醒目的强调按钮。我最初在文件里定了主色#2563EB但 PM 觉得“导出”这个动作太重要要更醒目。于是我在规范里引入了“强调按钮”概念主色背景、白色文字、额外在按钮前加一个下载图标。这次调整没有动任何其他组件AI 的输出也自然跟着变了。第二轮调整发生在“页面头部”上。原本 AI 给每个页面顶部都放了一个大标题比如“数据总览”“用户列表”。但我们实际项目里的头部是固定导航栏下面一条窄标题区高度 48px左对齐标题右侧放操作按钮。我把这条写进规范后AI 在生成新页面时就会自动遵循同样的头部结构不会再自己发挥成大横幅。第三轮是“禁止事项”的补充。第二版生成后我发现 AI 在“用户列表”页面的操作列里给每个用户都放了“编辑”“删除”“导出”三个 icon 按钮。这实际违反了我们的交互原则——删除应该收敛到一个下拉菜单里避免误操作。于是我在规范里加了“操作列表中的危险操作必须放到下拉菜单里不直接暴露删除按钮”。后续生成就完全改掉了这个坏习惯。整个过程下来我的体会是规范文件要有“生长性”。它不是写一次就封存的静态文档而是随着项目推进、踩坑不断补充的活文档。每当你发现 AI 在某个地方行为不如预期就把它纳入规范文件下一次就不会再犯。5. 常见问题与避坑指南和 AI 协作生成界面失败案例远远多于成功案例。即便你有了完善的 Markdown 规范文件也依然会碰到各种幺蛾子。这一节我把高频踩坑点整理成一个速查表外加几条独家心得希望能帮你少走弯路。5.1 问题速查表问题现象可能原因解决方案AI 完全无视规范文件输出的还是模板风格规范文件未被有效放置在上下文中或提示词里没有明确要求遵循把规范内容放进系统提示词并在用户提示词里声明“严格按照 design.md 执行”只遵守了一部分规则其他部分放飞自我上下文太长导致“注意力漂移”或者规则写得不够显眼在每次请求中复述本次任务最关键的 2-3 条规则将最重要的规范放在文件开头的显眼位置生成的颜色总是偏离你给的色值大模型对具体色值的重现能力较弱经常做了近似处理并觉得这“也行”在文件中给每个色值配一句语义说明如“主色 #2563EB对应品牌蓝禁止替换”必要时要求输出 CSS 变量自动添加你没要求的功能/图标/菜单项模型基于训练数据补全了它认为“应该有”的东西在“禁止事项”里明确列出不允许添加的功能类别给出功能清单并强调“只包含清单中的内容”生成的文案与实际业务不符甚至出现引导性话术文件缺少文案规范补充“文案规范”章节明确语言风格、常用句式和禁用句式同一份文件不同会话里生成的效果不一致模型随机性或上下文差异尽量固定系统提示词每次生成后把最终效果作为后续对话的参考上下文文件太长AI 抓不住重点规范文件过于庞杂重点被淹没拆分文件基础规范与页面规范分开按具体任务选择性引用使用了未定义的颜色或圆角规范中没写这些维度模型按它自带的“审美”补全了检查规范是否覆盖了颜色、间距、圆角、阴影、字体等全部视觉维度补全后再试要我总结一下这张表最核心的一句话那就是你的规范文件覆盖到什么程度AI 的输出就有多可靠。所有“AI 发挥过头”的案例归根结底都是因为你在某个维度上没有给出约束。5.2 我的几个独家心得下面这几条不一定能在网上找到属于实际项目里被恶心过之后的总结。第一条不要用形容词定义颜色。你在规范里写“浅蓝色背景”在 AI 眼里不如直接写background: #EFF6FF来得准。如果担心设计师不熟悉十六进制可以写成“浅蓝#EFF6FF用于选中状态背景”这样就同时满足了人和机器的可读性。第二条让 AI 生成的组件“对不上”时先检查是不是规范本身有歧义。举个例子如果你写“页面背景使用浅灰色”AI 可能会用#F3F4F6也可能用#F9FAFB这两个我都见过。哪怕都是“浅灰”不同人感知也不一样。所以干脆直接把色值写上一条歧义就消灭了。第三条善用“参考示例”而非“抽象描述”。你对 AI 说“表格要有高级感”它很可能给你加条纹、加圆角、加阴影、加悬浮高亮所有“高级”的要素全都来一遍。但如果你给它一个具体的表格布局描述“表头背景 #F9FAFB单元格垂直居中每行底部 1px #F3F4F6 分割线行距 12px”它的输出就完全在你的掌控之中了。我已经不止一次体会到给 AI 一个具体案例比给十句抽象描述有用得多。第四条生成代码类任务时让 AI 把规范中的值直接映射到 Tailwind 类或者 CSS 变量。比如在规范里给出主色: #2563EB 对应 Tailwind: blue-600 对应 CSS 变量: --color-primary这样做有两个好处一是人对最终代码更熟悉二是 AI 在生成时更容易前后一致。因为在它的训练数据里Tailwind 的 blue-600 和#2563EB的关联是高度稳定的。6. 写在最后这个思路还能怎么扩展最后想说说这套方法在更广阔的领域里的应用方向。用 Markdown 规范文件去约束 AI 生成界面本质上是用文本去建模视觉系统。既然视觉可以被文本建模那么其他领域也一样可以套用这个思路。我自己正在尝试的一个扩展方向是“文档结构规范”。公司的各种对外文档、产品手册也可以用类似的 Markdown 文件定义标题层级、术语表、图片风格、段落节奏让 AI 在生成文档时不再写出那种“一眼 AI”的排比句和空洞总结。另一个方向是“数据可视化规范”。让 AI 生成图表时直接在 Markdown 里规定图表的类型选择逻辑——什么时候用柱状图、什么时候用折线图、颜色怎么映射、标签怎么显示。这样生成的图表就不再是花里胡哨的默认模板而是真正贴合业务逻辑的可视化方案。再进一步想这个思路还可以应用到 **“AI Agent 的交互规范”**上。如果你的 Agent 要调用多个工具、完成多个步骤你可以用 Markdown 文件定义每一步的输出格式、状态文案、错误处理方式。这样 Agent 的行为就不会“漂移”每一步都严格在你设定的轨道上运行。我个人对 awesome-design-md 最大的感触是它表面上是一个“让 AI 好好做 UI”的提示工程方案但深层次上它让我们重新思考了一个问题——我们应该如何跟一个既聪明又缺乏常识的助手协作答案是把规则说清楚、把流程固定下来、把边界划明白。这不仅仅是技术方法更是一种协作哲学。如果你也想尝试我建议从一个小小的项目开始——比如一份“个人简历投递系统”的后台或者一个“宠物用品商城”的官网。先花三十分钟写一版设计规范再让 AI 照着它做。做完之后你会发现那份报告里少了很多“意外惊喜”但多了很多“本来就应该如此”的顺滑感。这种感觉其实是和 AI 协作里非常难得的确定感。 
长河君 · 2026/10/26 8:05:30 · 阅读 1.2k 用Markdown设计规范，让AI生成界面告别随机发挥
1. 先聊清楚AI 瞎编界面到底是在编什么如果你手头有哪怕一点点用 AI 生成网页或应用界面的经验大概率遇到过下面这些让人血压升高的场景让它做一个“用户管理后台”它直接给你画出一个带侧边栏、顶部导航、十六个数据卡片的标准模板看起来像模像样但你根本找不到“用户列表”在哪让它给三个按钮换个“现代化”的样式它把圆角调得能当轮胎用还顺手加了七层渐变投影最有意思的是它会一本正经地编造不存在的功能入口什么“AI测肤”“灵感广场”“元宇宙展厅”把一个 PDF 转表格工具做得像赛博朋克主题公园。这其实就是 AI 生成界面的核心病灶——大模型对于“界面”这个词的理解完全来自训练数据里的统计概率。它见过太多 Bootstrap admin 模板、太多 Dribbble 作品集、太多 SaaS 官网所以当你想让它做一个界面时它不是在“设计”而是在“缝合”它见过的各种组件碎片然后按照概率高低把它们堆到你面前。你说要一个登录页它十有八九先给出“欢迎回来”“邮箱地址”“密码”“忘记密码”“登录”这一套组合拳永不出错但也永远平庸。更让人头疼的是AI 输出界面的过程几乎没有任何“立场”。同一个问题换个问法它可能给你一套深色主题再换个提示词它又给你搞出毛玻璃切圆角。你问它为什么这里放了个橙色的按钮它也回答不上来因为它自己也不知道。它只是预估“橙色按钮 购买区域”在这个上下文里的概率比较高至于你的业务逻辑、你的用户习惯、你的视觉体系它一律不关心。我见过不少人为了解决这个问题拼命往提示词里塞描述——“要简洁、要高级、要科技感、颜色要蓝色系、字体要大一点”……然后 AI 输出的东西依旧不稳定。原因很简单“简洁”和“高级”这类形容词在模型眼里不过是一堆语义相近的向量它根本没有一个明确的参照物可循。这时候我意识到真正缺的不是更好的提示词而是一个能充当“视觉锚点”的东西。而这个东西最好是一个文件——一个 Markdown 文件。1.1 症状像是个很有礼貌的外行在帮你画图我习惯用一句话给这种情况定调AI 生成界面就像一位特别有礼貌但完全没审美的外行朋友你告诉他“我想要一个科技感的首页”他特别热情地给你推荐“那就来个深蓝色渐变背景加白色发光字吧”然后你还不能怪他因为你是这么要求的。但你要是给这位朋友一本“操作手册”呢手册上写清楚“首页顶部 60px 放置 logo 和导航”“首屏标题用 32px 加粗副标题用 16px 常规”“按钮统一 8px 圆角主色 #3B82F6悬停加深 10%”“不要渐变不要发光不要超过三种颜色”然后让他照着画。就算他审美再差画出来的东西也基本在可接受的范围内。原因很简单——他不需要理解设计他只需要执行规范。这就是 awesome-design-md 这一类思路的出发点不要试图让 AI 理解什么是“好看”而是把“好看”拆成一条条可执行、可量化、可校验的规则写进一个结构化的 Markdown 文件让 AI 像查字典一样去遵循它。1.2 根因大模型没有“视觉锚点”只有概率你应该听过“大模型本质是个概率模型”这种话但请注意这里的“概率”不是简单的“下一个词出现概率”它还包括了“语义空间里的邻近关系”。当你说“做一个卡片组件”时模型会在它的内部表示里找到一个区域这个区域聚集了大量和“卡片”相关的东西圆角矩形、阴影、图标、标题、描述文字、可能还有按钮。然后它按照训练时见过的频率把这些元素排列组合出来。问题在于它见过的“卡片”有十万种——带大图的有三万种、带头像的有两万种、带图标的有一万种、玻璃拟态的有一万种……它不可能知道你想要的是哪一种。所以它的输出结果就是各种特征的加权平均平均的结果往往是圆角够大但不匹配你的品牌、阴影够柔和但太泛、文字层级够分明但千篇一律。这就是为什么 AI 生成界面的观感永远“还行”但永远不够“对”。另一个隐藏的坑是大模型对“颜色”的记忆非常不准确。你让它用“品牌蓝”它大概率给你一个和你的品牌蓝八竿子打不着的蓝色。你直接给十六进制色值它倒是能输出但一旦你让它“稍微调亮一点”“换个类似的颜色”它就开始自由发挥最终产出一种脏兮兮的紫蓝色。视觉锚点的缺失让一切精细调整都变成了掷骰子。1.3 为什么偏偏是 Markdown 能救场市面上当然有其他方案——你可以用 JSON Schema、用 YAML、用设计 token 描述文件都能给 AI 提供结构化信息。但我个人非常偏爱 Markdown原因有三点。第一Markdown 是人类可读性最高的结构化格式之一。设计师、产品经理、前端工程师甚至不懂代码的老板都能看懂 Markdown 里写的是什么。这意味着这份“设计规范文件”可以成为一个团队内部的协作文档而不是只活在代码仓库里的配置文件。前端可以照着它写样式AI 可以照着它生成界面产品可以照着它评审设计同一个文件多方受益。第二Markdown 允许你用自然语言解释规则而不是把一切都压成字段。JSON 里你只能写borderRadius: 8px但 Markdown 里你可以写“按钮圆角使用 8px这是为了在视觉上和输入框保持一致不要使用圆形或胶囊形按钮”。这种带有上下文的表达恰恰是大模型最擅长理解的——它本来就是个语言模型你给它看文字说明比给它看冰冷的字段更容易激发它“按规矩办事”的模式。第三Markdown 的 token 消耗相对可控。相比一大段无序的提示词structured 的 Markdown 在同样信息量下更紧凑而且可以反复复用。你可以把这份文件放在项目的docs/目录里每次让 AI 生成界面时直接在提示词里引用它不需要每次重新描述一遍设计风格。2. awesome-design-md 的解决思路把设计意图“文本化”awesome-design-md 这个词你可以拆成两个部分理解。一部分是awesome-系列前缀这在开源社区里几乎约定俗成地表示“精选资源合集”——比如 awesome-vue、awesome-machine-learning它们都是收集了大量优质资源的列表。另一部分是design-md指的是“用 Markdown 承载设计规范”这件事。连起来的意思就是一份精心整理过的、能直接喂给 AI 用的 Markdown 设计规范以及围绕它的一套方法论。我知道网上已经有不少相关的开源项目和个人实践有些做得非常细致把整个设计系统都用 Markdown 描述了一遍连暗色模式下的颜色变量都列得清清楚楚。但更重要的不是组织列表而是理解这份文件的核心定位它是 AI 生成界面时的“第一参考资料”。2.1 一句话理解它的定位给 AI 生成界面时的传统做法是写一段包含大量形容词的提示词“请生成一个现代、简洁、有科技感的后台管理页面使用蓝色主题布局要合理卡片要有阴影整体风格要高端大气上档次。”这段提示词的问题很明显它全是主观感受没有一条是可执行的具体标准。awesome-design-md 的思路正好反过来。它把提示词里的形容词全部删掉替换成一组没有歧义的定义“现代” 使用无衬线字体、增加留白、减少装饰性元素“简洁” 每屏不超过三个视觉焦点、不使用不必要的渐变和装饰“科技感” 使用深色背景配合浅色文字、强调数据可视化的呈现“蓝色主题” 主色使用#2563EB辅助色使用#DBEAFE强调色使用#1D4ED8“卡片要有阴影” 卡片使用box-shadow: 0 1px 3px rgba(0,0,0,0.1)当所有主观描述都被“翻译”成这种可执行的规则时AI 的自由度就被限制在了合理的范围内。它不再需要猜测你要什么它只需要照着清单执行。这就是这份 Markdown 文件的定位——一份 AI 在设计时逐条照做的“施工图”。2.2 一个可复用的 Markdown 文件长什么样我个人的习惯是把这个文件命名为design.md放在项目的根目录或者docs/目录下。下面是我在实际项目里验证过可用的一个结构模板你可以直接复制修改# 项目设计规范 ## 1. 项目概述 - 项目名称XXX - 产品定位XXX一句话说清产品是干嘛的 - 目标用户XXX - 核心使用场景XXX ## 2. 视觉基础 ### 2.1 色彩系统 - 主色#4F46E5按钮、链接、选中态 - 辅助色#EEF2FF选中背景、标签背景 - 成功色#16A34A成功提示、完成状态 - 警告色#D97706需注意的状态 - 错误色#DC2626失败提示、删除操作 - 中性色—文字#111827正文 - 中性色—次级文字#6B7280辅助说明 - 中性色—边框#E5E7EB分割线、输入框边框 - 中性色—背景#F9FAFB页面底色 ### 2.2 字体排版 - 中文优先使用系统字体PingFang SC, Microsoft YaHei, sans-serif - 英文和数字使用Inter, sans-serif - 标题字号20px / 加粗 / 行高 1.4 - 正文字号14px / 常规 / 行高 1.6 - 辅助文字12px / 常规 / 颜色使用次级文字色 ### 2.3 间距体系 - 页面左右内边距24px - 模块间距24px - 组件间距16px - 内容间距8px ### 2.4 圆角与阴影 - 按钮圆角8px不要使用胶囊形按钮 - 卡片圆角12px - 卡片阴影0 1px 2px rgba(0, 0, 0, 0.05) ## 3. 组件规范 ### 3.1 按钮 - 主要按钮主色背景、白色文字、8px 圆角、高度 36px、内边距 12px 16px - 次要按钮白色背景、边框 1px 中性边框色、文字主色 - 危险按钮错误色背景、白色文字仅用于删除等破坏性操作 ### 3.2 卡片 - 白色背景、12px 圆角、1px 边框#F3F4F6、阴影按 2.4 规定 - 卡片标题16px / 加粗 - 卡片内容14px / 常规 / 次级文字颜色 ### 3.3 表格 - 表头背景#F9FAFB、文字加粗 - 单元格内边距12px 16px - 行分割线底部 1px #F3F4F6 - 悬停行背景#F9FAFB ## 4. 文案规范 - 所有文案使用简体中文 - 按钮文字必须包含明确的操作动词如“新建项目”“保存修改”“导出报表” - 禁止使用夸张宣传语和营销口吻 - 空状态文案格式“暂无{内容}”例如“暂无待办事项” ## 5. 禁止事项 - 不使用渐变作为按钮背景 - 不使用发光效果 - 不使用大于 12px 的圆角卡片除外 - 不自动生成图标图标统一使用 lucide-react 库 - 不多余添加组件页面上出现的任何元素都必须有实际功能你会发现这个文件里除了视觉规范还特意写了“文案规范”和“禁止事项”。这是很多人容易忽略的关键点——AI 瞎编界面不只是编视觉还编内容。它经常会在空列表里写“空空如也”在删除确认框里写“此操作无法撤销”在表单里写“请输入正确的邮箱”。这些都还好最烦的是它会编造功能入口和营销文案。所以你必须明确告诉它“不要干什么”这比告诉它“要干什么”往往更重要。2.3 为什么这个文件能约束 AI 的行为我曾经和一个做前端的朋友聊到这件事他第一反应是“这不就是把设计规范写成文档发给 AI 吗它真的会读吗”确实这里有个关键的认知差异。AI 不是“读”你的 Markdown 文件然后理解并执行而是在生成响应时你的文件是作为上下文的一部分被输入的。你给它多大的上下文权重它就有多大的概率遵循里面的规则。所以问题不在于“它会不会看”而在于“你怎么确保它优先看这个文件而不是凭记忆发挥”。我实际操作下来的经验是需要在提示词里明确加上类似“严格按照design.md中的规范执行文件中未定义的内容一律不要添加”这样的指令。这句话不是形式主义它真的能大幅降低 AI 自说自话的概率。另外还有一个“开关”值得打开多数大模型现在都支持系统提示词system prompt和用户提示词user prompt的分离。把 Markdown 文件的内容放进系统提示词把生成请求放进用户提示词效果比混在一起要好得多。原因也很容易理解系统提示词定义了 AI 的身份和总的行为准则用户提示词则是一次性的任务。你把设计规范放在系统提示词里等于告诉 AI“你是这个设计系统的执行者”否则它就只是一个临时接到需求的人。3. 实操三十分钟搭好你自己的设计规范文件我知道你看了上面的模板可能还是觉得有点抽象下面我详细拆一遍我实际搭建这份文件的过程。你可以把它当成一次“抄作业”参考也可以基于它改出一份属于自己的版本。3.1 准备工作先想清楚你要 AI 输出什么动手写文件之前先花五分钟回答三个问题这是什么类型的界面后台管理、官网、移动端 H5、数据看板……不同类型对应的规范差异很大。后台管理重在信息密度和布局稳定官网重在视觉冲击和品牌调性数据看板重在图表清晰和指标突出。整个产品最重要的视觉记忆点是什么比方说项目管理工具可能强调“集中”和“清爽”电商后台强调“数据”和“转化”开发者工具强调“极客”和“高效”。这个记忆点最好用一个词或一句话表达后面写文件时反复回到这个原点。哪些点是绝对不能妥协的有些人可能特别在意圆角不能太大有些人绝对不能接受渐变有些人希望所有表格都要有斑马纹。这些“禁忌”单独列出来写进“禁止事项”那一节。别小看这三个问题。我见过不少现成的 awesome-design-md 类文件写得很全面但用到自己项目上还是感觉不对劲就是因为缺少针对性。一个通用的规范文件可以约束下限但只有贴合产品定位的规范才能拉高上限。3.2 文件结构从元信息到组件清单具体写文件时我建议按照下面这个顺序组织从宏观到微观AI 理解起来会更容易项目概述告诉 AI 你这个产品是什么、给谁用、核心场景是什么。有了这个上下文AI 生成文案时会更贴切不会写出与产品定位不符的内容。设计原则用三到五句话描述视觉风格走向。这里的用语可以稍微抽象一点但最好配合具体的解释。比如“营造专业可信赖感——使用深蓝主色、稳重阴影、克制装饰”。视觉基元色彩、字体、间距、圆角、阴影。这些是整个设计系统的“原子”越精确越好。每个值都尽量给出十六进制色值、像素数字。组件规范按钮、输入框、卡片、表格、弹窗、表单、导航。不需要把每个组件都写一遍只写你这个项目里大概率用到的组件。关键参数包括尺寸、内边距、边框、圆角、颜色、状态悬停、禁用、选中。文案规范语言风格、常见格式、禁止使用的口吻。禁止事项明确列出不能做的事。参考示例放一两个标准页面的布局描述。注意是文字描述不是图片。可以写“顶部导航高度 56px左侧菜单宽度 200px主内容区白色背景页面标题 20px 加粗右上角放置主要按钮”。这里我特别想强调一点不要把所有组件都塞进一份文件里。如果你的项目很庞大比如有几十种复杂组件我建议按照页面类别拆分成多个文件——design-base.md放视觉基元design-components.md放组件规范design-pages.md放页面模板。在具体任务里按需引用省 token 不说还能避免 AI 因为上下文过长而“注意力涣散”漏掉关键规则。3.3 让 AI 严格执行的技巧约束词怎么写才有效把文件写好还不够你得会“喂”给 AI。这里分享几个我实测有效的操作方式。第一个技巧是优先级声明。在文件的顶部加一行“本文件是该项目唯一的界面设计权威参考。当其他指令与本文件冲突时以本文件为准。”这听起来像废话但真的有用。大模型在生成时会对指令的“权威性”有一定的敏感度明确宣布“唯一权威”能显著提高遵循率。第二个技巧是在用户提示词里复述关键约束。比如你想让 AI 生成一个表格页面在请求里加上“表格遵循 design.md 3.3 节的规范白底、表头浅灰、行间分割线、悬停变浅灰”。这么做相当于设置了双重保险。因为文件虽然放在上下文里但 AI 在生成长文本时可能“忘记”引用距离较远的信息你主动复述一遍它就没理由再编了。第三个技巧是要求 AI 先写“实施说明”。在生成界面代码之前让 AI 先输出一小段文字说明它将如何应用 design.md 中的规范。比如“根据 design.md我将为按钮添加 36px 的高度、8px 的圆角和 #4F46E5 的背景色。”这一步能强迫 AI 在生成前先“翻阅”一遍规范文档大幅降低遗漏的概率。说白了就是让模型先过一遍脑子再动手干活。第四个技巧是把 Markdown 文件转换成对话形式。如果你用的是支持上下文记忆的 AI 对话工具可以先把整份 design.md 发给它然后问“你理解这份设计规范了吗请概括一下其中的色彩系统和组件规则。”等它复述准确之后再让它干活。这个办法有两个好处一是确认 AI 确实“收到”了规则二是借它的复述发现你自己文件里没写清楚的地方。4. 实战案例用一份 Markdown 让 AI 生成完整后台页面前面讲了一堆理论下面用一个我最近实际做过的项目来完整演示一下。项目是一个内部用的数据报表后台功能包括数据总览、用户列表、报表导出、操作日志。这个项目的使用者都是公司内部员工对视觉效果要求不高但要求信息密度高、扫描效率好、别出幺蛾子。4.1 需求描述与初始生成效果我最早采用的是传统提示词玩法。当时的请求大概是这样的“生成一个数据报表后台首页包含顶部统计栏、图表、最近订单表格、快捷操作入口。整体风格简约现代蓝色系卡片要好看图表用柱状图和折线图。”AI 输出的第一版怎么说呢一眼看上去挺专业的深蓝色侧边栏、白色主内容区、四张渐变背景的统计卡片、两张图表区域、一个订单表格。但你仔细看就会发现一堆问题四张统计卡片的渐变都不一样看起来像四种不同风格的模板拼在一起统计卡片里的数字旁边都加了一个 icon但那些 icon 是我从未要求的而且风格不统一图表区域是真正能用的吗不是它只是给了一张 SVG 截图风格的假图侧边栏的菜单项里出现了“智能分析”“销售预测”这种我们根本没有的功能表格里的数据完全是为了占位编出来的有些用户的头像用了一堆被裁切的抽象色块这套东西你要拿给同事评审对方第一反应大概率是“这模板感太重了不像我们公司的系统。”问题就出在这里——它确实像模板因为它就是从成千上万个模板里取的平均值。4.2 加入 Markdown 规范前后的对比后来我把 design.md 写了出来关键内容大概是这样的主色定为#2563EB背景统一浅灰#F8FAFC卡片纯白统计卡片禁止使用渐变白底、12px 圆角、顶部加一条 3px 主色分隔线表格列顺序和字段名必须与需求描述完全一致不得自行增加列图表区域先留一个容器占位不要生成模拟图表图片侧边栏菜单项以需求描述中的功能列表为准不得添加未定义功能页脚区域取消不显示任何版权、技术支持信息然后把这份文件喂给 AI给出同样的生成请求。第二版的差异非常明显统计卡片统一了风格白底、细边框、左侧主色竖条信息清晰不再花里胡哨侧边栏菜单只有我列出的四个功能数据总览、用户列表、报表导出、操作日志表格列名严格对准需求“用户 ID、姓名、注册时间、订单数、总消费、操作”没有多余列图表区域放了一个带虚线边框的占位容器里面写着“图表渲染区数据由前端接入”彻底杜绝了假图表的问题最深的一个感受是第二版可能不惊艳但非常可靠。你知道它不会在某个你没留意的角落给你放一个莫名其妙的“充值会员”按钮。4.3 迭代过程中的参数与提示词调整记录写规范文件不是一次到位的我在这个项目里做了三轮调整你也可以参考我的阀值第一轮调整发生在“按钮换色”这个需求上。产品经理希望把“导出报表”按钮做成醒目的强调按钮。我最初在文件里定了主色#2563EB但 PM 觉得“导出”这个动作太重要要更醒目。于是我在规范里引入了“强调按钮”概念主色背景、白色文字、额外在按钮前加一个下载图标。这次调整没有动任何其他组件AI 的输出也自然跟着变了。第二轮调整发生在“页面头部”上。原本 AI 给每个页面顶部都放了一个大标题比如“数据总览”“用户列表”。但我们实际项目里的头部是固定导航栏下面一条窄标题区高度 48px左对齐标题右侧放操作按钮。我把这条写进规范后AI 在生成新页面时就会自动遵循同样的头部结构不会再自己发挥成大横幅。第三轮是“禁止事项”的补充。第二版生成后我发现 AI 在“用户列表”页面的操作列里给每个用户都放了“编辑”“删除”“导出”三个 icon 按钮。这实际违反了我们的交互原则——删除应该收敛到一个下拉菜单里避免误操作。于是我在规范里加了“操作列表中的危险操作必须放到下拉菜单里不直接暴露删除按钮”。后续生成就完全改掉了这个坏习惯。整个过程下来我的体会是规范文件要有“生长性”。它不是写一次就封存的静态文档而是随着项目推进、踩坑不断补充的活文档。每当你发现 AI 在某个地方行为不如预期就把它纳入规范文件下一次就不会再犯。5. 常见问题与避坑指南和 AI 协作生成界面失败案例远远多于成功案例。即便你有了完善的 Markdown 规范文件也依然会碰到各种幺蛾子。这一节我把高频踩坑点整理成一个速查表外加几条独家心得希望能帮你少走弯路。5.1 问题速查表问题现象可能原因解决方案AI 完全无视规范文件输出的还是模板风格规范文件未被有效放置在上下文中或提示词里没有明确要求遵循把规范内容放进系统提示词并在用户提示词里声明“严格按照 design.md 执行”只遵守了一部分规则其他部分放飞自我上下文太长导致“注意力漂移”或者规则写得不够显眼在每次请求中复述本次任务最关键的 2-3 条规则将最重要的规范放在文件开头的显眼位置生成的颜色总是偏离你给的色值大模型对具体色值的重现能力较弱经常做了近似处理并觉得这“也行”在文件中给每个色值配一句语义说明如“主色 #2563EB对应品牌蓝禁止替换”必要时要求输出 CSS 变量自动添加你没要求的功能/图标/菜单项模型基于训练数据补全了它认为“应该有”的东西在“禁止事项”里明确列出不允许添加的功能类别给出功能清单并强调“只包含清单中的内容”生成的文案与实际业务不符甚至出现引导性话术文件缺少文案规范补充“文案规范”章节明确语言风格、常用句式和禁用句式同一份文件不同会话里生成的效果不一致模型随机性或上下文差异尽量固定系统提示词每次生成后把最终效果作为后续对话的参考上下文文件太长AI 抓不住重点规范文件过于庞杂重点被淹没拆分文件基础规范与页面规范分开按具体任务选择性引用使用了未定义的颜色或圆角规范中没写这些维度模型按它自带的“审美”补全了检查规范是否覆盖了颜色、间距、圆角、阴影、字体等全部视觉维度补全后再试要我总结一下这张表最核心的一句话那就是你的规范文件覆盖到什么程度AI 的输出就有多可靠。所有“AI 发挥过头”的案例归根结底都是因为你在某个维度上没有给出约束。5.2 我的几个独家心得下面这几条不一定能在网上找到属于实际项目里被恶心过之后的总结。第一条不要用形容词定义颜色。你在规范里写“浅蓝色背景”在 AI 眼里不如直接写background: #EFF6FF来得准。如果担心设计师不熟悉十六进制可以写成“浅蓝#EFF6FF用于选中状态背景”这样就同时满足了人和机器的可读性。第二条让 AI 生成的组件“对不上”时先检查是不是规范本身有歧义。举个例子如果你写“页面背景使用浅灰色”AI 可能会用#F3F4F6也可能用#F9FAFB这两个我都见过。哪怕都是“浅灰”不同人感知也不一样。所以干脆直接把色值写上一条歧义就消灭了。第三条善用“参考示例”而非“抽象描述”。你对 AI 说“表格要有高级感”它很可能给你加条纹、加圆角、加阴影、加悬浮高亮所有“高级”的要素全都来一遍。但如果你给它一个具体的表格布局描述“表头背景 #F9FAFB单元格垂直居中每行底部 1px #F3F4F6 分割线行距 12px”它的输出就完全在你的掌控之中了。我已经不止一次体会到给 AI 一个具体案例比给十句抽象描述有用得多。第四条生成代码类任务时让 AI 把规范中的值直接映射到 Tailwind 类或者 CSS 变量。比如在规范里给出主色: #2563EB 对应 Tailwind: blue-600 对应 CSS 变量: --color-primary这样做有两个好处一是人对最终代码更熟悉二是 AI 在生成时更容易前后一致。因为在它的训练数据里Tailwind 的 blue-600 和#2563EB的关联是高度稳定的。6. 写在最后这个思路还能怎么扩展最后想说说这套方法在更广阔的领域里的应用方向。用 Markdown 规范文件去约束 AI 生成界面本质上是用文本去建模视觉系统。既然视觉可以被文本建模那么其他领域也一样可以套用这个思路。我自己正在尝试的一个扩展方向是“文档结构规范”。公司的各种对外文档、产品手册也可以用类似的 Markdown 文件定义标题层级、术语表、图片风格、段落节奏让 AI 在生成文档时不再写出那种“一眼 AI”的排比句和空洞总结。另一个方向是“数据可视化规范”。让 AI 生成图表时直接在 Markdown 里规定图表的类型选择逻辑——什么时候用柱状图、什么时候用折线图、颜色怎么映射、标签怎么显示。这样生成的图表就不再是花里胡哨的默认模板而是真正贴合业务逻辑的可视化方案。再进一步想这个思路还可以应用到 **“AI Agent 的交互规范”**上。如果你的 Agent 要调用多个工具、完成多个步骤你可以用 Markdown 文件定义每一步的输出格式、状态文案、错误处理方式。这样 Agent 的行为就不会“漂移”每一步都严格在你设定的轨道上运行。我个人对 awesome-design-md 最大的感触是它表面上是一个“让 AI 好好做 UI”的提示工程方案但深层次上它让我们重新思考了一个问题——我们应该如何跟一个既聪明又缺乏常识的助手协作答案是把规则说清楚、把流程固定下来、把边界划明白。这不仅仅是技术方法更是一种协作哲学。如果你也想尝试我建议从一个小小的项目开始——比如一份“个人简历投递系统”的后台或者一个“宠物用品商城”的官网。先花三十分钟写一版设计规范再让 AI 照着它做。做完之后你会发现那份报告里少了很多“意外惊喜”但多了很多“本来就应该如此”的顺滑感。这种感觉其实是和 AI 协作里非常难得的确定感。