设计师的 Vibe Coding 完整工作流
设计师不需要学会"写代码"，而是学会"指挥 AI 写代码"。这份指南将帮助你从零建立一套可复用、可交付的 AI 辅助开发工作流。
UI/UX 设计开发阶段只用 Mock 数据，不碰业务逻辑。UI 与业务逻辑分离，设计师负责前端界面和交互，开发负责接口和业务。
适合使用的场景
- 有明确设计稿的 UI 开发（新页面、新组件、改版）
- 确定性高的需求，交互和视觉已经定稿
- 团队愿意接受设计师提交的前端代码
不适合的场景
- 探索性原型或概念验证（需求还没定）
- 需要深度业务逻辑的功能模块
Workflow Overview
三阶段工作流总览
Phase 1
准备阶段
1-1 先理解业务，再动手实现
拿到需求后，先做这三件事再开始：
1-2 环境配置（仅首次需要）
需要安装的东西（找开发帮你或参考团队文档）：
1-3 建立 CLAUDE.md 项目上下文文件
在项目根目录创建 CLAUDE.md 文件——这是你和 AI 的"约定书"：
# 项目说明
## 技术栈
- 框架：React 18 + TypeScript
- 样式：Tailwind CSS
- 组件库：shadcn/ui
- 包管理：pnpm
## 文件结构
- 页面文件放在 src/pages/
- 组件文件放在 src/components/
- Mock 数据放在 src/mock/
## 开发约定
- 所有 Mock 数据必须有 TypeScript 类型定义
- 业务逻辑用 TODO 注释占位，不自行实现
- 不修改 src/api/ 目录下的任何文件
## 禁止事项
- 不调用真实 API
- 不修改路由配置文件
- 不改动已有业务组件1-4 启动项目 & 预览效果
环境装好后，先把项目跑起来。后续开发阶段的每一次修改都需要在浏览器里看效果，这是最基本的操作循环。
启动项目三步走
# ① 在编辑器中打开终端（Cursor / VSCode 底部的 Terminal 面板）
# 快捷键：⌃` (Control + 反引号)
# ② 安装项目依赖（仅首次 clone 后需要执行一次）
npm install
# 如果团队用 pnpm，则用：pnpm install
# ③ 启动开发服务器
npm run dev看到这样的输出就说明成功了
VITE v5.x.x ready in 320 ms
➜ Local: http://localhost:5173/
➜ Network: use --host to expose按住 ⌘ Cmd 点击终端里的链接，浏览器会自动打开页面。
开发循环：修改 → 保存 → 自动刷新
启动遇到问题？
command not found: npmEACCES permission denied 或依赖安装失败Port 3000 is already in usenpm run dev 即可。
Phase 2 · 核心阶段
开发阶段
让 AI 写 PRD 和技术方案
不要上来就让 AI 写代码，先让它理清思路：
我是一个 UI/UX 设计师，我要开发一个[模块名称]页面。
设计稿描述：
- [描述页面主要内容]
- [描述主要交互：如筛选、分页、弹窗]
- [描述数据展示：如列表、卡片、图表]
请帮我：
1. 整理这个页面的功能点清单（PRD）
2. 分析需要哪些组件
3. 规划开发顺序（从简单到复杂）
4. 列出需要 Mock 的数据结构
注意：这个阶段只做静态 UI，不涉及真实接口。拿到方案后，确认没有遗漏再进入开发。
准备 Mock 数据
关键步骤在写任何 UI 之前，先让 AI 生成 Mock 数据：
根据上面的功能分析，请帮我生成这个页面需要的 Mock 数据。
要求：
1. 用 TypeScript 定义类型（interface）
2. 生成 10 条以上的测试数据，数据要多样化
3. 包含边界情况（超长文字、空值、特殊字符）
4. 文件放在 src/mock/[模块名].ts静态 UI 开发
推荐从大到小、从框架到细节的顺序：
实现整体布局，用 Mock 数据填充，先不加交互
逐个实现具体组件：筛选栏、数据表格、弹窗等
展开/折叠、筛选、动画，数据变化仍在 Mock 范围内
Prompt 示例 — 第一轮搭框架
请根据设计稿实现 [页面名] 的整体布局：
1. 左侧 240px 侧边栏 + 右侧内容区
2. 顶部搜索栏 + 筛选区域
3. 主体是一个数据列表（用 Mock 数据填充 5 条）
4. 先不做交互，只做静态布局
技术栈：[React/Vue + 组件库]交互打磨
视觉和交互都完成后，让 AI 做自检：
请检查当前代码，找出以下问题并修复：
1. 是否有硬编码的字符串（应该用变量）
2. 是否有 console.log 未清理
3. 是否有未处理的 TODO
4. 响应式布局是否有问题（移动端/宽屏）
5. 是否有明显的性能问题（如列表没有 key）同时做极端情况测试：
业务逻辑占位
UI 完成后，主动标记所有需要接入真实逻辑的地方：
// TODO: 获取用户列表 - 需要调用 getUserList 接口
// 当前：使用 Mock 数据
// 替换为：调用 src/api/user.ts 中的 getUserList 方法Phase 3
交付阶段
3-1 推送前 Checklist
3-2 推送独立分支
每个功能 / 页面开独立分支，命名建议：
feat/[你的名字缩写]-[功能名]-ui
例如：feat/hsf-seo-audit-uiGit 速查 — 设计师常用命令
# 创建并切换到新分支
git checkout -b feat/hsf-seo-audit-ui
# 查看改了哪些文件
git status
# 提交所有改动
git add . && git commit -m "feat: seo audit page UI"
# 推送到远程
git push origin feat/hsf-seo-audit-ui不熟悉 Git？直接让 AI 帮你执行命令，说"帮我把代码推送到新分支 feat/xxx"即可。
3-3 撰写交付文档
写清楚 PR 描述，让开发知道你交了什么、他要做什么：
## 本次交付内容
- 实现了 [页面/功能名] 的静态 UI
- 使用 Mock 数据，所有业务逻辑已用 TODO 标记
## 需要开发补充的内容
- [ ] src/pages/UserList.tsx 第 23 行：接入用户列表接口
- [ ] src/components/UserFilter.tsx 第 45 行：接入筛选接口
- [ ] 分页逻辑（当前为 Mock 分页）
## 设计稿链接
[Figma 链接]
## 预览截图
[截图]3-4 和开发建立信任
设计师交付代码初期，开发可能持观望态度。关键是用交付质量说话：
只做 UI 层，业务逻辑全部用 TODO 标注，不越界、不增加开发负担
每次交付附带清晰的对接文档，降低开发理解成本
上线前主动拉开发 Review，接受反馈并快速迭代
前几次交付做到"零返工"，信任自然建立
Prompt Templates
Prompt 模板库
直接复制使用，[方括号] 内容替换为你的实际信息
通用开场
每次必用我是一个 UI/UX 设计师，正在用 Cursor 辅助前端开发。
请先阅读根目录的 CLAUDE.md，了解项目技术栈和规范。
我们现在要开发 [功能名称]。
开发约束：
- 所有数据使用 Mock，不调用任何真实 API
- 业务逻辑用 TODO 注释占位，说明需要对接什么
- 只改动 [涉及的目录/文件]，不要动其他文件
协作方式：请先看看我的描述，是否还有需要补充的？如果有请追问我；如没有请直接继续。
组件开发
帮我实现 [组件名] 组件。设计稿截图见附图。
视觉要求：[关键样式，如卡片圆角 12px、主色 #5B4CDB]
交互要求：[hover 效果、点击展开、加载态等]
需要的状态：[空状态 / 加载中 / 正常 / 错误]
数据：使用 src/mock/[文件名].ts 中的 Mock 数据
约束：不调用真实 API，业务逻辑用 TODO 占位
问题修复
[组件名/文件路径] 出现了问题。
当前现象：[描述你看到的表现]
预期效果：[描述正确应该是什么样]
报错信息：[如有报错，完整粘贴到这里]
请只修改相关文件，不要改动其他组件和页面。
修复后告诉我改了哪里、为什么。
代码解释
请用简单易懂的语言解释这段代码在做什么，
重点说明：这个逻辑对 UI 表现有什么影响？
[粘贴代码]
设计稿还原对比
高频这是设计稿截图（见附图），这是当前页面效果。
请逐一对比以下差异并修复：
1. 间距和尺寸是否与设计稿一致
2. 字号、字重、颜色是否匹配
3. 圆角、阴影、边框等细节
4. 元素对齐方式
修复后列出所有改动点。
响应式适配
高频[页面/组件名] 目前只适配了桌面端。
请添加移动端适配（断点：[768px / 1024px]）：
1. [描述移动端布局，如：侧边栏改为底部 Tab]
2. 表格在小屏改为卡片列表
3. 保持功能不变，只调整布局和字号
改完后帮我在 375px 和 768px 两个宽度下检查一遍。
交付对接文档生成
交付必备我已经完成了 [页面/功能名] 的静态 UI 开发，现在需要生成一份交付对接文档给开发。
请帮我梳理并输出以下内容：
1. 本次交付的页面/组件清单（列出所有新增和修改的文件）
2. 所有 TODO 占位点汇总（文件路径 + 行号 + 需要对接的接口/逻辑）
3. Mock 数据与真实接口的替换对照表
4. 需要开发注意的特殊逻辑或边界情况
5. 预览截图说明（哪些页面/状态需要开发重点验证）
输出格式：Markdown，可直接粘贴到 PR 描述中。
Internal Rollout
公司内部推进节奏
在公司内推进前，先明确自己的角色目标：
协作型
推荐起步设计稿 → 生成前端代码 → 交开发 Review / 集成
承接型
直接负责某些页面 / 功能的完整前端交付
建议：先做 A，用成果换信任，再逐步扩展到 B。
找低风险试验项目
目标是拿出一个"能跑、能看、能交付"的成果：
和一个开发建立盟友关系
不绕过开发，而是拉他一起——这比说服整个团队容易得多：
省了写 UI 代码的时间，只需 Review 和集成
获得技术背书，后续推进更容易
量化价值
数据比 PPT 有说服力。记录时间对比：
FAQ
常见问题
AI 生成的代码报错了怎么办？
AI 改了我不让它改的文件怎么办？
生成的 UI 和设计稿差很多怎么办？
对话太长 AI 开始乱改怎么办？
不知道一个功能该怎么实现怎么办？
担心代码质量不够好，开发不接受怎么办？
完全不懂 Git，能做 Vibe Coding 吗？
checkout -b（建分支）、status（看状态）、add + commit（提交）、push（推送）。不确定的时候直接告诉 AI"帮我把代码提交并推送到远程"，它会帮你执行。
公司内部推进时常见坑有哪些？怎么应对？
代码质量被开发否定：主动说“这是初稿，帮我看哪里需要改”，而不是“这是我写的代码”。
开发觉得你越权：强调“减少重复劳动”，而不是“替代你”。
承接后出 bug 背锅：提前和 PM / 开发约定好交付物的验收标准。
AI 遗忘早期约定：关键约束写进 CLAUDE.md 文件，不只在对话里说。
Toolbox