[🤖] 成品设计总在变化：我为什么需要 DESIGN.md

✨ GPT-5.6 Sol 摘要

宣传册每次做出来都不一样，所以我开始寻找 DESIGN.md。其实，我很早就在其他个人项目中感受到设计一致性的必要，也用自己的方式实践过。这篇文章记录了我如何把那些分散的标准连接成 AI 可以持续读取的格式。

每做一次宣传册，设计就变一次

长假结束后，我继续在现在的公司做宣传册。在管理协调者和 Worker 时，连宣传册都没能按时完成之后，我精简了工作方式，但设计仍让我放心不下。即使在同一份 PPT 里，每一页的氛围也会摇摆；每做一个新版本，设计就像重新生成了一次。

其他项目也没有太大不同。我让 AI 搜索设计参考和优秀样例，或者亲自把参考发给它，试图做出统一感。有时我甚至期待随机抽卡也能抽出一个好结果。最后得到的，却只有毫无统一感、AI 味扑面而来的 D 级抽卡结果。

我想要的并不是每次生成一张看起来还行的画面。我希望同样的颜色、文字层级、留白和组件感觉，能延续到下一页和下一个版本。可是宣传册没有这样的标准。AI 每次收到参考资料，都要从头重新猜测氛围。

这并不是我第一次发现这个问题

回头看，我并不是这次才第一次感到设计一致性的必要。早在 2025 年 7 月，我就留下过一篇思考如何为氛围编程建立设计系统的记录。当时我已经在设想这样的流程：用 Figma AI 做设计，把画面和代码保存为参考，整理字体系统与配色，再与实际成品进行比较。

在 Tadak Bible 中，我也没有只停留在思考。自 2026 年 1 月起，我开始把颜色、字体系统和主题集中到一个地方，并记录了粉彩蓝与薰衣草色、平静温暖的氛围、圣经打字页面的可读性等方向。之后我建立了 BibleColors、BibleTypography，以及间距、圆角、图标和动效 token，并把它们应用到多个页面。我还加上检查，防止新页面再次随意创造颜色和字号。

也就是说，我早就知道为什么需要设计系统。在 Tadak Bible 里，我已经沿着用代码和文档绑定产品色彩、字体和通用组件的方向走了很远。

问题在于，这段经验没有延续到其他项目和成品中。Tadak Bible 的标准分散在它自己的文档、Flutter 代码和检查里。新 Web 项目或 PPT 中的 AI 无法立即读取一个通用格式，再延续同样的设计感觉。每开始一个项目，我又要重新找参考、重新丢样例、重新等一个好结果。

我想用 DESIGN.md 连接分散的标准

后来，我发现了把韩国服务设计系统整理成 LLM 上下文的 ko/design.md 目录¹，以及 Google Labs Code 的 DESIGN.md 仓库。²

看到名称和示例，我大概明白了它是什么文件。它似乎把颜色、字体、间距、组件和整体氛围写在一个地方，让 AI 每次做设计时都能参考。我想到，也许可以把自己已经在 Tadak Bible 中建立的设计标准，转成 Agent 能持续读取的形式，并用同样的方法管理其他项目。

问题是，我在这里也用一个大概就带过了。我让 AI 调查 DESIGN.md 是什么，参考样例做一个类似的文件。之后我就想着，它应该已经查够了，也应该已经应用好了。我没有亲自确认官方文档所说的范围，也没有检查生成的文件是否遵守了这个范围，更没有一直验证到实际成品真的出现设计一致性。

AI 读了链接并做出一个看起来像样的文件，与我真正拥有了想要的设计标准，完全是两回事。没有确认这个差异，是我的错。

我差点把整个产品规划都塞进 DESIGN.md

在没有正确理解 DESIGN.md 范围的情况下，我打算从下一个产品规划开始，把不同用户的页面和流程、状态、权限、恢复机制全都整理到 DESIGN.md 里。Codex 也照着我的说法继续扩大范围，开始建立按角色划分的 DESIGN.md 和单独规则。

我觉得有些不对。它似乎没有真正处理好 UI，于是我再次要求它先检查我最强调的 Google Labs Code 示例。

读过原文后，边界清楚得多。Google Labs Code 的 DESIGN.md，是持续向编码 Agent 传达产品视觉身份的格式。YAML 可以保存准确的设计 token，Markdown 正文则说明为什么使用这些颜色、字体和形状，以及整体设计应该如何呈现、让人感受并产生行为。³

这里的产生行为，并不意味着吞下整个产品规划。用户角色、旅程、权限、异常、恢复、页面结构与验证，仍然应该在原有产品文档中详细处理。我一开始想建立的按角色细节并不是该丢掉的内容，只是应该整理在普通的 docs/ 中，而不应该叫 DESIGN.md。

遵循格式和照抄设计不是一回事

纠正边界后，我还需要确认另一件事。以 Google Labs Code 为标准，并不意味着把仓库里的示例设计原样复制到所有项目中。

Google 提供的是 DESIGN.md 的格式和解释方式，而不是设计内容。示例中的颜色、字体和氛围，只属于那些示例的视觉身份。真正项目的 DESIGN.md，应该放入从该产品的用户、环境、品牌和我选择的参考中形成的视觉标准。ko/design.md 目录同样只是参考与比较的材料；随便复制一种设计，并不会自动变成我们产品的身份。

因此，我重新修改了通用规则和产品规划 Skill。只有当视觉身份确实属于范围时才建立一个 DESIGN.md，而角色、旅程、权限、恢复和详细页面设计继续留在普通产品文档中。我删除了最初擅自创建的按角色 DESIGN.md 方向，最终模板也通过了 Google 的官方检查。

这一次，我为了减少设计抽卡而找到 DESIGN.md，却连 DESIGN.md 的含义也交给了 AI 抽卡。把链接交出去，说一句 “调查后应用”，然后只因为文件出现了就相信结果，AI 就会用自己的方式填满所有我没有确认的空白。

一个 DESIGN.md 不会自动带来好设计。尤其是 PPT，还需要真正制作幻灯片母版和版式样例，并检查渲染结果是否遵守这些标准。但是，如果把我为每个产品接受的视觉标准作为正本留在 DESIGN.md 中，至少可以减少 AI 每次都从空白画面重新抽取氛围的情况。

我很早就明白设计一致性的必要，也已经在 Tadak Bible 中建立设计系统。直到这次，我才找到一种 Agent 可以读取的格式，让那段经验延续到其他项目和成品，并终于把它与 DESIGN.md 这个名字连接起来。

参考资料

1. ko/design.md，韩国服务设计系统目录。它以 LLM 上下文的形式提供韩国服务的标志性设计。 ↩

2. Google Labs Code，DESIGN.md。它介绍了一种供编码 Agent 持续参考的视觉身份格式。 ↩

3. Google Labs Code，DESIGN.md specification。它定义了 YAML 设计 token 与 Markdown 设计依据的结构、标准章节和检查规则。 ↩