当同一个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 Code 是命令行工具，Claude Design 是图形界面工具。一个面向工程师，一个面向设计师。两者本质上是一个东西的两种姿势——就像 git 和 GitHub Desktop。
实验结果告诉我，这个判断错了。一个工具的”GUI 化”不会让产出质量发生质变。如果只是界面包装的差异，同一个模型在两边的产出应该是相似的——可能呈现方式不同，但品质不应该差这么远。
所以差距一定来自别的地方。
我之前判断 AI 产品好坏的逻辑也很简单：模型越强，产出越好。所以选 AI 工具的关键，是选它背后跑的是哪个模型。
但这次实验直接打了我的脸：两个工具用的是同一个模型。如果”模型决定一切”，它们的产出应该几乎一样。可事实是，差距大得像两个不同档次的产品。
那真正的差距，藏在哪里?
我后来去查了 Claude Design 的产品文档，以及一些前 Anthropic 员工在社交平台上的零散透露。把这些信息拼起来，我才意识到一件事：
你以为你给了两个工具一样的输入。其实你给的输入，完全不一样。
当我在 Claude Code 里输入”做一个冥想 App 首页”的时候，这句话基本是以原始形态被送进模型的。Claude Code 会加一些通用的系统提示——告诉模型这是个编程场景、用什么工具——但没有针对”做高质量设计”做特别优化。
而当我在 Claude Design 里输入完全同样的一句话时，在我看不见的产品后台，这句话被悄悄”包装”了。包装的内容大致包括：
我输入的是一句话，系统实际发给模型的，是一份几千字的”设计 brief”。模型还是那个模型，但喂给它的东西，变了一百倍。
这就是差距的真正来源。它不在模型，在”模型之外、用户之内”那一层——一层用户完全看不见、但实际决定产品品质的工程包装。
【一个类比】这就像两个厨师拿到同一份食材。Claude Code 拿到的是食材本身;Claude Design 拿到的是食材 + 一份米其林菜谱 + 一套主厨培训手册 + 一个指定的摆盘餐具。两个厨师的厨艺(模型)一模一样，做出来的菜却完全是两个档次。差距不在厨艺，在”约束体系”。
意识到这件事之后，我有一个朴素的问题：
Claude Design 在背后做的事，我能不能自己复刻一份?
答案是可以——而且做法比想象的简单。
DESIGN.md。它本质上是一份放在项目根目录的 markdown 文件，内容是你产品的”设计宪法”。
它有效的原因很物理：绝大多数 AI 编程工具(Claude Code、Cursor、Windsurf)在执行任务时，会自动读取项目根目录的特定文件作为上下文。把 DESIGN.md 放进去，你之后再让 AI 做任何设计相关的任务，它都会自动遵守你写的规范。
这等于是你手动给”裸 AI 工具”补上了一套类似 Claude Design 的工程包装——虽然达不到那种深度，但根据我的实践，效果能逼近 70%-80%，完全在你自己的控制下。
我自己用的模板，经过几次迭代之后大概长这样：
一份认真打磨的 DESIGN.md，大概 1500-3000 字。前期投入半天到一天，后续每次让 AI 出设计稿、写组件、做原型，都会享受到这份投入的复利。
模板列出来很简单，但真正写起来，有几个非显然的坑。我把自己踩过的几个写在这里，可能对你有用。
坑一：把”设计哲学”写得太抽象
我第一版的”设计哲学”是这么写的：”产品应该简洁、专业、可信。” 听起来很正确，但 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 行业过去几年发生过多次这样的事：
每一次都是同样的故事：今天的”工程护城河”，明天就是”模型自带能力”。
那么 DESIGN.md 这种东西，会不会两年后也变成多此一举?当模型足够强，它是不是不再需要我手把手告诉它”禁止纯黑、禁止饱和色块”?
我没有答案。这件事让我在写这篇文章时反复犹豫——我推荐的方法，会不会很快过时?
但我想了之后，还是决定写下来，有两个原因。
第一，即使两年后模型变强，”把模糊意图结构化为明确约束”这种底层能力也不会过时。DESIGN.md 这个具体形态可能消失，但这种思考方式不会——它本质上和我们写 PRD 是同一种能力。模型再强，也不知道”你的产品该是什么样”，这件事永远需要人来定义。
第二，在”够好”之前，我们还得用今天的方法做今天的产品。等模型变强再开始动手，代价是这两年的所有产品都做得粗糙。
所以我的判断是：不要把工程层当成护城河，但也不要因此放弃工程层。它是当下的杠杆，不是未来的资产。
这篇文章里的每个观察，都来自一个很普通的工作日——我只是做了一个粘贴对比的实验，然后顺着问题往下挖了挖。
我写出来，不是因为我想清楚了，是因为写的过程逼我把零碎的想法做了一次结构化。这种”被迫想清楚”的过程，对我自己的认知更新更有价值。
如果你也是 B 端 PM，或者在做 AI 产品的一线工作，欢迎在评论区告诉我：你有没有做过类似的实验?有没有发现过你以为是模型问题、其实是工程问题的具体案例?这些分享对我个人很有帮助。
本文由 @于小鱼 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。