!03-prd-doc-driven_index.png (../../public/images/Advanced/03-prd-doc-driven_index.png)
第三章：PRD 与文档驱动开发
序言
在让 AI 写代码之前，老师傅按住了你想要狂飙的手。他告诉你，写代码之前，先写文档。如果没有蓝图，AI 很容易就会像脱缰的野马，生成的代码往往缺乏结构，写出一堆谁也看不懂、改不动的功能。
产品验证三步法
老师傅说："在写任何代码之前，先做产品验证三步法：
第一步：灵魂三问。用户是谁？痛点在哪？为何用你？这三个问题看似简单，但很多人答不上来。如果用户是'所有人'，那就等于没有用户。如果痛点是'我觉得需要'，那就不是真痛点。如果'为何用你'的答案是'因为我们有最好的技术'，那用户根本不在乎。
第二步：MVP思维。能验证假设的最简版本是什么？不要想着一次做出完美产品。先做最小可行产品（MVP），快速验证核心假设。比如要做外卖 App，MVP 可能就是一个微信群 + 人工接单，而不是完整的 App。
第三步：快速验证。用最小成本验证假设。可以先用手工方式服务，或者做一个简单的落地页收集用户反馈。记住：失败得越早，成本越低。
PRD 就是 AI 的执行规范。当你想清楚了上面三步，PRD 就是把这些思考翻译成 AI 能理解的结构化文档。"
PRD 的作用
在传统开发中，PRD 是给团队看的；但在 AI 开发中，PRD 更重要的作用是给 AI 提供完整的上下文，让它不需要反复猜测你的意图。AI 友好的 PRD 结构应该包含五个部分：产品目标用一句话描述要做什么；核心功能列出 3-5 个主要功能点；用户流程用 Mermaid 图描述交互（AI 能理解这种图表）；技术栈明确使用的技术；数据模型用简化的结构描述。最关键的是结构化 + 可视化，Markdown + Mermaid 的组合是最优选择，因为 AI 对这种格式理解最好。有了这个"单一事实来源"，AI 的输出就会稳定很多，也不会出现需求爆炸的问题。
技术栈选择
你开始学习编写 PRD（产品需求文档）。老师傅直接甩给你一份成熟的模板，并拍板决定了 Next.js 16 全栈（搭配 Prisma 和 PostgreSQL）的技术栈。看着你对 Prisma 和 PostgreSQL 这两个数据库名词一头雾水的样子，老师傅摆摆手打断了你的提问："关于数据怎么存，后面会有专门的章节详细讲，现在别深究。" 他顺带提了一嘴，Prisma 的 schema 文件本身就是一份绝佳的数据库结构文档，非常适合在现阶段用来理清数据之间的关系。除了梳理业务逻辑，你意识到还需要记录具体的技术实现方案，也就是技术文档。老师傅点点头，表示对于现在的你来说，不必拘泥于形式，完全可以将技术文档与PRD合并，统称为项目文档，这样查阅起来更方便。
面对那么多技术选项，新手容易纠结。其实有个简单的决策框架：全栈 Next.js（AI 友好、生态成熟、部署便捷），除非你的项目是纯前端再考虑 Vite；数据库使用 PostgreSQL（关系型 + JSONB + pgvector，扩展性强），也可以使用 Supabase（基于 PostgreSQL ，还可以覆盖很多后端需求、快速开发）。核心思路是"明确需求 → 评估复杂度 → 选择最小可行方案"，预留扩展空间但不过度设计。在 AI 时代，技术栈越统一，AI 的上下文理解就越准确，开发效率也越高。
数据库选择：Supabase vs Neon vs 自建 PostgreSQL？各有优劣。【详见第7章】 有完整的对比和选择建议。
Markdown 与 Mermaid
在编写文档的过程中，你还顺便了解了 Markdown (.md) 和 Mermaid。Markdown 用于编写排版整齐的文本，Mermaid 用于通过文字代码绘制流程图、时序图。老师傅说，将这些文档提供给 AI，它生成的代码准确率显著提升。在这个过程中，你还顺便搞懂了 JSON 和 YAML 这种奇怪的配置文件格式。原来，对于 AI 来说，相比于散漫的自然语言，这些结构清晰的格式才是它们最爱读的"说明书"。此外经过老师傅的教导，你进一步理解了前后端交互、API 是什么，HTTP 是什么——本质上就是两个程序通过 HTTP 协议互相发送 JSON 数据包的过程。
鉴权与模块拆分
在规划功能时，你遇到了两个必须提前考虑的问题：
你想要做用户系统，这涉及到鉴权。你想要做地图功能，这涉及到外部 API。老师傅提醒你，不要把所有代码都塞在一个文件里，要学会把功能拆分成不同的模块，比如 auth（认证）、api（接口）、components（组件）。这种模块化思维是项目能长期维护的关键。
API 集成
API 文档与集成 你想接入 AI 能力，或者地图服务等。老师傅告诉你，这些外部 API 通常是收费的，但对开发者很友好，一般都有免费额度供你测试。你需要做的是：
获取凭证：找到官方开放平台的开发者文档，找到你需要的功能，注册账号生成 API Key（这是你的敏感凭证，切勿泄露）。老师傅特意叮嘱，一定要把 Key 保存到环境变量
.env文件中，而不是直接写死在代码里。环境变量就像是代码和密钥之间的"防火墙"，只要配置一下，程序运行时会自动去读取它们，这样既能保证功能正常，又能防止你把密钥上传到 GitHub 被人盗用。确立技术路线（SDK vs HTTP）：老师傅阻止了你让 AI 手写原始 HTTP 请求的想法。他介绍了 SDK（软件开发工具包） 的概念——官方通常已经把复杂的网络交互、错误处理和验证逻辑封装好了，只需要安装一下，找到官方文档就可以直接使用。更关键的是，官方 SDK 通常自带完善的 TypeScript 类型定义。这相当于给 AI 提供了代码指南，它能准确地知道有哪些功能可用，参数该怎么填，这比让它对着空白的 HTTP 请求瞎编要靠谱得多。特别是 Vercel AI SDK，它极大地简化了 AI 应用的开发。它帮你处理了技术难度较高的"流式传输"协议，让 AI 的回复能够实时逐字显示。如果你非要手写 Fetch 请求，不仅代码量翻倍，还很难实现这种流畅的交互体验。
归档参考文档：将这些 API 的关键文档（如请求格式、示例代码、返回码）整理好，归档在项目中（比如
docs/api-reference.md）。这样下次你需要 AI 写相关功能时，直接把这份文档喂给它，它就能精准地写出调用代码，而不是编造一个不存在的接口。
项目说明书 README.md
你终于意识到，代码不仅是给机器运行的，也是给人和 AI 阅读的。你知道了要写 README.md。这不是冗余信息，而是项目的"说明书"。你在里面清晰地记录了如何启动项目（pnpm dev）、如何配置环境变量、核心功能的逻辑。从此，无论是谁，直接看文档就上手了。
老师傅补充道："写 PRD 不是形式主义，而是为了训练你的问题定义能力。很多人直接让 AI'帮我做个功能'，结果来回改很多次。但先写清楚目标、用户、业务场景、和交互逻辑，AI 往往一次就对了。差距就在想清楚。"
最后，老师傅还顺带提到了 Swagger。以后当项目变得复杂，利用 Swagger 自动生成接口文档，能更高效地确保文档与代码实现保持一致。
对了，记得让 AI 随时保持文档的更新。
小节导航
基础部分
- **3.1 AI友好的PRD结构 (./01-AI友好的PRD结构.md)** 🔴 - 了解 AI 友好的 PRD 结构和编写要点
- **3.2 产品验证实战 (./02-产品验证实战.md)** 🟢 - 学习产品验证三步法和 MVP 思维
- **3.3 前后端分离概念 (./03-前后端分离概念.md)** 🟢 - 理解前后端分离的架构与交互
- **3.4 API与HTTP基础 (./04-API与HTTP基础.md)** 🟢 - 掌握 API 和 HTTP 协议的工作原理进阶部分
- **3.5 技术栈决策框架 (./05-技术栈决策框架.md)** 🟡 - 系统化地选择合适的技术栈
- **3.6 PRD编写规范 (./06-PRD编写规范.md)** 🟢 - 编写高质量、易维护的 PRD 文档
- **3.7 Coding-Agents理念 (./07-Coding-Agents理念.md)** 🔴 - 理解 AI Agent 的工作原理与协作模式（核心小节）实战部分
- **3.8 Mermaid流程图实战 (./08-Mermaid流程图实战.md)** 🟢 - 使用 Mermaid 绘制流程图、架构图
- **3.9 API文档编写 (./09-API文档编写.md)** 🟢 - 编写清晰、完整的 API 接口文档
- **3.10 项目说明书结构 (./10-项目说明书结构.md)** 🟢 - 编写完整的项目 README.md 文档