欢迎来到 Design to Build，一份面向 AI 原生设计师的设计手册。
如果你也在想怎么成为一个 AI 原生设计师，欢迎订阅。
Claude Code 现在可以通过 Figma MCP 直接写入 Figma Canvas。
你可以用自然语言描述界面，它在 Figma 的画布里做出。视觉上可以完全还原，但点进去发现颜色是 #5C6AC4，字体大小是 14，按钮是新建的一次性组件。
设计系统里明明有 color/brand/primary，有 text/body-sm，有现成的 Button Instance，但它一个都没用。
结构上脱节的问题，症结不在 AI 的能力。它知道怎么调用 Figma API，知道怎么查 Library，怎么绑定 Variable。它只是不知道在你的项目里，它「必须」这么做。没有人告诉它规矩，它就按自己的方式来。
AI 工程领域有一个概念叫 Harness。简单说，就是围绕模型搭建的一整套约束框架：告诉它什么能做、什么不能做、做完之后怎么验证。模型本身是引擎，Harness 是让引擎按照你的规则运转的那一切。
对我来说，这个概念翻译成设计语言就是「治理」。
Figma 有自己的治理体系，但是 Claude Code（包括其他 Agent）都是在这套治理体系之外做的设计，本质上是 magic number 的堆砌。每个颜色值都是孤立的，每个组件都是临时的，每次修改都要从头定位。它能通过视觉 QA，但通不过结构 QA。
也就是说，我们要解决的问题其实很明确：
怎么让 Claude Code 在 Figma 里按照 Design System 的治理规则工作，而不是 Freestyle。
基于这个判断，我做了一套 Claude Code Skills，专门用于 Figma 设计场景。四个 Skill，各管一件事。
📎 安装地址：github/senlindesign
01｜Preflight：开工前先做体检
每次设计会话启动时，自动执行三步并行检查：
- Figma MCP 连接是否正常；
- 文件读写权限是否到位；
- 当前文件里的 Styles、Variables 和 Components 是否全部加载。
同时输出一份 Token Map 和 Component Registry，作为整个会话的参照基准。
在 Preflight 通过之前，不允许创建任何节点。这一步的价值很直接：你不会在做了半小时之后才发现 Library 里的 Token 根本没有载入。
02｜Reference Interpreter：先出方案，再动手
当你给 AI 分享截图、参考链接或一段设计描述时，这条 Skill 被触发。它会先把参考信息解析成一份结构化的 Design Brief，列出要构建的 Section、对应的组件、使用的 Token。你确认方向之后，才进入实际构建。
03｜Component Rules：先找，再造
所有 UI 构建任务都受这条规矩约束。逻辑只有一条：先搜索已连接的 Library，找到匹配的组件就用它的 Instance；找不到，才考虑从零构建，且必须遵守 Auto Layout 和语义化命名。
这条 Skill 改变的是 AI 的默认行为。没有它，AI 的本能是「发明」；有了它，AI 的第一反应变成「查找」。对于维护了 Design System 的团队来说，这个顺序的差别就是可用和不可用的差别。
04｜Style Binding：Token 绑定 & QA
每次涉及颜色、字体、间距或圆角的设置，这条规矩自动生效。所有视觉属性必须绑定到对应的 Variable 或 Style，不接受任何裸值。写入 Figma 之后，自动执行一轮 QA 验证，逐项确认绑定状态。
这是四个 Skill 里最核心的一个。它做的事情只有一件：
把 #5C6AC4 变回 color/brand/primary。
这四个 Skills 解决的不只是 Token 绑定的技术问题。它们背后有一个更根本的判断：同一个 AI 工具，在不同的使用场景下，应该扮演不同的角色，产出不同格式的东西。
当设计师需要「in the loop」参与设计时，Claude Code 扮演的是 Design Assistant 的角色。它的产出必须可以被接手、被修改、被迭代，这意味着从 Token 到组件到布局结构，每一层都要合规。四个 Skills 在这个场景下全部生效，形成完整的治理链路。
当目的是快速出一个 Prototype 验证想法时，它切换成 Coding Assistant 的角色。这时候规范让位于速度，Harness 退到后台，硬编码完全可以接受。
AI 已经足够强大，它能写 Figma，也能写 React。但工具强大和工具好用之间，隔的往往就是一份没人写的规矩。
