企业官网建设流程全解析

1. 为什么要在原型阶段引入 Design.md

1.1 原型设计的核心痛点：风格漂移与沟通损耗

做过中大型产品原型的人大概都有这种体会：第一版原型出来的时候，产品经理说"感觉不对"，设计师说"这不是我们的调性"，开发说"这个间距和字号跟设计规范对不上"。问题出在哪？不是谁不专业，而是原型阶段缺少一个可被所有人引用的"风格基准"。

传统的做法是丢一份设计规范 PDF 或者 Figma 链接过去，但 PDF 是静态的，Figma 需要权限和工具门槛，而且原型工具（不管是 Axure、Figma 还是代码原型）里并没有一个"活的"规范约束。结果就是每个人凭记忆和理解去还原风格，做着做着就漂移了。

Design.md这个思路，本质上是把产品风格从"散落在各处的规范文档"收敛成一份纯文本、可版本管理、可被工具链读取的风格定义文件。它不依赖任何特定平台，Markdown 格式意味着谁都能打开、谁都能改、谁都能 diff。

1.2 Design.md 到底解决什么问题

我把它归纳成三件事：

• 统一语言：颜色、字号、间距、圆角、阴影这些基础 token 用固定命名写死，原型里引用的是变量名而不是魔法数字。
• 降低门槛：不需要打开设计软件，产品、运营、甚至老板都能直接读这份文件，理解"我们的主色是什么、按钮圆角是几像素"。
• 可追溯：改了哪条规范，git 记录清清楚楚，配合原型代码能快速定位"这次改版动了哪些视觉变量"。

适合谁来参考？我认为三类人收益最大：一是独立开发者或小团队，没有专职设计系统维护者；二是产品经理，需要快速产出"看起来像自家产品"的原型去验证需求；三是前端工程师，想在做高保真原型时直接复用一套 token。

1.3 一个生活化的类比

你可以把Design.md理解成装修时的"材料清单+配色卡"。以前装修，业主口头说"要温馨一点"，工人凭感觉刷墙，最后大概率返工。现在你拿着一张卡片：墙面是暖白（#FAF7F2），踢脚线是浅木色，主灯色温 3000K。工人照着做，业主照着验，谁都不用猜。原型设计里的Design.md就是这张卡片。

2. Design.md 的结构设计与字段拆解

2.1 一份可落地的 Design.md 应该包含哪些区块

我实测下来，一份够用的Design.md至少要有下面几个区块。少了任何一个，原型还原时都会出现"这个值从哪来"的尴尬。

这里我要强调一点：不要一上来就追求大而全。我见过有人把 Design.md 写成几百行的设计系统文档，结果没人看。原型阶段，色彩、字体、间距这三样覆盖了 80% 的视觉还原问题，先把这三块写扎实。

2.2 色彩系统：命名比色值更重要

新手最容易犯的错是直接写#3B82F6然后到处复制。正确做法是先命名，再赋值。比如：

## 色彩系统 ### 品牌色 - `--color-primary`: #3B82F6 （主操作、链接、选中态） - `--color-primary-hover`: #2563EB - `--color-primary-active`: #1D4ED8 ### 语义色 - `--color-success`: #10B981 - `--color-warning`: #F59E0B - `--color-danger`: #EF4444 ### 中性色阶 - `--color-text-primary`: #111827 - `--color-text-secondary`: #6B7280 - `--color-border`: #E5E7EB - `--color-bg`: #FFFFFF - `--color-bg-subtle`: #F9FAFB

为什么这么写？因为原型里你写color: var(--color-primary)，将来品牌色从蓝改成紫，只改一行。如果到处是硬编码色值，改版就是灾难。这个道理跟写代码不要用魔法数字是一模一样的。

2.3 字体与间距：建立可预测的节奏

字体排版我建议用阶梯式定义，而不是给每个地方单独定字号。间距同理，用基础单位倍数。

## 字体排版 - 字族: -apple-system, "PingFang SC", "Microsoft YaHei", sans-serif - 字号阶梯: - `--font-xs`: 12px - `--font-sm`: 14px - `--font-base`: 16px - `--font-lg`: 20px - `--font-xl`: 24px - `--font-2xl`: 32px - 行高: 正文 1.6，标题 1.3 - 字重: 常规 400，中等 500，加粗 600 ## 间距系统 - 基础单位: 4px - `--space-1`: 4px - `--space-2`: 8px - `--space-3`: 12px - `--space-4`: 16px - `--space-6`: 24px - `--space-8`: 32px

提示：间距基础单位选 4px 还是 8px，取决于你的产品密度。信息密集型后台选 4px 更灵活，消费级产品选 8px 更清爽。这个决定要在 Design.md 里写清楚理由，避免后来者随意打破。

2.4 组件规范：把"感觉"翻译成"参数"

组件区块是原型还原度提升最明显的地方。以按钮为例，与其写"主要按钮要显眼"，不如写死参数：

## 组件规范 ### 按钮 Button - 高度: 40px（大）/ 32px（中）/ 28px（小） - 内边距: 水平 `--space-4`，垂直 `--space-2` - 圆角: `--radius-md` (8px) - 主按钮: 背景 `--color-primary`，文字白色，hover 用 `--color-primary-hover` - 次按钮: 背景透明，边框 `--color-border`，文字 `--color-text-primary` - 禁用态: 透明度 0.5，光标 not-allowed

这样写的好处是，任何人拿到这份文件，都能在任意原型工具里复现出一致的按钮。这就是"符合产品风格"的底层保障。

3. 从 Design.md 到原型：完整实操流程

3.1 第一步：抽取现有产品的风格基因

如果你是从零开始的新产品，可以跳过这步直接定规范。但大多数情况是"已有产品，要做新功能原型"，那就得先逆向抽取。

我的做法是打开现有产品的几个核心页面，用取色器抓主色、次色、背景色，用开发者工具看字号和间距。抓的时候注意：

• 主色不要只抓一个，要抓 hover 和 active 态，否则原型交互会露馅。
• 字号要抓"实际渲染值"，注意有些产品用了 rem 缩放。
• 间距抓 5 到 8 个典型值，归纳出基础单位。

抓完填进Design.md模板，这一步大概花 1 到 2 小时，但能省下后面反复沟通的无数时间。

3.2 第二步：把 Design.md 接入原型工具链

这一步是很多人卡住的地方。分两种情况说。

情况一：用代码做原型（HTML/CSS 或 React 等）

最直接的方式是把 Design.md 里的 token 转成 CSS 变量文件：

:root { --color-primary: #3B82F6; --color-primary-hover: #2563EB; --font-base: 16px; --space-4: 16px; --radius-md: 8px; }

然后原型里全部用变量。我习惯再写一个tokens.js导出同名对象，方便 JS 逻辑里也用同一套值，避免 CSS 和 JS 两套颜色对不上。

情况二：用设计工具做原型

Figma 这类工具支持导入变量（Variables）。你可以手动把 Design.md 的值录入，或者写个小脚本把 Markdown 解析成 JSON 再导入。虽然多一步，但一次录入长期受益。

注意：不管哪种情况，Design.md 是唯一事实来源。工具里的值如果和文件不一致，以文件为准，并且要立刻同步回去。我踩过的坑就是工具里改了个色忘了更新文件，两周后做新页面时用了旧值，两个页面颜色微妙地不一样，被用户吐槽"看着别扭"。

3.3 第三步：用真实页面验证规范完整性

规范写完不代表能用。我的验证方法是拿一个中等复杂度的页面做"压力测试"，比如一个带表单、列表、弹窗的详情页。做的过程中每遇到一个 Design.md 里没定义的视觉决策，就记下来补进去。

常见的遗漏点包括：

• 分割线颜色和粗细
• 表格斑马纹
• 空状态插画的主色
• 加载骨架屏的灰阶
• 焦点态（focus）的描边样式

这些细节不补，原型就会在"看起来差不多但就是不对"的边缘反复横跳。

3.4 第四步：建立变更流程

Design.md 一旦被多人引用，就不能随便改。我建议定个简单规则：

1. 任何 token 变更走一次简短评审（哪怕只是群里发一句）。
2. 变更必须同时更新所有引用它的原型。
3. 重大变更（如主色调整）要记录在文件顶部的变更日志里。

## 变更日志 - 2024-06-01: 主色由 #2563EB 调整为 #3B82F6，提升可读性 - 2024-05-15: 新增 `--color-bg-subtle` 用于卡片背景

这个日志看着不起眼，但半年后回头看，能快速理解"为什么当时这么定"。

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

4.1 原型和 Design.md 对不上，怎么快速定位

这是最高频的问题。我的排查顺序是：

1. 先看是不是硬编码：搜索原型代码里有没有直接的色值或 px 值，有就替换成变量。
2. 再看变量是否被覆盖：有些组件库会覆盖全局变量，检查作用域。
3. 最后看 Design.md 本身是否过时：如果原型是对的、文件是旧的，那就是文件该更新了。

整理成速查表：

4.2 团队不买账，觉得"多此一举"怎么办

我遇到过这种情况。解决办法不是讲道理，而是用一次实际收益说话。我的做法是：挑一个需要做多端原型（比如 Web 和移动端）的需求，用 Design.md 统一规范后，两端原型一次性对齐，省掉了原本要来回改三轮的沟通。把这次对比摆出来，团队自然就接受了。

关键点是别把 Design.md 当成流程负担，而是当成省事工具。如果它让事情变复杂了，那一定是写法或用法出了问题。

4.3 规范太细导致原型僵化

这是另一个极端。有人把 Design.md 写到连"卡片内文字距顶部 12px"都规定死，结果遇到特殊场景没法变通。

我的经验是分两层：一层是"硬约束"（品牌色、字族、基础间距单位），不可随意改；一层是"软建议"（具体组件的间距组合），允许在合理范围内调整。在文件里明确标注哪些是硬约束，哪些是参考值。

4.4 多产品线如何共用一份 Design.md

如果公司有多条产品线，不要强行用一份文件。我的做法是一份基础规范 + 各产品线覆盖文件。基础规范定义通用 token，产品线文件只写差异部分（比如主色不同）。原型引用时先加载基础再加载覆盖，类似 CSS 的层叠逻辑。

这样既保证了品牌一致性，又给了产品线灵活性。实测下来比"一份大文件管所有"要清爽得多。

5. 让 Design.md 真正落地的几个心得

5.1 从最小可用版本开始，别追求完美

我第一版 Design.md 只写了 30 行，就颜色、字体、间距三块。但它已经能解决 80% 的问题。后面随着原型越做越多，遇到没定义的才补。这种"按需生长"的方式，比一开始憋一份大而全的文档要可持续得多。

5.2 把 Design.md 当成代码来管理

用 git 管理、写变更日志、走评审，这些在代码世界里理所当然的事，搬到设计规范上同样有效。我甚至建议给 Design.md 配一个简单的 lint 脚本，检查有没有重复定义的 token、有没有未使用的变量。工具化程度越高，越不容易腐化。

5.3 定期做"规范体检"

产品迭代几个月后，Design.md 里难免有僵尸 token（定义了但没人用）和缺失 token（用了但没定义）。我习惯每个季度花半小时扫一遍，清理僵尸、补齐缺失。这个习惯让规范始终保持"活"的状态，而不是变成一份没人维护的历史文档。

5.4 一个容易被忽略的细节：给 token 写用途注释

前面示例里我一直在色值后面写用途，比如"主操作、链接、选中态"。这个注释看着多余，但实际价值极高。新人拿到文件，不用猜--color-primary该用在哪；做原型时也能快速判断某个场景该用哪个色。命名解决"叫什么"，注释解决"用在哪"，两者缺一不可。

5.5 关于工具选型的个人建议

如果你团队已经在用某套设计工具，优先用它的变量功能，Design.md 作为文档和版本管理载体。如果团队偏工程化，直接上 CSS 变量 + 一份 Markdown 说明，最轻量。我不建议为了 Design.md 专门引入一套重型设计系统工具，那是本末倒置。规范的价值在于被使用，不在于工具多先进。

最后分享一个我一直在用的小技巧：把 Design.md 里最核心的 10 个 token 做成一张速查卡片，贴在原型项目的 README 顶部。任何人打开项目第一眼就看到核心规范，比藏在文件夹深处的完整文档有效得多。这个动作花不了十分钟，但能显著降低"随手写个近似值"的概率。