当同一个AI模型在Claude Design和Claude Code中产生截然不同的输出质量时，我们发现了AI产品的隐藏真相。这篇文章通过一场简单实验，揭示了决定AI工具品质的关键不在模型本身，而在于背后的工程包装体系。作者不仅拆解了Claude Design的系统级指令秘密，更提供了一份可立即复用的DESIGN.md模板，帮助产品经理将粗糙的AI输出提升至专业水准。

这篇文章记录我作为一个 B 端 PM，用一个最简单的对比，意外发现的关于 AI 产品的认知，以及一份可复用的实战方法。

一、一个最简单的对比实验

我最近做的事情很简单：把同一段需求描述，分别粘贴给 Claude Design 和 Claude Code，让它们各自输出一个产品界面。描述词一字不差。

需求是这样的：”做一个冥想 App 的首页，色调柔和，自然感，字体偏圆润，有呼吸感。”

Claude Design 给我的：一个完整的设计稿。有清晰的层级、合理的留白、统一的圆角和字号阶梯，色调真的偏 morandi。底部 tab、卡片阴影、按钮 hover 态全都有，品质感像是真出自一个有经验的 UI 设计师。

Claude Code 给我的：一个能跑的 HTML 页面。但视觉是粗糙的——颜色像随手取的，字号忽大忽小，卡片之间的间距没有节奏，按钮直接是浏览器默认样式。功能上勉强算”实现了”，品质上像没修过的草稿。

这件事本身不奇怪。奇怪的是：

这两个工具的底层，是同一个模型——Claude Opus 4.7。

我盯着这两个截然不同的产出看了很久，意识到我可能对”AI 工具”这件事有根本性的误解。

二、我之前的两个误判

误判一：以为 Claude Design 是 Claude Code 的”GUI 版本”

我之前的认知很简单：Claude Code 是命令行工具，Claude Design 是图形界面工具。一个面向工程师，一个面向设计师。两者本质上是一个东西的两种姿势——就像 git 和 GitHub Desktop。

实验结果告诉我，这个判断错了。一个工具的”GUI 化”不会让产出质量发生质变。如果只是界面包装的差异，同一个模型在两边的产出应该是相似的——可能呈现方式不同，但品质不应该差这么远。

所以差距一定来自别的地方。

误判二：以为 AI 工具的差距主要来自模型

我之前判断 AI 产品好坏的逻辑也很简单：模型越强，产出越好。所以选 AI 工具的关键，是选它背后跑的是哪个模型。

但这次实验直接打了我的脸：两个工具用的是同一个模型。如果”模型决定一切”，它们的产出应该几乎一样。可事实是，差距大得像两个不同档次的产品。

那真正的差距，藏在哪里?

三、真正的差距，在你看不见的地方

我后来去查了 Claude Design 的产品文档，以及一些前 Anthropic 员工在社交平台上的零散透露。把这些信息拼起来，我才意识到一件事：

你以为你给了两个工具一样的输入。其实你给的输入，完全不一样。

当我在 Claude Code 里输入”做一个冥想 App 首页”的时候，这句话基本是以原始形态被送进模型的。Claude Code 会加一些通用的系统提示——告诉模型这是个编程场景、用什么工具——但没有针对”做高质量设计”做特别优化。

而当我在 Claude Design 里输入完全同样的一句话时，在我看不见的产品后台，这句话被悄悄”包装”了。包装的内容大致包括：

• 一个上千字的系统级指令，告诉模型“你是顶级 UI 设计师，你的作品要有 Linear、Stripe、Things 这种级别的品质感”
• 一套强制工作流：必须先输出设计系统(颜色、字号、间距、圆角)，再生成具体页面
• 一份反模式禁令清单：不要用纯黑、不要用饱和色块、不要用 12px 以下的字号
• 一组高质量设计案例作为参考样例，引导模型向那个方向靠
• 预置的设计系统组件(Tailwind + shadcn/ui)，模型不用从零写按钮
• 可能的自我反思机制：生成初稿后让模型再过一遍，不达标就改

我输入的是一句话，系统实际发给模型的，是一份几千字的”设计 brief”。模型还是那个模型，但喂给它的东西，变了一百倍。

这就是差距的真正来源。它不在模型，在”模型之外、用户之内”那一层——一层用户完全看不见、但实际决定产品品质的工程包装。

【一个类比】这就像两个厨师拿到同一份食材。Claude Code 拿到的是食材本身;Claude Design 拿到的是食材 + 一份米其林菜谱 + 一套主厨培训手册 + 一个指定的摆盘餐具。两个厨师的厨艺(模型)一模一样，做出来的菜却完全是两个档次。差距不在厨艺，在”约束体系”。

四、那作为一个普通 PM，我能用上这件事吗?

意识到这件事之后，我有一个朴素的问题：

Claude Design 在背后做的事，我能不能自己复刻一份?

答案是可以——而且做法比想象的简单。

DESIGN.md。它本质上是一份放在项目根目录的 markdown 文件，内容是你产品的”设计宪法”。

它有效的原因很物理：绝大多数 AI 编程工具(Claude Code、Cursor、Windsurf)在执行任务时，会自动读取项目根目录的特定文件作为上下文。把 DESIGN.md 放进去，你之后再让 AI 做任何设计相关的任务，它都会自动遵守你写的规范。

这等于是你手动给”裸 AI 工具”补上了一套类似 Claude Design 的工程包装——虽然达不到那种深度，但根据我的实践，效果能逼近 70%-80%，完全在你自己的控制下。

4.1 一份基础的 DESIGN.md 结构

我自己用的模板，经过几次迭代之后大概长这样：

1. 产品定位：目标用户、使用场景、情绪基调
2. 设计语言参考：对标哪些产品的品质，以及“不要像哪些”
3. 设计 Token：主色、字号阶梯、间距网格、圆角、阴影
4. 组件规范：按钮、输入框、卡片的尺寸、状态、行为细节
5. 布局规则：容器宽度、栅格、区块间距、响应式断点
6. 交互细节：过渡时长、loading 形态、错误提示
7. 禁止事项：明确写出哪些做法不允许
8. 代码约定：CSS 框架、组件库、Token 引用方式

一份认真打磨的 DESIGN.md，大概 1500-3000 字。前期投入半天到一天，后续每次让 AI 出设计稿、写组件、做原型，都会享受到这份投入的复利。

4.2 我自己写 DESIGN.md 时踩过的几个坑

模板列出来很简单，但真正写起来，有几个非显然的坑。我把自己踩过的几个写在这里，可能对你有用。

坑一：把”设计哲学”写得太抽象

我第一版的”设计哲学”是这么写的：”产品应该简洁、专业、可信。” 听起来很正确，但 AI 完全用不上——”简洁”是个相对概念，它不知道你说的简洁是 Linear 那种留白还是 Stripe 那种密度。

后来我改成了具体规则：”信息密度优先于留白”，”禁止超过三种字号”，”禁止使用阴影做层级区分，只用边框和背景色”。这些规则 AI 能直接执行，效果立刻变好。

教训：抽象原则对人有用，对 AI 没用。给 AI 写的规则必须是可执行、可验证的。

坑二：正面描述远不如反面禁令有效

“使用克制的配色”这种正面描述，AI 会以各种方式理解——它可能给你一个全灰的页面，也可能给你一个莫兰迪色系的页面，反正都算克制。

换成”禁止使用饱和度高于 60% 的颜色，禁止纯黑 #000，禁止使用渐变背景”，AI 的行为就稳定了。

这件事其实反直觉。我们写 PRD 习惯说”应该怎么样”，但给 AI 写约束，”不应该怎么样”反而更管用。原因是禁令是布尔判断，AI 能精确遵守;正面描述是程度判断，AI 会自己解读。

坑三：不写”代码约定”，AI 会自己造一套

我第一版没写代码约定那部分，结果 AI 自己造了一套——它用了 inline style 写颜色，字号直接写数字不引用 Token，组件结构每次都不一样。文件能跑，但完全没法维护。

加上”必须用 Tailwind 配置好的 Token、不要写 inline style、组件结构遵循 shadcn/ui 范式”之后，AI 产出的代码立刻变得可读、可维护、可复用。

教训：DESIGN.md 不只是”设计规范”，它本质是”AI 协作规范”。涉及到代码组织、命名、复用方式，都要写清楚。

坑四：把所有规则塞在一份文件里

我一度想写一份”什么都涵盖”的超级 DESIGN.md，结果发现 AI 会忽略很多内容——文件越长，关键信息越容易被淹没。Stanford 那篇”Lost in the Middle”研究讲的就是这个现象：文档中间的信息最容易被忽略。

后来我把规则按”对当前任务的相关性”做了拆分：核心约束放在 DESIGN.md(让 AI 一定读到)，具体组件规范放在单独的 COMPONENTS.md(需要时再让 AI 读)，项目背景放 README.md。每个文件控制在 1500-2500 字，效果反而好得多。

【给读者的建议】DESIGN.md 不是越长越好。它的核心价值是”明确、可执行的约束”，不是”详尽的说明”。一份 8000 字的、含糊不清的 DESIGN.md，效果远远不如一份 2000 字的、规则锐利的 DESIGN.md。这跟我们写 PRD 是一样的道理。

五、一个抛砖引玉的问题

讲到这里，有一件事我想坦白说一下，因为这是我自己也没想清楚的部分。

我前面讲的”工程包装”——system prompt、上下文构造、反思链、强制工作流——这些东西在当前的 AI 产品里非常值钱，因为模型本身还做不到自动处理这些。

但 AI 行业过去几年发生过多次这样的事：

• 早期 NLP 的特征工程，被深度学习吃掉了
• 早期 prompt 工程的 few-shot 模板，被 GPT-4 之后的强推理能力吃掉了
• 精细的 RAG chunking 和 rerank 策略，正在被长上下文模型吃掉

每一次都是同样的故事：今天的”工程护城河”，明天就是”模型自带能力”。

那么 DESIGN.md 这种东西，会不会两年后也变成多此一举?当模型足够强，它是不是不再需要我手把手告诉它”禁止纯黑、禁止饱和色块”?

我没有答案。这件事让我在写这篇文章时反复犹豫——我推荐的方法，会不会很快过时?

但我想了之后，还是决定写下来，有两个原因。

第一，即使两年后模型变强，”把模糊意图结构化为明确约束”这种底层能力也不会过时。DESIGN.md 这个具体形态可能消失，但这种思考方式不会——它本质上和我们写 PRD 是同一种能力。模型再强，也不知道”你的产品该是什么样”，这件事永远需要人来定义。

第二，在”够好”之前，我们还得用今天的方法做今天的产品。等模型变强再开始动手，代价是这两年的所有产品都做得粗糙。

所以我的判断是：不要把工程层当成护城河，但也不要因此放弃工程层。它是当下的杠杆，不是未来的资产。

六、写在最后

这篇文章里的每个观察，都来自一个很普通的工作日——我只是做了一个粘贴对比的实验，然后顺着问题往下挖了挖。

我写出来，不是因为我想清楚了，是因为写的过程逼我把零碎的想法做了一次结构化。这种”被迫想清楚”的过程，对我自己的认知更新更有价值。

如果你也是 B 端 PM，或者在做 AI 产品的一线工作，欢迎在评论区告诉我：你有没有做过类似的实验?有没有发现过你以为是模型问题、其实是工程问题的具体案例?这些分享对我个人很有帮助。