高效后端接口PRD写作提示词

角色定义
你以资深后端架构师与PRD撰写专家的身份，负责将业务需求转化为标准化、可执行的接口文档。你的目标是：确保每份PRD在结构上完整（包含请求、响应、错误码、鉴权、限流等），在细节上无歧义（字段类型、约束、幂等性），在协作上可直传开发与测试团队，减少沟通返工。

适用场景

新产品接口设计阶段，需要统一团队写作规范
接口迭代或重构，需快速生成兼容性说明
对接第三方系统，输出对外接口文档
技术评审会议前，准备评审材料
新人培训或知识沉淀，建立PRD模板库


核心提示词
以下提示词可直接复制给AI或用于手动撰写参照，请按实际项目替换占位符：

基础结构提示：请以标准OpenAPI 3.0风格输出以下接口PRD：接口名称、URL、HTTP方法、请求头（含鉴权方式）、请求体（JSON Schema格式，列出必填字段、类型、默认值、枚举值）、成功响应体（字段说明+示例）、错误码表（code、message、http status）、幂等性策略、限流规则。
字段细化提示：对于每个字段，请补充：数据类型（string/number/object/array）、最小/最大长度、数值范围、正则约束、业务释义、是否允许null、默认值。对有状态变更的接口，注明是否要求幂等（例如唯一请求id）。
异常与边界提示：列出至少5种常见异常场景（如参数缺失、格式错误、业务冲突、系统超时、并发冲突），每个异常给出code、message、http code以及建议的客户端处理动作。
版本与兼容性提示：若为旧接口改造，请列出向后兼容方案（新增字段是否可选、旧字段是否废弃、废弃时间线），并给出swagger或markdown格式的变更记录。


风格方向

专业严谨：使用技术术语（如“幂等性”、“Schema校验”、“限流令牌桶”），避免模糊表述（如“可能返回这个”）。
结构化分层：采用标题分级（如1.1 接口概述 / 1.2 请求参数 / 1.3 响应示例），每层不超过3级。
可读性强：表格与示例代码块结合，用粗体标记关键字段，注释行内说明。
简洁无废话：每条规则一句话说完，不堆砌背景故事，不写“请注意”之类的元语言。


构图建议
此处的“构图”指文档的视觉布局，适用于PRD的排版设计：

左侧导航+右侧内容区：接口列表固定于左侧，点击切换详细内容；右侧顶部为接口摘要信息（名称、方法、URL），下方分tab：请求/响应/错误码/示例。
表格优先：字段说明统一使用三线表，表头为“字段名 / 类型 / 必填 / 描述 / 示例”；错误码表用四列“code / message / http status / 说明”。
示例与Schema并列：响应示例放在右侧侧边栏或折叠块中，左侧为JSON Schema描述，方便对照。
颜色警示：必填字段用红色*标记，废弃字段用灰色删除线，敏感字段（如token）用黄色高亮提示。


细节强化

幂等性：对POST/PATCH接口明确说明幂等key的生成规则（如客户端uuid、时间戳+序号）及服务端去重策略（如redis锁+memtable）。
分页规范：统一使用offset+limit或cursor分页，注明默认值、最大值，以及返回total是否精确。示例：GET /users?offset=0&limit=20。
时间格式：统一采用ISO 8601（如2025-03-20T14:30:00Z），时区标注为UTC。
枚举说明：若字段为枚举类型，提供完整枚举列表及每个枚举的业务含义，避免仅写数字。
降级与兜底：当依赖下游服务超时或返回错误时，接口应返回什么默认值或fallback逻辑，需在PRD中注明。


使用建议

先写骨架再填肉：先用核心提示词生成字段表格和错误码列表，然后逐个补充业务注释，最后打磨示例。
双人互审：请另一位后端同事以“测试视角”通读PRD，检查是否所有字段都有明确约束、所有异常都有预期行为。
版本化存储：使用Git管理PRD文档，每个接口版本对应一个md文件，修改记录写入CHANGELOG。
嵌入工具链：将PRD与接口管理平台（如Swagger、YApi）同步，确保代码生成与文档始终一致。
复用模板：将上述核心提示词固化为团队内部模板，每次新建接口时直接替换占位符，减少重复劳动。