事情是这样的。前阵子接了一个内部中台产品的原型重构例会开了三轮产品经理对着我的高保真图反复提同一个意见这版交互没问题但视觉上不像我们自己的产品更像你上个项目的东西。这话听着扎心但确实是很多原型设计师的通病——每一稿都好看每一稿都跟目标产品的气质对不上。后来我换了个思路不再直接开设计软件画图而是先写了一堆 Markdown 文档把产品的设计语言、组件规范、页面骨架全部文字化再拿这份文档去驱动原型的构建。这个做法效果比我预想的好得多所以今天把这套用 Design.md 构建符合产品风格原型的方法完整拆一遍包括我踩过的坑和整理出的细节模板。1. 为什么需要一份 Design.md 而不是直接打开设计软件很多团队的原型流程是产品经理写 PRD交互设计师画 Axure视觉设计师出高保真前端再拿设计稿还原。听起来分工明确但中间至少有三个断层PRD 里不会写间距是 8 还是 12Axure 里的灰色矩形到了视觉阶段要全部推翻重画前端拿到稿子还要猜设计规范。我试过最难受的一次。产品经理在 PRD 里描述“这是一个卡片式列表选中状态要明显”交互稿里我画了灰底白卡视觉稿里设计换成了带阴影的圆角卡前端实现时把主色用成了品牌蓝。最后的成品确实是个卡片列表但没有任何人知道它应该长什么样。根因就一句话原型缺少一个单一的事实来源导致每个环节都在自行解释“产品风格”。Design.md 解决的就是这个问题。它本质上是一份用 Markdown 写成的产品设计契约里面包含了颜色、字体、间距、组件、页面模板、交互状态、甚至文案语气。它不是给设计软件用的配置文件而是给人看的、开会能吵出结论的、改起来只要搜替换的文本协议。有人会问这不就是设计规范文档吗Figma 里也有 design tokens。对本质上是一回事但 Design.md 有自己的独特价值零工具门槛任何人用记事本就能打开产品、设计、开发都能参与编辑版本可追溯Git 里能清楚看到谁改了什么为什么改可生成原型Markdown 本身能转 HTML配合轻量脚本就是一套低配设计系统适合文档驱动写清楚了再做图避免“先画再说”导致的反复推翻我用这套方法重构之后整个原型从零到交付只用了三个工作日而且视觉负责人过稿时几乎没提“风格不对”的意见。不是因为我的画图水平突然变高了而是因为在中途的每一步Design.md 都在约束我做出符合产品风格的决定。1.1 Design.md 和常规设计规范的本质区别可能有人听到这里觉得不就是把设计规范写成 Markdown 吗和之前的规范文档有什么区别。区别在于“能否被执行”。传统设计规范一般是做完了稿子才补的一份 PDF里面写着“主色为 #2F54EB圆角为 4px”但设计稿里用没用没人管。Design.md 的写法则不同它的条目会直接映射到原型代码里的变量、类名和组件参数。我在实际操作时会把 Design.md 定义成三块内容设计令牌Design Tokens颜色、字号、间距、圆角、阴影的具体数值组件定义按钮、卡片、表格、弹窗等标准组件的结构和状态页面模板列表页、详情页、表单页的布局骨架和区块说明这个结构的好处是当我开始搭原型时不需要再动脑子想“这个按钮应该是什么色”直接照抄 Design.md 里的令牌不需要纠结“表单页长什么样”直接套页面模板。原型成了一个填充过程而不是设计过程效率和一致性同时提升。1.2 哪些项目最适合用这种文档驱动的方式我也得泼点冷水Design.md 不是万能的。它最适合的是 B 端中后台、工具类产品、数据密集型页面这类产品有几个共同特征界面以功能模块为主、视觉风格收敛克制、需要大量重复组件、迭代频率高。中后台产品的每个页面几乎都是表格、表单、卡片的组合用文档驱动就是先定义好这些标准件再拼装。反之如果做的是强视觉运营页、创意落地页、品牌展示站Design.md 的约束反而会成为枷锁。这类页面追求视觉冲击力和差异化用标准组件拼不出独特感。这种情况还是老老实实开设计软件逐个像素打磨更靠谱。我给自己的判断标准很简单如果同一个组件在这个产品里出现了五次以上就应该在 Design.md 里定义它如果五秒内想不出产品的主色和圆角值说明这个产品还处于视觉探索期不适合文档驱动。2. 搭一个能吃进产品气质的单文件原型骨架有了 Design.md接下来的问题是怎么用它构建原型。我的做法是写一个单文件 HTML 原型把所有样式和组件都内联在里面文件的header里引用 Design.md 生成的设计令牌这就是最轻量的“Design.md 执行器”。为什么不直接用现成的组件库比如 Element 或 Ant Design因为这些库有它们自己的风格一用就变成“Element 风格”或“Ant Design 风格”而不是你的产品风格。我要的是让原型透出目标产品自己的气质所以核心样式必须由 Design.md 驱动而不是由组件库驱动。2.1 从 Design.md 到 CSS 变量的一步转换Design.md 里写完设计令牌后我会把它们转换成 CSS 变量。这一句话看起来轻巧但实际做的时候有个关键点不只是纯数值的搬运而是把数值背后的语义固定下来。我在 Design.md 里的写法和最终生成的 CSS 变量保持对应关系比如## 设计令牌 ### 品牌色 - 主色: #2557A7品牌蓝用于主按钮、选中态、链接 - 辅助色: #13A8A8成功/正确 - 警示色: #E6A23C警示/待处理 - 危险色: #F5222D错误/删除生成到 CSS 里就是:root { --brand-primary: #2557A7; --brand-success: #13A8A8; --brand-warning: #E6A23C; --brand-danger: #F5222D; }这里有个非常容易忽略的细节Design.md 里的注释要写得像设计规范而不是像代码注释。比如“主色用于主按钮、选中态、链接”这句话等到配色调整时最关键我一改 Markdown 里的色值全文的变量跟着换但语义不会丢。表格、侧边栏、步骤条的配色依赖的是语义名不是某个具体色值。用 CSS 变量还有一层好处后期如果要切换品牌主色比如从蓝色调换成绿色调只需要改 Design.md 里的一个色值全文所有用到var(--brand-primary)的地方全部自动变。这个能力在给某个大客户做定制化主题时非常有用几乎是零成本换肤。2.2 用 HTML 结构模板锁定页面骨架单文件原型里除了样式还有一个更重要的东西页面骨架。B 端产品的页面再千变万化拆到最后就是几个固定区块的排列组合——顶部导航、侧边栏、内容区、页脚、操作栏。我在 HTML 里定义了一套基础布局骨架完全对应 Design.md 里的页面模板描述div classapp aside classsidebar !-- 侧边导航Design.md 定义宽度为 220px -- /aside main classmain header classpage-header h2 classpage-title/h2 div classpage-actions/div /header section classcontent !-- 具体业务内容 -- /section /main /div这个骨架的代码量不大但它起到了一个“模具”的作用。不管往里填什么业务内容页面的大结构都不会跑偏产品经理、设计师看到原型时一眼就能认出“这是我们产品的页面框架”而不是一个陌生的网页。2.3 为什么我强烈建议用单文件而非构建工具可能有人觉得既然要上 Design.md干脆用一套构建工具把 Markdown 编译成完整的样式系统再配合组件框架。我一开始也这么想装完两套工具之后发现陷入了工具泥潭配置编译、处理缓存、维护依赖真正花在原型本身的时间不到三分之一。后来我回归了最朴素的单文件 HTML。理由很实在原型的核心目的是讨论需求、验证交互、确认视觉方向不是生产级代码。单文件不需要构建、不需要服务器、不需要安装依赖双击就能打开还能直接丢进评审群里让任何人开浏览器看。为了做到单文件需要注意几点纪律所有 CSS 写在style标签里不允许外链样式文件所有 JS 改成纯手工写需要的那几行不需要挂 UI 框架组件之间用语义化 class 区分不引入原子化 CSS这样哪怕原型做了上百个页面也只是在一个 HTML 里复制区块和修改文案。文件大了点但任何一台电脑都能打开这比任何工程化方案都可靠。3. 从 Design.md 到视觉变量颜色/字体/间距的真实落地过程这一节讲具体的转换细节也是我在实操中发现“原型风格不统一”的关键根源。很多原型设计者不是不会配色、不会选字体而是每一次凭感觉做的决定不一样。Design.md 就是把这些“感觉”固化下来。3.1 颜色体系不能只给一个主色很多设计规范只写一个主色和一个辅助色实战里根本不够用。一个完整的产品颜色体系至少要覆盖以下层面颜色类型代表 Token典型用途我这边的落地建议品牌主色--brand-primary主按钮、选中态、链接选一个百搭且不刺眼的低饱和蓝少用纯色功能色--brand-success/warning/danger状态反馈用“成功绿、警示黄、危险红”标准色图表辅助色--chart-1到--chart-6图表系列和主色同色系并递减饱和度不要用彩虹色中性色--text-primary/secondary/disabled文字层级从灰 900 到白分出至少 5 个层级边框背景--border-color,--bg-page,--bg-container布局划分页面底灰、容器底白、边框淡灰我列一个实际写过的配色块作为参考:root { --brand-primary: #2557A7; --brand-primary-light: #E8F0FE; --brand-primary-dark: #173A6B; --brand-success: #13A8A8; --brand-warning: #E6A23C; --brand-danger: #F5222D; --text-primary: #262626; --text-secondary: #595959; --text-disabled: #BFBFBF; --border-color: #E8E8E8; --bg-page: #F5F7FA; --bg-container: #FFFFFF; }这套值并不是随手写的而是基于“黑白文字 一个主色 一个中性背景”的经典 B 端配色公式。主色负责品牌识别中性色负责信息层级功能色负责状态反馈。我不会选超过两个高饱和颜色作为主色否则整个页面会像广告页不像工具产品。3.2 字体与字号层级比字体本身更重要字体这块B 端产品通常不需要自定义字体直接走系统字体栈确保任何设备上打开都不难看。但字号层级必须明确我参考过不少设计系统的规则自己整理成一套足够用的字号令牌:root { --font-size-xs: 12px; /* 辅助说明、时间戳 */ --font-size-sm: 13px; /* 次要信息 */ --font-size-md: 14px; /* 正文默认 */ --font-size-lg: 16px; /* 页面标题/强调 */ --font-size-xl: 20px; /* 模块大标题 */ --font-weight-regular: 400; --font-weight-medium: 500; --font-weight-bold: 600; }这套字号从 12 到 20正好覆盖中后台的典型场景。这里有个很实用的小经验正文不要小于 12px否则在 125% 缩放的屏幕上会发虚页面大标题也不要轻易上 24pxB 端页面信息密度高字号过大会压缩内容空间。3.3 间距与圆角8 像素网格和克制的阴影间距设计我统一走 8px 网格体系4、8、12、16、24、32、48。间距令牌不写死 4 或者 6 这种“方便正好”的数字而是走等比增长的区间。理由在于页面上任何一处对齐关系都能从这几个数字里找到解释不会出现 17px 这种需要猜的间距。圆角也走克制路线中后台产品我用两个档位小圆角 2px大圆角 6px。对比度弱的卡片间距、输入框用 2px按钮、标签、弹窗用 6px。阴影只保留一层悬浮阴影用于弹窗和下拉面板卡片不常设阴影而是用边框和底色做区分。把这些写进 Design.md 之后我发现整个原型的“消毒水味”少了亲近感多了不张扬但很稳这就是产品该有的气质。4. 通过组件定义让原型自带产品基因设计令牌是原料组件才是真正拼装页面的零件。一个原型像不像某个产品很大程度取决于组件长什么样。我在 Design.md 里给每个组件写清结构、状态和视觉参数然后在 HTML 里实现。4.1 标准组件包按钮/表格/表单/Banner 的形态落地挑几个最核心的组件展开这些也是我在实际项目里最常被反复改样式的地方。按钮是最多细节的组件。Design.md 里定义它的层级主按钮实心底、次按钮白底描边、文本按钮无底色无边框、危险按钮红色实心。状态至少包括默认、悬停、按下、禁用。在主原型里按钮的 CSS 是这套思路.btn { height: 32px; padding: 0 16px; border-radius: 6px; font-size: 14px; border: 1px solid transparent; cursor: pointer; } .btn-primary { background: var(--brand-primary); color: #fff; } .btn-primary:hover { background: var(--brand-primary-dark); } .btn-default { background: #fff; border-color: var(--border-color); color: var(--text-primary); }尺寸上我还会区分大中小三档大 36px 用于页面级主操作区中 32px 是默认小 24px 用于表格内操作。这个尺寸体系写进 Design.md 后无论谁画原型出来的按钮都不会变形。表格是所有中后台页面的主角。Design.md 里定义表格的头部底色、行高、边框、对齐方式、悬停行为。实际操作我非常看重行高紧凑型表格行高控制在 36px标准型 44px宽松型 52px。表格的视觉风格一起页面整体基调就定了。表单的标签对齐、输入框宽度、校验状态也是高频痛点。我给表单的关键约束是标签右对齐且宽度统一输入框宽度至少 240px错误状态要有图标和红色描边。这样表单页即使内容再多看起来也是规整的。Banner 提示用相对克制的做法。成功/警告/错误三种状态用淡色底、左侧色条、常规文字构成不搞大面积渐变底。4.2 状态设计的三个层次原型设计里最难看出来的东西是状态但状态恰恰最影响质感。我拆成三层元素状态按钮的悬停、卡片的选中边框、输入框的 focus 效果页面状态加载中骨架屏或 loading 图、空状态插图文案引导按钮、错误状态说明和重试数据状态表格加载状态显示一行灰色 loading、筛选无结果显示空图、提交失败返回错误提示我在 Design.md 里为这些状态单独立了一个章节每条写清触发条件和展示方式。这样前端在还原时不会问“这个按钮 hover 应该是什么颜色”直接在文档里搜“hover”就有答案。4.3 把交互交互说明也塞进 Design.md原型不仅是静态图交互说明决定了它的灵魂。我在 Design.md 里给每个组件追加交互注释比如按钮点击后是打开弹窗、跳转新页还是提交表单表格行点击是进入详情还是展开行。这些交互注释我一般用括号跟在组件描述后面例如### 操作按钮组 - 主按钮: [操作名称]点击后弹窗确认确认后提交表单 - 危险按钮: [删除]点击后二次确认使用危险色警示 - 批量操作选中行后启用未选中时置灰这份文档既是设计师画交互时对照的剧本也是前端开发时对照的说明书。后来团队把它直接当作轻量 PRD 的交互补充产品经理审稿速度都变快了。5. 用页面模板把规范固化进业务场景组件和令牌是零部件页面模板则是装配图纸。很多团队的原型不统一不是组件不一致而是同样的业务场景画出了完全不同的页面布局。Design.md 里的页面模板章节专门治这个问题。5.1 列表页模板和详情页模板的骨架设计我定义了几个中后台高频页面模板每一个都写清布局区块、区块宽度和内容占比。列表页模板是最常用的。它的结构是顶部面包屑 页面标题区标题 右侧操作按钮 筛选区条件表单一行排开 工具栏批量操作 统计信息 视图切换 表格区 分页区。每个区块在 Design.md 里有明确说明比如筛选区默认一行最多四个筛选项多余的收起到“更多筛选”折叠面板。详情页模板的结构则是标题区返回按钮 名称 状态标签 基本信息区多个字段左右两列展示 区块分割线 详情卡片区可多个卡片按优先级排列 操作区固定在底部或随区块后。这个模板的最大价值是防止详情页变成一坨没有断层的按钮堆。5.2 模板在 HTML 里的实际使用方式页面模板在 HTML 里表现为一段可复制的骨架代码。每当我需要新开一个列表页就在原文件里复制一段列表区块替换标题和数据行。这样做三个工作日做出二十多个页面完全没问题因为每个页面都是成熟模板的组合不需要从零搭建。例如列表页的最小模板长这样div classpage div classpage-header div h3 classpage-title客户列表/h3 span classpage-desc共 128 条记录/span /div div classheader-actions button classbtn btn-primary新建客户/button button classbtn btn-default导出/button /div /div div classfilter-bar !-- 筛选条件表单 -- /div div classtable-wrapper !-- 数据表格 -- /div div classpagination !-- 分页 -- /div /div这个模板的好处是即便它最终没有被交付到开发环境也能作为低保真页面继续参与需求讨论。产品经理拿到的是结构完整、风格一致、可点击跳转的“假系统”比看一页页线框图直观得多。5.3 风格一致性在跨页面场景下的约束价值跨页面一致性是最难在传统流程保持、又最容易在原型阶段崩盘的部分。设计师画第一个页面时很专注画到第十五个页面时开始疲惫颜色的深浅、间距的大小就会偷偷漂移。Design.md 加模板的方式直接堵死了这种漂移。我做原型时有个习惯每隔几个页面就对照一次 Design.md检查顶部导航的高度、侧边栏宽度、按钮间距是否一致。因为所有页面共用同一套变量和模板正常情况下它们天然一致需要检查的只是内容区块本身。这套约束对交付后的前端开发也有强烈正反馈。前端拿到原型看到每个按钮尺寸都有 CSS 变量对应心里稳了一大截还原度直接上了一个台阶。6. 把维护迭代做成可持续的循环Design.md 不是一次性文档它跟着产品一起演进。我在这套体系里最重视的就是维护机制没有维护机制文档会在两周后腐烂然后所有人迅速回归“凭感觉做风格”。6.1 一个变更流程和职责划分的建议我建议执行一套简单但有效的变更流程。当某个人提出“我觉得主色可以换一下”的时候不要直接在原型里改颜色而是先改 Design.md同时提交变更说明说明变更原因、影响范围、新旧对比。在具体协作中职责划分是产品经理负责维护页面模板和业务组件描述设计师负责维护设计令牌和视觉细节前端维护 HTML/CSS 实现。任何变更都先走文档再从文档传导到原型和开发环境。关于这一点我觉得讲再多都不如亲手跑一次试过之后就能体会到“文档驱动”和“事后写文档”的差别。6.2 从 Design.md 到实际开发的传导路径Design.md 最终不只服务原型阶段它还可以直接成为前端组件的注释来源。我在开发阶段做同样一件事把 CSS 变量传给前端代码仓库的 design tokens 文件把组件描述翻译成前端组件 API 文档页面模板直接作为前端路由的页面骨架参考。这个传导路径听起来像是做了两遍工作实际上因为所有信息都以 Markdown 文本形式存在传菜成本非常低。只要我用脚本定期把 Markdown 里的令牌同步成 CSS 文件前端每次构建都能拿到最新规范不会再有“设计稿和线上差一个颜色”的魔幻事件。6.3 找到适合自己团队的执行节奏走到这里大家应该看得出来Design.md 本质上是一套轻量、文档驱动、能串联需求和实现的原型工作流。我不能说它适合所有团队但对信息密集、组件复用高的 B 端产品它的收益立竿见影。如果你的团队还在为“原型风格漂移”发愁与其再换一个设计工具不如先试着把风格写成一份文档让所有人对着同一个文本做决定。还有几个实战细节想分享Markdown 里的颜色值最好统一用十六进制小写方便脚本读取每次修改 Design.md 后记得用脚本同步一遍 HTML 里的 CSS 变量给 Design.md 建一个“变更记录”章节写清楚日期、修改人、修改原因后续翻文档的时候能省很多力气我做过的几个内部项目最后这步都保留了下来。原型做得再敷衍只要 Design.md 是新的下一个版本重做原型都花不了几个小时反过来原型画得再精细文档烂了下个迭代依然要从头吵一遍。所以我的忠告是把文档当作原型真正的资产页面只是它的输出物之一。