十年设计师的 AI 提效手册：从 PRD 到工程交付

在各家大模型能力突飞猛进的今天，设计师的交付终点，是否依然只能停在设计稿上？

在本次实践之前， AI 在我工作流中的地位，大多也是用来发散灵感和辅助出图。但实际交付物只要还是设计稿，即使有 Figma Dev Mode，样式对不齐反复走查的链路也一直存在，根本谈不上所谓的提效。

打破这种断层的关键是把交付边界直接推进到工程里，依托现有的组件库与规范，让 AI 直接生成 React 页面代码。设计师在浏览器里调好细节与交互，交付物就升级成是一个跑通业务需求的代码分支。

这篇文章就拿我最近做的一个马来西亚项目订单退款审核业务场景为例，聊聊如何使用 Codex 跑通从需求到工程交付的闭环。

一、需求落地流程

整个过程分五步：理清项目规范 → 仓库与分支 → 理解业务 → 生成与验收 → 推送并交付。

1. 理清项目规范

工程化设计不是关起门来画图，它从第一步起就依赖实际代码。开工前，先找前端对齐三项基础资料：

Figma 里的组件用来画设计稿，工程里的代码组件则承载真实的状态与响应。两边底层遵循同一套规范，关键是让 AI 知道具体代码放哪里并能随时调用。

在 Codex 中打开项目文件夹，让它先根据你拿到的项目资料理清可用资产：

阅读项目代码和组件文档，对照提供的设计规范，整理退款审核页可以复用的组件，以及布局、颜色、字号和间距要求。将这些内容与对应文档位置保存为 design-rules.md，供后续设计使用。

整理出的文档应当明确交代：表单页使用项目里的哪些组件，详情沿用哪种布局以及文字和状态颜色按哪份规范执行等等。我们作为设计师再确认一遍，看它和现有产品是否一致。

2. 准备代码仓库，创建本次设计分支

第一步完成后，让 Codex 用这份基础代码建立代码仓库，再创建一个叫 refund-review 的设计分支。

 用这份基础代码建立设计仓库，创建 refund-review 分支，启动项目并给出预览地址

打开 Codex 给出的预览地址，确认基础页面能正常显示。

3. 确认 AI 理解了业务

把本次需求的 PRD 交给 Codex。先确认它是否理解了业务全貌，再让它整理保存。

先梳理这份需求的业务流程、页面信息和状态变化，有不清楚的地方问我。等我确认后，保存为 refund-review-prd.md，再开始设计。

我在本次案例中的需求如下。

设计师在这个节点的任务是重点核对业务关系。比如审核通过以后，显示的是审核结果，不能直接写成退款已经到账。把这些关系确认清楚，再开始设计。

4. 确定页面结构，指导 AI 生成

业务理顺后，使用我们设计师熟悉的推导思路，开始主导界面的信息架构：

业务流程 → 页面框架 → 组件使用 → 全局样式。

按确认后的 PRD 制作退款审核页。上方筛选、下方列表，点击查看详情打开右侧抽屉。详情按申请信息、订单与商品、退款原因与凭证、审核记录分组，底部根据状态显示操作或结果。

把这次确定的页面结构补入 design-rules.md，沿用项目组件和样式。生成时分别对照 PRD 和设计规则检查，修正问题后说明检查结果，启动页面并给出预览地址。

生成代码时，AI 会同时执行两项校验：先查业务字段和操作条件是否齐全，再查组件使用和样式规范是否违规。

检查无误后，打开本地预览地址，开始验收。

这里按照需求的业务流程操作一遍。如果遇到交互断点，直接指出位置和预期结果让 AI 修正。

5. 把页面和代码交给研发

页面验收通过后，让 Codex 把最终内容推送到团队代码仓库的设计分支，再按项目流程构建。

提交并推送本次设计分支，按项目约定完成构建和预览交付。给出同事可以访问的页面地址、代码仓库地址和分支名称，并说明构建结果。

研发拿到的是一个可交互的预览地址，以及一份 Git 分支代码。前端同事只需拉取分支，在现有 UI 结构上补齐真实接口与鉴权逻辑，即可快速完成上线。

二、AI 真的帮我提效了吗？

现在这套工作流把页面的基础搭建以及状态联动与代码调试交由 AI 执行。设计师负责界定业务逻辑与体验规则，在真实体验中校准细节；前端则顺着这份带有完整结构的代码，补齐业务数据与真实接口。

即使在设计系统高度成熟的团队里，设计稿与工程之间依然存在可观的损耗，因此，结构规整的页面，高度标准化的组件和样式，天然适合让 AI 辅助提效：

• 减少标准页面的手工搭建： 在我的实践中，退款审核这类典型的中后台页面，本质是由表格、筛选区和抽屉构成的容器。AI 按照需求直接从项目代码库中调用现成组件完成拼装，顺手把必要的交互逻辑写好。作为设计师，不必再机械地堆叠组件和调整状态变体，精力得以完整回归到业务流程与交互体验本身。

• 大幅缩短迭代周期： 在常规的工作流中，设计师在 Figma 中完成一个需求，往往需要等研发排期，发布测试环境后才能看到真实效果。现在，设计师指出调整方向，AI 直接修改代码，在设计阶段就能当场改好并验收，免去了跨职能来回确认的沟通成本。

• 设计成果直接沉淀为工程资产： 页面布局与交互逻辑，从一开始就写在项目的分支代码里。交付内容从静态设计稿直接升级成具备完整结构与交互响应的代码基底。设计与研发围绕同一份工程向前推进，免去了从设计稿到代码的二次搭建过程。

三、如何稳定 AI 生成的页面质量？

为了让AI 生成就有明确的依据，设计师验收时也有清晰的排查路径，我们把设计规范拆分为业务流程、页面框架、组件使用、全局样式四个层次：

规范借由业务不断完善，系统产出的质量才能随着时间真正稳定下来。

四、把已跑通的流程沉淀成 Skill

设计交付过程跑通后，沉淀下来的规则可以整理成两份 Skill：Design Skill 负责界面表达，SOP Skill 负责工程推进。

• Design Skill ：沉淀页面模板、组件用法、布局间距与特定业务规则。下次生成页面时，AI 直接沿用这套既定约束，避免每次重新交代规范。

• SOP Skill ：和研发一起把环境检查、切分支、启动预览、构建与交付的标准步骤固化下来。AI 照章执行工程动作，设计师不必每次重新梳理命令行操作。

五、余论：UX设计师的未来之路

长期以来，设计和开发泾渭分明。设计在 Figma 里表达意图，前端在工程里理解意图。成熟的 Design System 确实往前推了一大步，但一份高保真设计稿，依然是大部分设计工作的交付终点。

当工程资产接入大模型后，这道分工的缝隙被填平了。底层组件和规范一旦理顺，很多常规的软件工作都可以直接生成。这也意味着，设计师的价值开始自然地向两端移动。

往前看，是走到界面之前，把业务规则吃透。

当界面生成门槛降低，设计师的差距就开始体现在规则制定上。过去我们先在 Figma 中把主干画完，再去补充分支状态；往后这个顺序大概率要反过来，先把规则和状态彻底理顺，界面不过是它自然显现的外壳。

往后看，是走到界面之后，直接对运行态负责。

过去设计师往往要等开发实现后，再进入走查阶段。借助 Agent，在本地拉起工程，极大提高了设计走查效率和迭代周期。

这当然不是鼓吹设计师都要转型为全栈开发，但常规的工作边界也很难再站得住脚。当设计师已经有能力直接看到最终结果，就很难再把工作的终点停留在设计稿上。

设计规范也正在从给人看的文档，演变成给 AI 执行的规则

过去做 Design System，整理组件、Token、使用说明和交互规范，主要作用是让团队里的人理解并保持视觉一致。现在这些规则直接进入了 Agent 的上下文，变成了 AI 执行时的硬性约束。

所以，AI 对设计行业真正深远的影响，从来就不是什么谁取代谁的陈词滥调。只会画图的人，价值一定会越来越薄；真正稀缺的，会是那些既能理解业务，定义规则，又能借助 AI 把设计一路推进到产品中的人。

设计师未必要成为工程师，但一定会比以往任何时候，都更接近业务本身。

感谢看到这里。

@Lucian_Lc7，UX设计师，记录 AI 使用方法、副业变现实操。