实战型数据库管理PRD需求文档提示词

角色定义与任务定位

请以资深数据库架构师兼产品需求分析师的身份，执行本次任务。你的核心目标是：为一项具体的数据库管理项目或功能迭代，撰写一份目标明确、边界清晰、技术可行、可直接用于开发与测试团队执行的产品需求文档（PRD）。这份文档应聚焦于数据库层面的变更、运维或优化需求，而非泛泛的产品功能描述。

适用场景

• 规划新的数据库表结构、索引策略或存储过程。
• 定义数据库迁移（如版本升级、数据迁移）的具体需求与回滚方案。
• 制定数据库性能监控、备份恢复、安全审计等运维管理规范。
• 明确与应用程序交互的数据接口、ETL流程或数据治理规则。

核心提示词

以下提示词组合可直接用于生成文档的各个核心部分。请根据你的具体项目替换“[]”中的内容。

• 文档概述：“撰写PRD文档概述，明确项目名称：[项目名]，核心目标：[例如：提升订单查询性能50%]，涉及的主要数据库系统：[如MySQL 8.0]，并简述该数据库变更如何支撑整体业务目标。”
• 非功能性需求：“详细定义数据库需求中的非功能性指标，包括：1) 性能要求：[如：单表亿级数据下，根据用户ID分页查询响应时间<100ms]；2) 可用性与SLA：[如：主库故障后，10分钟内完成读写切换]；3) 安全要求：[如：敏感字段必须加密存储，访问日志全量审计]；4) 容量与扩展性：[如：设计需支持未来三年数据量年增长200%]。”
• 数据模型与变更：“以SQL或图表描述形式，详细说明本次需求涉及的[新建/修改]表结构。包括：表名、字段名、数据类型、约束（主键、外键、非空、唯一）、默认值，以及字段的业务含义说明。同时，描述与此表相关的关键索引策略。”
• 接口与交互：“定义应用程序与数据库交互的关键接口。列出需要[新增/修改]的API、存储过程或数据服务，说明其输入参数、输出结果、触发条件、调用频率以及预期的异常处理机制。”
• 运维与监控需求：“提出数据库上线后所需的运维支持需求。包括：备份策略（全量/增量频率、保留周期）、监控指标（如慢查询、连接数、磁盘空间）、报警阈值，以及日常健康检查的要点。”

风格方向

• 文体风格：采用技术规范文档的文体，要求表述精准、客观、无歧义。避免使用市场宣传或模糊性语言。
• 结构层次：文档应具备清晰的层级，建议采用“1. 概述 -> 2. 业务背景 -> 3. 功能性需求 -> 4. 非功能性需求 -> 5. 数据模型 -> 6. 接口定义 -> 7. 运维需求 -> 8. 验收标准”的逻辑结构。
• 术语使用：准确使用所在技术栈（如Oracle, MySQL, MongoDB）的专有术语，并对团队内可能不统一的术语进行集中定义。

构图建议（文档结构隐喻）

将PRD想象为一幅精密机械的工程蓝图。文档概述是总装图，功能性需求是核心部件分解图，数据模型是每个零件的三视图与尺寸标注，非功能性需求是材料强度与公差要求表，而运维需求则是保养手册与故障排查指南。各部分必须严丝合缝，相互引用。

细节强化

• 量化指标：所有性能、容量、时间要求必须尽可能量化（例如：“数据归档任务应在每日业务低峰期4小时内完成”，而非“快速完成”）。
• 变更影响分析：对现有系统的改动，需单独小节分析“影响范围”，包括：影响的现有表、应用程序模块、上下游数据流程、以及需要同步更新的文档。
• 验收标准具体化：验收标准应可直接测试。例如：“需求验收通过标准：1）执行新建索引的SQL后，指定的查询语句在测试环境执行计划显示‘Using index’；2）使用模拟工具并发执行该查询，P99延迟低于50ms。”
• 假设与依赖：明确列出项目前提，如“假设运维团队已提供具备XX IOPS的存储”，或“本需求依赖于用户中心服务在Q2提供新的UID生成接口”。

使用建议

• 首先，使用“核心提示词”中的模块，逐一生成文档初稿的各个部分。
• 在整合全文时，注意保持术语、指标单位（如ms, TB, QPS）的一致性。
• 强烈建议为“数据模型”部分生成实体关系图（ERD）或表结构图，并将图片作为附录插入文档，在文中引用。
• 完成初稿后，可基于“细节强化”要点进行自查，补充遗漏的量化指标和影响分析。
• 最终文档应使开发工程师能明确知道“要做什么”，测试工程师能据此编写用例，运维工程师能规划上线步骤。