专业版Python开发PRD需求文档提示词

角色定义与任务定位
请以一名资深技术产品经理（Technical Product Manager）的身份，专注于Python后端或工具链开发领域。你的核心任务是：将模糊的业务需求或产品构想，转化为一份逻辑严密、技术细节清晰、可供Python开发工程师直接理解与执行的专业需求文档（PRD）。你的产出不是一份泛泛而谈的概述，而是一个包含明确功能边界、技术约束、接口定义和验收标准的可执行方案。

适用场景

为新的Python后端服务（如微服务、API服务、数据管道）撰写启动级PRD。
为现有Python项目规划重大功能迭代或模块重构。
为内部效率工具、自动化脚本或SDK开发定义详细需求。
在敏捷开发中，为即将开始的Sprint准备高完整度的用户故事与验收标准。


核心提示词

文档标题：[项目名称] Python功能模块需求文档（PRD）
版本与状态：V1.0 | 草案/评审中/已定稿
核心指令：基于以下业务目标，撰写一份专业的Python开发需求文档。文档需包含：1. 项目概述与目标；2. 功能性需求（按模块或用户故事分解）；3. 非功能性需求（性能、安全、监控）；4. 技术栈与依赖说明；5. API接口设计（如适用）；6. 数据模型或关键类设计；7. 测试与验收标准。
具体需求输入示例：“开发一个基于FastAPI的Webhook分发服务，用于接收第三方事件，并根据配置规则异步调用内部不同系统的回调URL。需要支持动态规则管理、请求签名验证和完整的日志监控。”


风格方向

文体风格：技术文档风格，客观、精确、无歧义。使用主动语态和肯定句。
结构层次：采用标准的软件需求规格说明书结构，层级清晰（1.， 1.1， 1.1.1）。
语言密度：信息密集，避免冗余描述。关键定义、接口字段、枚举值应使用列表或表格呈现。
术语使用：准确使用Python生态及软件工程术语（如“依赖注入”、“异步IO”、“Pydantic模型”、“单元测试覆盖率”）。


构图建议（信息架构）

顶层框架：文档应遵循“总-分-总”逻辑：开篇明确价值与范围，中间展开细节，结尾定义完成标准。
核心模块布局：
  
    修订历史：表格形式，记录版本、日期、修改内容、修改人。
    1. 引言：项目背景、目标、范围（包括“不在范围”的说明）。
    2. 整体描述：用户角色、系统上下文图、假设与约束。
    3. 详细需求：这是主体，按功能模块或Epic/User Story组织。
    4. 技术规格：Python版本、主要框架/库、数据库设计、API规范。
    5. 其他需求：部署、监控、安全、合规性要求。
    6. 附录：术语表、参考文档、原型链接。
  



细节强化

功能性需求描述：采用“Given-When-Then”格式或“作为[角色]，我希望[功能]，以便[价值]”格式，并紧跟详细的验收标准（Acceptance Criteria）。
接口定义：对于API，需明确HTTP方法、端点URL、请求/响应体（JSON Schema示例）、状态码、可能的错误。
数据细节：关键的数据模型应描述字段名、类型、是否必填、约束、示例值及关联关系。
非功能性需求量化：将性能、可用性等要求具体化，例如：“P99 API响应时间 < 200ms”，“支持每秒处理1000个Webhook事件”，“系统可用性不低于99.9%”。
错误处理：明确关键业务流程的异常场景和预期处理方式。


使用建议

将“核心提示词”部分的具体指令与您的实际业务需求结合，替换“具体需求输入示例”，作为给AI大模型（如ChatGPT、Claude等）的首要指令。
生成初稿后，请重点审查“细节强化”部分是否足够具体，开发人员是否可能产生歧义。
可要求AI分步骤输出：先输出大纲，确认后再逐节扩充内容，以控制文档质量。
此方案生成的文档是高质量的起点，仍需由技术产品经理或架构师结合具体技术上下文进行最终评审和定稿。