企业官网建设流程全解析

1. 从“能跑就行”到“好看能用”：一个前端开发者的觉醒

我干了快十年的前端，说实话，早期很长一段时间，我的审美和设计能力，基本停留在“能用就行”的阶段。接到一个需求，脑子里想的全是：这个功能用哪个组件库实现最快？这个交互逻辑怎么写最省事？至于颜色搭配、间距控制、字体选择，基本就是“凭感觉”或者“抄竞品”。做出来的页面，功能是齐了，但总感觉哪里不对劲，要么是颜色刺眼，要么是布局混乱，要么是交互生硬。每次把设计稿交给UI设计师评审，对方总能挑出一堆“视觉问题”和“体验细节”，而我只能尴尬地点头，心里却不太明白：这个按钮从#1890ff蓝色换成#1d39c4深蓝色，真的有这么大区别吗？行高从1.5调到1.6，用户真的能感觉到吗？

这种状态持续了很久，直到我开始独立负责一些从零到一的项目，或者参与一些对视觉和用户体验要求极高的产品（比如面向C端的工具类应用、品牌官网）。没有专业UI设计师全程跟进的窘境，逼着我必须自己去思考“好看”和“好用”背后的逻辑。我开始疯狂地看设计网站、读设计规范、研究Material Design和Apple Human Interface Guidelines。但问题又来了：这些知识太碎片化了。今天看到一篇文章讲配色，明天看到一个视频讲栅格系统，学的时候觉得有道理，但一到实际项目中，面对空白的画布，又不知道从何下手。如何把这些零散的设计原则，系统地应用到一个具体的网站项目中？

这个困扰我许久的问题，最近被一个看似简单的文件解决了——DESIGN.md。它不是什么新框架，也不是某个AI设计工具，它就是一个放在你项目根目录下的Markdown文档。但正是这个文档，彻底改变了我（以及我团队）协作和开发网站的方式。它让“写出高颜值的网站”从一个依赖个人天赋和经验的玄学，变成了一套可执行、可迭代、可协作的工程化流程。简单来说，DESIGN.md就是你项目的“设计宪法”，它提前定义了所有关于“美”和“体验”的规则，让开发者在写第一行代码之前，就知道最终的产品应该长什么样，以及为什么长这样。

2. DESIGN.md 究竟是什么？它如何终结“像素级还原”的扯皮

如果你经历过前端和UI的经典扯皮场景，你一定对下面这些话不陌生：

• 前端：“这个间距是多少？设计稿上没标。”
• UI：“就按8的倍数来，视觉上对齐就行。”
• 前端：“这个‘警告’状态的色值是多少？设计稿上只有成功和错误的。”
• UI：“你找个看着像警告的橙色用一下。”
• 前端：“这个卡片在移动端怎么排列？设计稿只做了桌面版。”
• UI：“你看着适配吧，保持美观。”

DESIGN.md就是为了从根本上消灭这种低效沟通而生的。它不是设计稿（Sketch、Figma文件），而是设计稿的“元数据”和“使用说明书”。我们可以把它理解为一个项目的设计系统雏形或设计决策记录文档。

一个完整的DESIGN.md通常包含以下几个核心部分，它把抽象的设计原则，转化为了前端开发中具体、可量化的约束：

2.1 设计令牌：将视觉变量转化为代码常量

这是DESIGN.md最核心、最工程化的部分。它直接定义了项目中所有可复用的视觉属性。

## 设计令牌 ### 颜色 - `--color-primary`: #1a73e8 (主要按钮、重要链接) - `--color-primary-hover`: #0d62d9 (主色悬停) - `--color-success`: #00c853 (成功状态) - `--color-warning`: #ff9800 (警告状态) - `--color-error`: #f44336 (错误状态) - `--color-text-primary`: #202124 (主要文字) - `--color-text-secondary`: #5f6368 (次要文字) - `--color-background`: #ffffff (背景色) - `--color-border`: #dadce0 (边框色) ### 间距与尺寸 - 基础单位: `8px` - 间距尺度: `4px`, `8px`, `16px`, `24px`, `32px`, `48px`, `64px` (所有间距必须使用此尺度) - 容器最大宽度: `1200px` - 边框圆角: `4px` (小), `8px` (中), `16px` (大) ### 字体与排版 - 主字体: `-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif` - 代码字体: `'SF Mono', Monaco, 'Courier New', monospace` - 字体尺度: - `--text-xs`: 12px / 1.4 (辅助信息) - `--text-sm`: 14px / 1.5 (正文小) - `--text-base`: 16px / 1.6 (正文) - `--text-lg`: 18px / 1.6 (小标题) - `--text-xl`: 24px / 1.3 (标题)

为什么这如此重要？在没有DESIGN.md的时代，颜色值可能散落在几十个CSS文件里，一个“主蓝色”可能有#1a73e8、#1967D2、#4285F4等好几种变体。有了设计令牌，所有颜色、间距、字体都成了唯一的“常量”。前端在开发时，不再需要询问或猜测，直接引用这些CSS自定义属性即可。这保证了视觉的绝对统一，也为后续的主题切换、暗黑模式打下了坚实基础。

2.2 组件规范：约定大于配置

这一部分描述了常见UI组件的具体样式和行为，是设计令牌的具体应用。

## 组件规范 ### 按钮 - **主按钮**: 背景色 `--color-primary`， 文字白色，内边距 `12px 24px`，圆角 `--radius-md`。 - **悬停效果**: 背景色变为 `--color-primary-hover`， 添加 `translateY(-1px)` 的轻微上移和阴影。 - **禁用状态**: 透明度 `0.6`， 鼠标指针为 `not-allowed`。 - **大小变体**: 大(`padding: 16px 32px`)， 中(默认)， 小(`padding: 8px 16px`)。 ### 卡片 - **默认样式**: 背景白色， 边框 `1px solid var(--color-border)`， 圆角 `--radius-lg`， 内边距 `--spacing-24`。 - **阴影**: 默认无阴影， 需要悬浮效果的卡片使用 `box-shadow: 0 2px 8px rgba(0,0,0,0.1)`。

这部分内容极大地减少了开发者的决策负担。当需要一个新的按钮时，不需要重新设计，只需要决定用“主按钮”还是“次按钮”，用“大号”还是“小号”。一致性自然就达成了。

2.3 布局与栅格：构建页面的骨架

定义页面整体的布局逻辑，响应式适配的规则。

## 布局系统 ### 栅格 - 采用12列弹性栅格系统。 - 栅格间隙(Gutter): `--spacing-24`。 - 容器: 最大宽度 `--container-max-width`， 左右自动边距。 ### 响应式断点 - `sm`: ≥640px (移动端) - `md`: ≥768px (平板) - `lg`: ≥1024px (桌面) - `xl`: ≥1280px (大桌面) ### 页面模板示例 - **详情页**: 左侧内容区(8列)， 右侧侧边栏(4列)。 - **列表页**: 卡片网格， 在 `lg` 断点下为3列， `md` 下为2列， `sm` 下为1列。

有了这个，前端在搭建页面结构时，就像有了施工图纸。他知道这个页面在大屏上是几栏布局，到小屏上应该如何折叠，不再需要为每个页面单独思考响应式策略。

3. 当DESIGN.md遇见AI：开发流程的“降维打击”

有了详尽的DESIGN.md， 我们相当于把“设计意图”彻底机器可读了。这时，再结合当前强大的AI编程工具（如Cursor、Claude Code），整个前端开发体验会发生质变。你不再只是一个写代码的人，而是成为一个“设计系统的执行官”和“AI编程的指挥官”。

3.1 场景一：用自然语言描述，直接生成符合规范的代码

这是最直接的提升。假设你要开发一个用户个人中心的卡片，在以前，你需要：

1. 看设计稿，测量间距、颜色。
2. 在CSS文件里写样式，可能还要去查颜色变量名。
3. 编写HTML结构。
4. 反复调整直到视觉上接近设计稿。

现在，如果你的DESIGN.md足够完善，你可以在Cursor（已内置Claude Code等模型）中直接输入：

“创建一个用户信息卡片，包含头像（圆形，直径64px）、用户名（使用--text-xl）、职位描述（使用--text-secondary颜色），以及一个‘编辑资料’的次要按钮。所有间距遵循8px倍数原则，整体样式符合我们卡片组件的规范。”

AI（如Claude Code）在理解了你的DESIGN.md后，能够直接生成如下高度可用的代码：

<!-- AI生成示例 --> <div class="user-profile-card"> <div class="card-header"> <img src="avatar.jpg" alt="用户头像" class="avatar" /> <div class="user-info"> <h2 class="user-name">张三</h2> <p class="user-title">高级前端工程师</p> </div> </div> <p class="user-bio">专注于构建美观且高性能的Web应用。</p> <button class="btn btn-secondary">编辑资料</button> </div>

/* AI生成示例 - 自动引用了DESIGN.md中的变量 */ .user-profile-card { background-color: var(--color-background); border: 1px solid var(--color-border); border-radius: var(--radius-lg); padding: var(--spacing-24); max-width: 400px; } .avatar { width: 64px; height: 64px; border-radius: 50%; object-fit: cover; } .user-name { font-size: var(--text-xl); color: var(--color-text-primary); margin-bottom: var(--spacing-8); } .user-title { font-size: var(--text-sm); color: var(--color-text-secondary); } .btn-secondary { /* AI会从DESIGN.md中知道次要按钮的具体样式 */ margin-top: var(--spacing-16); }

关键点在于：AI生成的代码，其视觉样式是直接锚定在DESIGN.md所定义的“唯一真理源”上的。这避免了AI“自由发挥”导致风格不一致的问题。你不再需要花时间调整像素，只需要关注业务逻辑是否正确。

3.2 场景二：重构与样式审查的自动化助手

当项目进行到中期，代码量变大后，经常会出现一些“样式债”：比如某个地方为了赶工期，直接写了color: #999;， 而没有使用--color-text-secondary。手动检查这些不一致性如同大海捞针。

现在，你可以直接让AI（通过Cursor的Chat功能）来帮你做这件事：

“检查当前src/components/目录下所有.vue文件中的样式，找出所有直接使用十六进制颜色值（如#fff）或固定像素单位（如margin: 10px）的地方，并建议如何替换为DESIGN.md中定义的设计令牌。”

AI可以快速扫描代码，给出类似这样的报告：

• UserCard.vue第45行：color: #5f6368;建议改为color: var(--color-text-secondary);
• Dashboard.vue第12行：margin-bottom: 20px;建议改为margin-bottom: var(--spacing-24);（因为20不是8的倍数）

这相当于拥有一个24小时在线的、精通你项目设计规范的代码审查员。

3.3 场景三：快速生成设计系统的代码骨架

当你DESIGN.md中的设计令牌非常完善时，你甚至可以要求AI直接为你生成配套的、可落地的代码文件。例如：

“根据DESIGN.md中的‘设计令牌’章节，为我生成一个完整的CSS文件，将所有令牌定义为CSS自定义属性（CSS Variables），并包含一个基础的排版工具类（如.text-primary,.mt-16）。”

AI生成的成果可能是一个可以直接引入的tokens.css文件，这为你快速搭建一个原型或启动一个新项目节省了大量初始化时间。

注意：AI不是魔法，DESIGN.md是它的“知识库”。AI生成代码的质量，与DESIGN.md的详细和准确程度成正比。一个模糊的DESIGN.md只会让AI生成模糊的代码。你必须先投入精力把“宪法”制定好。

4. 如何从零开始，为你的项目创建一份高效的DESIGN.md

创建一份好的DESIGN.md并非一蹴而就，它是一个迭代和积累的过程。你可以遵循以下步骤：

4.1 阶段一：初创与收集期（项目启动时）

这个阶段的目标是快速建立一个最小可行版本，让团队有章可循。

1. 确立核心设计决策：和产品、设计负责人（如果有）一起，确定1-2个主品牌色、1套主要字体、1个基础间距单位（强烈推荐8px）。把这些写入DESIGN.md。
2. 定义最常用的组件：先定义按钮、输入框、卡片、警告框这4-5个最高频的组件。描述清楚它们的基础状态（默认、悬浮、点击、禁用）。
3. 创建文件并共享：在项目根目录创建DESIGN.md， 将上述内容用Markdown格式写好。在团队README或开发规范中明确指出，所有UI开发必须参考此文档。

4.2 阶段二：发展与细化期（开发过程中）

这个阶段随着具体页面的开发同步进行，不断丰富文档。

1. 遇到即补充：当开发一个新模块（比如数据表格、步骤条、模态框）时，如果DESIGN.md里没有规范，不要随意实现。先和团队（哪怕是只有开发者）讨论出一个规范，更新到DESIGN.md中，然后再基于此规范进行开发。
2. 抽象共性问题：当发现多个地方用了相似的样式（比如不同的“成功”提示），将其抽象为一条设计令牌（如--color-success）和一个可复用的组件（如Toast组件）。
3. 记录决策原因：在DESIGN.md中，不仅写“是什么”，还可以简单写“为什么”。例如：“主按钮圆角采用4px， 因为调研发现此圆角在直角和圆角之间取得最佳平衡，既现代又不失稳重。” 这有助于新成员理解设计逻辑。

4.3 阶段三：工具化与自动化（效率提升）

当DESIGN.md足够成熟后，可以借助工具将其价值最大化。

1. 与CSS-in-JS或CSS预处理器结合：你可以写一个简单的脚本，将DESIGN.md中的令牌（如颜色、间距）自动生成对应的JavaScript对象或SCSS变量文件，实现“一处定义，处处使用”。
2. 创建可视化故事书：如果使用像Storybook这样的工具，你可以将DESIGN.md中的组件规范，直接转化为一个个可交互、可视化的Story，成为活生生的组件文档。
3. 集成到CI/CD：可以设置一个简单的检查，在代码提交时，用脚本扫描CSS文件，看是否有直接使用未在DESIGN.md中定义的色值或间距，从而保证规范的执行。

5. 避坑指南：让DESIGN.md真正发挥作用，而非沦为摆设

在我推动团队使用DESIGN.md的过程中，踩过不少坑。总结下来，要让这份文档活起来，关键不在于文档本身有多华丽，而在于流程和习惯。

坑一：文档与实现脱节，成了“僵尸文档”。这是最常见的问题。DESIGN.md更新了，但代码库里的老组件没有同步更新；或者代码里出现了新的样式模式，却没有被记录到文档中。

• 解决方案：建立“文档驱动开发”的轻量流程。在开发新功能或修改现有样式时，第一步不是直接写代码，而是先查看/更新DESIGN.md。将更新DESIGN.md作为代码审查（Code Review）的一项必检内容。可以约定，任何直接使用硬编码样式（如color: red）而不引用设计令牌的代码，都不予通过。

坑二：设计令牌过于抽象或过于具体，难以使用。如果把所有可能的阴影值都定义成令牌（如--shadow-1到--shadow-10）， 开发者会记不住。如果只定义几个，又可能不够用。

• 解决方案：遵循“实用主义”原则。只定义那些高频复用和具有语义意义的令牌。例如，定义--shadow-card（卡片阴影）和--shadow-dropdown（下拉框阴影）就比定义--shadow-light和--shadow-heavy更实用。同时，允许在特殊情况下“按需扩展”，但扩展后需要评估该值是否具有普遍性，从而决定是否要反向补充到DESIGN.md中。

坑三：在缺乏专业设计的团队中，由谁来制定初始规范？很多中小团队或后台项目组并没有专职UI设计师。这时，DESIGN.md的初始版本由谁来写？

• 解决方案：由团队中最具产品感和审美意识的前端或全栈开发者牵头。不要从零开始创造，而是“站在巨人的肩膀上”。直接借鉴成熟开源设计系统（如Ant Design、Material Design、Tailwind CSS的默认主题）的配色、间距、字体尺度。这些系统经过大量产品验证，审美在线且具备良好的可用性。你的DESIGN.md初期完全可以声明：“本项目视觉风格主要参考Ant Design 5.0，并在此基础上进行如下定制...”。这是一个快速启动且不犯大错的策略。

坑四：过度依赖AI，丧失设计把控力。AI能根据DESIGN.md生成代码，但它无法理解更深层次的品牌调性、用户情感和交互微细节。比如，一个“成功”的提示，用绿色圆角Toast和用绿色横幅通知，带来的感受是不同的。

• 解决方案：将AI定位为“高级执行助手”，而非“设计决策者”。DESIGN.md应该由人（尤其是对产品体验负责的人）来主导制定和迭代。AI的任务是严格遵循这份人类制定的规范，提高产出效率。对于复杂的交互逻辑、动画曲线、微交互细节，仍然需要开发者基于对产品的理解进行精细打磨。AI生成的是“骨架”和“血肉”，而产品的“灵魂”和“气质”需要人来注入。

从我个人的实践来看，引入DESIGN.md最大的收益不是节省了多少写样式的时间，而是统一了团队的认知频道。产品、设计和开发在讨论一个功能时，可以基于同一套明确的、书面的规范进行，减少了大量的模糊地带和沟通成本。当每一个按钮、每一处间距、每一种颜色都有了“名字”和“出处”时，项目的视觉质量就从一种偶然，变成了一种必然。再结合AI编程工具的能力，你确实可以更自信地说：我们也能写出高颜值的网站了。这背后不是魔法，而是将设计思维工程化、将开发流程规范化的必然结果。