后端接口PRD写作清晰框架提示词

角色定义与任务定位

请以“资深后端技术文档架构师”的身份，并设定“为开发团队创建一份无歧义、可执行、涵盖所有关键要素的后端接口产品需求文档（PRD）”为核心目标。你的产出不是一篇泛泛而谈的指南，而是一份能够直接驱动接口设计、开发与测试的结构化需求蓝图。

适用场景

• 为新功能或模块定义后端API规范。
• 为现有接口的迭代或重构编写明确需求。
• 在跨团队（产品、后端、前端、测试）协作中，建立统一的技术需求基准。
• 将模糊的产品需求转化为精确的技术实现约束。

核心提示词框架

以下为可直接复制、填充使用的结构化提示词模板。请将【】内的内容替换为具体信息。

• 接口概述：提供接口名称【如：用户信息查询接口】，简要说明其核心业务目的【如：根据用户ID获取其公开资料】。
• 请求定义：明确请求方法【GET/POST/PUT/DELETE/PATCH】、请求路径【如：/api/v1/user/{userId}】、请求头要求【如：Content-Type: application/json, Authorization: Bearer token】。
• 请求参数：清晰列出路径参数【如：userId: integer】、查询参数【如：fields: string, 可选】、请求体参数【JSON结构示例】。每个参数需包含：字段名、类型、是否必填、默认值、取值范围/枚举、描述。
• 响应定义：规定成功响应状态码【如：200】及数据结构【JSON Schema示例】；列出所有可能的错误状态码【如：400, 401, 404, 500】及其对应的错误信息格式与业务含义。
• 业务规则与约束：描述权限验证逻辑【如：仅能查询当前登录用户自身信息或管理员可查所有】、数据过滤规则【如：敏感字段脱敏】、限流策略【如：每秒10次】、幂等性要求等。
• 非功能性要求：指明性能指标【如：P99延迟 < 100ms】、数据一致性要求、缓存策略【如：缓存时长5分钟】、降级方案等。

风格方向

• 文风：采用客观、精准、无歧义的技术说明文风，避免口语化和模糊词汇（如“大概”、“可能”）。
• 结构：遵循“总-分”逻辑，从接口概览到细节逐层展开，使用层级标题和列表保持结构清晰。
• 术语：使用一致且团队内公认的技术术语，对必要的专有名词提供简短解释。

构图建议（信息组织框架）

• 将文档想象为一个由模块化信息块构成的“技术图纸”。
• 采用“金字塔”结构：顶部是接口名片（概述、基础URL），中部是核心交互区（请求/响应详情），底部是支撑与约束区（规则、非功能要求、附录）。
• 善用表格对比参数，用代码块展示JSON示例，使关键信息区块化、可视化。

细节强化

• 边界与异常：明确参数为空、越界、重复提交等异常情况的处理方式。
• 数据示例：提供至少一个完整的、真实的请求示例和响应示例。
• 变更记录：设立版本记录部分，注明修订日期、版本号、修改内容与修改人。
• 关联链接：关联到相关的数据字典、领域模型图或上游/下游接口文档。

使用建议

• 在填充核心提示词框架前，先与产品经理确认核心业务逻辑，与前端开发者对齐数据格式预期。
• 撰写时，始终自问：“仅凭这份文档，一位中级后端工程师能否在不二次确认的情况下，独立完成接口开发？”
• 完成后，可邀请一位同事进行“快速审阅”，重点检查流程的完整性和描述的明确性。
• 将此框架保存为模板，并根据团队具体技术栈（如Spring Boot, Django REST framework）补充特定的注解或配置约定。