OpenDesign 指南：如何用 Claude Code 做前端设计——从审美方向提示到可拥有的设计系统

Claude Code 做前端设计，"开箱即用"的结果往往是千篇一律的默认值；把 frontend-design 插件装上、改用审美方向而非像素值来提示、一次只调一个设计维度，并规划好 3–5 轮迭代，就能拿到真正有品味的界面。本篇基于 OpenDesign 仓库，完整还原这套工作流的每个实操步骤，并用仓库中的技能文件（SKILL.md）、设计系统目录（design-systems/）与 daemon 提示词组合源码，说明"设计系统变成 agent 可读文件"在工程上到底是怎么实现的。

为什么"开箱即用"的结果总是平庸

直接让 Claude Code"做个落地页"，你通常会拿到和所有人一样的结果：保险的字体、默认的蓝色、毫无主张。这不是模型能力的天花板，而是提示词和配置的问题。配上合适的插件、养成几个习惯，Claude Code 做出来的前端设计就能真正有辨识度。这篇文章是实操版：怎么配置、怎么提示，以及如何把产出从一个好看的单屏，升级成一套你能真正交付并拥有的设计系统。

先划清边界：OpenDesign 团队就在"设计到代码"这条链路上做产品，本文会明确区分官方插件管到哪里、agent 原生的设计系统层从哪接上。但指南的绝大部分内容，纯粹是关于如何把 Claude Code 的前端设计能力榨干。

第一步：安装 frontend-design 插件

Anthropic 为 Claude Code 提供了官方的 frontend-design 插件（随 Claude Code 官方插件仓库发布），它是对设计质量提升最大的一招。在 Claude Code 里安装：

1. 输入 /plugin。
2. 选择 Add Marketplace，输入 anthropics/claude-code。
3. 找到 frontend-design 并安装。

装好之后，只要你让 Claude 构建界面，这个 skill 就会自动激活。它的作用是推开默认值：在写任何代码之前，先确立一套设计框架——目的、受众、一个明确的审美方向——这样你拿到的是有辨识度的排版、刻意的配色和经过推敲的动效，而不是模板化的产出。

这个 skill 具体在做什么：以 frontend-design 技能 为例

OpenDesign 仓库内置了一份从 Anthropic 官方 frontend-design skill 适配而来的实现（见 skills/frontend-design/SKILL.md），它的 frontmatter 和工作流正好把上面那句话落实成了可检查的步骤：

• 技能声明 od.craft.requires: [typography, color, anti-ai-slop] 与 od.design_system.requires: true——也就是说，这个技能明确要求配套排版、色彩与"反 AI 味"工艺规则，以及一套激活的设计系统；
• 工作流共 6 步：先理解 brief（受众、核心任务、领域、情绪基调、技术约束），再承诺一个具体的审美方向（brutally minimal、editorial、retro-futuristic、calm enterprise……），然后设计真实界面而非占位海报（空态/加载/错误态、表格、筛选、导航、响应式），再构建生产级代码（语义化标记、键盘可达、焦点态、CSS 变量），最后精修工艺并做交付前自检；
• 其中第 2 步明确列出要规避的 AI 默认套路：紫蓝渐变、模糊玻璃卡片、 interchangeable 的 SaaS 布局、过度圆角卡片、库存图标排、不服务于界面的装饰 blob。

这解释了"为什么装了插件就不平庸"：skill 把工作流的顺序改写成了"先定方向、后写代码"，而把"避免默认套路"从建议变成了清单。

第二步：用审美方向提示，而不是像素值

最大的错误就是过度指定。别把一堆边距和十六进制色值的规格丢给 Claude；给它一个方向，让它在这个框架内自己做选择。告诉它该考虑什么：

• 目的与受众——"一个面向开发者工具的落地页，要有精准、迅捷的感觉"，而不是"做个落地页"。
• 调性——冷静、编辑感，或大胆、高对比，又或者复古终端风。
• 字体类别——"正文用人文主义无衬线，标题用有辨识度的展示字体"，胜过点名某一款具体字体。
• 色彩族系——"暖中性色配一抹荧光强调色"给它留了余地；"#63fe13 的按钮"则没有。
• 动效理念——"克制、退场迅速"对比"俏皮、有弹性"。

审美方向就是把 vibe design 的思路用在 Claude Code 上：你描述感觉和约束，由 agent 来填补手艺。

这个原则在 OpenDesign 的仓库里有直接的工程印证。craft/anti-ai-slop.md 把"AI 默认值"列成了七条"原罪"，其中前几条就是审美方向要替代的对象：

1. 默认 Tailwind 靛蓝当强调色（#6366f1、#4f46e5、#8b5cf6 等一组 hex）——文档原话："Indigo is the textbook AI tell"，激活的 DESIGN.md 提供了 --accent，应该用它；
2. Hero 上的双色"信任感"渐变（紫→蓝、蓝→青、靛→粉）；
3. 用 emoji 当功能图标（✨🚀🎯⚡🔥💡）；
4. 标题用无衬线而种子绑定的是衬线；
5. 圆角卡片 + 彩色左边框——典型的"AI 仪表盘图块"形状；
6. 编造指标（"10× faster"、"99.9% uptime"）；
7. 填充文案（lorem ipsum、feature one/two/three）。

这些规则中的一部分由 daemon 的 lint-artifact 检查器在 P0 级别自动拦截（见 craft/anti-ai-slop.md 开头说明）——"接受第一套配色/字体"之所以是常见错误，不只是品味问题，在 OpenDesign 里它是一条会被机器判负的回归。

第三步：一次只引导一个设计维度

当第一版已经接近但还显得平庸时，别推倒重来——把 Claude 的注意力一次集中到一个维度上。下面每一项都是你可以独立拉动的杠杆：

维度	弱提示	强提示
排版	"字体好看点"	"字号对比更强——超大号展示标题、小型大写字母的标签"
色彩	"换个颜色"	"降到接近单色的基底，只留一个高饱和强调色"
动效	"加点动画"	"入场淡入约 200ms，退场干脆约 140ms，不要回弹"
背景	"别那么素"	"淡淡的点阵网格纹理，不要渐变"
参照	"做得现代点"	"往 Linear／IDE 深色主题那种审美靠"

点名一个参照（某个 IDE 主题、某个品牌、某种文化审美）是把 Claude 从默认值里拽出来最快的办法——它给了模型一个具体的目标，而不是一个平均值。

两个细节值得注意：

• 动效数字不是随口说的。 表格里"入场约 200ms、退场约 140ms"与仓库的设计系统规范完全一致：docs/design-systems.md 第 7 节给出的 UI 动效约定正是 --motion-enter: 200ms; --motion-exit: 140ms，配强 ease-out 曲线 cubic-bezier(0.23, 1, 0.32, 1)，并明确"UI 元素不要用 ease-in、不要从 scale(0) 开始"。这与 craft/animation-discipline.md 的时长阈值（200–300ms 用于进入的 UI、非导航微交互应低于 500ms）互为印证。也就是说，"给方向 + 给区间数字"的提示方式，恰好落在业界收敛的数值带上。
• 参照审美可以直接指向目录里的现成设计系统。 说"往 Linear 深色主题靠"，在 OpenDesign 里对应的就是一个真实包：design-systems/linear-app/，内含 DESIGN.md、tokens.css、components.html 等完整文件。整个目录目前有 151 个这样的包（见 design-systems/README.md），每个包都是一份"agent 能直接读取的审美参照"。

第四步：分层下达需求，并为多轮迭代做规划

把第一版当成地基，而不是成品功能。两个会越用越省力的习惯：

• 分层构建： 先类型（types），再逻辑（logic），然后 UI，最后测试（tests）。一条提示词里要求所有东西只会得到一团乱麻；分层能让每一遍都可审查。
• 规划 3–5 轮迭代。 第一屏确立方向；第 2 到第 5 遍才是品味出现的地方。每一轮都对照你的审美方向来评审，而不是逐像素地抠。

如果你的原型需要真正能跑起来，而不只是看着对，那就是 vibe design 与 vibe coding 的分界线——Claude Code 在两边都强，因为设计从一开始就是代码。

第五步：从一次性单屏到一套可拥有的设计系统

到这里，官方插件的职责就结束了，更难的问题才刚开始。frontend-design 插件能让单个屏幕看起来很棒。但一个产品是四十个必须保持连贯的屏幕，是一套要在各个功能间存活下去的设计系统，是你要维护一年的代码。逐屏独立提示，你得到的是四十个有品味却互不一致的页面，以及一套只活在你提示历史里的设计系统。

解法是把设计系统变成 Claude Code 能读取的东西，而不是每次提示都重新描述一遍。这正是 OpenDesign 在 Claude Code 之上补的东西：每套设计系统都成为一个 DESIGN.md，每项可复用能力都成为一个 SKILL.md——都是你的 agent 会加载的纯文件，于是"做设置页"会继承和其他一切相同的字号梯度、色彩系统与组件，产出也就从提示词走到你拥有的、可交付的代码。*诚实地划清边界：*对于单个页面或一个快速原型，光用插件就完全够了——当一个真实产品的跨页面一致性、以及对这些文件的所有权开始变得重要时，再上设计系统这一层。这也是它分别契合设计师与工程团队的方式。

这些文件在 OpenDesign 里是怎么起作用的

仓库源码可以把上述说法落成一条可核对的链路：

1. 设计系统是一个包，不是单个 Markdown 文件。 每个包的最低机器可读形态是三个文件（见 design-systems/README.md 与 docs/design-systems.md）：

design-systems/<slug>/
├── manifest.json  ← 发现元数据与声明的包文件
├── DESIGN.md      ← 给 agent 读的设计正文
└── tokens.css     ← 编译后的语义化 CSS 自定义属性

manifest.json 拥有稳定的发现元数据与来源信息；DESIGN.md 是"规范性的设计正文"；tokens.css 是"规范性的编译后 token 样式表"。富包还可以声明 USAGE.md（给 agent 的阅读顺序指引）、components.html（组件 fixture）、design-tokens.json、tailwind-v4.css 等派生文件——派生文件是缓存而非竞争性事实来源。

2. DESIGN.md 不写像素规格，写意图。 docs/design-systems.md 第 3 节明确：DESIGN.md 向 agent 解释意图、决策与用法，"它不是固定九节的编号 schema"；质量守卫只要求迁移包至少 7 个有实质内容的 H2 小节，常用覆盖包括视觉主题与氛围、色彩角色与对比意图、字体族/字阶/行高/字距、间距与布局、组件与交互状态、动效行为与 reduced-motion 处理、可达性预期、具体反模式。正文与编译值必须保持同步——"如果 DESIGN.md 命名了一个强调色、字阶、间距节奏或动效时长，tokens.css 里对应的绑定必须表达同一个决策"。

3. daemon 在每次构建时把这些文件组合进 agent 提示词。 从 apps/daemon/src/prompts/system.ts 的 ComposeInput 结构看，提示词由这些层按固定顺序拼出：技能正文（skillBody）、激活设计系统的正文（designSystemBody）、逐字注入的 tokens.css :root 契约（designSystemTokensCss）、USAGE.md 路由（designSystemUsageMd）、组件清单摘要（designSystemComponentsManifest），以及通过技能 frontmatter od.craft.requires 解析出的工艺规则（craftBody）。源码注释说明了顺序的意图：craft 规则被放在 DESIGN.md 之后、技能正文之前注入，"品牌 token 在冲突时胜出，但工艺规则（字距、强调色使用上限、anti-slop）覆盖其后的一切"。

4. token 契约不是建议，是绑定。 组提示词时，daemon 对 agent 的指令是（见 apps/daemon/src/prompts/system.ts）："把未加作用域的 :root { ... } 块逐字粘贴进产物的第一个 <style>，让每个 var(--*) 引用在运行时都能解析。不要发明新 token，不要重定义这些值，不要在这个 :root 块之外写原始 hex。DESIGN.md 是正文；这是绑定契约。" 这正是"审美方向提示 + 机器可执行 token"的分工：方向决定选哪个包、包内的 prose 决定气质、tokens.css 保证四十个屏幕共用同一套变量。

5. 一致性有机器兜底。 仓库用 pnpm guard（入口见 scripts/guard.ts）校验 manifest 声明路径、token 契约、组件 fixture 与预览覆盖等；lint-artifact 则对产物执行 craft/anti-ai-slop.md 里的 P0 规则。设计系统不再只存在于提示历史里，而是存在于可版本化、可校验的文件里——这就是"拥有"这两个字的工程含义。

常见错误

• 过度指定像素。 你会把模型压扁成一个渲染器。给方向，让它来选。
• 一条超级提示词包办一切。 改成分层：类型 → 逻辑 → UI → 测试。
• 指望一次就完美。 预留 3–5 轮迭代；对照 vibe 评审，而不是像素。
• 多屏工作没有设计系统。 逐屏提示会漂移；把系统放进 agent 能读取的文件里。
• 接受第一套配色/字体。 默认值就是平均值；点名一个参照来逃离它们。

常见问题

Claude Code 真能做出好的前端设计吗？ 能，配上 frontend-design 插件和以方向为主导的提示方式。没有它们你拿到的是平庸的默认值；有了它们你拿到的是有辨识度、有意图的 UI。

怎么安装 Claude Code 的 frontend-design 插件？ 在 Claude Code 里输入 /plugin → Add Marketplace → anthropics/claude-code → 安装 frontend-design。之后只要你请求构建界面，它就会自动激活。

该怎么给 Claude Code 写设计提示？ 用审美方向（目的、调性、字体类别、色彩族系、动效理念）和参照，而不是像素值——然后迭代 3–5 次，一次引导一个维度。

怎么让设计在很多屏幕之间保持一致？ 把设计系统从提示词里挪出来，放进 agent 能读取的文件里。像 OpenDesign 这样的 agent 原生层会把每套设计系统变成 Claude Code 每次构建都加载的 DESIGN.md（外加逐字注入的 tokens.css 契约）。想了解它在更大格局里的位置，可以看看 最佳 AI 设计工具 指南。

Claude Code 比专门的 AI 设计工具更好吗？ 形态不同：Claude Code 以代码方式做设计，所以没有从设计稿到代码的交接环节——权衡之处见 设计到代码工具 的对比。

要点回顾

Claude Code 的前端设计水平，取决于你的配置和提示：安装 frontend-design 插件，用审美方向而非像素来提示，一次引导一个设计维度，并做好迭代的打算。这能让你得到真正出色的单屏。而要让整个产品保持连贯、并真正拥有成果，就把设计系统放进你的 agent 能读取的文件里——这正是 OpenDesign 押注的方向：你的 agent，你的、以 DESIGN.md 形式存在的设计系统，从提示词直达可交付。

• 技能与工作流：skills/frontend-design/SKILL.md
• 设计系统目录与作者指南：design-systems/README.md、docs/design-systems.md
• 反 AI 味规则与动效纪律：craft/anti-ai-slop.md、craft/animation-discipline.md
• 提示词组合实现：apps/daemon/src/prompts/system.ts