Figma 还原得像，不代表功能能跑；功能能跑，也不代表
dist能交付。
用 Codex 做前端（前提你得花钱买额度😁😁😁😁😁😁），最容易踩的坑，是一句话同时要求它看 Figma、接接口、修交互、跑测试、打包甚至上线。任务跨度越大，中间越难检查，最后往往只剩一句“已经完成”。更可靠的方式，是把开发拆成短步骤：每一步只使用两三个相关 Skills，并明确输入、输出和验收条件。每一步都有独立产物，方便评审、回退和继续交接。下面的 01–04 是一条主流程；S1“设计系统”是长期项目的支撑能力，不是每次开发都必须执行。
流程速查
| 阶段 | Skills 组合 | 本阶段只负责 |
|---|---|---|
| 01 页面 | figma-design-to-code + figma-implement-design + vue-best-practices | 根据 Figma 完成 Vue 模板、样式和组件结构 |
| 02 逻辑 | documents + vue-best-practices | 根据需求文档和现有项目补业务逻辑 |
| 03 测试 | control-in-app-browser + playwright | 在真实浏览器验证功能并修复问题 |
| 04 构建 | vue-best-practices + playwright | 完成类型检查、回归检查并输出 dist |
| S1 支撑 | figma-generate-library + figma-code-connect + vue-best-practices | 统一设计组件、代码组件和设计变量 |
✍️ 01｜根据 Figma 编写页面
Skills： figma-design-to-code + figma-implement-design + vue-best-practices
这一阶段只处理页面骨架和视觉还原：读取指定 Figma 节点，把布局写进 Vue 的 <template>，把样式写进 <style>，并复用项目已有组件和设计变量。可以先使用静态数据占位，不急着连接接口，也不在这里顺手重构整个项目。输出应是一个能打开、结构合理、桌面和移动端不溢出的页面。
你可以这样问 Codex： 我有一个 Figma 地址，请读取指定节点，在
src/views/OrderDetail.vue中编写对应的 HTML 和 CSS。使用 Vue 3 和项目现有组件，先完成页面还原，不接接口；完成后检查桌面端和移动端布局。
✍️ 02｜根据需求文档补业务逻辑
Skills： documents + vue-best-practices
页面完成后，再读取需求文档、AGENTS.md、相似业务模块、接口封装和状态管理方式。这个阶段负责请求参数、表单校验、按钮事件、权限、加载状态、错误提示和数据回显，不重新设计页面。需求是 Word 或 Google Docs 时使用 documents；如果只是仓库里的 Markdown，可以直接读取，不必为了凑组合强行调用它。
你可以这样问 Codex： 这是订单详情需求文档。请先阅读现有项目结构、
AGENTS.md、相似页面和编码规范，再在刚才的 Vue 页面中补齐接口请求、按钮事件、权限和异常状态。保持现有架构，不修改无关模块。
✍️ 03｜在真实浏览器做功能测试
Skills： control-in-app-browser + playwright
浏览器 Skill 用来启动页面、登录、点击和快速复现；playwright 把关键路径变成可重复的检查步骤。此时重点验证数据加载、表单提交、弹窗关闭、路由跳转、失败提示和移动端布局。发现问题就在当前阶段修复并重新测试，不要测试失败后仍继续打包，也不需要把系统级截图当成默认动作。
你可以这样问 Codex： 请启动现有项目，在真实浏览器中测试订单详情页。检查正常加载、接口失败、编辑提交、权限按钮和返回列表，再用 Playwright 覆盖桌面与手机两个视口；发现问题直接修复并重新验证。
✍️ 04｜检查并构建 dist
Skills： vue-best-practices + playwright
功能测试通过后，才进入构建阶段。先运行项目已有的 lint、vue-tsc、单元测试或关键 Playwright 回归，再执行仓库规定的构建命令。最后确认命令成功、dist 已生成、静态资源路径正确，并可按项目现有方式预览构建结果。这一步到 dist 为止，不自动部署服务器，也不修改 CI 或托管配置。
你可以这样问 Codex： 页面功能已经完成，请按项目现有命令运行 lint、类型检查和关键回归测试。全部通过后执行生产构建，确认
dist目录生成且资源能正常加载；不要发布，只汇总构建结果和仍未覆盖的风险。
✍️ S1｜统一设计系统和代码组件
Skills： figma-generate-library + figma-code-connect + vue-best-practices
这个组合不是“自动把整个项目变漂亮”，而是解决设计稿与代码长期不一致的问题。具体可以拆成四步：
- 先盘点前端已有的颜色变量、字号、间距和 Vue 基础组件，确认哪些才是代码事实来源。
- 使用
figma-generate-library在 Figma 中建立或补齐变量、Button、Input、Select、Dialog 等组件及其尺寸、状态和变体。 - 使用
figma-code-connect建立映射，例如 Figma 的Button / Primary / Disabled对应代码中的<AppButton type="primary" disabled />，而不是让 Codex每次重新写一个按钮。 - 后续执行 01 时，设计到代码流程优先复用这些已映射组件；组件 API 发生变化时，再同步检查 Figma 和代码两边。
对前端最直接的价值是减少重复组件、统一属性命名，并让设计稿里的状态能够落到真实代码。它适合组件较多、多人协作、页面会持续增加的项目；一次性活动页通常没有必要先建设完整设计系统。直接写入 Figma 时，还需要遵循 figma-use 的前置操作规范。
你可以这样问 Codex： 请先盘点
src/components和样式变量，列出按钮、输入框、下拉框和弹窗的现有 API；然后在 Figma 中建立对应组件和变体，并用 Code Connect 映射到真实 Vue 组件。先完成这四类，不重写业务页面。
Skills 地址
以下优先使用 Skill 自身或所属插件的公开仓库；没有独立公开页面的条目，使用插件清单声明的官方地址。
- figma-design-to-code：在开始编码前获取 Figma 节点、设计上下文、截图和素材，帮助 Codex 准确理解要实现的页面。
- figma-implement-design：把 Figma 设计高还原地实现成生产代码，并优先复用项目现有组件和设计变量。
- vue-best-practices：约束 Vue 3、Composition API、
<script setup>和 TypeScript 的写法，减少组件、响应式和类型问题。 - documents：读取、创建或修改 Word 等文档；在本文流程中主要用于理解正式的需求文档。
- control-in-app-browser：打开并操作本地页面，通过点击、输入和页面观察快速复现前端问题。
- playwright：自动执行真实浏览器流程，用于表单、弹窗、路由、不同视口和关键回归测试。
- figma-generate-library：根据代码库建立或更新 Figma 变量、主题、组件及变体，形成可持续使用的设计系统。
- figma-code-connect：把已发布的 Figma 组件映射到仓库中的真实代码组件、文件路径和属性用法。
- figma-use：规范直接读取或修改 Figma 文件时的操作，是调用 Figma 写入工具前必须遵循的基础流程。
结语
如果你还有其他前端 Skills 的组合方式，欢迎留言交流；本文也会随着 Codex 和相关 Skills 的变化持续更新。
