用AI做小程序：7步补齐设计规范

跟着前面几篇做，你大概已经能做出一个让自己满意的小程序。页面怎么摆、按钮点了怎么回应，也有了思路。

但是问题来了：每一页单独看都满意，放在一起检查，才发现字体大小、按钮形状、卡片圆角不太统一，看起来不像同一套小程序。

今天我们补齐这最后一步：把页面和交互的共同规则定下来，让AI后面做每一页都有依据。 以后加页面、换文案或改主色，就不用每次重新解释。

这一篇直接整理设计规范要包含的内容，以及这些规则怎么写进项目、落实到代码和逐页检查。先从现有页面提炼一套共同规则，后续新增和修改页面都沿用它。

01. 先确定规范管什么

设计规范需要说明适用范围：覆盖哪些页面、哪些组件，哪些部分由微信平台提供，哪些部分由项目自己控制。规范还要记录版本和更新位置，避免AI同时读到几份互相矛盾的说明。

统一的是同一用途的规则。 主要操作、次要操作和危险操作可以有区别，但这些区别应当写明；页面结构也可以随内容变化，不必把所有页面排成同一个样子。

一份完整规范至少覆盖下面几类内容：

把规范放在项目中一个明确的位置。Markdown是纯文本格式，design-spec.md可以作为设计规范文档的文件名；文件名是否固定由项目决定，后续让AI始终读取同一份有效文档。

02. 统一字体和文字层级

先决定字体方案，再规定文字层级。需要写清字体名称、字体不可用时的后备方案，以及不同平台和设备上是否允许使用系统字体；不能只记录某台电脑上看到的效果。

Type Scale是字阶，把不同用途的文字按层级组织起来。页面标题、区域标题、正文和辅助说明分别确定字号、字重与行高；相同用途的文字在不同页面中引用同一套定义。

文字规范还要规定长内容如何处理。哪些文字允许换行，哪些可以截断，截断后是否需要完整查看入口，都应当明确；重要内容不能只靠缩小字号塞进固定高度。

验收时同时看层级和适配。字号一致还不够，文字放大后仍应当可读，换行不能挡住操作，固定区域不能裁掉关键内容；视觉层级也要保持清楚。

03. 给颜色分配明确用途

颜色规范应当先按用途分类，再确定具体色值。品牌色、正文色、辅助文字色、页面背景、内容背景、边框和状态色分别记录，设计和代码使用相同命名。

Semantic Color是语义色，让颜色带着明确用途。品牌色与成功、警告、错误等状态可以采用不同定义；调整品牌色时，需要检查哪些定义应该跟着变化，哪些仍然保留原有含义。

同一个组件在默认、按下、选中和禁用时，可以使用不同颜色，但状态之间的变化要有统一约定。文字与背景也需要足够的可读性，次要信息不应淡到无法辨认。

颜色不能承担唯一的状态提示。选中、错误和成功应当配合可识别的文字或图标，让用户在分不清颜色的情况下仍能理解页面。

04. 统一形状、间距和图形元素

按钮、卡片和输入区域的形状，需要规定圆角、边框、阴影和尺寸。相同类型的部件沿用同一套规则；尺寸或用途不同的变体应当单独记录，避免每个页面临时决定。

间距也要有共同尺度。写清页面左右边距、模块之间的距离、组件内部留白，以及文字、图标和操作之间的空间关系；每项都标明单位，不能把不同单位的数值直接混用。

图片与图标需要一起纳入规范。规定图片比例和裁切方式，图标的风格、线条粗细、视觉尺寸和对齐方式；相同用途的图形保持一致，缺少素材时也要有统一处理方式。

小程序的布局还要考虑平台区域。明确使用原生导航还是自定义导航，自定义部分避让胶囊和系统区域；固定操作区避让底部手势区域，滚动内容为它预留空间。设备变化时按实际可用区域适配，不能将一张截图的坐标当成通用规则。

05. 把规则落实到可复用组件

Component是组件，将重复使用的界面结构和行为封装起来。组件规范不能只有一张外观图，还要写明接收什么内容、怎么排列、可以执行什么动作，以及内容变化时如何处理。

Variant是变体，表示同一组件为不同用途或状态提供的形式。变体要有明确名称和使用条件，新增页面优先选择已有形式；确实需要新的形式时，再补充规范。

每个组件至少写清四组信息：

• 内容与结构：包含哪些元素，哪些必填，哪些可以省略。

• 外观与尺寸：字体、颜色、间距、形状与对齐引用哪些定义。

• 交互与状态：点击范围、反馈、禁用条件和状态变化。

• 边界与适配：长文本、缺图、无内容、文字放大和窄屏如何处理。

组件复用应当落实到代码。只复制一份外观相似的样式，后续各自修改，仍会产生差异；相同用途应当引用共同组件或共同样式入口，有明确用途的例外再单独记录。

06. 统一状态和交互反馈

交互规范需要记录触发条件、界面变化、持续时间或结束条件，以及用户接下来能做什么。加载、选中、按下、禁用、空内容、错误和完成反馈，都要有对应约定。

不同状态不能混在一起。加载表示还在等待，空内容表示当前没有符合条件的数据，错误表示操作或请求没有正常完成；相应的文字、图标和处理入口要让用户分得清。

涉及输入和提交时，写清校验提示的位置、修改后的反馈，以及失败后保留哪些内容。处理中避免连续触发同一操作；请求超时或结果暂时不明时，先核实实际状态，不能直接判断为失败。

导航与返回也要有约定。主要入口的切换方式、页面返回、取消操作和临时内容的保留条件都应当明确；数据变化后需要重新检查的条件，同样写进规范。具体行为由业务要求决定，设计规范负责让相同条件下的反馈保持一致。

07. 把规范写进代码，再逐页验收

Design Token是设计变量，用共同名称管理颜色、字号、间距和圆角等经常复用的值。规范文件中的定义应当对应代码里的实际位置，组件和页面共同引用，避免多处维护互相独立的数值。

要求AI说明每一类规则在哪里实现、哪些组件在使用、哪些页面受到影响。只把规范写进文档，还不能证明页面已经遵循；修改共同定义以后，要检查实际使用位置和相关状态。

Acceptance Criteria是验收标准，将要求写成可以逐项检查的结果。可以按下面几组核对，不用“更好看”“更清爽”代替具体标准：

验收需要在微信开发者工具和手机预览里进行，HTML预览只能辅助检查。记录发现的问题、修复位置和核对结果，没有实际检查的项目标为待验证；规范更新后，把受影响的页面一起纳入核对。

一个容易踩的坑：规范文件和代码各改各的

规范里的颜色、圆角或字号更新了，实际页面仍沿用旧定义，这套规范就没有形成共同依据。常见原因是重复样式、页面单独覆盖和组件各自维护参数，文档与实现之间缺少明确对应关系。

处理时先找到有效定义，再列出受影响的组件和页面。把同类规则接到共同入口，检查局部覆盖是否有必要；有明确用途的差异保留并记录，不能把所有差异都当成错误清掉。

规范更新时，文档、共同定义和验收记录一起更新。这样后续AI读取的说明、代码执行的规则和你检查的标准才保持一致，新增页面也能继续沿用。

最后把规范维护流程固定下来

按“盘点现有页面 → 整理共同规则 → 落实变量与组件 → 逐页验收 → 更新有效规范”的顺序处理。规范应当放在项目里，与实际页面一起维护；下一次让AI新增或修改页面时，先让它读取有效规范，再开始实现。

下面这段提示词可以直接用于你自己的项目：

请基于【小程序名称】的现有页面与代码，整理并落实设计规范。

现有材料：【项目目录、页面截图、已有设计文件】
希望保留的视觉方向：【已有风格与不希望改变的内容】
平台与技术方案：【原生小程序或现有框架】
修改范围：【要统一的页面与组件】

请统一以下内容：
1. 字体、字阶、字重、行高、长文本和文字放大的处理。
2. 品牌色、文字色、背景色、边框色、状态色的命名与用途。
3. 圆角、边框、阴影、尺寸、间距、图片比例和图标风格。
4. 可复用组件的结构、变体、内容限制、交互行为和适配。
5. 加载、选中、禁用、空内容、错误、完成以及返回、取消的反馈。
6. 顶部导航、胶囊、底部操作区、手势区和不同屏幕的适配。
7. 设计变量、共同组件的代码位置及逐页验收标准。

先盘点现有差异，按用途提炼共同规则。
保留有明确用途的差异，标明变体或例外；不强行把所有页面做成同一布局。
没有明确的新视觉要求时，沿用现有方向，避免重新设计整套风格。
输出一份有效的设计规范文件，并把规则落实到共同定义和组件。
说明哪些代码已修改、哪些页面受影响、还有哪些重复样式或局部覆盖。
在微信开发者工具与手机预览中按规范核对。
未实际运行、未核对的部分标为待验证。
后续修改规范时，同步更新代码引用和受影响页面的验收记录。

把这份规范作为后续改页面的共同依据。每次增加页面或调整设计，先读规范、再改共同定义、最后核对受影响的位置，页面就能保持在同一套规则里。

关于作者

Punk｜中科大管理学硕士｜AI提示词、AI小白教程｜Punk系列Skills作者｜3个月赚了8位数｜Learn in Public｜FDE文章浏览量240w｜@AdrianPunk115