上周跟某团队聊原型评审，对方把三个页面的设计稿拍在我面前，主色蓝就出现了五种，没有两个颜色值相同。评审会开了一个小时，快一半时间在争论“这个蓝到底是不是我们品牌那个蓝”。原型阶段最让人心累的从来不是画得快不快，而是画出来的东西和产品风格是不是同源。
后来我跟他们推了一套很轻的做法：在项目仓库里放一份Design.md，把产品风格拆解成可执行的设计决策和设计令牌，然后用这份文档反推原型。效果比预想中好，原本三周才定下来的视觉方向，一周内就收敛了。如果你也有“原型看着精致，但一放进产品就格格不入”的困扰，这篇内容应该能帮到你。
用Design.md构建符合产品风格的原型设计，不是什么高深理论，本质上就是把“设计规范”从PPT式宣讲稿变成可以在原型里被直接引用的数据源。适合两类人看：一类是单打独斗的独立开发者，画原型全凭手感，今天圆明天方；另一类是正在搭建设计流程、但暂时没有专职设计系统维护者的中小团队。读完你至少能带走一份可以直接套用的Design.md模板，以及一套让原型自动对齐品牌风格的操作方法。
1. 先把问题说清楚：原型为什么总是和产品风格对不上
1.1 产品风格不是一句抽象描述，而是可量化的决策
很多团队对“产品风格”的定义是这样的：高级、简约、大气。这句话放在需求文档里没问题，放到原型里等于什么都没说。我做过一个类比：装修房子时你不会跟施工队说“装得高级一点”，而是会指定墙面乳胶漆的色号、地板的材质和规格、踢脚线的高度。产品风格同理，它必须具体到某一种颜色用在哪一层、文字在什么场景用几号字、两个相邻模块之间留多少空。
用Design.md思考产品风格，第一件事就是把这个模糊概念转译成可量化、可复用的决策集合。比如“品牌的信任感”转译为“主色使用特定色阶的深蓝，按钮圆角控制在4px，卡片阴影不超过两个层级”；“内容密度高”转译为“列表行高压缩到32px，页面左右留白收窄到16px”。这些不再是风格形容词，而是原型里每一处细节的裁决依据。
1.2 传统做法为什么行不通：三个断层
回顾一下大部分团队的原型产出流程，问题几乎都出在三个地方。
第一个断层在设计稿和代码之间。设计师在工具里用颜色八位数色值，开发在样式表里凭肉眼近似一个“差不多”的颜色，肉眼近似在蓝色系上尤其容易跑偏，某品牌蓝稍微偏青一点就不再是那个味道。
第二个断层是规范文档做完即弃。很多团队不是没有设计规范，而是规范以PDF或在线文档形式躺在共享盘里，没有和项目迭代挂钩。规范是规范，原型是原型，两条平行线。过两个迭代，规范版本跟不上实际设计，就再也没人愿意打开。
第三个断层是原型工具和真实界面脱节。工具里做出来的高保真原型，组件状态、字体渲染、间距表现和真实浏览器环境总有差异，评审时说“这里再鲜艳一点”，实现出来又是另一回事。原型如果从一开始就不生长在真实渲染环境下，后续所有验证都是带偏差的。
1.3 我的解法：把Design.md当成设计系统的README
Design.md是什么？你可以把它想成一份以Markdown为载体的设计系统接口文档，它同时承担三个职能：写清产品风格的来源和理由，记录所有设计令牌的设计值与使用边界，在评审和开发联调时充当对照基准。为什么用Markdown而不是在线协作文档或专业设计工具？因为我希望你把它放进代码仓库，和代码一起走版本管理、一起被评审、一起更新迭代。它像工程代码里的README，读得懂、改得动、有历史记录，任何人都可以用编辑器打开然后提一个变更请求。
这个思路的精髓是把设计规范从“装饰性文档”变成“接口约定”。设计团队改了一版按钮圆角，不再需要在群里喊话全团队同步，只需要修改Design.md里对应的令牌值，然后由下游文件统一引用。风格由此从“某个人脑子的理解”变成“代码库里一份可追溯的配置”。
2. Design.md到底该写什么：从原则到令牌再到组件
2.1 第一层：先写清楚“为什么”，再写“是什么”
Design.md开头不是直接上色板，而是先写设计原则。这是很多人跳过的步骤，但它恰恰是后期避免争论的关键。设计原则解决的是“为什么这样设计”，比如“优先保证信息可读性，而不是视觉冲击力”，有了这条原则，后续关于“标题要不要加大加粗加阴影”的争论就自动结束——不符合原则的提案不需要讨论。
实操时可以列三到五条原则，每条配上一段解释和反例。反例尤其重要，比如某条原则规定“交互反馈优先用状态变化而非弹窗打断”，反例就是“删除操作立即弹二次确认，没有给用户反悔时间”。这会约束原型阶段的表现形式，让页面行为具备产品气质，而不仅仅是长得好看。
2.2 第二层：设计令牌，一个把所有风格数据化的关键步骤
设计令牌是整个Design.md的引擎。它解决的问题很直接：让颜色、字号、间距、圆角这些视觉变量具备身份和层级，而不是散落在原型各个角落里的魔法数字。
为了后续扩展和换肤方便，我建议把设计令牌拆成三层。
- 基础令牌：最原始的数值，比如“蓝色500=#2563EB”“字号4=24px”“间距4=32px”，它们只描述“有什么”。
- 语义令牌：描述“用在什么场景”，比如“主按钮背景色=品牌蓝600”“页面背景色=灰阶50”，它们建立“值”和“场景”的对应关系。
- 组件令牌：更具体的组件场景，比如“卡片圆角=圆角2”“导航栏高度=间距5”，它们描述“哪一块长什么样”。
这个分层看起来多一道工序，实际上值回票价。后期换主题色、加暗色模式，只需要改基础令牌或语义令牌，组件层自动跟着变。我见过很多团队在盘点“改版对色值影响范围”时，因为只有一个扁平色板而翻遍了所有原型页面，有了分层之后，改动范围是一目了然的。
Markdown里写令牌时，我建议不要再把它当作文档表格，而是当作原型文件的“配置源”。我习惯用一个代码块保存YAML格式的令牌表，方便后续复制到任何构建工具里：
# 基础令牌 color: brand-blue-500: "#2563EB" brand-blue-600: "#1D4ED8" brand-blue-700: "#1E40AF" gray-0: "#FFFFFF" gray-50: "#F8FAFC" gray-100: "#F1F5F9" gray-500: "#64748B" gray-900: "#0F172A" semantic-error: "#DC2626" typography: font-family-base: "-apple-system, 'Segoe UI', Roboto, 'PingFang SC', 'Microsoft YaHei', sans-serif" font-size-xs: "12px" font-size-sm: "14px" font-size-md: "16px" font-size-lg: "20px" font-size-xl: "24px" line-height-base: "1.5" spacing: spacing-xs: "4px" spacing-sm: "8px" spacing-md: "16px" spacing-lg: "24px" spacing-xl: "32px" radius: radius-sm: "4px" radius-md: "8px" radius-lg: "12px"有些人会觉得用YAML写设计规范很另类，但你在实际操作中会发现，它比一句一句的散文描述更接近“可执行”。原型工具做不到自动读取中文描述，却能直接识别这种结构化数据。
2.3 第三层：组件规范与页面骨架
设计令牌解决了风格数据问题，但要让原型稳定，还需要定义组件的组合规则。组件规范在Design.md里是一张表或一段代码块，描述每个组件在什么场景下使用哪一组令牌，以及存在哪些状态。
以按钮为例，最小必要信息包括：默认背景色、悬停态背景色、按下态背景色、禁用态透明度或灰度值、圆角、内边距、字体令牌。如果加上不同尺寸的按钮，还要给出高度、水平内边距、字号的一组优选值。写到这里你可能会觉得太细了，但这是让“产品风格”落到原型上的关键一步。原型里如果每个按钮都是临时调的尺寸和颜色，风格就不可能统一。
表单、卡片、数据表格、导航菜单同理。组件规范的精髓是保证相同功能的交互元素在产品的每一个角落看起来和用起来都一致。页面骨架则是组件在具体布局里的摆放规则，比如内容区最大宽度、栅格列数、左右留白，这些在Design.md里用一小节带图注的文本说明即可，不需要画像素级线框图。
2.4 一份可以直接复制的Design.md目录模板
下面这个目录结构我实际用过，已经跑过多个项目，你可以按团队情况增删。
# 项目名 Design System ## 1. 设计原则 （3-5条原则+解释+反例） ## 2. 设计令牌 ## 2.1 基础令牌：颜色 / 字体 / 间距 / 圆角 / 阴影 / 层级 ## 2.2 语义令牌：主题用色 / 文本用色 / 功能用色 / 背景层级 ## 2.3 组件令牌：按钮 / 表单 / 卡片 / 表格 / 导航 ## 3. 组件规范 ## 3.1 按钮体系（尺寸 / 状态 / 图标搭配） ## 3.2 表单控件（输入框 / 选择器 / 校验态） ## 3.3 数据展示（表格 / 卡片 / 空状态 / 加载态） ## 3.4 反馈组件（Toast / 弹窗 / 空操作反馈） ## 4. 页面布局 ## 4.1 栅格与断点 ## 4.2 页头 / 导航 / 内容区规则 ## 4.3 通用间距规则 ## 5. 变更记录 （表格：日期 / 版本 / 变更内容 / 影响范围）特别注意：Design.md不应当变成流水账日记，也不用把每个设计细节都写进去。它是一份给原型和研发共同遵守的接口文档，只记录会跨页面复用、会影响视觉一致性的决策。临时为单个页面做的特殊处理，留在页面备注里就可以。
3. 从Design.md到可用原型：一套可复制的实操流程
3.1 为什么我推荐直接在浏览器里做原型
主流原型工具有很多，我并不是说它们不好，只是当你的目标是“让原型符合产品风格”时，浏览器直接产出原型有不可替代的优势：原型里的每一个颜色、字距、间距都真实地运行在CSS环境中，所见即所得，且和最终开发实现几乎零偏差。另外，浏览器环境下你可以直接引用Design.md里的设计令牌变量，从根本上杜绝手误改错色值。
当然这需要你会一点HTML和CSS基础，不需要精通，能看懂变量、会用Flexbox布局、会写静态页面即可。如果你是完全零代码背景的设计师，也不要有压力，这一步可以由团队里一位开发同事配合完成，而你要负责的是Design.md里的决策部分。
实操项目建议选一个团队里大家都熟悉的页面，比如“某企业数据看板”这种常见后台界面。用Design.md驱动这个页面的原型搭建，比从头设计“未来产品”更容易暴露问题。
3.2 第一步：把Design.md里的令牌变成CSS变量
从Design.md到原型最关键的一步，是让令牌在原型里“活起来”。方法是在全局样式表里添加CSS自定义属性，让每个变量名与Design.md中的语义令牌一一对应。
以颜色和间距为例：
:root { /* 语义令牌颜色 */ --color-primary: #1D4ED8; --color-primary-hover: #1E40AF; --color-bg-page: #F8FAFC; --color-bg-card: #FFFFFF; --color-text-primary: #0F172A; --color-text-secondary: #64748B; --color-border-light: #F1F5F9; --color-error: #DC2626; /* 间距令牌 */ --space-xs: 4px; --space-sm: 8px; --space-md: 16px; --space-lg: 24px; --space-xl: 32px; /* 圆角与阴影 */ --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px; --shadow-card: 0 1px 2px rgba(15, 23, 42, 0.06), 0 1px 3px rgba(15, 23, 42, 0.1); }建立映射时有个小原则：CSS变量名必须跟Design.md中的语义令牌名一致，而不是跟基础令牌一致。比如Design.md里“品牌蓝600”是基础令牌，而“主按钮背景色=品牌蓝600”是语义令牌，CSS变量应命名为--color-primary，而不是--color-brand-blue-600。原因前面说过，语义层在换肤和暗色模式下能起到稳定的接口作用。
3.3 第二步：根据Design.md的页面布局规则搭框架
接下来搭页面框架。你不需要每个像素都对齐最终成品，但要符合Design.md里栅格与留白的约定。以前面提到的数据看板为例，我通常是这样划分的：左侧导航固定宽度240px，顶部栏高度64px，右侧内容区采用12列栅格，左右页边距24px，卡片间距16px。
这些数字不是随手拍的，它们都能在Design.md的页面布局章节找到出处。如果Design.md还没定义，那此刻就是补全文档的时机——从原型里提炼出经过验证的组合值，回写到规范里。原型和规范来回“喂”数据，这个循环就是Design.md能持续进化的关键。
骨架层的HTML结构可以简化为这样：
<div class="layout"> <aside class="sidebar">导航区</aside> <div class="main"> <header class="topbar">页头区</header> <main class="content"> <div class="card">统计卡片 1</div> <div class="card">统计卡片 2</div> <div class="card">图表区域</div> </main> </div> </div>搭配的CSS里只使用步骤3.2中定义的变量，坚持“不在样式表里写任何魔法数字”。你想临时加大某块留白，优先去检查是设计规范本该如此，还是原型自己跑偏了。这套约束力会让你少走很多回头路。
3.4 第三步：按组件规范组装高价值页面
框架搭好后，以组件规范为字典，把各类页面组装出来。以三个页面为例：
页面一：登录页。这是品牌感最集中的页面，要求在主视觉区和表单区严格使用主色和品牌辅助元素。登录按钮的常规、悬停、加载和禁用四个状态都要做出来，因为状态缺失正是原型评审时最容易出现的风格漏洞。
页面二：数据列表页。全屏页面最能暴露组件一致性的问题。同一行中有多个操作按钮时，它们的尺寸和间距是否统一；表格空状态是否使用了Design.md定义的插画风格和文案语气；异常状态的用色是否来自功能令牌，而不是随便一个“红色”。
页面三：数据详情页。该页面通常由多张卡片组成，是检验卡片组件规范的好地方。卡片内部间距是否统一按4的倍数叠加，标题与副标题的字号关系是否符合排版层级。
组装页面时，我强烈建议把常用的组件块拆成可复用的局部。你可以顺手把这几个页面做成原型模板，后续新页面的产出会非常快，因为只要套用骨架和组件，页面上一个已经符合产品风格的雏形就出现了。
3.5 第四步：回写闭环，原型里发现的新决策要反哺Design.md
这一步是被大多数人忽略但价值极高的部分。原型阶段一定会有拍板的新决策——页头多了一个筛选区，原本表格里的状态文案决定升级为标签组件，这些决策如果在原型里定了，却没有回写到Design.md，再过两周，原型就再次和规范脱节。
我实际操作时给自己定了个流程：每周五下午花半小时，把本周原型里新产生的、可复用的设计决策追加到Design.md，同时把已经过时的组件规范标记为废弃并记录原因。这半小时是在给下个月的自己省下几天的时间。Design.md的运行方式是“用完即改”，而不是“写完就锁死”，这恰是它能长期活下去的生命力所在。
4. 搭建与维护中常踩的5个坑（附排查思路）
4.1 问题一：Design.md写完了，但没人真去读
这是最普遍的尴尬。文档躺在仓库里并不是价值，被使用才是。排查思路很简单：看团队在评审原型时是打开Design.md逐项对照，还是凭感觉说“有点不对”。如果是后者，说明项目流程没有给文档设计“使用时机”。
解决办法是把Design.md直接变成一个流程节点：原型评审开始前，由发起人把本次评审涉及的设计原则和组件规范列出来；评审结束前，扔出最后一个问题——“这版原型有没有与Design.md冲突的地方？”有了这个强制动作，文档才可能被真正打开。另外，把Design.md放在代码仓库根目录，开发同学在联调时顺手就能打开查看，这比放在共享盘里更容易被触及。
4.2 问题二：暗色模式一开，颜色乱成一团
很多团队做暗色模式时，直接给所有背景换深色，文字换白色，结果红色品牌元素在暗底上刺眼、卡片阴影几乎不可见、边框色过淡，页面层次全丢了。根因往往是把基础令牌当语义令牌用了，页面组件直接引用了“白色背景”“黑色文字”这种基础值，没有经过语义层。
排查方式是检查CSS里是否大量出现直接引用基础色值的现象，正确的做法是组件全部引用--color-bg-card、--color-text-primary这类语义变量，暗色模式只需要覆盖顶层变量而不动组件代码。暗色模式下阴影通常需要加深而不是减弱、避免直接用纯黑、边框色可能需要比亮色模式稍微亮一点来保持边界可见，这些细节都要在Design.md里明确写进语义令牌的说明中。
4.3 问题三：间距越来越大，页面越改越散
原型改几版之后，经常出现卡片内边距24px、卡片之间又是24px、与页面留白还是24px，如果内部子模块再叠加margin，最终视觉密度完全跑偏。这是间距叠加效应在作怪。
排查时直接在浏览器里审查元素，看块级组件的margin和padding分别是什么，有没有两个相邻组件“外间距相加”的情况。我推荐的解决方式是：卡片内由padding控制内白，布局层由margin控制模块间距，各自只在一个方向使用，并严格使用Design.md的间距令牌，不额外用“微调数值”。如果某个细节真需要多出2px的调整，也该先想着这是不是设计规范本身需要修正。
4.4 问题四：字号按规范设置后，页面反而显得粗糙
字号规范不是单看字号数值，行高和字重缺一不可。有些团队只定了字号，结果小字号加上过大的行高，文字之间像插了空行，大字标题又用了过细的字重，视觉撑不住。
排查流程是检查原型里主要文字是否成体系。我一般建议行高在小字号场景用1.5，标题场景用1.2到1.3，并同步定义字重，正文常规字重，数据数值用中等字重，页面主标题用加粗。另外，中文字号不建议做得过小，12px是阅读舒适度的底线，如果在暗色模式或低分辨率屏上还要再下探，不如去重构信息层级而不是压缩字号。
4.5 问题五：有人不按Design.md来，怎么推都推不动
这种情况我见得最多。真正原因通常不是“大家不尊重规范”，而是规范没有参与最终验收。如果原型评审只看视觉效果、代码评审只查功能逻辑，那规范文档自然成了空气中无约束力的存在。
排查思路比较直接：在原型评审、视觉验收、开发联调三个节点里都加入“规范一致性检查”这一栏，并让Design.md责任人拥有对风格相关问题的否决权。只要这个职位效能是真实的，成员就会逐渐把Design.md当成刚需工具，而不是约束锁链。同时要坦白讲，不是每一次偏离都值得纠正，偶尔视觉上更优的做法，应该在更新Design.md后变成新规范，而不是保留私下做法。
5. 给我的最后一句话
用Design.md构建符合产品风格的原型设计，核心并不是Markdown，也不是CSS变量，而是“把风格转译为数据，再让数据驱动界面”的思维模式。我见过太多团队花大力气去追热门协作平台、点选式设计系统工具，实际上解决问题的关键不在于工具多豪华，而在于决策是否有记录、是否有唯一来源、是否被后续流程强制消费。
如果让我给刚接触这套流程的团队一个最务实的建议，我会说：别强求一步到位。第一版Design.md哪怕只有半页纸——写清主色、字体、间距、四五个组件的状态——都足够支撑第一次原型搭建。然后让它在一次真实迭代里自然生长，你很快会发现自己再也不需要用“感觉”来做视觉判断了。这就是我踩过几次坑之后，最深的一点体会。
