第一次用 Claude Design：先搭设计系统，再改前端

为什么很多人第一次用效果不好

很多人第一次用 Claude Design，会直接输入一句：“帮我把这个页面做得好看一点。”它通常能给你一张看起来更完整的页面，但你把结果放回真实项目，很快会发现问题：按钮不符合原站，信息顺序变了，移动端塞不下，代码实现也不知道该照哪一部分。

更具体的原因是：你没有告诉它设计系统、已有页面、业务限制、用户路径和不可改事实。它只能按自己的默认经验补齐，结果可能漂亮，但不一定能用。

我现在更愿意把 Claude Design 当成一个设计协作环境。它要先吃项目材料，生成可以继续讨论的设计源，再导出文件，把改版交给代码代理接住。

第一次打开 Claude Design，我会先按下面这条路走。不要急着要最终稿，先让它理解项目，再让设计一步一步变清楚。

Claude Design 要按一条流程用

第一次上手很容易被功能名带走：Design System、UI Kit、Markup、Edit、Tweaks、wireframe、git diff、MVP。单独看每个词都懂，真正难的是把它们排成一条能落地的流程。

第一步，先把项目知识交给 Claude Design。代码库、已有页面、品牌素材、核心组件、截图、业务边界，都属于输入。你不给它这些，它只能按通用审美猜。

第二步，先让它做结构，不要先做视觉。wireframe 的价值是把“用户先看什么、再点哪里、在哪一步会卡住”画出来。结构错了，高保真越漂亮，返工越痛苦。

第三步，在画布上协作。大方向用聊天，局部细节用 Markup、Edit、评论。不要把所有反馈都塞进一个长会话。

第四步，把设计结果交给代码。Claude Design 导出的 HTML、CSS、React、data 这类文本文件要进项目，用 git diff 看变化，再让 Codex 或 Claude Code 改真实前端。

第五步，保持设计源和代码同步。代码里临时改了页面，设计源也要回填。否则下一次改版时，设计稿和代码会从两个版本开始说话。

先建设计系统，先把边界说清楚

我会把 Design System 放在最前面。这个点很容易被低估。很多人以为设计系统是大公司才需要的东西，自己只是改个页面，不用搞这么正式。

在 Claude Design 这里，设计系统首先是给 AI 画边界。它要知道按钮长什么样，卡片怎么分组，正文多大，移动端怎么折叠，哪些颜色能用，哪些内容不能改。

Claude Design 能从代码库、品牌指南、幻灯片、设计文件、截图和文档里提取颜色、字体、组件和布局模式。第一次用不需要准备得像大公司那么完整，但至少要给它一个“最小输入包”。

这里可以先让代码代理读一遍你的项目，生成一份“设计需求文档”。这份文档不需要写得很文学，只要能告诉 Claude Design：当前页面有哪些模块，用户路径是什么，哪些组件已经存在，哪些约束不能动。然后你把这份文档连同截图一起喂给 Claude Design。

先做 wireframe，再做高保真

如果你还没想清楚页面结构，不要先让 Claude Design 做高保真。高保真会把问题盖住。字变好看、卡片变精致以后，你更容易误以为结构已经对了。

正确顺序是：先让它输出 wireframe，只看信息架构和用户路径。比如一个内容站或工具站，首页负责什么，栏目页负责什么，详情页负责什么，提交弹窗负责什么。每个页面先做好自己的事，再谈视觉。

我的做法是先写粗需求，不追求一开始就写完美 PRD。先把想到的内容列出来，再让 Claude Design 根据这份需求出 wireframe；我看着线框图调整信息顺序；最后再把确认后的 wireframe 和原始想法整理成正式 PRD。

这个过程看起来比“直接出页面”慢，但它能帮你提前发现很多问题：用户是否需要先理解分类，是否需要先看案例，是否应该先放风险说明，按钮是否太早出现，移动端首屏有没有塞太多东西。

结构大改用聊天，局部细节用 Markup / Edit / 评论

第一次用 Claude Design，很多人会把所有反馈都写进聊天里。这样可以，但效率不高。大方向可以聊天：比如“把首页从工具入口改成文章优先”，或者“把详情页里的说明拆成两段”。

局部细节要点元素。按钮太靠下、卡片间距太大、输入框状态不清楚、移动端某段文字太挤，这些问题用 Markup、Edit 或评论更直接。

可以粗暴地分成三类：

• 聊天：改页面职责、整体布局、导航结构、多页面关系。
• Markup / 评论：框选一块区域，告诉它这块为什么不清楚。
• Edit / Tweaks：调元素、间距、颜色、状态、加载样式、移动端折叠。

还有一个容易忽略的点：管理上下文。不要在同一个长会话里从首页聊到详情页，再聊到弹窗，再聊到移动端所有状态。新页面、新阶段、新目标，最好开新会话，或者至少把当前阶段说清楚。

设计也要抽样。LLM 有随机性，不要因为第一版看起来完整就直接接受。你可以让它出 2 到 3 个方向，然后用固定标准评估：信息是否更清楚，用户路径是否更短，移动端是否不拥挤，按钮是否像可以点击。

不要说“感觉不对”

“感觉不对”对 Claude Design 没什么帮助。你要把反馈落到可执行的位置。

• 把主按钮放到关键说明下面，用户看完就能点击。
• 移动端首屏只保留标题、核心说明和一个主按钮，不要塞四张卡片。
• 把这组说明拆成“自助内容”和“需要人工确认”两组。
• 表单字段间距可以小一点，但按钮高度保持 42px 以上。

设计稿导出后，要进项目、进 git diff

Claude Design 改完设计后，别只把截图丢给 Codex 让它猜。下载设计文件，放进项目里的 design 目录，用 git diff 看设计稿到底改了哪里。

这一步会让后面的实现简单很多。你给 Codex 或 Claude Code 的指令不用写很长，因为设计变化已经在文件里了。它可以读目录、看 diff，再改真实前端代码。

实现完成后，还要回到浏览器看截图。桌面首屏、正文中段、移动端首屏、移动端关键区域都要看。只要有图片和长代码块，移动端尤其容易出问题。

设计源和代码要同步

很多团队会在这里分叉：设计稿确认后，开发临时在代码里改了按钮、文案和布局，但没有回填到设计源。下一次改版时，Claude Design 看到的是旧设计，代码里跑的是新页面，两边开始互相打架。

所以这套流程有一个笨办法：重要页面的设计导出要留在项目里。代码里改了影响视觉和结构的东西，就同步回设计源，或者至少写进项目规则。这样下一次你再让 Claude Design 继续改，它不会从旧版本开始猜。

你也可以像写 `CLAUDE.md` 一样，把长期规则写下来。比如：不要改导航命名；不要把两个不同栏目混在一起；所有按钮都必须有 hover 和移动端状态；文章页图片要能点击放大；正文最大宽度不要超过当前博客习惯。它们不一定都要写进 Claude Design，但至少要成为你每次改版的检查规则。

我会怎么跑一轮真实改版

如果我自己要用 Claude Design 改一个已有网站，我不会从“帮我美化”开始。我会这样跑：

给 Claude Design 的 3 个提示词模板

模板不是咒语。你要把真实截图、组件、限制和目标补进去。下面这几段适合直接改成自己的版本。

请先不要改设计。

我会上传现有页面截图、品牌素材和核心组件截图。请先帮我整理当前项目的轻量 Design System：
1. 颜色和使用场景
2. 字体层级
3. 按钮和链接样式
4. 卡片、表单、弹窗、导航的规律
5. 移动端折叠规则
6. 目前页面里最容易让用户误解的地方

请先复述你的理解，等我确认后再进入 wireframe。

你是产品设计师。请先基于我上传的品牌素材、已有页面截图和组件截图，整理一个轻量 Design System，包括颜色、字体层级、按钮、卡片、表单、导航和移动端规则。

我要设计一个新页面：{页面名称}。
目标用户：{用户是谁}。
用户进入页面后要完成：{核心动作}。
必须展示的信息：{列出内容}。
不能改的事实：{栏目边界、交付方式、风控说明、产品边界}。

请先给我 wireframe，不要先做高保真。
wireframe 要说明：首屏放什么，用户下一步点哪里，移动端怎么折叠。
确认 wireframe 后，再基于 Design System 做高保真版本。

这是现有页面的桌面和移动端截图，请先不要美化。

请先做页面诊断：
1. 用户可能在哪里看不懂。
2. 哪些信息重复或放错位置。
3. 哪些按钮不像可点击操作。
4. 移动端首屏是否能看懂页面目标。

改版目标：{写清楚目标，比如减少用户走错路径、突出下一步入口、让自助内容和人工服务分开}。
保留内容：{不能删的文案和事实}。
不可改动：{产品名、导航入口、交付说明、关键流程}。

先输出改版 wireframe。结构确认后，再做一版高保真。
请沿用当前站点风格，不要换成另一个品牌。

请把这些页面当成一个完整用户路径来设计，不要单页分别美化：
1. 首页：{截图或说明}
2. 栏目页：{截图或说明}
3. 详情页：{截图或说明}
4. 提交或咨询弹窗：{截图或说明}

用户路径：
进入首页 -> 理解内容分类 -> 选择合适入口 -> 打开详情 -> 知道下一步怎么做。

请先输出信息架构图和每个页面的职责。
每页只回答它该回答的问题。
不要让同一段解释在多个页面重复出现。
不要让用户在自助内容和需要人工确认的服务之间混淆。

先输出 wireframe，确认后再做高保真，并保持同一套按钮、卡片、间距和移动端折叠规则。

请参考 design 目录里 Claude Design 导出的最新文件，用 git diff 对比设计变化，然后把真实前端页面同步成同样的结构和视觉。

要求：
1. 不要改无关业务逻辑。
2. 保持当前项目已有组件和路由习惯。
3. 如果设计稿和真实代码冲突，先说明冲突，再选择最小改动。
4. 完成后跑本地预览，截图桌面首屏、正文中段、移动端首屏和关键交互区域。

常见错误清单

最后的建议

第一次用 Claude Design，不要追求一轮出最终成品。你先让它理解项目，再让它画清楚结构，接着做高保真和原型，最后把导出文件交给代码代理。

AI 设计工具应该把我的判断变成可讨论、可点击、可导出、可追踪的设计源。方向、品味和产品判断，仍然要由人来负责。

如果你只是想做一张漂亮图，Claude Design 很容易让你有短期满足感。如果你想把一个真实网站改好，就按完整流程来：设计系统、wireframe、画布协作、导出、git diff、代码实现、本地验收。慢半拍，但少很多回头路。