Vibe Coding 对设计师来说，不是「学会写代码」，而是把设计稿变成能跑起来的界面，再用一份清楚的交接说明交给开发。这条工作流只做界面层：布局、组件、状态、交互——不碰业务逻辑。
- 从设计稿到可点击的界面
- 不等排期，当天就能评审
- 边界清晰，开发愿意接
适合这样做
- 设计稿已定稿的页面、组件、改版
- 交互与状态基本明确，不需要推理业务规则
- 团队接受「设计师提 PR、开发 Review」的方式
不适合这样做
- 需求还在探索，以快速验证想法为主的原型
- 强依赖权限、计费、审批等功能模块
- 涉及接口设计、数据结构迁移的部分
三阶段工作流总览
准备阶段
1-1先读懂需求，再动手
拿到需求别急着打开 AI。先确认三件事，后面能省掉大量返工：
1-2装好四件套（仅首次）
前两件是运行基础，后两件是指挥 AI 的工具。装完各跑一条命令确认版本，报错就先解决环境。
Node.js
跑前端的运行时node -v
Git + GitHub
拉代码、开分支、提 PRgit -v
Claude Code
终端里的编码代理claude --version
Codex
另一条可选的编码代理codex --version
1-3写一份 AGENTS.md 项目约定
放在项目根目录。AI 每次开始工作都会先读它——比你每次在对话里重复一遍规则可靠得多，也解决了「聊到后面它忘了约定」的问题。
# 项目说明
内部运营后台。设计师负责 UI 层，业务逻辑由开发实现。
## 技术栈（以 package.json 为准）
- React 19 + TypeScript
- Tailwind CSS 4
- 组件库：shadcn/ui
- 包管理：pnpm
## 目录
- 页面：src/pages/
- 组件：src/components/
- Mock 数据：src/mock/
## 约定
- 数据只从 src/mock/ 读取，每个结构都要有 TS 类型
- 业务逻辑用 TODO 占位：写清接哪个接口、在哪一行、当前是什么
- 颜色、间距、字号只用设计 token，不写裸色值和魔法数字
- 不写内联 style，除非是运行时动态计算的值
## 禁止
- 不调用真实接口，不改 src/api/
- 不引入新的 UI 库，新增组件前先检索现有组件
- 不改路由配置、不改别人负责的业务组件AGENTS.md；Claude Code 读 CLAUDE.md，从 2.1.277 版起，在没有 CLAUDE.md 时会直接读 AGENTS.md。所以只维护一份 AGENTS.md 就能两边通用；想让两边都读，就在 CLAUDE.md 里写一行 @AGENTS.md。1-4把项目跑起来
之后每一次改动都要在浏览器里看结果，这是整套工作流最基本的循环。
# 在项目目录下打开终端（VS Code：⌃`）
node -v # 先确认 Node 装好了
pnpm install # 首次拉代码后执行一次；用 npm 就 npm install
pnpm dev # 启动开发服务器看到这样的输出就说明成功：
VITE v8.x ready in 320 ms
➜ Local: http://localhost:5173/
➜ Network: use --host to expose按住 ⌘ Cmd 点击链接即可打开页面；改完代码保存，浏览器会自动刷新（热更新），不用手动刷新。
1 · 让 AI 改代码
在对话里描述改动
2 · 保存文件
⌘S（多数编辑器自动保存）
3 · 浏览器刷新
切过去就能看到最新效果
启动常踩的三个坑
command not found: pnpm
→ Node 没装好，或没全局安装 pnpm。装完重开终端窗口再试。
EACCES: permission denied / 依赖装不上
→ 把完整报错复制给 AI，说「帮我修掉这个报错，只改必要的配置」。
Port 5173 is already in use
→ 上一次的开发服务器还开着。关掉旧终端窗口，或让 AI 换一个端口。
pnpm dev 就行，项目不会坏。开发阶段
2-1先要方案，再要代码
直接把设计稿丢过去说「实现这个页面」，它会给你一堆局部正确、整体拼不上的代码。先让它拆方案：
我是 UI/UX 设计师，负责 [模块名] 的 UI 层，设计稿见附图 / Figma 链接。
先不要写代码，输出四件事：
1. 功能点清单：页面有哪些区块，各有哪几种状态（空 / 加载 / 错误 / 无权限）
2. 组件拆分：哪些能复用现有组件，哪些要新建
3. 实现顺序：从骨架到细节，拆成 3 轮
4. Mock 数据结构：每个列表 / 卡片需要哪些字段
约束：只做静态 UI 和本地交互，不接真实接口。2-2先造 Mock 数据 关键步骤
UI 的难点从来不是正常数据，而是极端数据。先把数据造全，做界面时才不会被「这个字段没有」卡住。
按上面的数据结构，生成 src/mock/[模块名].ts：
1. 用 interface / type 定义每个字段，标出可选字段
2. 12 条以上数据，长度和类型都要有差异
3. 至少各 1 条：超长文本、空值、0 或负数、特殊字符、超多条目
4. 导出 get[模块名]List() 之类的方法，参数和返回值要像真实接口
不要写成随机生成器，数据要能直接用肉眼判断布局是否出问题。贴近真实接口
之后换真数据只改一处
覆盖极端数据
提前暴露换行、截断、溢出
有类型定义
AI 改错字段会立刻报错
2-3分三轮做出静态 UI
从整体到细节，每一轮都要能在浏览器里看到东西。不要一次让它写完整个页面——出问题时你很难判断是哪一层坏了。
第一轮
搭骨架
布局、导航、区块占位，先不填真实内容
第二轮
填组件
表格、卡片、筛选栏、弹窗，逐个替换占位
第三轮
加交互
展开、筛选、分页、hover、动效，数据仍在 Mock 内
按设计稿实现 [页面名] 的整体骨架：
1. 左侧 240px 导航 + 右侧内容区（顶部标题栏 + 筛选区 + 列表区）
2. 先只用占位块和 Mock 数据的前 5 条，不做交互
3. 断点按项目规范：≥1280 三列 / 768–1279 两列 / <768 单列
4. 复用项目已有的布局组件和间距 token，不要新写一套
改完告诉我：哪些结构是你自己决定的，我需要重点看哪里。补充把 Figma 接进来，能省掉一半返工
截图喂给 AI，它只能「猜」间距和颜色。接上 Figma 官方的 Dev Mode MCP 后，AI 直接读图层树、auto-layout 间距和变量（token）名，生成的代码引用的是你真实的设计变量，而不是眼测出来的近似值。
# 1. Figma 桌面端：Preferences → 打开 Dev Mode MCP Server
# （Figma 需要一直开着，服务跑在本机 127.0.0.1:3845）
# 2. 在 Claude Code 里接上这个本地服务
claude mcp add --transport http figma-dev-mode-mcp-server http://127.0.0.1:3845/mcp
# 也可以改用 Figma 官方插件，一条命令装好
claude plugin install figma@claude-plugins-official
# 3. 在 Figma 里选中要实现的 frame，回终端描述需求
# 「读取当前选中的 frame，用我们的设计 token 实现这个卡片」config.toml 里挂同一个 MCP 服务即可。2-4自检 + 极端数据
视觉对了不等于能交付。让 AI 先按清单自查一遍，再自己动手改数据试：
只做检查，不要顺手重构。逐条给结论，需要改的标出文件:行号。
1. 是否有硬编码的色值、间距、文案（应该来自 token / 常量）
2. 是否有 console.log、调试代码、没用到的 import
3. 列表渲染是否有稳定的 key，是否存在不必要的整页重渲染
4. 空 / 加载 / 错误 / 超长文本 / 无权限 五种状态是否都有对应 UI
5. 键盘可达性：按钮能 Tab 聚焦、有 focus 样式、弹窗能 Esc 关闭然后自己改数据试一遍——这一步 AI 替不了你：
- 列表清空：空状态是否成立，文案有没有告诉用户下一步做什么
- 标题拉到 60 字：是否截断、是否顶掉右侧按钮
- 数字改成 0 / 负数 / 百万级：千分位、单位、对齐是否还成立
- 图片缺失：有没有占位和兜底，而不是一个破图图标
2-5业务逻辑留成 TODO
把「这里将来要接真实数据」标清楚。这是开发最在意的一步，也决定了你的交付是帮忙还是添乱。
// TODO(接接口): 用户列表
// 现在：src/mock/user.ts 的 mockUserList（12 条）
// 将来：src/api/user.ts 的 getUserList({ page, keyword })
// 位置：本文件 handleSearch()，目前只做前端过滤交付阶段
3-1推送前自检清单
3-2独立分支提交
一个页面一条分支，命名要让开发一眼看懂是谁、做什么：
git switch -c feat/ui-[页面名] # 建分支并切过去（老版本用 checkout -b）
git status # 确认改了哪些文件
git add . && git commit -m "feat: [页面名] 静态 UI"
git push -u origin feat/ui-[页面名] # 推上去，然后开 PR3-3写清交付说明
开发打开 PR 时只想快速知道三件事：你做了什么、还需要他做什么、去哪里看效果。
## 本次交付
- [页面名] 静态 UI（桌面 / 移动两套）
- 数据全部来自 src/mock/[模块名].ts，未接任何真实接口
- 交互已实现：筛选、分页、空状态、加载态
## 需要补的部分
- [ ] src/pages/UserList.tsx:42 搜索 → 接 getUserList({ page, keyword })
- [ ] src/pages/UserList.tsx:88 分页 → 接真实 total
- [ ] 导出按钮：等接口，暂未实现
## 设计稿与预览
- 设计稿：Figma / [图层名或链接]
- 预览：本地 pnpm dev，或 [预览地址]
- 建议重点看：空状态、超长标题、移动端筛选
## 已知差异
- 表格在 1280 以下会折行，设计稿只给了 14403-4和开发建立信任
第一次交付，开发大概率会观望。别用嘴解释，用交付质量说话：
边界清晰
只交 UI 层。不碰接口和业务规则，TODO 标到位，开发接手不用反推你的思路。
文档先行
每个 PR 附交付说明。他能直接对照「哪里要接、接什么」，而不是先读一遍你的代码。
主动 Review
上线前拉他一起过一遍。有分歧当场改，比上线后返工便宜得多。
零返工
前两次做到「拿过去就能接」。后面他会主动把页面递给你做。
Prompt 模板库
通用开场
每次必用我是一个 UI/UX 设计师，负责这个项目的 UI 层。先读一下根目录的 AGENTS.md，了解技术栈和约定。
这次要做：[功能名]，设计稿见附图 / Figma 链接。
约束：
- 数据全部用 src/mock/ 里的 Mock，不调用真实接口
- 业务逻辑用 TODO 占位，写清接什么、在哪接
- 只改 [目录/文件]，其他文件不要动
开始前先复述一遍你的理解，并列出你还需要我确认的问题；没问题再动手。单组件实现
实现 [组件名]，设计稿见附图。
视觉：[尺寸 / 圆角 / 主色 / 字号等关键值]
状态：默认 / hover / focus / disabled / loading / 空
数据：用 src/mock/[文件].ts 里的 [类型名]
要求：复用项目已有组件和 token，不新增依赖，不写内联样式。
完成后告诉我：哪些值是你从设计稿读到的，哪些是你自己补的。设计稿对比修复
高频这是设计稿，这是当前页面截图。逐项对比后修复：
1. 间距、尺寸、圆角
2. 字号、字重、行高、颜色（确认是否用了 token）
3. 对齐方式与层级
4. 图标尺寸与位置
只改这一个组件。改完列出「改了什么 / 从多少改到多少」。报错修复
[文件路径] 报错了。
现象：[你看到的]
报错（完整粘贴）：[...]
期望：[正确应该是什么样]
先判断根因再改，只动相关文件；改完说明改了哪里、为什么。响应式适配
高频[页面/组件] 目前只做了宽屏。
按项目断点补 [768 / 1024] 的布局：
1. 导航：[如收成汉堡菜单]
2. 表格：[如改为卡片列表]
3. 字号与间距按 token 缩小，不新增断点
改完在 375 / 768 / 1440 三个宽度下自查一遍，并列出你做的取舍。看懂代码再改
用设计师能听懂的话解释这段代码：
1. 它在页面上对应什么
2. 哪些值是「样式」，哪些是「数据」
3. 如果我要改 [某处视觉]，应该动哪一行
[粘贴代码]交付说明生成
交付必备我完成了 [页面名] 的静态 UI，请生成一份给开发的交付说明：
1. 新增 / 修改的文件清单
2. 所有 TODO 汇总（文件:行号 + 要接的接口 + 当前实现）
3. Mock → 真实接口的替换对照
4. 需要开发注意的边界与已知差异
5. 建议 Review 的重点
输出 Markdown，能直接粘进 PR 描述。在团队里推进
模式 A
协作型 建议起步
你出界面代码 → 开发 Review 并接业务逻辑
阻力最小，也最容易持续
模式 B
承接型
你独立负责某些页面 / 模块的完整前端交付
需要信任和流程，别一上来就做
- 选一个低风险试验田：内部工具、活动页、非核心业务页面。目标是拿出一个「能跑、能看、能交付」的成果，别拿主产品线练手。
- 拉一个开发当盟友：不是绕过他，而是让他少写 UI。他省时间，你拿技术背书——比说服整个团队容易得多。
- 用数据说话：记录同一类页面「以前 / 现在」的耗时，一次具体的对比比任何 PPT 都有说服力。
以前
~2 周
设计稿 → 排期 → 开发写 UI
现在
~3 天
设计稿 → 可点击界面 → 开发接逻辑
数字随页面复杂度变化，记账时按「同一类页面」对比才站得住。
常见问题
AI 报错了，我看不懂怎么办？
把报错完整复制给它，说「帮我定位并修掉这个报错」，不要只说「报错了」。报错里的文件路径和行号就是最好的线索，通常一次就能改对。如果两轮还没好，先让它解释这个报错在说什么，再决定改哪里。
AI 改了我没让它动的文件怎么办？
两件事一起做：在 AGENTS.md 的「禁止」里写死不能动的目录；每次任务开始先说清「只改 xxx 目录」。真改了也不怕——git status 能看到动了哪些文件，git checkout -- 文件名 单独还原那一个。
生成的界面和设计稿差很多怎么办？
别用文字描述差异，直接并排放两张图：设计稿 + 当前截图，让它逐项对比间距、字号、颜色、圆角。视觉对比比任何形容词都准。如果接了 Figma MCP，先说「读这个 frame 的变量」，很多偏差根本不会出现。
怎么让 AI 产出符合产品风格的界面？
核心思路：把「产品风格」变成它能读的规则，而不是每次 Prompt 里描述一遍。在 AGENTS.md 里写死四件事：
说清调性，别只丢一个参考站
用一句话说清气质，比如「信息密度高、克制、像 Linear 的紧凑感」。只给网址，它学到的往往是最表层的颜色。
锁死设计 token
颜色、间距、字号只能用变量，不准写裸色值和魔法数字。从源头断掉它「自己调色」的空间。
强制复用组件
「不引入新的 UI 库，必须用现有的 xxx」。新建组件前先检索，避免同一个按钮做出三个版本。
限制写法边界
不写内联 style（动态值除外），样式统一走 Tailwind / CSS 变量，保证风格可追溯、可统一改。
一句话：Prompt 里给约束，规则里定边界。给它一个沙盒，别给它一张白纸。
对话越来越长，AI 开始乱改怎么办？
这是最常见的问题：上下文塞满后它会忘掉早期约定，开始「自作主张」。两个动作：① 一个功能做完就开新对话，把进度和下一步说清；② 长期约定全部沉到 AGENTS.md 里，新对话自动带上。判断信号很简单——它开始修改你没提过的文件时，就该换对话了。
完全不懂 Git，能做这件事吗？
能。日常只用四个动作：建分支、看状态、提交、推送。命令记不住就直接说「帮我把改动提交到新分支并推送」，它会替你执行，但推完你自己确认一眼分支名。要守住一条底线：永远不直接往主分支提交。
开发觉得我越权、质疑代码质量，怎么办？
- 别说「我写了前端」，说「我把 UI 先做出来了」。定位是你替他省掉重复劳动，不是替代他。
- 把初稿当草稿递过去：「这是第一版，帮我看哪里需要改」比「你看我写完了」好接十倍。
- 提前约定验收标准：谁负责交互、谁负责接口，写进 PR 描述，避免上线后返工扯皮。
- 前两次宁可慢一点：拿过去就能接的交付，比交付得快但满地 TODO 更能换来下一次机会。
推荐工具组合
Claude Code
终端里的编码代理。读 AGENTS.md、能跑命令看报错，可接 Figma MCP 直接读设计稿。
Codex
另一条编码代理，沙箱更严格、长任务更稳。两个都装也行，按任务挑一个。
Figma
设计源文件 + Dev Mode MCP，把图层、间距和变量直接交给 AI，少猜一半。
Git + GitHub
分支、PR、Review。交付的载体，也是你敢让 AI 改代码的底气。