从 PRD 到可运行应用：我用 GPT、Stitch、Figma 和 Codex 跑通了一套 AI 协同开发流程

食用指南

注意：该方法仅适合T型人才，需要开发者或者设计师懂一些设计或者开发，当然如果设计开发都会的话将事半功倍

最近我尝试把 AI 深度接入到一个真实应用的开发流程里。

这篇文章不讨论"AI 能不能一句话生成应用"这种表面问题，而是记录一套更接近实际生产的流程：

先用 GPT 梳理需求和 PRD，再用 Stitch 快速生成 UI 方向，然后导入 Figma 做高保真优化，最后把设计稿和开发文档交给 Codex，让它基于完整上下文输出开发计划并执行实现。

我的结论很直接：

AI 开发的关键不是让 AI 自由发挥，而是人先把需求、设计、约束和验收标准讲清楚，再让 AI 在明确边界内执行。

---

1. 为什么我没有直接让 Codex 写代码

很多人使用 AI 编程工具时，第一步就是直接输入：

帮我做一个应用。

这类提示词最大的问题是上下文太少。

AI 确实可能生成一个看起来能跑的项目，但它通常会出现几个问题：

1. 页面结构不清晰；
2. 业务边界模糊；
3. 数据字段随意设计；
4. 样式和交互缺少统一标准；
5. 后续修改成本很高；
6. 代码结构可能一开始就偏掉。

所以我没有一开始就让 Codex 写代码。

我先把整个开发流程拆成几个阶段：

需求定义

↓

PRD 文档

↓

UI 初稿生成

↓

Figma 高保真优化

↓

设计稿进入项目目录

↓

Codex 读取上下文

↓

Codex 输出开发计划

↓

人工审查计划

↓

Codex 分阶段实现

↓

人工验收和返工

这套流程的核心不是"自动化"，而是"上下文工程"。

---

2. 第一步：用 GPT 把需求压实成 PRD

我不会直接对 AI 说"做一个应用"。

我会先用 GPT 把需求整理成 PRD。

PRD 至少要包含这些内容：

1. 项目背景；
2. 核心目标；
3. 用户角色；
4. 页面结构；
5. 核心流程；
6. 数据字段；
7. 状态变化；
8. 操作边界；
9. 异常情况；
10. 技术约束；
11. 验收标准。

一个比较实用的 PRD 结构如下：

2.1 项目背景

说明这个应用为什么要做，它解决什么问题。

2.2 核心目标

列出这个应用最重要的 3 到 5 个目标。

2.3 用户角色

说明谁会使用这个应用，不同角色分别做什么。

2.4 页面结构

列出所有页面，例如：

1. 首页；
2. 操作页；
3. 结果页；
4. 管理页；
5. 记录页；
6. 设置页。

2.5 核心流程

描述用户从进入应用到完成主要操作的完整路径。

2.6 数据结构

列出核心数据字段，例如：

1. id；
2. name；
3. status；
4. image；
5. createdAt；
6. updatedAt。

2.7 业务规则

说明哪些行为允许，哪些行为不允许。

2.8 异常情况

例如：

1. 数据为空时如何展示；
2. 操作失败时如何反馈；
3. 本地数据丢失时如何处理；
4. 图片加载失败时如何兜底。

2.9 技术要求

例如：

1. 是否需要离线运行；
2. 是否需要本地存储；
3. 是否需要跨平台；
4. 是否需要打包成桌面应用；
5. 是否需要适配固定屏幕比例。

2.10 验收标准

说明做到什么程度才算完成。

PRD 的价值不是形式，而是让 AI 不再靠猜。

---

3. 第二步：用 Stitch 快速生成 UI 方向

PRD 完成后，我会把核心页面和视觉要求交给 Stitch，让它生成 UI 初稿。

Stitch 的价值不在于直接替代设计师，而在于快速跳过空白画布阶段。

它适合做：

1. 页面结构探索；
2. 视觉方向探索；
3. 组件布局尝试；
4. 多方案快速发散；
5. 快速形成可讨论的界面草稿。

但它也有明显限制：

1. 中文排版不一定稳定；
2. 细节层级可能不合理；
3. 图标和装饰元素可能偏随机；
4. 组件规范不一定统一；
5. 生成结果看起来像设计稿，但不一定能直接开发。

所以 Stitch 生成的东西，我一般只把它当作 UI 方向参考，而不是最终设计稿。

---

4. 第三步：导入 Figma 做高保真优化

如果 Stitch 生成的方向可用，我会导入 Figma 继续优化。

Figma 阶段主要处理这些问题：

1. 信息层级是否清楚；
2. 主按钮是否足够突出；
3. 页面是否符合实际操作场景；
4. 字体、颜色、圆角、阴影是否统一；
5. 不同页面之间是否有一致的组件语言；
6. 页面状态是否完整；
7. 空状态、加载状态、异常状态是否有设计；
8. 是否方便后续开发还原。

这一步是 AI 很难完全替代人的地方。

AI 能生成"看起来不错"的界面，但它不一定知道：

1. 哪个信息应该最优先出现；
2. 哪个按钮才是主操作；
3. 哪些状态必须补齐；
4. 哪些视觉细节会影响真实使用；
5. 哪些设计会增加开发成本。

所以 Figma 阶段不是简单修图，而是把 AI 的视觉草稿改成可以进入开发的高保真设计稿。

---

5. 第四步：把设计稿放进项目目录

设计稿完成后，我不会只把它留在 Figma 里。

我会把关键高保真页面导出成图片，放进项目目录中的固定文件夹。

例如项目结构可以这样组织：

1. docs：存放 PRD、开发计划、页面说明等文档；
2. design：存放首页、操作页、结果页、管理页等高保真截图；
3. src：存放实际源码；
4. README.md：说明项目基本信息；
5. package.json：说明依赖和运行脚本。

这样做有几个好处：

1. Codex 可以直接读取设计稿；
2. 文档、设计和代码处在同一个上下文里；
3. 后续修改时不用反复口头描述界面；
4. AI 可以同时参考 PRD、README、项目结构和 UI 图片；
5. 项目交接时更清楚。

这个动作可以理解为：

把设计稿变成开发上下文。

很多 AI 开发失败，不是因为 AI 不会写代码，而是因为它拿不到足够清楚的上下文。

---

6. 第五步：让 Codex 先输出开发计划

设计稿和文档准备好之后，我不会立刻让 Codex 改代码。

我会先让它读取：

1. PRD 文档；
2. README；
3. 项目结构；
4. 高保真 UI 设计图；
5. 当前技术栈；
6. 现有代码；
7. 页面路由；
8. 数据结构；
9. 打包配置。

然后让它先输出开发计划。

我通常会这样要求：

请先不要修改代码。

先读取当前项目结构、README、PRD 文档和 design 文件夹中的高保真 UI 设计图。

然后输出一份开发计划，内容包括：

1. 你理解到的项目目标；
2. 当前项目已有结构；
3. 需要新增或修改的页面；
4. 需要新增或修改的组件；
5. 需要设计的数据结构；
6. 需要注意的技术边界；
7. 分阶段开发步骤；
8. 每个阶段的验收标准。

在我确认开发计划之前，不要开始写代码。

这一步非常重要。

因为 AI 写错代码不是最危险的。

真正危险的是：

AI 在错误理解需求的基础上，写出一套看似合理但方向完全偏掉的代码。

先看开发计划，就是为了提前拦截这种问题。

---

7. 第六步：监管 Codex 分阶段开发

开发计划确认后，我会让 Codex 分阶段执行，而不是一次性全部做完。

比较稳的节奏是：

1. 第一阶段：搭建页面结构和路由；
2. 第二阶段：完成静态 UI 还原；
3. 第三阶段：接入本地数据结构；
4. 第四阶段：实现核心业务流程；
5. 第五阶段：补齐异常状态和空状态；
6. 第六阶段：做样式细节修正；
7. 第七阶段：本地运行测试；
8. 第八阶段：打包和验收。

每个阶段结束后，我会检查：

1. 是否破坏原有项目结构；
2. 是否引入不必要的依赖；
3. 是否按设计稿还原；
4. 是否把数据写死；
5. 是否方便后续维护；
6. 是否存在重复代码；
7. 是否有明显样式污染；
8. 是否符合技术栈约定；
9. 是否完成当前阶段目标，而不是擅自扩展。

这里的关键是：

不要把 Codex 当成全自动开发者，而是把它当成一个需要管理的执行单元。

它可以很快，但不能放任。

---

8. 这套流程的优点

这套流程最大的优点是稳定。

不是结果一定完美，而是每一步都有可检查的产物。

1. PRD 可以检查需求是否清楚；
2. UI 初稿可以检查视觉方向是否可行；
3. Figma 可以检查设计是否能落地；
4. 设计稿入仓可以增强 AI 上下文；
5. 开发计划可以检查 Codex 是否理解正确；
6. 分阶段开发可以降低失控概率；
7. 人工验收可以保证最终质量。

这比直接让 AI 写代码更可控。

它的本质不是"让 AI 替我完成所有事情"，而是把 AI 放进一个明确的生产流程里。

---

9. 这套流程的限制

这套流程不是万能的。

它也有明显限制。

9.1 前期文档成本更高

如果只是做一个非常小的 Demo，写 PRD、整理设计稿、输出开发计划可能显得麻烦。

但如果是一个要长期维护、要交付、要反复迭代的应用，这些前期成本是值得的。

9.2 AI 仍然会误解设计稿

Codex 可以读取图片，但它不一定能 100% 理解设计细节。

例如：

1. 间距可能不准确；
2. 字体层级可能偏差；
3. 阴影和渐变可能还原不到位；
4. 组件状态可能漏掉；
5. 装饰元素可能被简化。

所以 UI 还原阶段仍然需要人工审查。

9.3 AI 容易过度开发

有时候只是需要一个简单功能，AI 可能会主动加入复杂封装。

例如：

1. 过度抽象组件；
2. 引入多余状态管理；
3. 创建不必要的工具函数；
4. 写出看似专业但维护成本更高的结构。

这类问题必须人工拦截。

9.4 人仍然必须懂基本技术判断

如果完全不懂项目结构、不懂前端、不懂数据流，很难判断 Codex 写出来的东西是否合理。

AI 可以降低实现门槛，但不能取消判断门槛。

---

10. 我的最终判断

这套流程跑下来，我对 AI 开发的判断是：

AI 开发不是从"写代码"开始的，而是从"提供上下文"开始的。

PRD 是上下文。

设计稿是上下文。

README 是上下文。

项目结构是上下文。

数据字段是上下文。

验收标准也是上下文。

如果这些东西不清楚，AI 就只能猜。

如果这些东西足够清楚，AI 就可以从一个随机生成器，变成一个可被管理的执行单元。

所以我现在更倾向于把 AI 开发理解为：

不是用一句提示词生成应用，而是用一套流程管理 AI，把需求、设计和代码串成连续的生产链路。

这也是我认为目前更现实、更可靠的 AI 协同开发方式。