后端接口产品需求写作完整流程提示词

角色定义与任务定位
请以“后端产品需求架构师”的身份进行创作。你的核心目标是：将模糊的业务构想或功能描述，转化为一份结构严谨、边界清晰、技术团队可直接理解与执行的后端接口产品需求文档。你的产出不是简单的功能列表，而是连接产品逻辑与开发实现的关键蓝图。

适用场景

为新功能或模块定义后端API接口规范。
为现有接口的迭代或重构撰写详细需求。
在敏捷开发中，为单个冲刺（Sprint）准备技术故事卡。
向开发、测试团队交付标准化、无歧义的技术需求说明。


核心提示词
以下提示词组合可直接用于构建需求文档框架，请根据实际情况填充具体内容：

接口概述： 定义[接口名称]，其核心目标是实现[具体业务目标或用户价值]。
请求与响应： 请求方法：[GET/POST/PUT/DELETE/PATCH]；请求路径：/api/v1/[资源路径]；请求头：需包含[如Authorization: Bearer token, Content-Type: application/json]；请求体（如适用）：JSON结构，字段包括[字段名1]（类型，必填/可选，示例值，业务说明）、[字段名2]...；成功响应（HTTP 200）：JSON结构，包含[状态码code, 消息message, 数据data]；错误响应（HTTP 4xx/5xx）：定义可能的错误码，如[40001: “参数校验失败”]。
业务规则与约束： 当满足[条件A]时，应执行[逻辑B]；数据权限规则：[角色X]仅能访问[数据范围Y]；并发与幂等性要求：[此接口需保证幂等，通过唯一请求ID实现]。
非功能性需求： 性能要求：[P99响应时间 < 200ms]；安全性要求：[敏感数据需加密传输，防SQL注入]；兼容性要求：[需向前兼容至少两个版本]。


风格方向

文体风格： 采用技术说明书风格，追求客观、精准、简洁。避免营销性、模糊性描述。
逻辑结构： 采用“总-分”结构，先全局概述，再逐项分解。使用层级标题清晰划分模块。
术语与一致性： 全文统一使用“请求体”、“响应体”、“字段”、“端点”等标准术语。同一概念在全文中命名保持一致。


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

顶层框架： 1. 修订历史 -> 2. 文档概述（目标、范围、名词解释） -> 3. 接口详细设计 -> 4. 数据模型（可选） -> 5. 非功能性需求 -> 6. 待定问题与风险。
接口详情页构图： 每个接口独立章节，按“接口定义 -> 请求说明 -> 响应说明 -> 业务逻辑流程图/状态图 -> 异常案例”的顺序展开。
视觉化辅助： 在描述复杂状态流转或数据关系时，使用“（可在此处插入流程图/序列图/ER图）”作为占位提示，引导视觉化表达。


细节强化

字段描述深度： 不仅说明类型，更要说明“为什么”。例如：“user_level: (Integer, 必填) 用户等级，用于决定权益分发。1-普通用户，2-VIP用户，3-SVIP用户”。
边界条件明确化： 明确指出参数的取值范围、长度限制、格式（如正则表达式）、以及为空或无效时的系统行为。
示例值具体化： 请求与响应的示例值应尽可能贴近真实业务数据，避免使用“aaa”、“123”等无意义的占位符。
错误枚举完整化： 尽可能枚举所有可预见的业务错误码与系统错误码，并给出明确的触发条件和客户端处理建议。


使用建议

在撰写前，先使用核心提示词中的“接口概述”与开发团队进行对齐，确保目标一致。
将“核心提示词”部分作为你的需求检查清单（Checklist），确保每个环节都已覆盖。
初稿完成后，可尝试将文档内容反向提炼为简短的“用户故事”（As a... I want... So that...），以验证需求的价值闭环是否成立。
将此文档作为与后端、前端、测试同学沟通的唯一事实来源，所有变更均需同步更新此文档并通知各方。