1. 为什么原型总被说“不像我们的产品”

做原型这件事，很多人以为难点在画得快不快、组件全不全。真到了评审桌上，被挑得最多的往往不是交互逻辑，而是一句很朴素的话：“这看着不像我们的产品。”

我踩过这个坑。早些年做后台系统原型，我习惯直接拖一套通用组件库，灰底蓝按钮，规规矩矩。功能演示没问题，但产品负责人看完只说了一句：“你这套东西放到哪个项目里都成立，我看不出这是我们自己的东西。”当时我不太服气，原型不就是验证流程的吗，要那么像干嘛。后来才想明白，原型承担的不只是“能不能走通”，它还承担“团队对最终形态的共识”。如果原型和产品真实风格差太远，评审时大家脑子里各想各的，讨论就会跑偏，等到视觉稿出来才发现方向不对，返工成本就上去了。

所以这次我想聊的，是一套我自己反复用、也确实省事的方法：用一份Design.md把产品风格沉淀成可复用的规则，再拿它去驱动原型设计。核心关键词就是Design.md、产品风格、原型设计、设计规范、组件库、设计令牌。它解决的问题很具体——让原型在“快”和“像”之间不再二选一。适合谁看？如果你是产品经理、交互设计师、前端开发，或者一个人要顶好几个角色的小团队，这套东西能直接抄去用。

先说清楚它是什么。Design.md不是什么官方标准，也不是某个工具的专属格式，它就是一份用 Markdown 写的设计说明文档。你可以把它理解成“给原型和代码看的产品风格说明书”。它把颜色、字体、间距、圆角、阴影、组件状态这些原本散落在设计稿、口头约定、代码变量里的东西，集中写成一个纯文本文件。纯文本的好处是：人看得懂，工具也读得懂，还能进版本管理，改一行所有人都能看到。

它能做什么？最直接的是，你把这个文件交给原型工具或者 AI 辅助工具，让它按里面的规则生成界面，出来的东西天然带着产品自己的味道，而不是通用模板味。它解决的是“风格一致性”和“沟通成本”两个老问题。接下来我会从整体思路、核心细节、实操过程、问题排查几个角度，把这件事拆开讲透。

2. 整体设计思路：为什么是 Markdown，而不是一份设计稿

2.1 从“看图模仿”到“读规则生成”的转变

传统做法里，原型风格靠什么传递？靠设计稿截图、靠组件库、靠口头说“按钮用主色，圆角小一点”。这些方式都有个共同毛病：信息是模糊的、分散的、不可执行的。你说“圆角小一点”，到底是 4px 还是 6px？你说“用主色”，主色是哪个色值？每个人理解都不一样。

Design.md的思路是把这些模糊描述变成明确规则。它不追求把每个页面画出来，而是把“生成页面时该遵守什么”写清楚。这就像做菜，以前是给厨师看一张成品照片让他照着做，现在是给他一份标准菜谱，写清楚几克盐、几分钟火候。照片能看不能量，菜谱能看能量还能复制。

我选择 Markdown 而不是 JSON 或 YAML，是有考虑的。JSON 结构严谨但人读起来累，改一个色值要小心括号和逗号；YAML 好一点，但对非技术同学还是有点门槛。Markdown 的优势在于，它既是给人看的文档，又能被工具解析。你可以在里面写标题、写表格、写代码块，排版自然，产品、设计、开发三类人都能直接读。而且它天然适合放进代码仓库，跟项目一起做版本管理，谁改了什么一目了然。

2.2 一份 Design.md 应该覆盖哪些维度

风格这件事，说复杂也复杂，说简单也就那么几类。我总结下来，一份能驱动原型的Design.md，至少要覆盖下面这几个维度，缺一个都容易在生成时露馅。

这张表不是让你一次写全，而是提醒你：风格一致性是整体感受，任何一个维度掉链子，整体就会“不像”。我见过最典型的情况是色彩和字体都对了，但间距全凭手感，结果页面看起来就是别扭，说不上哪里不对，其实就是节奏乱了。

2.3 为什么这套方法特别适合小团队和独立开发者

大团队有专门的设计系统团队，维护一套完整的组件库和文档站。但小团队没这个资源，往往一个设计师加一两个前端就把活干了。这种情况下，Design.md的性价比极高。

它不需要你搭文档站，不需要引入重型工具，一个文件就能起步。你可以先写最核心的十几条规则，用起来，发现不够再补。它也不绑定任何特定工具，今天用这个原型工具，明天换那个，规则文件还在，迁移成本很低。我自己的习惯是，每接一个新项目，先花半小时把Design.md的骨架搭起来，后面所有原型和页面都从它出发，越用越顺。

提示：不要一上来就追求大而全。先写色彩、字体、间距这三块，它们对“像不像”的影响最大，覆盖 80% 的观感问题。

3. 核心细节解析：把风格写成可执行的规则

3.1 色彩体系怎么写才不空洞

色彩是最容易写、也最容易写废的部分。很多人就写一句“主色是蓝色”，这等于没写。工具拿到“蓝色”两个字，只能猜。你得给出具体色值，还要说明用途。

我一般会分三层来写。第一层是品牌色，也就是产品最核心的那个颜色，通常一到两个。第二层是语义色，成功、警告、错误、信息这四种，每种给出明确色值。第三层是中性色，从最深的文字色到最浅的分割线色，排成一个梯度。

## 色彩 ### 品牌色 - 主色 Primary: #2F6BFF - 主色悬停 Primary Hover: #1F55E0 - 主色浅底 Primary Light: #EAF0FF ### 语义色 - 成功 Success: #1FA971 - 警告 Warning: #E8A33D - 错误 Error: #E5484D - 信息 Info: #3B82F6 ### 中性色 - 标题文字: #1A1D24 - 正文文字: #3D434D - 次要文字: #7A828E - 分割线: #E5E8ED - 页面背景: #F6F7F9

这样写的好处是，任何工具或人拿到后，都能准确还原。悬停色和浅底色也一并给出，是因为交互态和背景态在实际界面里出现频率极高，临时调容易出错。我踩过的坑是只给了主色，结果生成出来的按钮悬停时颜色是工具自己算的，跟品牌色差了一截，评审时被一眼看出来。

3.2 字体排版：层级比字体本身更重要

字体这块，很多人纠结用哪个字体家族。其实对原型来说，字体家族的影响远不如层级关系大。原型阶段用系统默认字体完全够用，关键是字号、字重、行高这三者的搭配要成体系。

我的做法是定义一个“排版阶梯”，从最大的标题到最小的辅助文字，每一级都写清楚。这样生成时，工具知道什么内容该用什么级别，不会出现标题比正文还小的情况。

行高这个参数特别容易被忽略，但它对观感影响很大。行高太小文字挤成一团，太大又显得松散。我一般按字号乘以 1.5 左右来定，正文 14px 配 22px 行高，读起来最舒服。字重上，标题用 600 而不是 700，是因为 700 在多数系统字体里显得过重，600 更克制，符合大多数产品的调性。

3.3 间距节奏：让页面“呼吸”的隐形规则

间距是最隐形、也最能体现专业度的地方。新手做原型，间距全凭感觉，这里 10px 那里 15px，单看每个元素都没问题，合在一起就是乱。解决办法是定义一个基础间距单位，所有间距都用它的倍数。

我通常用 4px 作为基础单位，然后定义几档常用间距：4、8、12、16、24、32、48。小到图标和文字之间用 4 或 8，卡片内边距用 16 或 24，区块之间用 32 或 48。这样整个页面就有了统一的节奏感。

## 间距 基础单位: 4px - xs: 4px （图标与文字） - sm: 8px （紧密元素之间） - md: 16px （卡片内边距） - lg: 24px （区块内边距） - xl: 32px （区块之间） - xxl: 48px （大区块之间）

写清楚每一档的用途，比只写数值有用得多。因为工具在生成时，需要判断“这里该用哪一档”，用途说明就是判断依据。我实测下来，有了这套规则，生成出来的页面留白明显更均匀，不会出现某块特别挤、某块特别空的情况。

3.4 圆角、描边与阴影：决定“质感”的三个参数

这三个参数单独看都很小，但合在一起决定了产品的质感走向。圆角大显得亲和、年轻，圆角小显得专业、克制。阴影重显得浮起来，阴影轻显得扁平。描边有无，也影响整体的干净程度。

我一般会先定一个基调，比如“克制、专业”，然后所有参数都往这个方向靠。圆角统一用 8px，卡片和按钮一致；描边用 1px 的浅灰；阴影只用一层很淡的，避免多层叠加显得脏。

## 圆角与阴影 - 圆角: 8px（按钮、卡片、输入框统一） - 小圆角: 4px（标签、徽章） - 描边: 1px solid #E5E8ED - 卡片阴影: 0 1px 3px rgba(0,0,0,0.06) - 浮层阴影: 0 4px 12px rgba(0,0,0,0.10)

这里有个经验：圆角不要混用太多档。我见过一个界面里按钮 6px、卡片 10px、输入框 4px，单看都还行，放一起就乱。统一成 8px 之后，整体立刻干净了。阴影也是同理，能用一层就别用两层，原型阶段更是如此，越简单越不容易出错。

3.5 组件状态：让原型“活”起来的关键

静态原型和能演示的原型，差别就在状态。一个按钮至少有默认、悬停、按下、禁用、加载五种状态。如果Design.md里不写清楚，生成出来的往往只有默认态，演示时点一下没反应，体验就断了。

我会把高频组件的状态规则写进去，重点是按钮、输入框、卡片这三类。按钮的悬停色、禁用色，输入框的聚焦边框色，卡片的悬停阴影，都给出明确值。这样生成出来的原型，鼠标移上去有反馈，点下去有变化，演示时说服力完全不一样。

注意：状态色不要自己临时调，一定要从色彩体系里取。比如按钮悬停色就用之前定义的 Primary Hover，保证全局一致。

4. 实操过程：从零到一份能用的 Design.md

4.1 第一步：收集现有风格素材

如果你手上已经有产品在跑，那最好办，直接去收集现有素材。打开几个核心页面，把用到的颜色、字号、间距都扒出来。可以用浏览器开发者工具看计算样式，也可以直接问设计同学要设计稿的标注。

如果是从零开始的新项目，那就先定基调。找三五个你认可的同类型产品，看看它们的风格走向，是偏冷静还是偏活泼，是信息密集还是留白充足。定下基调后，再往具体参数上落。这一步不用纠结太久，半小时内定下来就行，后面用起来还能调。

我自己的习惯是建一个临时文档，把收集到的色值、字号先堆进去，不做整理。堆得差不多了，再按前面说的维度归类，去掉重复的，补上缺失的。这个过程有点像收拾房间，先全拿出来，再分类放好。

4.2 第二步：搭建 Design.md 骨架

骨架不用复杂，按维度分节就行。我常用的结构是这样的：

# 产品名 Design System ## 色彩 ## 字体排版 ## 间距 ## 圆角与阴影 ## 组件状态 ## 文案语气

每一节先写最核心的几条，不要追求一次写全。比如色彩先写主色和文字色，字体先写正文和标题，间距先写三档。写完先拿去用，用的时候发现哪条不够，再回来补。这种“边用边补”的方式，比一次性憋一份大文档效率高得多，也更贴合实际需求。

4.3 第三步：把规则喂给原型工具

这一步是很多人卡住的地方。Design.md写好了，怎么让它真正影响原型生成？取决于你用什么工具。如果是支持自定义规则或提示词的原型工具，直接把文件内容作为规则输入。如果是用 AI 辅助生成界面，就把文件内容作为上下文一起给进去。

关键点是：规则要完整、明确，不要有歧义。我试过只给一部分规则，结果生成出来的界面在没覆盖的地方就“自由发挥”了，风格立刻跑偏。所以要么给全，要么明确告诉工具“未定义的部分用中性默认值”。后者其实更稳妥，避免工具乱猜。

生成规则补充： - 未在 Design.md 中定义的样式，一律使用中性默认值 - 不要自行发明新的颜色或字号 - 所有间距必须取自定义的间距档位

这三条补充规则，能有效防止工具“自作主张”。我踩过的坑就是没写这几条，结果工具给某个按钮加了个渐变，跟整体扁平风格完全不搭。

4.4 第四步：生成后逐项核对

生成出来的第一版，不要直接拿去评审，先自己核对一遍。核对的方法很简单，拿Design.md当检查清单，一项一项对。颜色对不对，字号层级对不对，间距是不是用的定义档位，圆角统一不统一。

我一般会重点看几个高频出问题的地方：按钮的悬停态有没有，输入框的聚焦边框是不是主色，卡片阴影是不是只有一层。这几处对了，整体基本就稳了。核对完把问题记下来，如果是规则没写清楚导致的，就回去补规则；如果是工具理解偏差，就在补充规则里再强调一遍。

4.5 第五步：沉淀成可复用的模板

一个项目做完，Design.md不要丢。把这次用到的规则整理一下，去掉项目特有的部分，留下通用的骨架，就成了一份可复用的模板。下个项目直接拿这份模板改，改改色值和字体，半小时就能起步。

我现在的做法是维护一份“基础版”Design.md，里面是通用的色彩结构、排版阶梯、间距档位。每接新项目，复制一份，把品牌色和字体替换掉，其余基本不动。这样既保证了每个项目都有自己的风格，又不用每次从零开始。时间久了，这份基础版越来越完善，起步速度也越来越快。

5. 常见问题与排查技巧实录

5.1 生成结果“像但不对”，问题出在哪

最常见的情况是，生成出来的界面乍看没问题，但总觉得哪里不对。这种“像但不对”，八成是间距或层级出了问题。颜色和字体容易对，间距和层级最容易被忽略。

排查方法：把生成结果和Design.md并排看，重点量三个地方。一是卡片内边距，是不是用的定义档位；二是标题和正文的字号差，是不是拉开了层级；三是区块之间的间距，是不是比区块内部大。这三点对了，观感基本就正了。我遇到过好几次，就是区块间距和内部间距一样大，导致所有内容糊成一片，拉开之后就清爽了。

5.2 工具不认规则怎么办

有些工具对 Markdown 规则的解析能力有限，你写了它不一定完全照做。这时候不要硬刚，换个思路：把规则拆成更小的、更明确的片段，分次给。比如先只给色彩规则，生成一版看颜色对不对；对了再给排版规则，再生成一版。逐步叠加，比一次性全给更容易控制。

另一个办法是把关键规则写成更直白的句子，放在文件最前面。工具通常对开头的内容更敏感。我试过把“所有按钮圆角必须是 8px”这句话单独拎出来放最前面，生成结果的圆角就统一了。规则的位置和表述方式，有时候比规则本身还重要。

5.3 团队协作时怎么避免各改各的

Design.md一旦多人用，就容易出现各改各的情况。今天 A 把主色改了，明天 B 把间距调了，最后文件面目全非。解决办法是把它当成代码来管，放进版本管理，改动走评审。

具体做法是：主色、字体这类核心规则，改动需要设计负责人确认；间距、圆角这类，可以放宽一些。每次改动在提交信息里写清楚原因，方便回溯。我见过最乱的情况是文件里同一个色值出现三种写法，就是因为不同人用不同格式加的。统一格式这件事，最好在文件开头就写清楚规范。

5.4 常见问题速查表

这张表我基本每次做新项目都会过一遍，能提前避开大部分坑。尤其是最后一条，规则不完整是导致风格跑偏的头号原因，宁可多写几条默认规则，也不要留空白让工具猜。

5.5 几个我踩过的坑和对应技巧

第一个坑是过度设计。一开始我总想把Design.md写得特别全，结果写了两天还没写完，项目都开始了。后来想通了，规则是用的不是看的，先写核心的，用起来再补。现在我的基础版也就一两百行，够用。

第二个坑是忽略暗色模式。有些产品需要暗色模式，如果Design.md里只写了亮色规则，生成暗色界面时就会乱。解决办法是色彩部分按“亮色/暗色”成对写，语义色和中性色都给出两套值。这个前期多花十分钟，后期省很多事。

第三个坑是文案语气没定义。界面里的按钮文字、提示语，如果没规定语气，生成出来会忽正式忽口语。我一般会写清楚：按钮用动词短语，提示语用陈述句，避免感叹号。这几条一写，文案立刻统一了。

提示：Design.md不是写完就锁死的，它应该跟着产品一起成长。每次评审发现风格问题，都回头看看是不是规则没写清楚，补上，下次就不会再犯。

6. 把风格规则用起来之后的一些体会

这套方法我用在好几个项目上，最大的感受是：它把“风格”这件原本很虚的事，变成了可以执行、可以检查、可以传承的东西。以前风格靠设计师的直觉和口头传达，人一换就断档；现在规则写在文件里，谁来都能接上。

对独立开发者来说，它的价值更直接。你一个人既要想产品又要画原型，没精力去维护一套完整设计系统。一份Design.md就是你的轻量设计系统，几十行规则，就能让原型看起来有模有样，拿去给人看也不露怯。

最后分享一个小技巧：每次做完项目，把Design.md里真正用到的规则标出来，没用到的删掉。几轮下来，剩下的都是精华，文件越来越薄，但越来越准。这个习惯我坚持了挺久，现在手头的基础版已经精简到很舒服的程度，新项目起步基本就是改几个色值的事。