08 从PRD到代码：让AI自动推导API规范与数据库设计

从PRD到代码：让AI自动推导API规范与数据库设计【核心观点】上一篇我们搞定了需求分析——AI把一句话需求变成了结构完整的PRD。但这只是第一步。PRD是给人类看的"商业文档"，要让AI干活，还需要把它翻译成AI能直接"消化"的技术规范。今天，我们就来走这关键的一步：从PRD自动推导API规范和数据库设计。这是整个SDD流程中最"魔法"的一环——当PRD足够清晰时，让AI推导接口和表结构，就像让高中生做代数题一样，几乎是确定性的。一、从"商业语言"到"技术语言"先理解一下我们到底在做什么。PRD是产品经理的语言——它说的是"用户故事"“业务流程”“功能边界”。这些内容AI能理解，但AI没法直接拿来写代码。写代码需要的是"API定义"“表结构”“字段类型”——这是工程师的语言。从PRD到技术规范，本质上是一次"翻译"。传统的翻译流程是这样的：产品经理写完PRD后端开发读PRD，理解业务逻辑后端开发在脑子里（或者草稿纸上）把业务逻辑翻译成API和表结构后端开发写代码实现API和表结构这个流程的最大问题是：翻译发生在开发者的脑子里。脑子里的东西是隐性的、不可验证的、容易出错的。AI Native时代的流程是这样的：产品经理写完PRD（可能就是一句话）AI把一句话扩展成完整PRD（上一篇讲的）AI把PRD翻译成API规范和数据库设计（今天要讲的）AI基于技术规范生成代码核心变化：翻译从"脑子"变成了"文档"，从"隐性"变成了"显性"。这有什么好处？可验证：技术规范写出来，你能一眼看出对不对可迭代：规范错了改规范，不用改代码可复用：同一个PRD可以推导出不同的技术方案（比如换数据库）更重要的是：当技术规范足够清晰时，代码生成几乎是自动的。二、先搞清楚：技术规范长什么样？在让AI干活之前，你得先知道"好东西"长什么样。一份生产级的API规范文档，至少包含：模块核心内容示例接口列表所有API端点的完整清单GET /api/v1/group-buys请求格式每个API的请求方法、路径、参数groupId: string (path)响应格式成功和失败的响应结构Result状态码定义业务错误码的含义1001: 用户不存在认证授权哪些接口需要登录/权限Bearer Token一份生产级的数据库设计文档，至少包含：模块核心内容示例ER图实体关系图User 1:N Order表结构每个表的字段定义status: varchar(20)索引设计哪些字段需要索引idx_user_id约束关系外键、唯一约束FOREIGN KEY (userId)迁移脚本建表SQL（可选）CREATE TABLE…注意到规律了吗？技术规范的每个模块，都可以从PRD中对应模块推导出来：PRD的"用户故事" → API的"接口列表" PRD的"业务流程" → API的"状态码定义" PRD的"数据模型" → 数据库的"表结构" PRD的"实体关系" → 数据库的"ER图"和"外键"这就是"翻译"的本质——信息没有增加，只是换了表达形式。三、API规范推导：提示词模板好，理论够了。来点实战。以下是我总结的API规范推导提示词模板，你可以直接使用：你是一位资深的API架构师。请基于以下PRD，生成一份完整的API规范文档。 ## PRD内容 [在这里粘贴完整的PRD内容，或者引用PRD文件路径] ## 项目上下文 - 框架：[例如：NestJS 10.x] - 认证方式：[例如：JWT Bearer Token] - 响应格式规范：[例如：所有接口返回 ResultT 泛型] - 基础路径：[例如：/api/v1] ## 输出要求 ### 1.