设计师工作流

用 Codex 实现

这条工作流最适合放在 Codex + 设计稿 + Mock 数据 的组合里来理解：

设计师先把页面目标、设计稿和交付边界说清楚
Codex 先做拆解，不急着一上来生成整页代码
所有数据先用 Mock 驱动，业务逻辑只做 TODO 占位
最后把结果以“可 review、可集成、可继续接接口”的方式交给开发

可以直接这样说：

text

我是设计师，这次只负责前端 UI 层交付。
请先根据设计稿和项目约定，帮我完成：
1. 页面功能点拆解
2. 组件树
3. Mock 数据结构
4. 开发顺序
5. 需要给开发预留的 TODO 点

要求：
- 不调用真实 API
- 不改动业务接口目录
- 先做静态 UI，再补交互

建议配合：

🎯 核心问题

设计师真正要学的，不是把自己变成专业前端工程师，而是学会用 AI 和工程约定，把设计稿稳定推进成交付级前端结果。

1. 这条工作流解决的是什么问题

很多团队里，设计到开发的损耗并不在“设计稿画不出来”，而在下面这些地方：

设计稿讲不清交互边界
开发要反复还原视觉细节
UI 代码完成了，但没人知道后面该怎样接接口
设计师想更深参与交付，却又担心越界

这条工作流的目标不是让设计师“包办整个前端”，而是建立一个清晰边界：

设计师负责 UI 结构、视觉、交互表现、Mock 驱动
开发负责 真实接口、业务逻辑、架构与最终集成

只要边界清晰，设计师就能把原本停留在 Figma 的成果，往前推进到：

可运行的前端页面
可 review 的组件代码
可对接的 TODO 清单
可复制的交付方式

2. 黄金原则：只做 UI，不碰业务逻辑

这条原则非常重要：

UI 开发阶段只用 Mock 数据，永远不要在不清楚业务边界时直接碰真实接口和核心逻辑。

这样做的好处是：

设计师能专注界面和交互，不会被后端细节拖住
开发接手时边界清晰，知道哪些地方只是占位
后期替换真实 API 时，改动范围更可控

2.1 适合的场景

已有明确设计稿的新页面或新模块
视觉和交互方向已经基本确定
团队接受设计师提交前端 UI 代码
需要快速做出可演示、可 review 的页面成果

2.2 不适合的场景

需求还在探索中的概念原型
强依赖复杂业务规则的功能模块
没有设计稿、完全凭想法临时生成代码
涉及支付、权限、流程编排等核心业务链路

3. 三阶段工作流总览

flowchart LR
  A["准备阶段<br/>确认范围 / 配环境 / 建项目约定 / 跑起项目"] --> B["开发阶段<br/>拆 PRD / 做 Mock / 搭 UI / 补交互 / 标 TODO"]
  B --> C["交付阶段<br/>自检 / 分支提交 / 交付文档 / 开发 Review"]

如果你在带课，我建议把这条工作流讲成一句话：

先把范围和约定讲清，再让 Codex 帮你把设计稿推进成静态 UI，最后用清晰文档把它交出去。

4. 准备阶段：先把边界定住

4.1 先确认自己负责什么

拿到设计稿后，不要急着让 AI 生成代码，先确认：

这次你负责的是整个页面，还是其中几个模块
哪些交互要做出效果，哪些只需保留入口
团队技术栈是什么：React、Vue、组件库、样式方案、包管理器
哪些目录不能碰，哪些文件只能由开发改

建议把这些信息写成一份“本次交付边界”：

页面范围
不做的部分
交付物形式
需要开发接手的地方

4.2 准备项目约定文件

如果项目里已经有 AGENTS.md、CLAUDE.md 或类似说明文件，先读懂；如果没有，就补一份最小版约定。

例如：

# 项目约定

## 技术栈
- React 18 + TypeScript
- Tailwind CSS
- shadcn/ui

## 本次交付范围
- 只做运营后台的活动列表页和详情弹窗
- 所有数据使用 Mock
- 业务逻辑全部用 TODO 占位

## 禁止事项
- 不修改 src/api
- 不修改路由主配置
- 不接真实接口

对 Codex 来说，这类文件的作用就是“长期有效的项目记忆”。

4.3 跑起项目，建立最小循环

开始写 UI 之前，至少先保证下面这个循环跑通：

安装依赖
启动项目
浏览器能看到页面
代码改动后能热更新

只有这个循环通了，后面的设计还原和交互打磨才会顺。

5. 开发阶段：让设计稿变成可交付页面

5.1 先让 Codex 帮你拆功能，不急着写代码

设计师最容易犯的一个错，是把“一张设计稿”直接当成“一次代码生成任务”。

更稳的做法是先让 Codex 输出：

页面功能点
页面区域拆分
组件树
需要哪些 Mock 数据
哪些地方将来要接接口

可以这样说：

text

这是一个设计稿页面，请先不要直接整页生成代码。
请帮我输出：
1. 页面功能点清单
2. 组件树
3. 开发顺序
4. Mock 数据字段设计
5. 未来需要接入真实逻辑的点

5.2 先做 Mock 数据

UI 想做稳，Mock 数据必须先准备好。

一份合格的 Mock 数据至少应该满足：

有类型定义
数据足够多样化
包含空状态、超长文本、边界值
和未来真实接口结构尽量接近

建议提示词：

text

请根据这个页面的功能点，先生成 Mock 数据文件。
要求：
1. 用 TypeScript 定义类型
2. 数据至少 10 条
3. 包含超长文本、空值、异常值
4. 文件放在 src/mock/xxx.ts
5. 字段命名尽量贴近未来真实接口

5.3 静态 UI 开发要按“三轮法”

推荐按这个顺序推进：

第一轮：搭框架

把整体布局搭出来
把主要区域放对
用最小的 Mock 数据填充
先别急着做交互

第二轮：补组件

列表
卡片
筛选栏
弹窗
状态标签

逐个补，不要一口气让 AI 同时生成太多区域。

第三轮：加交互

展开/收起
切换态
hover
tab
本地筛选
mock 分页

这一轮依旧不碰真实业务逻辑。

5.4 交互打磨要做“设计对比 + 极端数据测试”

当页面看起来“差不多完成”时，不要立刻交付，要让 Codex 再做两轮检查：

设计稿对比

间距是否一致
字号和字重是否匹配
圆角、阴影、边框是否还原
对齐方式是否准确

极端情况测试

空数组
超长文本
0 值 / 负值
多标签换行
小屏宽度

这一步非常能体现设计师优势，因为你对视觉差异最敏感。

5.5 主动做好业务逻辑占位

UI 做完以后，不要把逻辑空着不说明，而要主动标记：

// TODO: 调用 getActivityList 接口替换当前 Mock 数据
// TODO: 筛选条件需要接入真实查询参数
// TODO: 分页逻辑目前为前端 mock，后续改成服务端分页

这会直接决定开发接手时的体验。

6. 交付阶段：让开发愿意接你的成果

6.1 推送前 Checklist

交付前，至少检查这几件事：

浏览器无报错
关键交互能正常演示
没有遗留 console.log
Mock 数据有类型定义
所有业务逻辑占位都写清楚了
没有改到约定中禁止改动的文件

6.2 每次交付走独立分支

最稳妥的命名方式可以是：

bash

feat/designer-[page-name]-ui

例如：

bash

git checkout -b feat/designer-event-dashboard-ui
git status
git add .
git commit -m "feat: event dashboard ui"
git push origin feat/designer-event-dashboard-ui

6.3 交付文档必须一起给

一份合格的交付说明，至少要写清楚：

本次新增和修改了哪些文件
哪些地方只是 UI 占位
哪些 TODO 需要开发继续接
Mock 和真实接口如何替换
哪些页面状态需要重点验收

推荐结构：

## 本次交付内容
- 完成活动列表页静态 UI
- 完成活动详情弹窗
- 所有数据均为 Mock

## 开发需要继续完成
- 接入列表接口
- 接入筛选接口
- 接入服务端分页

## 特别说明
- 空状态、超长标题、移动端已做适配

6.4 建立信任的关键

设计师第一次交代码时，开发最在意的不是“你会不会写”，而是：

你有没有越界
你交付得清不清楚
他接手成本高不高

所以最有效的方式不是强调“我也会写代码”，而是证明：

边界清楚
文档清楚
质量稳定
返工少

7. 一套可直接复制的 Prompt 模板

7.1 通用开场

text

我是设计师，这次要负责 [页面/模块名] 的前端 UI 交付。
请先阅读项目里的约定文件，理解技术栈和限制。

这次的开发边界是：
- 只做 UI 层
- 所有数据都用 Mock
- 业务逻辑全部用 TODO 占位
- 只允许修改 [目录或文件范围]

请先告诉我：
1. 你理解到的页面目标
2. 还缺哪些信息
3. 建议的开发顺序

7.2 组件开发

text

请帮我实现 [组件名]。

输入信息：
- 设计稿截图见附图
- 数据使用 src/mock/[name].ts
- 状态包括：空状态 / 加载态 / 正常态 / 错误态

约束：
- 不接真实 API
- 不改动业务目录
- 写完后告诉我组件拆分是否合理

7.3 设计还原对比

text

这是设计稿截图，这是当前实现。
请你逐项对比并修正：
1. 间距
2. 字号与字重
3. 颜色、圆角、阴影
4. 元素对齐
5. 小屏宽度下的排版

不要整页推翻重写，优先做小步修正。

7.4 问题修复

text

[组件/页面名] 出现问题。

当前现象：
[描述现象]

预期效果：
[描述预期]

报错信息：
[完整报错]

请只修改相关文件，并告诉我：
1. 根因是什么
2. 你改了哪些地方
3. 还有什么需要我手动验证

7.5 交付文档生成

text

我已经完成了 [页面/模块名] 的静态 UI 开发。
请根据当前改动生成一份给开发的交付文档，包含：
1. 文件清单
2. TODO 占位点汇总
3. Mock 与真实接口替换对照
4. 需要重点验证的状态
5. 可直接粘贴到 PR 描述里的 Markdown

8. 在团队里怎么推进这条工作流

8.1 先选低风险试验项目

最适合起步的是：

内部工具
活动页
运营页面
非核心业务后台页

不要一开始就去碰主产品最复杂的业务链路。

8.2 先和一个开发建立协作关系

最容易成功的推进方式，不是一次说服整个团队，而是先找到一个愿意协作的开发。

对他来说：

少写重复的 UI 代码
更快进入接口和业务集成

对你来说：

获得技术反馈
获得团队背书
更容易把经验复制出去

8.3 用时间对比证明价值

推进这件事时，数据比口号有用得多。

建议记录：

原来设计稿到 UI 完成需要几天
现在设计师借助 Codex 做到可 review 前端代码需要几天
开发接手后返工次数是否减少

9. 常见坑和应对方法

9.1 开发觉得代码质量一般

不要强调“这是最终版”，而要说：

这是交付级 UI 初稿，请帮我 review 哪些地方更适合按团队规范调整。

9.2 团队担心你越界

要反复强调：

我只做 UI 层
不碰真实 API
不改业务架构
是为了减少重复劳动，不是替代开发

9.3 交付后容易背锅

这通常不是因为你写了 UI，而是因为边界没写清。

解决方式：

TODO 写清
文档写清
验收范围写清

9.4 AI 长对话后开始乱改

解决方式：

开新会话
重新贴上项目约定
只给当前阶段必要信息
不要一次塞多个任务

10. 推荐工具组合

工具	作用	在这条工作流里的位置
`Codex`	代码生成、拆解、修正、验证	核心协作代理
`Cursor / VS Code`	编辑器	日常开发环境
`Figma`	设计稿来源	视觉与结构输入
`Stitch`	界面方向探索	设计前期试错
`shadcn/ui`	组件基础	加快 UI 搭建
`Tailwind CSS`	样式表达	提高 AI 生成稳定性
`TypeScript`	类型定义	让 Mock 更规范
`Git + GitHub`	分支与交付	团队协作与 review

11. 这一页和本站其他内容怎么串起来

建议按下面的顺序学习：

先看 Figma 与 MasterGo 入门
再看这一页，建立设计师交付级工作流
然后看从设计原型到项目代码
如果要让 AI 直接读取设计上下文，再看 Figma MCP 与 Codex 协作实战

参考来源

本页基于公开页面主题重新整理，并结合本站 Codex 主线、课程风格和项目交付方式改写：

设计师 Vibe Coding 工作流

设计师工作流 ​

用 Codex 实现 ​

1. 这条工作流解决的是什么问题 ​

2. 黄金原则：只做 UI，不碰业务逻辑 ​

2.1 适合的场景 ​

2.2 不适合的场景 ​

3. 三阶段工作流总览 ​

4. 准备阶段：先把边界定住 ​

4.1 先确认自己负责什么 ​

4.2 准备项目约定文件 ​

4.3 跑起项目，建立最小循环 ​

5. 开发阶段：让设计稿变成可交付页面 ​

5.1 先让 Codex 帮你拆功能，不急着写代码 ​

5.2 先做 Mock 数据 ​

5.3 静态 UI 开发要按“三轮法” ​

第一轮：搭框架 ​

第二轮：补组件 ​

第三轮：加交互 ​

5.4 交互打磨要做“设计对比 + 极端数据测试” ​

设计稿对比 ​

极端情况测试 ​

5.5 主动做好业务逻辑占位 ​

6. 交付阶段：让开发愿意接你的成果 ​

6.1 推送前 Checklist ​

6.2 每次交付走独立分支 ​

6.3 交付文档必须一起给 ​

6.4 建立信任的关键 ​

7. 一套可直接复制的 Prompt 模板 ​

7.1 通用开场 ​

7.2 组件开发 ​

7.3 设计还原对比 ​

7.4 问题修复 ​

7.5 交付文档生成 ​

8. 在团队里怎么推进这条工作流 ​

8.1 先选低风险试验项目 ​

8.2 先和一个开发建立协作关系 ​

8.3 用时间对比证明价值 ​

9. 常见坑和应对方法 ​

9.1 开发觉得代码质量一般 ​

9.2 团队担心你越界 ​

9.3 交付后容易背锅 ​

9.4 AI 长对话后开始乱改 ​

10. 推荐工具组合 ​

11. 这一页和本站其他内容怎么串起来 ​

参考来源 ​

设计师工作流

用 Codex 实现

1. 这条工作流解决的是什么问题

2. 黄金原则：只做 UI，不碰业务逻辑

2.1 适合的场景

2.2 不适合的场景

3. 三阶段工作流总览

4. 准备阶段：先把边界定住

4.1 先确认自己负责什么

4.2 准备项目约定文件

4.3 跑起项目，建立最小循环

5. 开发阶段：让设计稿变成可交付页面

5.1 先让 Codex 帮你拆功能，不急着写代码

5.2 先做 Mock 数据

5.3 静态 UI 开发要按“三轮法”

第一轮：搭框架

第二轮：补组件

第三轮：加交互

5.4 交互打磨要做“设计对比 + 极端数据测试”

设计稿对比

极端情况测试

5.5 主动做好业务逻辑占位

6. 交付阶段：让开发愿意接你的成果

6.1 推送前 Checklist

6.2 每次交付走独立分支

6.3 交付文档必须一起给

6.4 建立信任的关键

7. 一套可直接复制的 Prompt 模板

7.1 通用开场

7.2 组件开发

7.3 设计还原对比

7.4 问题修复

7.5 交付文档生成

8. 在团队里怎么推进这条工作流

8.1 先选低风险试验项目

8.2 先和一个开发建立协作关系

8.3 用时间对比证明价值

9. 常见坑和应对方法

9.1 开发觉得代码质量一般

9.2 团队担心你越界

9.3 交付后容易背锅

9.4 AI 长对话后开始乱改

10. 推荐工具组合

11. 这一页和本站其他内容怎么串起来

参考来源