如何让AI根据PRD生成代码

PRD 写得好不好，直接决定了 AI 生成的代码质量

很多人有一个误解：觉得 AI 编程工具足够聪明，只要把需求大致描述一下，它就能自动把整个功能做出来。实际操作下来，你会发现结果往往不尽人意——AI 生成的代码要么偏离了业务逻辑，要么遗漏了关键的边缘情况，要么自作主张加了一堆你不需要的功能。

问题的根源通常不在 AI 工具本身，而在于你给 AI 的输入质量不够。这个输入，核心就是你的 PRD（Product Requirements Document，产品需求文档）。

传统 PRD 是写给人看的。人类读者遇到模糊的地方会「脑补」，会结合上下文做出合理推断，甚至会主动来找你确认。AI 不一样。AI 严格按字面意思理解你的每一句话，不会脑补，不会推断，不会主动确认。如果你的 PRD 写了「用户可以添加任务」，AI 不会自动帮你考虑「添加失败怎么办」「重复添加怎么办」「空列表怎么展示」。这些你没写的东西，AI 要么忽略，要么按自己的理解随意发挥。

这意味着，在 AI 编程时代，PRD 的写作方式需要升级。你要学会用「AI 能理解」的方式来组织需求文档，把 PRD 从「给人看的叙述文」变成「给 AI 看的规格说明」。

本文会系统地讲清楚四件事：

1. AI 视角的 PRD 应该怎么写
2. 如何把 PRD 转化成 AI 能高效执行的 Prompt
3. 分步生成代码的策略——为什么不能一次生成整个项目
4. AI 生成代码之后的校验和修正流程

AI 视角的 PRD 应该怎么写

给人看的 PRD 和给 AI 看的 PRD，区别在哪里

传统 PRD 侧重讲「为什么做」和「做什么」，包含大量背景说明、业务分析、竞品对比。这些内容对人类决策很有价值，但对 AI 生成代码来说，大部分是噪音。AI 需要的是明确的「做什么」和「怎么做」，是不留模糊空间的规格描述。

给 AI 的 PRD 需要包含哪些结构

一份面向 AI 的 PRD，建议包含以下核心模块：

1. 项目概述（一段话）

用 2-3 句话说清楚这是什么产品、核心功能是什么、目标用户是谁。不需要商业分析和市场背景。

## 项目概述
一个面向自由职业者的时间追踪工具。核心功能：开始/暂停计时、
按项目分类记录时间、生成周报。目标用户是同时服务多个客户的
独立咨询师。

2. 技术栈约束

明确告诉 AI 用什么技术，不要让 AI 自己选。

## 技术栈
- 前端：Next.js 15 + TypeScript + Tailwind CSS
- 状态管理：Zustand
- 后端：Next.js API Routes
- 数据库：SQLite（本地存储，无需后端服务）
- 图表：Recharts

3. 数据模型

用表格或伪代码定义核心数据结构。这是 AI 生成代码时最重要的参考。

## 数据模型
 
### Project（项目）
| 字段 | 类型 | 说明 |
|------|------|------|
| id | string (UUID) | 唯一标识 |
| name | string | 项目名称，最长 50 字符 |
| color | string (hex) | 项目标识颜色，默认 #3B82F6 |
| createdAt | ISO 8601 | 创建时间 |
 
### TimeEntry（时间记录）
| 字段 | 类型 | 说明 |
|------|------|------|
| id | string (UUID) | 唯一标识 |
| projectId | string | 关联项目 ID |
| startTime | ISO 8601 | 开始时间 |
| endTime | ISO 8601 \| null | 结束时间，null 表示进行中 |
| note | string | 备注，可为空，最长 200 字符 |

4. 功能规格（逐个功能拆解）

每个功能要写清楚：输入、输出、状态变化、边缘情况。

## 功能规格
 
### F1: 开始计时
- 触发：用户点击「开始」按钮，选择一个项目
- 行为：创建一条 TimeEntry，startTime 为当前时间，endTime 为 null
- 状态变化：
  - 按钮变为「暂停」状态
  - 页面顶部显示计时器，格式 HH:MM:SS，每秒更新
  - 如果已有进行中的计时，先自动结束上一条（endTime = 当前时间）
- 边缘情况：
  - 切换浏览器标签后回来，计时器要准确（用 startTime 计算，不靠 setInterval 累加）
  - 页面刷新后，进行中的计时要恢复
 
### F2: 生成周报
- 触发：用户点击「生成周报」
- 输入：自动选择当前周（周一 00:00 到周日 23:59）
- 输出：按项目分组，显示每个项目的总时长和占比
- 空状态：如果本周没有任何记录，显示「本周暂无记录」

5. 不做清单（Out-of-Scope）

这一项非常关键。不写的话，AI 可能自作主张加功能。

## Out-of-Scope（不做）
- 不做用户注册/登录（纯本地应用）
- 不做多设备同步
- 不做项目归档功能
- 不做移动端适配（仅桌面端）

PRD 写作的五个原则

原则一：具体胜于抽象。 不要说「界面要简洁美观」，要说「白色背景、灰色卡片、按钮圆角 8px、主色调蓝色 #3B82F6」。抽象形容词对 AI 没有指导意义。

原则二：状态变化要完整描述。 用「初始状态 → 触发条件 → 中间状态 → 最终状态」的格式。按钮点击后是「立即禁用 → 显示 loading → 成功后恢复 / 失败后显示错误提示」，而不是简单的「点击后提交」。

原则三：默认值必须写明。 列表默认显示多少条？排序按什么规则？空状态显示什么文字？这些细节 AI 不会帮你决定，你不写它就随机选一个。

原则四：用优先级标注功能。 用 P0（必须实现）、P1（应该实现）、P2（可以后续迭代）标注。否则 AI 可能把 P2 功能做得比 P0 还精细。

原则五：用 Mermaid 流程图代替长段文字。 AI 能准确理解 Mermaid 语法，比自然语言描述更不容易产生歧义。

把 PRD 转化为 AI Prompt 的方法

PRD 写好了，不能直接整篇丢给 AI 说「帮我实现」。你需要一个转化过程，把 PRD 的结构化内容变成 AI 能高效执行的 Prompt。

Prompt 的基本框架

一个有效的代码生成 Prompt 通常包含五个部分：角色设定、上下文、任务指令、约束条件、输出格式。

## Prompt 模板
 
你是一个 TypeScript 全栈开发工程师，熟悉 Next.js 15 App Router、
Zustand 和 Tailwind CSS。
 
### 上下文
我正在构建一个时间追踪工具。以下是核心数据模型：
[粘贴数据模型部分]
 
### 任务
请实现「开始计时」功能（对应 PRD 中的 F1）。
 
### 约束
- 使用 Zustand store 管理计时状态
- 计时器精度依赖 startTime 计算，不靠 setInterval 累加
- 组件文件放在 src/components/timer/ 目录下
- 不要实现登录、同步等 Out-of-Scope 功能
 
### 输出格式
1. 先给出你的实现方案（文件结构、关键函数签名）
2. 我确认后再输出完整代码

不同工具的 Prompt 适配

Prompt 链式策略

不要试图用一个 Prompt 完成所有工作。用「链式 Prompt」逐步推进：

第一步：确认理解。 让 AI 先复述它理解的需求，检查是否有偏差。

请阅读以下 PRD，用你自己的话复述你对这个项目的理解：
1. 核心功能有哪些？
2. 数据模型是什么？
3. 有哪些边缘情况需要处理？
4. 哪些功能是不需要做的？

第二步：输出方案。 让 AI 先给出技术方案，不要直接写代码。

基于以上 PRD，请给出你的技术实现方案：
1. 文件结构设计
2. 核心状态管理方案
3. 关键函数的签名和职责
4. 你预见的技术难点

第三步：确认方案后再生成代码。 逐模块生成，一个功能确认后再做下一个。

方案确认。请先实现数据模型和 Zustand store，
包括 TypeScript 类型定义和基础的 CRUD 操作。
完成后再实现 UI 部分。

分步生成策略：不要一次生成整个项目

为什么不能一次生成

很多人满怀期待地把完整 PRD 丢给 AI，然后说「帮我实现这个项目」。AI 确实会输出一大段代码，但这些代码往往存在以下问题：

• 不同模块之间的接口定义不一致
• 状态管理方案前后矛盾
• 边缘情况被大量遗漏
• 代码风格不统一
• 关键逻辑有方向性错误，返工量大

根本原因是：AI 的注意力是有限的。一次生成的内容越多，每个细节分配到的注意力就越少。这就像让一个程序员同时写 20 个功能——他一定会漏掉很多东西。

分步生成的四层策略

每一层完成之后，都要验证通过，再进行下一层。不要跳层。

分步生成的具体操作

以一个「用户注册」功能为例，分步过程如下：

第一步：数据模型

请根据以下 PRD 实现数据模型：
 
### User 模型
| 字段 | 类型 | 约束 |
|------|------|------|
| id | string (UUID) | 主键 |
| email | string | 唯一，格式校验 |
| passwordHash | string | bcrypt 哈希 |
| name | string | 2-50 字符 |
| createdAt | ISO 8601 | 自动生成 |
 
请输出：
1. TypeScript interface 定义
2. 数据库 schema（使用 Prisma）
3. email 格式校验函数

第二步：核心逻辑

数据模型确认。请实现注册的核心逻辑：
 
1. register(email, password, name) 函数
2. 密码哈希使用 bcrypt，cost factor 12
3. 邮箱重复时抛出自定义错误 DuplicateEmailError
4. 密码强度要求：8 位以上，包含大小写和数字
5. 返回创建的用户对象（不含 passwordHash）
 
不要实现 HTTP 层，只写业务逻辑。

第三步：UI 组件

核心逻辑确认。请实现注册页面的 UI：
 
1. 表单字段：邮箱、密码、确认密码、用户名
2. 前端校验：实时显示格式错误（红色文字提示在字段下方）
3. 提交按钮：提交中显示 loading 状态并禁用
4. 成功：跳转到 /dashboard
5. 失败：显示后端返回的错误信息（toast 形式）
6. 使用 Tailwind CSS，参考现有的登录页样式

第四步：集成和边缘情况

请补充以下边缘情况处理：
1. 网络断开时提交，显示「网络错误，请重试」
2. 快速双击提交按钮，只发送一次请求
3. 注册成功后，自动登录，不需要再次输入
4. 密码字段支持显示/隐藏切换

AI 生成代码的校验流程

AI 生成了代码，不代表代码就是对的。你需要一个系统化的校验流程，确保生成的代码符合 PRD 的要求。

校验的四个层次

第一层：编译检查。 代码能不能跑起来？TypeScript 有没有类型错误？依赖包有没有装？这一步是基础，但 AI 生成的代码经常在这一步就出问题——比如引用了不存在的包、使用了错误的 API。

第二层：PRD 对照检查。 逐条对照 PRD 中的功能规格，检查每一条要求是否都被实现了。这一步可以用一个清单来完成：

## PRD 对照检查清单
- [ ] F1: 开始计时功能
  - [ ] 点击开始后，创建 TimeEntry
  - [ ] 已有进行中计时，自动结束上一条
  - [ ] 计时器每秒更新，精度依赖 startTime
  - [ ] 页面刷新后恢复进行中的计时
- [ ] F2: 生成周报
  - [ ] 按项目分组显示总时长
  - [ ] 本周无记录时显示空状态

第三层：运行时验证。 在浏览器里实际操作，看功能是否正常。重点关注：交互是否符合预期、状态变化是否正确、UI 是否符合设计。

第四层：边缘情况测试。 故意做一些「不正常」的操作：快速连点按钮、输入超长文本、断网后操作、刷新页面。检查 AI 是否处理了这些情况。

发现问题后怎么修正

发现 AI 生成的代码有问题，不要直接手动改代码——除非只是一个简单的 typo。正确的做法是修正你的 Prompt，让 AI 重新生成。原因很简单：如果你手动改了代码，下次 AI 基于旧代码继续生成时，它不知道你已经改了什么，可能会产生新的冲突。

修正 Prompt 的方法：

你生成的 RegisterForm 组件有以下问题：
 
1. 密码强度校验缺少「包含特殊字符」的要求
   → PRD 中的要求是：8 位以上，包含大小写字母、数字和特殊字符
2. 提交按钮在 loading 状态下仍然可以点击
   → PRD 中明确要求：提交中禁用按钮
3. 错误提示用的是 alert，应该用 toast
   → 项目中统一的错误提示方式是 sonner toast
 
请修正以上问题，保持其他代码不变。

关键技巧：引用 PRD 原文。不要用自己的话重新描述需求（那样可能引入新的歧义），直接引用 PRD 中的原话，告诉 AI 它生成的代码和 PRD 哪里不一致。

常见问题和解决方案

问题一：AI 生成的代码和 PRD 不一致

这是最常见的问题。原因通常是以下几种：

问题二：AI 自作主张加了不需要的功能

比如你只要求做一个简单的表单，AI 顺手加了表单验证库、国际化支持、暗黑模式。

解决方案：在 PRD 和 Prompt 中明确写出 Out-of-Scope 清单。如果 AI 还是加了多余功能，在修正 Prompt 中明确说「不要实现 XX 功能，这在 Out-of-Scope 清单中」。

问题三：AI 生成的代码风格不统一

前面生成的组件用函数式写法，后面的用 class 组件；有些地方用了 async/await，有些地方用了 Promise.then。

解决方案：在项目的全局配置文件（如 .cursorrules、CLAUDE.md）中写明代码风格约束，或者在第一个 Prompt 中就声明代码风格：

代码风格约束：
- 使用函数式组件，不使用 class 组件
- 异步操作统一使用 async/await
- 变量命名使用 camelCase
- 常量命名使用 UPPER_SNAKE_CASE
- 每个文件只导出一个主要组件

问题四：PRD 要写多详细才够

一个实用的判断标准：如果 AI 读完 PRD 之后，还需要问你「这个按钮放哪里」「失败时显示什么」「数据要保存多久」这类问题，说明 PRD 还不够详细。

但你也不需要写到伪代码级别。PRD 的详细程度应该让 AI 能做出正确的实现决策，而不需要猜测。业务规则、数据约束、状态流转、边缘情况必须详细；CSS 样式细节、动画参数可以在 UI 层 Prompt 中补充。

问题五：可以让 AI 边写代码边补充 PRD 吗

不推荐。这种做法会导致 PRD 和实际代码不同步，后续维护和迭代时会很混乱。正确的流程是：先把 PRD 写到足够详细，再开始让 AI 生成代码。如果生成过程中发现 PRD 遗漏了什么，先暂停代码生成，补充 PRD，再继续。

实战案例

案例一：用 PRD 让 AI 生成用户注册模块

背景： 一个 SaaS 产品的用户注册功能，技术栈是 Next.js + Prisma + PostgreSQL。

PRD 关键内容：

## 功能：用户注册
 
### 数据模型
| 字段 | 类型 | 约束 |
|------|------|------|
| id | string (UUID) | 主键，自动生成 |
| email | string | 唯一，标准邮箱格式 |
| passwordHash | string | bcrypt 哈希 |
| displayName | string | 2-30 字符，不允许特殊符号 |
| status | enum | 'active' \| 'unverified'，默认 'unverified' |
| createdAt | ISO 8601 | 自动生成 |
 
### 业务规则
1. 邮箱已被注册时，返回友好提示「该邮箱已注册，请直接登录」
2. 密码要求：8-64 位，包含大小写字母和数字
3. 注册成功后发送验证邮件（邮件发送失败不阻塞注册）
4. 注册成功后自动登录，跳转到 /dashboard
 
### 前端规格
1. 表单字段：邮箱、密码、确认密码、昵称
2. 实时校验：邮箱格式、密码强度、两次密码一致性
3. 提交中：按钮 loading 状态，禁用所有字段
4. 错误显示：字段级错误在输入框下方红色文字，全局错误用 toast
 
### Out-of-Scope
- 不做第三方登录（Google/GitHub）
- 不做手机号注册
- 不做验证码（后续迭代）

分步生成过程：

第一步，让 AI 生成数据模型和类型定义。确认 Prisma schema 和 TypeScript interface 都符合 PRD 的数据模型要求。

第二步，生成注册的业务逻辑。Prompt 中明确引用 PRD 中的业务规则，要求 AI 先输出函数签名和错误处理方案。确认后再输出完整代码。

第三步，生成注册表单组件。Prompt 中引用 PRD 的前端规格，包括校验规则、状态变化、错误显示方式。

第四步，补充边缘情况：网络错误处理、重复提交防护、邮件发送失败的降级逻辑。

每一步都对照 PRD 验证，全部通过后才进入下一步。整个过程大约需要 4-5 轮对话，最终生成的代码覆盖率约 85%，剩余 15% 是手动微调（主要是样式细节）。

案例二：用 PRD 让 AI 生成数据看板

背景： 一个内部管理系统的数据看板页面，需要展示用户增长趋势、收入统计和活跃度。

PRD 关键内容：

## 功能：数据看板
 
### 页面布局
- 顶部：4 个统计卡片（总用户数、今日新增、本月收入、日均活跃）
- 中部左：用户增长趋势折线图（最近 30 天）
- 中部右：收入趋势柱状图（最近 12 个月）
- 底部：活跃度日历热力图（最近 90 天）
 
### 数据接口
| 接口 | 参数 | 返回 |
|------|------|------|
| GET /api/stats/summary | 无 | { totalUsers, todayNew, monthRevenue, dailyActive } |
| GET /api/stats/growth | from, to (日期) | Array<{ date, count }> |
| GET /api/stats/revenue | from, to (日期) | Array<{ month, amount }> |
| GET /api/stats/activity | from, to (日期) | Array<{ date, level }> |
 
### 状态处理
- 加载中：每个卡片/图表独立显示 skeleton
- 加载失败：显示「数据加载失败」+ 重试按钮
- 数据为空：图表区域显示「暂无数据」占位图
 
### 技术约束
- 图表库使用 Recharts
- 数据请求使用 SWR
- 日期范围支持选择（默认最近 30 天）

分步生成过程：

第一步，生成 API 层：四个数据请求的 hook 函数，基于 SWR 封装，定义好 TypeScript 返回类型。

第二步，生成统计卡片组件：4 个卡片，支持 loading skeleton 和错误状态。

第三步，生成图表组件：折线图、柱状图、热力图各一个组件，每个组件独立处理 loading、error、empty 状态。

第四步，组装页面布局：将所有组件按 PRD 的布局要求组合到看板页面。

第五步，补充日期选择器功能，联动所有图表的数据范围。

关键经验：这个案例中，PRD 里的「状态处理」部分写得越详细，AI 生成的代码质量越高。特别是「每个图表独立显示 loading」这一点，如果不明确写出来，AI 大概率会做成全局统一 loading。

从 PRD 到 AI 生成代码的完整流程

这个流程看起来步骤很多，但实际操作中，每一步的耗时并不长。相比「一次性生成然后花大量时间手动改代码」，分步策略的总耗时通常更少，而且最终代码质量更高。

检查清单

在开始让 AI 根据 PRD 生成代码之前，逐项检查以下内容：

• PRD 包含明确的技术栈约束，没有留给 AI 自行选择
• 数据模型已定义完整，包括字段名、类型、约束和默认值
• 每个功能都有输入、输出、状态变化的描述
• 边缘情况已列出（空值、超长输入、网络错误、重复操作）
• Out-of-Scope 清单已写明，防止 AI 自由发挥
• 功能按优先级（P0/P1/P2）标注
• 验收标准是可验证的具体条件，不是模糊的「功能正常」
• 分步生成计划已制定，不会一次性生成整个项目
• 代码风格约束已在全局配置中声明
• 准备好了 PRD 对照检查清单，用于校验生成的代码
• 每个生成步骤都有对应的验证方式（编译、测试、手动检查）
• PRD 中使用的术语前后一致，没有歧义

小结

让 AI 根据 PRD 生成代码，核心不在于 AI 工具的操作技巧，而在于你能否把需求文档写得足够清晰、具体、无歧义。传统 PRD 给人看，允许模糊；面向 AI 的 PRD 给机器看，不允许模糊。这是 AI 编程时代产品经理和开发者需要掌握的新技能。

记住几个关键原则：结构化胜于叙述性、具体胜于抽象、分步胜于一次性、校验胜于信任。PRD 是你和 AI 之间的「合同」，合同写得越清楚，交付的质量就越高。

参考资料

1. Writing PRDs for AI Code Generation Tools in 2026 — ChatPRD，关于如何为 AI 代码生成工具编写 PRD 的系统指南
2. 从 PRD 到代码 — VibeVibe — PRD 文档驱动开发，AI 如何「阅读」和理解 PRD
3. 给 AI 当 PM 的一天：如何撰写极度严谨的 PRD — 为 AI 编写严谨 PRD 的实战方法
4. Generating Code — Prompt Engineering Guide — Prompt 工程在代码生成中的应用
5. Spec-driven development with AI — GitHub Blog — GitHub 关于规格驱动开发的开源工具和方法论
6. How Structured Requirements Unlock the Full Potential of AI Tools — 结构化需求如何释放 AI 编程工具的全部潜力
7. 15 Prompting Techniques for Code Generation — 15 个面向开发者的 Prompt 工程技巧
8. AI Coding: 3 Docs You MUST Create — AI 编程必备的三份文档