如果让我给过去半年的 AI 前端生成做一次复盘我最想说的判断是廉价模板感不是模型的问题而是缺少一份开源 DESIGN.md 式的设计契约。最近我连续用 AI 编码工具做了不少前端页面从落地页到后台管理界面几乎每轮都会遇到同一个现象页面第一眼很完整有导航、有 hero、有三列卡片、有圆角阴影但多看一眼就露馅——颜色没有主次间距像随手敲出来的按钮状态只有一个默认态换一页就像换了一套组件。很多人习惯把这个结果归结为“AI 写不出好前端”然后去换提示词、换更大模型。但我更建议先不要折腾模型而是给项目补一份DESIGN.md。这个思路并不是某个人的灵机一动它在开源社区里正在变成一种可复用的前端生成约束。1. 为什么 AI 前端代码总有一股“模板味”1.1 表面问题看起来很完整但细节经不起看“模板味”或者“廉价感”不是一个玄学概念它其实可以被非常具体地拆成几个信号。我用 AI 生成一个典型产品页时输出往往是这样的顶部一个固定导航栏左边 logo右边两个按钮中间一屏居中的主视觉大字标题、副标题、一个主按钮下面三列卡片每张卡片里有一个 icon、一个标题、一段描述、一个“了解更多”再往下可能是 logo 墙或者数据统计区最后是页脚。整套结构没有错但放大看细节问题立刻出现。颜色系统是散的。页面上可能同时出现蓝、绿、紫、橙但它们之间没有任何语义关系主按钮的颜色和图标颜色不是同一套体系。间距是乱的。有的卡片 padding 是 24px旁边的卡片又是 32px标题和描述之间有时 12px有时 18px。字号和字重也没有层级正文比辅助文字还小按钮文字和页面标题几乎一样粗。hover 状态更敷衍很多按钮只改一下背景色没有反馈节奏。这些细节叠加在一起就形成了所谓“AI 味”。它不是模型不会写代码而是模型在没有任何约束的情况下从训练数据里取了一个“平均答案”。平均答案意味着哪里都合理但哪里都不精准。1.2 根源不是模型笨而是缺少“设计契约”很多人误以为廉价模板感是因为提示词不够长或者模型不够聪明。实际上问题出在我们没有给模型一个足够明确的决策依据。模型训练数据里确实有大量优秀的前端页面但它不知道你的项目应该长什么样子。你只告诉它“做一个科技感的产品介绍页”它只能按照多数网站的大概率特征去补全。这就是为什么生成结果总像一个统计样本居中 hero、三列卡片、大渐变按钮因为它们在全网出现频率最高。这不是模型能力不足而是输入信息不够。模型缺少一份“设计契约”这个产品的主色是什么背景色是什么间距该按什么单位递增按钮有多少种状态哪些风格是你绝对不想要的没有契约模型就只能自由发挥。自由发挥不等于有创造力它等于概率分布的中心。所以我一直认为AI 前端生成质量的分水岭不是从 GPT-4 到下一代模型的参数提升而是我们有没有把大脑里的设计判断转化成机器可读的规则。1.3 廉价感的本质是“没有可复用的设计体系”一个页面之所以有质感不是因为某一个颜色特别好看而是因为页面里的所有元素共享同一套决策规则。人做设计的时候会在潜意识里维持一套体系主色、辅助色、间距、圆角、字号层级、组件状态、交互反馈。这套体系不一定写下来但它存在。AI 没有看过你脑子里的体系它只能从你的提示词里猜。提示词是高度压缩的语义比如“简洁”“高级”“现代”这些词不足以约束具体的视觉决策。廉价模板感的本质就是设计体系缺失。它让 AI 生成出来的页面像拼凑的而不是一个整体。开源社区开始流行把DESIGN.md放进项目根目录本质上就是在弥补这个缺口把隐性的设计体系变成显性的、可复制、可审查、可喂给 AI 的文档。它不是某个炫酷组件库而是一份“设计决策说明书”。2. 一份会写进 AI 上下文的 DESIGN.md到底应该长什么样2.1 先明确它不是产品文档也不是设计稿我在很多团队讨论里发现大家一听“把设计规范写进 AI 提示词”第一反应是把 PRD 或者 Figma 设计稿丢给模型。这其实不太对。DESIGN.md不是产品需求文档。PRD 回答的是“这个页面要解决什么问题”而设计契约回答的是“这个页面在视觉上如何做选择”。它也不是设计稿因为模型不能从图片里精确读取颜色 token、间距倍率和组件状态。它应该是一份纯文本、结构化、能直接进入模型上下文的 Markdown 文件。更重要的是它要能被代码直接引用。比如文档里写--color-primary: #0b5fff模型生成代码时就可以把这个值直接用到 className 或 style 中。文档里写“所有间距必须是 8 的倍数”模型生成 margin 和 padding 时就会尽量避免 13px、17px 这种孤立值。换句话说它是一份可执行的规范而不是一堆形容词。2.2 必备模块目标、原则、token、组件、页面骨架、反面模式结合我自己的使用经验一份能显著改善 AI 输出质量的DESIGN.md通常包括六个模块。第一是设计目标。用两到三句话说清楚这个产品在视觉上要传达什么比如“专业、克制、信息密度高像企业内部工具不像营销落地页”。模型需要先建立整体判断。第二是设计原则。三到五条硬性规则每条都要能落到代码上。比如“一屏只能有一个主行动点”“所有间距必须是 8 的倍数”“不使用大渐变背景和夸张动效”。这些规则会成为模型生成布局时的约束。第三是 Visual Tokens。这是最重要的部分。颜色、间距、圆角、阴影、字体、字号都需要给出具体值。不要写“主色要稳重”要写--color-primary: #0b5fff。第四是组件规格。按钮、卡片、表单、导航这些高频组件要写明不同状态下的尺寸、配色、交互。这一步能避免 AI 生成“圆角超大按钮”或“卡片没有边框”之类的问题。第五是页面骨架。不同页面类型的布局模板要单独写。比如列表页必须是“搜索区 表格区 分页区”详情页必须是“左侧信息 右侧操作区”。模型拿到骨架后不容易自由发挥成三列卡片堆叠。第六是反面模式。这一块很容易被忽略但极其重要。模型见过太多模板你不禁止它就会回到模板。所以必须明确写清楚不要使用紫色渐变按钮不要把所有内容居中对齐不要使用超过两个强调色。六个模块里token 和反面模式对消除模板感作用最大。2.3 一个可参考的最小 DESIGN.md 片段下面这个示例是一个“最小可用”的结构不是万能模板具体数值要根据自己项目调整。# DESIGN.md ## Design Goals - 专业、克制、信息密度高。 - 页面像企业内部工具不像营销落地页。 ## Design Principles - 一屏只能有一个主行动点。 - 所有间距必须是 8px 的倍数。 - 不使用大渐变背景和夸张动效。 ## Visual Tokens - --color-bg: #f5f7fa - --color-surface: #ffffff - --color-primary: #0b5fff - --color-text: #1b1f24 - --color-muted: #6b7280 - --color-border: #e5e7eb - --space-unit: 8px - --radius-sm: 4px - --radius-md: 6px - --font-family: system-ui, -apple-system, Segoe UI, Roboto, sans-serif ## Component Rules ### Button - 主按钮primary 背景白色文字radius-md高度 36px。 - 次按钮surface 背景border 颜色text 颜色radius-md。 - 危险按钮红色文字 红色边框不用大面积红色填充。 ### Card - 背景 surfaceborder 1pxradius-mdpadding 16px。 - 禁止三列以上卡片同时出现在首屏。 ## Page Skeleton - 页面最大宽度 1280px。 - 侧边栏 240px内容区使用 12 列栅格。 - 列表页必须有搜索区、表格区、分页区信息密度优先。 ## Anti-Patterns - 不要使用紫色渐变按钮。 - 不要使用大面积背景插图。 - 不要把所有内容居中对齐后台界面以左对齐为主。这个示例的价值不在于直接套用而在于展示“可执行”是什么样子。如果你用的是 Tailwind可以把 token 映射成tailwind.config如果你用的是组件库也可以映射成 theme overrides。关键是让模型能把这个文档和实际代码对应起来而不是看了一段理念后自行发挥。3. 从“加提示词”到“喂设计文档”我建议的落地流程3.1 三步走先写 DESIGN.md → 再让 AI 生成单一页面 → 最后做批量任务很多人的习惯是一上来就打开 AI 工具写一大段提示词让模型直接生成完整页面。这个流程在“试玩”阶段没有问题但如果你想稳定得到有质感的结果我建议换成一个更稳的三步流程。第一步先写DESIGN.md。如果你不知道怎么开头不要从空白硬写。打开一个你自己觉得效果不错的页面反向提炼背景色是什么主色是什么间距规律是什么按钮有哪些状态布局结构是什么。把这个页面拆解成规则整理成文档。这样做的好处是你提炼出来的规则一定符合你的审美而不是从网上抄一个通用规范。第二步在 AI 编码工具中使用这份文档。如果是对话式 AI把DESIGN.md完整粘贴进上下文然后输入页面需求。如果是 Cursor 这类编辑器插件把它放到项目根目录并在新会话里明确说“先阅读 DESIGN.md再实现 XX 页面”。不要省略“先阅读”这个指令这会让模型把文档当作必须遵守的输入而不是无关背景。第三步只生成单个页面。先让模型生成首页或列表页检查通过后再扩展其他页面。一次要求生成整个后台系统输出几乎一定会快速退化成模板。原因很简单页面越多上下文越拥挤模型越难同时维护全局设计约束。单页面跑通后再逐步扩展。3.2 单页面验证 check-list颜色、间距、层级、状态、响应式拿到 AI 生成的页面后不要只看整体效果要按下面这个列表逐项检查。颜色页面里是否只出现 token 中定义的颜色有没有跑出来一个文档里不存在的新色值间距所有 margin 和 padding 是否可以整除 8有没有出现 13、17、23 这种孤立值层级一屏里主按钮是不是只有一个标题、正文、辅助说明的字号和字重是否层次清楚组件状态按钮的 hover、disabled、loading 状态有没有处理还是只有默认态响应式在 1440、768、375 三种宽度下布局有没有按栅格断点变化还是只在桌面宽度下成立代码结构className 或 style 里是否直接写死颜色和间距有没有使用 token 或主题变量如果 AI 输出不满足其中几项不要直接说“重新生成”。更好的做法是把差异写成负面反馈比如“把间距改成 8 的倍数不要单独出现 17px”。模型对具体的负面反馈修正得更快也更容易保持现有页面结构。3.3 批量生成前先让 AI 做一次“设计自检”当你准备让 AI 生成多个页面时有一个动作非常有效让模型在生成代码前先输出一份“设计自检”说清楚这个页面会用到哪些 token、哪些组件、遵循哪条设计原则。例如你可以这样要求“请根据 DESIGN.md 实现用户管理列表页。在开始前先输出一段 Design Self-Check列出页面使用的 token、布局、组件状态和禁止项生成后再次检查。”这个动作看起来多了一步但效果很明显。它强迫模型在推理时把抽象的设计文档落实到具体代码决策上。模型如果能在生成前梳理出“主按钮将使用--color-primary列表项间距是 16px不使用大渐变背景”那么它生成代码时更可能遵守这些约束。我试过在同一个项目里对比让 AI 直接生成列表页和先自检再生成列表页。后者的代码里直接写死颜色和间距的概率明显更低也更接近我项目里的既有风格。这不是玄学而是给模型增加了一条“声明约束”的环节让约束从背景信息变成执行前提。3.4 如果 AI 不遵守文档怎么办用“反向确认”和“差分修改”即使你把DESIGN.md写得很清楚模型仍然可能不遵守。这时候先别急着换模型一步步排查。首先确认文档是否真的在上下文里。对话式 AI 如果聊天记录很长早期贴入的文档可能会被模型部分遗忘。解决方案是开新会话把文档放在靠前的位置并明确要求“先阅读 DESIGN.md 再作答”。如果模型确实读到了仍然不遵守可以用两个手段。第一是反向确认。让模型用自己的话复述一遍DESIGN.md里的关键约束比如“请复述这个项目的主色、间距单位和反模式”。如果模型复述正确说明它理解了没遵守可能是后续生成时没有执行。如果复述错误说明文档的表述不够清晰或者上下文被冲淡了。第二是差分修改。不要整个页面推倒重来而是针对违反规范的具体部分让模型做最小修改。比如“把主按钮从紫色渐变改成--color-primary并把圆角改成--radius-md其他部分保持不变”。这种修改方式比“重新生成一版”更容易保留正确部分也避免模型重写时引入新的模板感。注意不要一上来就让 AI 重写整个页面。先改最小差异再逐步让输出对齐 DESIGN.md。4. 真正让“开源”有价值的不是文件本身而是可复用的约束资产4.1 从个人项目到团队资产“开源 DESIGN.md”这件事如果只是一个人在自己项目里写一份设计文档那它只是一个技巧。它的价值会随着使用范围扩大而体现出来。当一个团队或者一个开源项目把DESIGN.md放进仓库里它就不再是一个人的审美偏好而成了团队的设计共识。新成员加入时不用靠“看优秀页面”来猜测风格AI 生成页面时也不用反复解释“我们想要的感觉”。所有人只维护一份文档文档同时服务人和机器。长期看我们可以沉淀出不同场景的DESIGN.md后台管理系统版、内容社区版、移动端 H5 版、营销页面版。每个项目开始时复制一份调整 token 和反模式就能快速进入状态。这种资产复用价值是“开源”这个关键词在这个主题里真正值得关注的地方。4.2 开源 DESIGN.md 可以沉淀哪些东西一个成熟的DESIGN.md不只是放几个颜色变量它可以沉淀四类资产。第一是语义化 token。颜色、间距、圆角、阴影的命名和数值能被 AI 和代码同时引用。第二是组件规格。高频组件的默认状态、hover 状态、禁用状态、错误状态都能在文档里提前定义。第三是页面骨架。不同页面类型的布局结构可以让模型生成时少犯结构性错误。第四是正反例。正面例子可以是“这一段代码是符合规范的”反面模式则明确写清楚哪些风格不能出现。这些内容看起来像一个组件库文档但它并不绑定任何 UI 框架。你可以同时使用 React、Vue、Tailwind 或自带组件库DESIGN.md在更上层抽象了一套设计规则。它给了 AI 一个相对稳定的坐标系而不是某个具体代码库的接口说明。4.3 它的边界不是设计系统不是 UI 库也代替不了设计师这个方向很好但不能被神化。DESIGN.md有三条明确边界。第一它不是一个组件库。它只定义视觉和交互规则不提供可运行的组件代码。你仍然需要业务组件库或者 CSS 框架来承载实现。第二它不是设计系统的唯一来源。大型项目里颜色和 spacing token 通常需要在样式工程里维护DESIGN.md更像是一份“入口文档”用来给 AI 和新人快速建立上下文不能替代代码工程。第三它不能代替设计师的创造力。如果团队本身没有审美能力一份写满规则的文档也可能被 AI 机械执行生成“合规但无趣”的页面。所以我对它的定位是给 AI 戴上约束的缰绳而不是让 AI 变成设计师。它能帮我们把已有的审美偏好稳定输出但不能凭空创造一套新的设计语言。4.4 适用场景与不适用场景适用场景不适用场景后台管理系统、内部工具界面高度依赖品牌创意与视觉叙事的营销页面MVP、独立开发者快速做产品前端需要探索全新交互模式的产品原型团队需要统一 AI 生成的多页面风格团队没有设计感知且无人维护文档基于现有设计系统做项目迭代一次性草稿、不需要长期复用的页面这张表想表达的是DESIGN.md是一个约束工具它依赖你已经知道“好”大概是什么样子。如果你追求的是开发效率和一致性它非常合适如果你需要的是突破性创意它只能帮你守住底线不能帮你找到上限。5. 踩坑排查当 AI 前端生成还是“很模板”时按这个顺序查5.1 排查链路输入 → 文档 → 上下文 → 输出 → 人工校验如果你已经用了DESIGN.md生成结果仍然很模板不要急着换模型。我建议按下面这条链路逐层排查。第一步看输入。DESIGN.md是否完整进入了模型上下文有没有只粘贴一段模型是否在生成前明确阅读过第二步看文档质量。文档里写的是抽象形容词还是可执行数值“主色要稳重”是无效约束“主色是 #0b5fff”才有效。第三步看上下文。对话是否过长中间是否夹杂了大量无关内容可能把设计文档冲掉了第四步看输出。模型生成的代码里className 或 style 是用了 token还是写死颜色和间距第五步做人工校验。在浏览器里实际检查 hover、响应式和间距确认不是只有代码看起来规范。大部分“AI 不遵守设计文档”的问题都出在前三步。真正需要模型背锅的情况反而少。出现廉价模板感先别急着换大模型。先确认 DESIGN.md 是否真的进入了输入以及文档里是否有可执行的值。5.2 高频坑点为什么约束会失效我见过不少团队用DESIGN.md效果不稳定最后复盘时发现是下面这些坑。第一文档写得太像设计理念。满屏“现代、大气、简洁”没有一个具体值模型只能继续猜。第二一次生成太多页面。生成一个页面时约束还能保持生成十个页面时上下文已经被需求冲乱。第三让模型“参考”设计文档而不是“先阅读并自检”。参考在很多情况下等同于忽略。第四token 命名和实际代码不一致。文档里定义--color-primary: #0b5fff代码里却用#3b82f6AI 生成的页面无法继承主题。第五只查桌面宽度。AI 生成的页面在 1440px 下看起来不错到 375px 就完全崩掉。第六没有版本管理。文档被来回修改团队和 AI 都不知道当前生效的是哪一版。这些坑的共性是我们都以为文档存在就够了但DESIGN.md需要被读取、被引用、被检查才能变成真正的约束。5.3 一个排查实例为什么按钮还是紫色渐变举个例子。假设DESIGN.md里明确写了“不使用紫色渐变按钮”但 AI 生成的主按钮还是紫色渐变。先别怪模型。按顺序排查。检查上下文。如果你的对话里有一大段其他需求可能模型已经忘了文档末尾的 Anti-Patterns。解决方法是开新会话把文档放在更靠前的位置并要求模型先复述一下反模式。检查表述。不使用紫色渐变按钮在模型看来更像一个风格倾向而不是硬性 token 约束。可以改成按钮背景必须使用 --color-primary禁止使用 gradient、purple、violet 等颜色词。规则越接近代码越容易被模型执行。检查自检步骤。如果只是让 AI 写代码它可能没有意识到这条约束。可以在需求里加一句“生成前先说明本例有哪些反模式”。这会让模型更关注文档里的禁止项。检查 diff。如果还不生效直接把这一段违规代码复制给模型告诉它“这个按钮违反了 DESIGN.md 第 X 条反模式请修改为--color-primary不要重写整个页面”。这个例子说明很多“模型不听话”其实是因为约束没有被转成机器可执行的指令。6. 回到本质AI 前端的下一个分水岭不是模型是“输入纪律”6.1 模板感的尽头是约束感越用 AI 生成前端我越觉得一个问题很关键我们到底给了模型多少可执行的输入过去我们把 AI 当创作工具希望它“自由发挥”。但自由发挥的结果往往就是平均模板。因为模型擅长从概率分布里补全信息而不是替我们做审美决策。你越是只给它一个模糊方向它越会产出高频风格。DESIGN.md的本质就是把输入纪律化。它不是限制 AI 的想象力而是把“想象力”从随机采样变成有边界的创作。写作需要风格指南设计需要设计 token代码需要 lint 规则。前端生成也一样没有约束的 AI 会写平均页面有约束的 AI 才可能写出产品级界面。我越来越觉得AI 前端生成的下一个分水岭不是模型参数更多而是输入纪律更强。6.2 对普通前端开发者的启发这套方法不需要等团队推动个人项目也可以立刻用起来。不用一开始就写完整设计系统。从最轻量的一组规则开始一个主色、一个间距单位、一个圆角值再加一条反模式。然后把它们写成DESIGN.md放进项目根目录。下一次你让 AI 生成页面时把这份文件放进上下文要求它先阅读、再实现、最后自检。你会发现同样一个提示词生成结果的质感会出现明显变化。这不是因为模型变聪明了而是因为你终于给了它一套确定的标准。对一个前端开发者来说这更像是工作流升级而不是又多学了一门技术。6.3 今天的第一个行动如果你读完这篇文章只做一件事我建议是从你最近做的一个页面开始反向写一份迷你DESIGN.md。找出这个页面至少五个视觉决策主色是什么背景色是什么间距的规律是什么圆角用多大按钮的 hover 状态怎么处理。整理成 Markdown放到项目根目录。然后用它去做一次 AI 页面生成对比加文档前后两次输出的差异。这个动作成本很低但它会改变你对“AI 能不能做好前端”的判断。模板感不会自动消失它只会退到约束之外。而DESIGN.md就是我们给 AI 划出的那条边界。当模型在动手前先读懂我们对审美的规则廉价模板感才算真正退场。