DESIGN.md：AI生成UI的工程化约束与验证框架-平芜编程栈

1. 从“感觉对了”到“工程化验证”：为什么UI设计需要一场变革

最近几年，AI生成UI（用户界面）的能力突飞猛进，从Midjourney、DALL-E的惊艳概念图，到Figma AI、Galileo AI这类能直接生成可交互界面原型的工具，效率的提升是肉眼可见的。但作为一名在产品和设计一线摸爬滚打多年的从业者，我观察到一个普遍现象：绝大多数团队在使用AI生成UI时，依然停留在“凭感觉”的阶段。设计师或产品经理输入一段描述，AI吐出一堆方案，然后大家围在一起，指着屏幕说“这个感觉不错”、“那个配色好像更高级一点”。这种工作模式，本质上和十年前我们凭“灵感”和“审美”在Photoshop里画图没有区别，只是工具从画笔换成了提示词。

问题就出在这里。当设计决策依赖于“感觉”时，它就变得不可量化、不可追溯、也难以规模化协作。A设计师觉得圆角8px“感觉”更友好，B产品经理认为直角“感觉”更专业，谁也说服不了谁，最后往往由职级更高的人拍板。更麻烦的是，当业务方问“为什么这个按钮要放在这里？”时，我们只能回答“因为这样用户体验更好”，却拿不出任何数据或理论来支撑这个“更好”。AI的介入，非但没有解决这个问题，反而因为其输出的随机性和多样性，让决策过程变得更加混乱和主观。我们急需一种方法，将AI从“灵感喷射器”转变为“可验证的设计引擎”。这就是DESIGN.md理念诞生的背景——它不是一个具体的工具，而是一套将UI设计，特别是AI辅助的UI设计，从艺术创作转变为可验证工程的思维框架与实践方法。

2. DESIGN.md的核心：为AI生成UI建立“设计约束系统”

那么，什么是DESIGN.md？你可以把它理解为一个项目的“设计宪法”。就像软件开发中的README.md定义了项目的目标、结构和运行方式一样，DESIGN.md旨在定义一个设计项目的目标、约束和验证标准。它的核心思想是：在设计开始之前，先明确规则；在AI生成之后，依据规则进行验证。

一个完整的DESIGN.md文档，应该包含以下几个关键部分，它们共同构成了AI生成UI的“输入条件”和“验收标准”。

2.1 设计目标与用户故事（Why）

这是所有设计的起点，也是给AI最重要的“战略指令”。它需要超越简单的“做一个登录页”，而是明确回答：这个界面为谁而做？要帮他们完成什么任务？在什么场景下使用？

示例（传统模糊指令）：“生成一个科技感强的数据仪表盘。”
示例（DESIGN.md 结构化指令）：
- 核心用户：某SaaS公司的运营主管，年龄35-50岁，每天需要快速监控关键业务指标。
- 核心任务：在5秒内定位到“今日新增用户数”和“转化率趋势”，并能一键下钻查看异常数据源。
- 使用场景：通常在每周一上午的站会前，在办公室的台式机上快速浏览。
- 设计目标：优先保证信息的可扫描性和关键数据的突出性，其次才是视觉风格的“科技感”。

当AI获得了这样清晰的背景信息，它生成的UI就更有可能在布局、信息层级和交互热区上做出合理的选择，而不是堆砌一些炫酷但无用的视觉元素。

2.2 设计系统与原子约束（What）

这是将品牌和体验一致性工程化的关键。我们需要在DESIGN.md中预先定义好设计的“原材料”，即设计系统的核心元素。

约束类别	具体内容	对AI提示词的影响	验证方式
色彩系统	主色、辅助色、成功/警告/错误色、中性色板的具体HEX/RGB值。规定主色仅用于主要按钮和关键数据，错误色不得用于背景等。	提示词中需包含“使用主色 #1A73E8 作为主要操作按钮颜色”。	生成后，用吸管工具检查关键元素的色值是否完全匹配。
排版系统	定义好用于H1-H6、正文、标签等所有文本层级的字体、字重、字号、行高。例如：“所有卡片标题使用 Inter 字体，字重600，字号16px，行高24px”。	提示词需明确“标题字体使用 Inter Bold，16px”。	检查生成界面中各类文本的字体属性是否与规范一致。
间距系统	制定基础的间距单位（如4px或8px为基数），并规定不同组件间（如卡片与卡片）、组件内（如标题与内容）的间距标准。	可以描述为“遵循8px网格系统，组件间距为16px或24px”。	使用测量工具检查各元素间距是否为8的整数倍。
组件库	明确基础组件的样式，如按钮的圆角大小、填充/描边状态，输入框的高度、边框样式等。	“按钮使用4px圆角，默认状态为填充主色，悬停状态加深10%”。	核对生成的按钮、输入框等是否与预设组件样式一致。

有了这些原子级的约束，AI生成的界面就不再是“凭空捏造”，而是在一个明确的框架内进行组合与创新，从根本上保证了多轮生成、甚至多人协作下产出的一致性。

2.3 交互逻辑与状态定义（How）

UI不是静态的图片，而是动态交互的界面。DESIGN.md必须定义核心的交互逻辑和组件状态，这是目前许多AI工具的盲区，也是需要人工重点校验的部分。

交互流程：描述关键的用户操作路径。例如：“用户点击‘筛选’按钮后，应从右侧滑入一个筛选面板，面板外点击或再次点击‘筛选’按钮关闭。”
组件状态：定义每个交互组件的所有状态。例如，一个按钮应包括：默认（Default）、悬停（Hover）、点击（Pressed）、禁用（Disabled）、加载中（Loading）这五种状态的外观（颜色、边框、内部图标/文字变化）。
反馈机制：操作后的系统反馈是什么？是Toast提示、模态弹窗，还是页面内局部的数据更新？

在给AI的指令中，我们需要尽可能详细地描述这些交互。例如：“生成一个表格行，当鼠标悬停在某一行时，该行背景色变为浅灰色（#F5F5F5），并且行末出现一个‘编辑’图标按钮。” 生成后，我们需要手动模拟或开发原型来验证这些交互逻辑是否被正确实现。

2.4 可访问性与性能基线（Constraint）

这是专业工程化设计与随意涂鸦的分水岭。DESIGN.md必须包含硬性的、可量化的质量要求。

可访问性（A11y）标准：
- 色彩对比度：所有文本与背景的对比度必须至少满足WCAG AA标准（普通文本4.5:1，大文本3:1）。这需要在生成后使用对比度检测工具（如Figma插件“A11y”）进行验证。
- 焦点顺序与键盘导航：逻辑上，Tab键的焦点顺序必须符合视觉流和操作逻辑。这需要手动测试。
- 屏幕阅读器支持：关键图标必须有替代文本（alt text），这需要在代码层面或设计稿注释中明确。
性能影响考量：
- 图片/资产优化：规定图标使用SVG格式，复杂图片需经过压缩。评估AI生成的背景或装饰性图形是否过于复杂，导致文件体积过大。
- 布局复杂度：过于复杂的嵌套布局或滥用阴影、模糊效果可能影响页面渲染性能。需要在DESIGN.md中设定简单原则，如“阴影层数不超过2层”。

这些约束可能在AI生成时无法被完美遵循，但它们构成了不可或缺的“验证清单”。生成结果必须经过这份清单的检验，不合格则需要调整提示词重新生成或手动优化。

3. 实操流程：如何运行一个基于DESIGN.md的AI设计循环

理论说完，我们来看如何将DESIGN.md融入实际工作流。这绝不仅仅是写一份文档，而是一个“定义-生成-验证-迭代”的闭环过程。

3.1 阶段一：撰写与共识——在动笔（或动嘴）之前

项目启动时，产品、设计、前端甚至相关业务方，需要共同参与DESIGN.md的撰写。这个过程本身就是对齐认知、消除歧义的过程。

填充框架：基于上述章节，结合项目需求，逐一讨论并确定DESIGN.md的具体内容。争议点（比如主色选哪个）在这个阶段通过讨论、参考竞品或用户调研数据来解决，而不是留到设计评审时。
工具化存储：将定稿的DESIGN.md放在项目Wiki、Notion或Figma文件的首页。更重要的是，将其核心参数（色值、字体、间距等）转化为AI工具能直接理解的“提示词片段库”或“风格预设”。例如，在Midjourney中，可以将品牌色等保存为自定义风格；在Figma AI中，可以提前设置好文本样式和颜色样式。

3.2 阶段二：提示词工程——用DESIGN.md“编程”AI

这是将结构化约束转化为AI指令的关键步骤。你的提示词应该是一份详细的“设计任务规格书”，而不是一句模糊的“咒语”。

低质量提示词示例：“画一个漂亮的音乐播放器界面。”

基于DESIGN.md的高质量提示词示例： “生成一个移动端音乐播放器的主播放界面。遵循以下规范：

布局：采用经典的底部播放控制栏固定，中部为大面积专辑封面展示区的结构。封面图片比例1:1。
色彩：背景使用深色主题，主色为 #1DB954（Spotify绿），用于播放/暂停按钮和进度条。文字颜色为 #FFFFFF 和 #B3B3B3。
排版：歌曲标题使用 SF Pro Display，字重600，字号20px。歌手名使用 SF Pro Text，字重400，字号14px，颜色#B3B3B3。
组件：播放/暂停按钮为圆形填充按钮，直径56px。前进后退按钮为线性图标，大小24px。进度条为细长条，高度4px，已播放部分为#1DB954，未播放部分为#535353。
交互状态：请分别展示播放状态（暂停图标）和暂停状态（播放图标）下的按钮。
目标：界面需简洁，确保用户在运动（如跑步）时能一眼看清歌曲信息并盲操作播放控制。”

3.3 阶段三：生成与验证——从“看感觉”到“做检查”

AI生成出结果后，我们进入严格的验证阶段，这就像代码提交后的CI/CD（持续集成/持续部署）流水线。

自动化校验（尽可能）：
- 使用Figma插件自动检查色彩对比度、字体使用是否匹配样式。
- 编写简单的脚本，检查导出图片中的主要色块是否与DESIGN.md中的色板匹配。
人工清单校验（必须）：
- 拿出DESIGN.md的“可访问性与性能”章节，逐条核对。
- 检查交互逻辑的描述是否在静态稿中有所体现（如不同状态的呈现）。
- 评估布局是否符合目标用户的使用场景（如在手机模型上查看移动端设计）。
记录与决策：将验证结果记录在案。完全符合规范的部分，可以直接进入下一环节；不符合的部分，需要明确问题：是提示词不够精确？还是当前AI能力无法达到？如果是前者，优化提示词重新生成；如果是后者，则标记为需要手动调整的部分。

3.4 阶段四：迭代与沉淀——优化系统，而不仅是单次产出

一次循环的结束是下一次循环的开始。DESIGN.md本身也应是迭代的。

优化提示词库：将本次验证中效果最好的提示词片段（例如，描述某种卡片样式的措辞）沉淀到团队的提示词库中，供未来项目复用。
更新设计约束：如果在验证中发现预设的某个间距标准在实际AI生成中总是走样，可以反思这个标准是否合理，是否需要调整。
积累反模式：记录下AI容易犯错的“坏例子”（比如，它总喜欢把按钮做得过于花哨），并在未来的DESIGN.md中明确禁止这些模式。

通过这个闭环，每一次AI生成都不再是孤立的、碰运气的行为，而是一次受控的、可衡量的设计实验。团队积累的不再是一堆散乱的设计稿，而是一个不断进化的“设计约束系统”和高效的“提示词资产库”。

4. 工程化带来的挑战与应对策略

将设计工程化，尤其是引入AI后，必然会遇到阻力。最大的挑战往往不是技术，而是人与流程。

挑战一：扼杀创意？这是最常见的质疑。我的观点是：创造力体现在制定规则和解决规则内的复杂问题，而非无视规则。DESIGN.md约束的是“原子”（颜色、字体），解放的是“分子”和“组织”（布局、组合、流程）。就像写十四行诗，严格的格律（约束）并没有阻止莎士比亚创作出伟大的作品，反而激发他在规则内进行极致表达。AI在明确约束下，能更高效地探索布局、视觉层次、微交互的无数种可能性，设计师则从重复劳动中解放，专注于制定规则、评审AI方案中那些真正体现“创意”和“用户体验洞察”的部分。

挑战二：增加前期成本？撰写DESIGN.md确实需要时间。但这是一种投资。它避免了在设计中后期因方向不明、标准不一导致的无穷无尽的评审、返工和扯皮。对于任何需要迭代、有多个页面或由多人协作的项目，这份前期投入的时间都会在后期十倍百倍地节省回来。对于小型、一次性的设计，或许可以简化DESIGN.md，但核心的“目标-约束”思维依然适用。

挑战三：AI无法完全遵循复杂约束？是的，这是现状。当前的AI，特别是文生图模型，在理解精确的数值约束（如精确到像素的间距）、复杂的交互逻辑和状态管理上仍有不足。因此，DESIGN.md实践必须拥抱“人机协作”，而非追求全自动化。AI的角色是“超级草稿生成器”和“灵感拓展器”，负责快速产出大量符合基础约束（色彩、风格）的方案。设计师的角色是“规则制定者”、“高级验证者”和“精修师”，负责处理AI不擅长的精确交互、状态设计和深度可用性优化。两者结合，才能实现效率与质量的最大化。

挑战四：工具链不成熟？目前确实没有一款工具能完美承载整个DESIGN.md工作流。但我们可以组合现有工具：用Notion写文档，用Figma维护设计系统组件库和做验证，用Cursor或Claude等代码助手将设计约束转化为前端主题配置代码。这个过程中的“摩擦”正是机会，也催生了对下一代设计工具的需求——一个能直接理解DESIGN.md、并据此驱动AI进行生成和验证的一体化平台。

在我自己的团队中，推行这套方法后，最直观的变化是设计评审会的效率。以前评审集中在“这个颜色好不好看”、“那个图标大不大”，现在评审焦点变成了“这个布局是否最优地支持了用户故事”、“这个交互状态是否符合我们定义的规范”、“可访问性检查是否通过”。讨论变得更有建设性，决策依据也从主观喜好转向了客观标准。AI生成的结果，不再是一堆令人眼花缭乱、难以抉择的选项，而是经过初步筛选、符合项目基线的、可供进一步深化讨论的半成品。

说到底，DESIGN.md是一种思维转变：它要求我们像工程师对待代码一样对待设计——需求明确、接口清晰、逻辑严谨、可测试、可复用。当AI成为强大的“代码生成器”时，一份好的“设计需求规格书”（DESIGN.md）就是确保它写出正确、高效、可维护代码的关键。这场变革的目的，不是用机器取代设计师，而是让设计师更像战略家和架构师，让AI成为他们手中最听话、最高效的执行者，共同把用户界面设计这门“手艺”，真正升级为一门可衡量、可复制、可进化的“工程”。