Figma 设计稿真正有价值的部分，不只是颜色和间距，还包括组件关系、变量、状态和响应式约束。Figma Design to Code Skill 的作用，是把这些上下文带进实现过程，再把实现结果放回真实浏览器检查。
先看结论：它解决的是映射和验收
不要把它理解成“上传一张图，自动得到生产代码”。更稳妥的路径是：读取目标节点和变量，检查项目现有组件，先约定允许修改的目录，再实现一个最小页面或组件，最后用同一视口截图对照。这样才能知道差异来自设计理解、项目约束还是素材缺失。
开始前先确认连接、节点和代码边界
准备 Figma 文件链接或节点 ID、目标项目根目录、当前技术栈和页面入口。连接完成后先做只读检查，列出可以访问的页面、组件、变量和图片资源，不要一开始就要求写回 Figma 或批量改动项目。
同时写清三类范围：允许修改的组件和样式文件、禁止触碰的公共导航和业务逻辑、完成后必须运行的 lint、测试和浏览器命令。设计稿没有提供的信息，例如真实接口字段或权限策略，不能由 Skill 猜出来。
按这个顺序完成一次实现
第一步：读取节点结构而不是只看截图
让 Skill 输出页面层级、组件名称、布局方向、间距、颜色变量、字体和交互状态。若同一元素在多个断点使用不同约束，要把变化单独记下来。
第二步：盘点项目中可以复用的组件
查找现有按钮、表单、卡片、布局容器和设计令牌。优先复用项目已有实现；只有当节点表达了项目中不存在的新行为时，才增加组件。这样能避免设计稿局部细节破坏现有系统。
第三步：实现一个可观察的小范围
先做一个页面区块或一条完整交互路径，接入真实文本和代表性数据。把节点到代码的对应关系写进任务记录，包含断点、资源路径和未决问题，不要用大量占位块掩盖遗漏。
第四步：用浏览器和截图完成验收
至少检查桌面和移动视口、键盘焦点、加载和错误状态、真实内容长度以及控制台错误。截图用于定位视觉差异，不能替代功能测试和无障碍检查。差异修复后再保存最终截图和命令结果。
一个可复核的任务示例
可以把下面的任务发给 Codex：先读取 Figma 文件链接 + 节点 ID，只读列出节点层级、变量、组件和缺失素材；再检查项目中的布局和按钮组件，只允许修改 src/pages/Profile 及其测试；实现桌面和移动布局；最后运行项目测试并用浏览器分别截图 1440px 与 390px，列出设计差异和未确认项。没有得到确认前，不写回 Figma，不修改公共导航。
这份任务至少应留下三种证据：Figma 节点与变量清单、代码 Diff、同一视口的设计稿与浏览器截图。发现差异时，标明它是字体替换、布局约束、素材缺失还是实现错误。只有这样，下一轮修改才有明确目标，不会凭感觉不断调整像素。
若项目已经有按钮的禁用、加载和错误样式，还要在实现中复用这些状态；设计稿只给了默认状态时，不能删掉产品中真实存在的交互。真正缺少状态设计时，先沿用项目规范并在验收记录中标出，而不是给所有按钮添加同一套临时视觉。
最容易误判的地方
- 只按截图重写，忽略组件状态和真实数据长度。
- 直接新建一套颜色和按钮，造成项目设计令牌重复。
- 把 Figma 权限当成项目写权限，未区分两套授权范围。
- 只验收桌面首屏，移动端、键盘和错误状态完全没有证据。
- 用占位图片或默认字体完成截图，却没有说明素材和字体仍缺失。
完成后的检查
- 目标节点、项目目录和允许修改范围都有记录。
- 设计变量、现有组件和新增代码的映射关系可回查。
- 桌面、移动、键盘、真实数据和错误状态均有验证结果。
- Figma 与项目的权限最小化，未把私人设计文件写入日志或公开截图。
- 相关组件的测试和浏览器证据已经保存，未确认的部分明确标注。
