返回整理

产品设计说明 / 2026-09-14

DESIGN.md

把产品的设计规则写进项目，让团队和编码助手在做新页面时有据可依。

面向创业团队以 Google Stitch 的视觉设计用法为主

核心用途

DESIGN.md 保存颜色、字体、间距等设计值，也解释它们应该用在哪里。创业团队可以用它减少重复说明和界面返工。它的作用取决于规则是否明确、是否被读取，以及是否与实际代码保持一致。

文件里写什么

在 Google Stitch 的用法里，DESIGN.md 是描述产品视觉系统的纯文本文件。正文用 Markdown 写设计原则，可选的 YAML 文件头保存能被程序读取的精确数值。[1]

设计值与使用规则
内容写法示例解决的疑问
精确值主色 #28634C
组件圆角 4px		具体用什么值？
使用规则主色用于主要操作按钮；正文维持高对比度。用在哪里，为什么？

表中的颜色和尺寸是本页教学示例，不是 Google 的默认值。

同名文件还有另一种用途。Kiro 的 design.md 记录技术架构、组件交互和实现方案。判断含义要看文件内容和所在工具；文件名大小写不足以区分。[2]

规则如何变成界面

假设你在做一个阅读产品。文章列表和阅读页共用一组规则：主要操作用同一种颜色，组件使用相同的圆角与间距。

修改下面的规则，观察两个示例页面和文件内容一起变化。

当前规则：苔绿主色，4px 圆角，16px 间距。

页面示例：阅读库

稍后阅读

让笔记更容易找回来产品思考
给文章留出呼吸的空间设计随笔
保存文章
页面示例：阅读页

让笔记更容易找回来

打开收藏的文章，接着读上次停下来的段落。工具收在正文旁边，让内容保持清楚。

读完后，把有用的想法记下来。

添加笔记
DESIGN.md教学节选，可选 YAML + Markdown 正文
---
name: Reading Demo
colors:
  primary: "#28634C"
rounded:
  sm: 4px
spacing:
  md: 16px
---

## Overview
阅读内容优先，工具保持简洁。

## Colors
主色用于主要操作按钮。

## Layout
内容内边距和相邻内容间距使用 spacing.md。

## Shapes
容器和按钮使用 rounded.sm。

示例由本页脚本直接同步数值，用来解释规则与界面的关系。实际开发仍需编码助手读取文件并修改代码；保存一个 Markdown 文件不会自动改变产品。本例不是完整的生产设计规范。

  1. 1记录已认可的设计保存具体值及其使用理由。
  2. 2让贡献者读取规则编码助手与开发者使用同一份依据。
  3. 3检查实际页面确认规则被落实，新的决定写回文件。

创业团队能用它解决什么

对需要持续增加页面的小团队，直接收益是少重复解释已有决定，并减少由规则不清造成的返工。下面是使用建议，效果需要在自己的产品中验证。

常见问题与文件能承担的工作
团队遇到的问题写进文件的内容怎样判断有用
每个新页面都像另一个产品字体、颜色角色、间距、通用组件规则新页面是否复用了已有样式
创始人反复提同样的修改意见“主按钮只能有一个”等已认可的决定及适用范围同类修改意见是否减少
设计理由只在某个人脑子里为什么这样排版，什么情况下允许例外新同事能否解释并沿用这些决定
换一次工具就重新解释风格随项目保存的文字说明和精确值换工具后是否仍能读到同一份规则
评审只剩“好不好看”可核对的组件状态和移动端行为评审能否指出具体哪条规则未满足

产品需求、任务流程和用户是否能顺利完成操作，仍要另外验证。文件也会保留不合理的设计，所以实际页面的检查不能省。

它与其他文件的分工

可以按下面的方式组织项目。这里的分工是一种团队约定，各工具对文件名的识别方式不同。

项目文件的建议分工
文件或资产主要回答示例
需求文档 / PRD为谁做，要完成什么任务？用户可以保存文章，并继续上次的阅读。
DESIGN.md界面按什么规则呈现？阅读区宽度、正文样式、工具位置。
AGENTS.md 等项目指令编码助手怎么参与这个项目？修改界面前读取设计规则，复用现有组件。
架构文档系统内部如何实现？文章存储、同步机制、接口与错误处理。
组件库 / CSS 变量运行时实际使用什么实现？按钮组件、主题变量、响应式布局。

如果组件库已经保存了精确设计值，文档应引用它，或从同一来源生成。两份独立手写的数值会增加同步工作。

怎样开始用

从团队已经认可的页面开始，把反复用到的决定写下来。

  1. 选一个已认可的页面

    查看现有代码和组件，提取实际使用的规则。标明哪些已经确定，哪些还没有定义。

  2. 写清数值、用途和状态

    覆盖颜色角色、排版、间距与常用组件。补充移动端、加载、空白、错误等会影响使用的状态。

  3. 明确要求读取

    在项目指令中写明：“修改界面前读取 DESIGN.md，优先复用现有组件。”有文件不等于每个工具都会自动读取。

  4. 确定谁负责更新

    指定维护人。调整组件或设计规则时，在同一次修改中更新相关代码、文档和变更记录。

  5. 用新页面检验规则

    检查桌面和手机上的实际效果，把仍然需要口头解释的重复决定补进文件。

Google Labs 的工具支持格式检查、版本比较和设计值导出。格式检查可以辅助发现结构、引用和部分对比度问题；界面的实际行为仍需检查。[3]

npx @google/design.md lint DESIGN.md

方法与来源

根据本次对话中于 2026 年 9 月 14 日查阅的公开文档整理。Google 于 2026 年 4 月 21 日宣布开放草案；查阅时规范版本标为 alpha。[4]

用途解释来自格式规范与工具文档。创业团队的做法、文件分工和互动示例属于本页分析；没有测量节省时间或业务增长。品牌案例网站提供第三方分析，不能当作品牌官方规范。

  1. Google Labs / DESIGN.md 格式规范

    了解文件结构、可选 YAML、设计值与正文规则。适合作为格式起点。

  2. Kiro / Feature Specs

    核对技术设计文档的另一种用法：架构、时序和实现考虑。

  3. Google Labs / DESIGN.md 项目与工具

    查看示例、lint 格式检查、diff 版本比较，以及设计值导出说明。

  4. Google / Stitch 的 DESIGN.md 草案发布说明

    发布于 2026 年 4 月 21 日，介绍跨项目和跨工具传递设计规则的用途。

  5. Google Labs / Stitch Design Skills

    参考从现有代码提取设计规则、导入设计系统和生成页面的工作方法。