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

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

【免费下载链接】open-design🎨 Best DeepSeek Harness Design Plugin. The open-source Claude Design alternative. 🖥️ Local-first desktop app. 🖼️ Your coding agent becomes the design engine: prototypes, landing pages, dashboards, slides, images & video — real files, HTML/PDF/PPTX/MP4 export. 🤖 Claude Code / Codex / Cursor / DeepSeek Harness / OpenCode & 20+ CLIs via BYOK.项目地址: https://gitcode.com/gh_mirrors/opend/open-design

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-designskill 适配而来的实现（见 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 的注意力一次集中到一个维度上。下面每一项都是你可以独立拉动的杠杆：

点名一个参照（某个 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），以及通过技能 frontmatterod.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

【免费下载链接】open-design🎨 Best DeepSeek Harness Design Plugin. The open-source Claude Design alternative. 🖥️ Local-first desktop app. 🖼️ Your coding agent becomes the design engine: prototypes, landing pages, dashboards, slides, images & video — real files, HTML/PDF/PPTX/MP4 export. 🤖 Claude Code / Codex / Cursor / DeepSeek Harness / OpenCode & 20+ CLIs via BYOK.项目地址: https://gitcode.com/gh_mirrors/opend/open-design