以个人作品集网站 diw.craft 的完整开发过程为例，分享 UX 设计师如何用 Figma 定义设计、Claude 推演方案、Cursor 落地开发，实现从设计到上线的全流程 AI 协作。
设计师的角色正在发生变化——从“画图”到“定义问题 + 驱动落地”。AI 不会取代设计师，但会用 AI 的设计师会拉开差距。
本文以我的个人作品集网站 diw.craft 的完整开发过程为例，分享三个工具如何串联设计到开发的全流程：Figma 定义视觉方案，Claude 推演技术架构与内容生产，Cursor 将设计变成可运行的代码。
在开始之前，先明确三个工具各自的职责边界：
Figma —— 视觉设计与原型验证。定义“做什么”：布局结构、组件样式、配色字体、间距规范。设计稿是整个项目的视觉基准线。
Claude —— 需求梳理、方案推演与内容生产。思考“怎么做”：技术选型对比、项目架构设计、内容数据模型、文案撰写与优化。Claude 是设计师的思维搭档。
Cursor —— 代码实现与视觉调试。把设计变成产品：组件开发、响应式适配、CSS 微调、实时预览。Cursor 是设计师友好的开发环境。
三者的协作关系是线性且互补的：Figma 输出视觉规范 → Claude 将规范转化为技术方案 → Cursor 将方案落地为代码。每个环节的输出都是下一个环节的输入。
所有工作从 Figma 开始。在 diw.craft 项目中，Figma 负责的不仅仅是“出图”，而是定义整个网站的视觉语言。
首先是布局系统。diw.craft 采用 Bento Grid 布局，我在 Figma 中定义了三种卡片类型：image-only（纯图片展示）、text-only（纯文字内容）、image-text（图文混排）。每种卡片支持 1×1 和 2×1 两种尺寸，组合后能产生丰富的视觉节奏。
其次是 Design Token。配色、字体、间距、圆角等视觉变量在 Figma 中统一定义，确保设计稿和代码使用同一套参数。这些 Token 会在后续的 Cursor 开发中直接映射为 Tailwind CSS 的自定义变量。
最后是组件规范。每个卡片组件的 hover 状态、响应式断点、内容截断规则都在 Figma 中明确标注。这些标注不是给开发者看的“交付物”，而是给 AI 的“需求文档”——当我在 Claude 或 Cursor 中描述组件需求时，这些规范参数是最重要的上下文。
关键经验：设计稿不是终点，而是给 AI 的输入。你在 Figma 中定义得越精确，后续 AI 协作的输出质量越高。
Claude 在这个项目中的角色不是“写代码”，而是“想清楚”。它帮我在动手开发之前，把模糊的设计意图转化为清晰的技术方案。
项目初期最大的疖惑是技术选型。内容管理用 Notion 还是 Obsidian？框架用 Astro 还是 Next.js？我把需求背景和约束条件告诉 Claude，让它帮我做方案对比。
比如 Notion vs Obsidian 的选择，我向 Claude 说明了几个关键约束：需要纯静态部署、内容完全可控、离线可编辑、零 API 依赖。Claude 基于这些约束给出了明确的推荐：Obsidian + Astro + Vercel，并解释了每个选择的权衡。
后来项目演进到使用 Notion 作为 CMS 的方案时，Claude 同样帮我分析了 Notion API 的限制（速率限制、响应速度）以及对应的优化策略（ISR、图片优化、缓存）。
确定技术方向后，我用 Claude 生成了项目的内容数据模型。基于 Figma 中定义的三种卡片类型和四种内容分类（project、writing、photo、experiment），Claude 帮我设计了完整的 Schema：Title、Slug、Category、Tags、Style、Card Size、Cover Image、Sort Order 等字段，每个字段都有明确的用途和约束。
这个数据模型后来直接映射为了 Notion 数据库的属性结构，也成为 Cursor 开发时的数据接口定义。
Claude 在内容层面的价值同样显著。项目描述、SEO Description、文章标题优化这些任务，我都是在 Claude 中完成的。关键是给 Claude 足够的上下文——包括网站的定位、目标受众、内容风格，这样它生成的文案才能与整体调性一致。
关键经验：给 Claude 的 Prompt 越结构化，输出越精准。我总结出一套有效的格式：角色 / 任务 / 背景 / 约束 / 要求，每个字段都尽可能具体。模糊的描述只会得到模糊的结果。
这个选择对设计师来说很关键。Claude Code 是命令行工具，擅长“描述需求 → 完整实现”的场景，但无法实时看到设计效果。而 Cursor 基于 VS Code，支持边写代码边预览，这对需要频繁调整间距、配色、动效的前端项目至关重要。
diw.craft 是一个视觉密集型的前端项目，Bento Grid 的卡片间距、响应式断点、hover 动效都需要反复调试。在 Cursor 中，我可以直接看到修改的效果，这和在 Figma 中调整设计的体验是相似的。
Cursor 中的开发流程通常是这样的：
@file 引用设计需求文档作为上下文npm run dev，在浏览器中实时预览@file:website-design-requirements.md 让 Cursor AI 读取这些上下文。这样生成的代码会更贴合设计意图，减少来回调整的次数。关键经验：渐进式开发效果最好。先让 AI 生成基础版本，确认结构正确后再逐步添加 hover 动画、响应式适配、暗色模式等功能。一次性描述太多需求会降低输出质量。
以 diw.craft 首页的 Bento Grid 布局为例，走一遍完整流程：
第一步：Figma 定义设计
在 Figma 中完成首页布局设计：12 列栅格系统，卡片间距 16px，三种卡片类型的视觉样式，移动端单列布局的断点规则。所有参数标注清楚，确保后续环节有明确的视觉基准。
第二步：Claude 生成技术方案
把 Figma 中的设计规范翻译成结构化文字，交给 Claude。Claude 基于这些规范生成项目结构、组件拆分方案、数据流转设计。例如，它会建议将卡片拆分为 BentoCard（单个卡片组件）和 BentoGrid（布局容器）两个独立组件，并定义各自的 Props 接口。
第三步：Cursor 实现代码
在 Cursor 中引用 Claude 生成的技术方案文档，逐步实现组件。先完成 BentoCard 的基础结构，确认三种卡片类型渲染正确；再完成 BentoGrid 的响应式布局；最后添加 hover 动效和过渡动画。每一步都在浏览器中实时预览，对照 Figma 设计稿进行视觉还原度检查。
第四步：部署上线
Git push 到 GitHub，Vercel 自动触发构建和部署。从提交代码到网站更新通常在 1-2 分钟内完成。
这个流程的效率提升是显著的。传统流程下，设计师完成 Figma 设计后需要写详细的开发文档交给工程师，再经历多轮走查和调整。现在，设计师可以自己完成从设计到上线的全过程，AI 充当了“理解设计意图的工程师”角色。
Claude 无法“看到”设计稿。它不能直接解读 Figma 文件，所以你需要把视觉意图翻译成精确的文字描述。“卡片要好看一点”这种描述几乎无效，而“卡片圆角 12px、内边距 24px、悬停时 Y 轴上移 4px 并添加 0 8px 24px rgba(0,0,0,0.08) 阴影”这样的描述才能产生有效输出。设计师学会“描述设计”比“画设计”更重要。
AI 生成的代码不等于最终产品。它能快速搞定 80% 的工作，但剩下 20% 的视觉还原度微调仍然需要设计师亲自把关。尤其是间距节奏、字体层级、动效缓动曲线这些细节，AI 往往给出“可用”但不够“精致”的方案，需要人工介入。
在传统流程中，Figma 设计稿是给开发者的“交付物”。在 AI 协作流程中，它变成了给 AI 的“输入源”。这意味着你在 Figma 中的标注习惯需要调整——不只是标注给人看，还要能被清晰地“翻译”为文字描述交给 AI。
整个项目下来，最深的体会是：设计师的核心价值不在于“操作工具”，而在于“定义问题和衡量标准”。AI 可以帮你写代码、生成文案、推演方案，但“这个间距应该是 16px 还是 24px”“这个动效是否传达了正确的情绪”这些决策仍然属于设计师。工具变了，判断力没变。
在我写完这篇文章后，Figma 官方发布了一项重要更新：Claude Code to Figma。简单来说，你现在可以把 Claude Code 中构建的可运行 UI 直接推送到 Figma 画布上，变成可编辑的设计稿。这个能力配合此前已有的 Figma MCP Server（从 Figma 设计稿生成代码），形成了一个完整的双向闭环。
这对 UX/UI 设计师的工作流程有几个深远影响：
我在前文描述的工作流是线性的：Figma → Claude → Cursor → 部署。代码完成后，如果需要调整设计，你得回到 Figma 手动修改设计稿，再重新走一遍流程。现在这个环路被打通了：代码中的 UI 可以直接回到 Figma 画布，设计师在画布上调整后，再通过 MCP Server 推回代码。设计和开发之间不再是一次性的交接，而是持续的循环。
Figma 官方博客中提到一个关键观点：AI 正在改变“开始”的含义，几乎立刻就能有一个可交互的原型去回应。这让设计对话从“怎么做出来”变成了“哪个版本值得深入”。对于 UX 设计师而言，这意味着你可以用 Claude Code 快速生成多个可运行的方案，然后抵送到 Figma 画布上并排比较、标注差异、与团队讨论取舍。代码擅长“收敛”——运行一个构建，查看一个状态；画布擅长“发散”——平铺所有可能性，看到分支和方向。两者结合才是完整的设计流程。
以前，设计师想要回应代码中的 UI，得看截图、录屏，或者自己拉代码跑本地服务。现在，开发者用 Claude Code 构建的界面可以直接捕捉到 Figma 文件中，团队成员可以在同一个画布上标注反馈、探索替代方案，而不需要切换环境。这降低了设计师和开发者之间的协作摩擦力。
回到 diw.craft 项目，如果这个能力在项目初期就可用，我的工作流会发生明显变化。比如 Bento Grid 的布局方案，我可以用 Claude Code 快速生成三个不同的布局变体，直接推送到 Figma 画布上并排对比，而不是先在 Figma 中手动设计每一个版本。这不是说 Figma 中的设计工作不重要了，而是它的角色从“生产线的起点”变成了“方案的评审平台”。
这是一个值得所有设计师关注的趋势。工具之间的边界正在模糊，设计和开发不再是两个独立的阶段，而是一个持续循环的过程。能够在这个循环中自由切换的设计师，将拥有更大的影响力。
如果你也是一名设计师，不妨从一个小项目开始尝试这套工作流。不需要等到“完全学会编程”才动手，正是因为有了 AI，设计师可以在“做”的过程中“学”，用每一次实践拓展自己的能力边界。