数据库管理PRD写作结构化提示词

角色定义与任务定位

请以“资深产品架构师”与“数据库需求分析师”的双重身份进行思考与创作。您的核心目标是：系统性地解构数据库管理需求，将模糊的业务诉求转化为一份结构严谨、技术边界清晰、可直接用于开发评估与方案设计的《产品需求文档（PRD）》结构化草案。

适用场景

• 为全新的数据库管理系统（DBMS）或数据平台撰写初始PRD。
• 为现有数据库系统的重大功能迭代（如分库分表、迁移、性能优化）编写需求章节。
• 向技术团队（开发、DBA、测试）明确传达数据库层面的设计约束与验收标准。

核心提示词

请基于以下结构化框架填充具体内容，形成完整的PRD章节：

• 1. 概述与目标：定义本数据库模块要解决的[核心业务问题]，达成[例如：数据一致性提升至99.99%、查询延迟降低50%]等可衡量的目标。
• 2. 数据模型与实体：列举核心业务实体（如[用户表]、[订单表]），描述其主要属性、数据类型、约束（非空、唯一），并说明实体间关系（一对一、一对多）。
• 3. 功能性需求：
  • 数据操作：支持对[指定表]的增、删、改、查（CRUD）操作，并明确[批量更新]、[条件删除]等复杂操作的触发条件与边界。
  • 查询需求：定义高频查询场景，如“根据[用户ID]分页查询其近[6个月]的[订单详情]，并按[创建时间]倒序排列”，并注明期望的[最大响应时间]。
  • 数据维护：规定[数据归档]策略（如将[3年前]的日志迁移至历史库）、[数据清洗]规则与执行周期。
• 4. 非功能性需求：
  • 性能：明确[单表数据量]预期、[峰值TPS/QPS]要求、[复杂查询响应时间]上限。
  • 可用性与可靠性：要求系统支持[99.9%]的可用性，设计[故障自动切换]机制，明确[数据备份]策略（全量/增量，每日/每周）与[RPO/RTO]目标。
  • 安全与合规：定义数据[访问权限]控制粒度（库/表/行/列级）、[敏感信息]（如手机号）的加密存储要求、审计日志必须记录的[操作类型]与[关键字段]。
• 5. 演进与扩展性：考虑未来[数据量增长10倍]时的扩容方案，以及为适应[可能的新业务线]而需预留的[字段扩展]或[分库分表]设计空间。

风格方向

• 文档风格：采用技术文档的客观、精准、无歧义文风。避免营销性语言，多使用“必须”、“应当”、“禁止”等明确的需求表述词。
• 结构风格：遵循“总-分”结构，从业务目标推导出技术需求。每个需求应可独立追溯、评审与测试。

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

将PRD想象为一幅层次分明的技术蓝图：

• 顶层全景：用“系统上下文图”或“数据流向图”展示本数据库与外部系统（如应用服务器、ETL工具）的交互关系。
• 中层结构：使用“实体关系图（ER图）”可视化核心表结构，用“状态转换图”描述关键数据（如订单状态）的生命周期。
• 底层细节：用“表格”列举字段定义，用“序列图”阐明关键事务（如支付成功后的数据更新流程）的调用顺序。

细节强化

• 在定义“性能需求”时，补充具体的[基准测试场景]描述，如“在[1000万条]测试数据下，执行[指定查询语句]的耗时应低于[200ms]”。
• 在“安全需求”中，明确[密码加密算法]（如bcrypt）、[数据脱敏]规则（如身份证号仅显示前6位与后4位）。
• 为“扩展性”加入[技术选型考量]，如“选择支持在线DDL的数据库版本”或“采用逻辑分表以降低未来迁移成本”。

使用建议

• 本提示词框架可作为PRD撰写的检查清单（Checklist），确保无重大需求遗漏。
• 在实际撰写时，请将方括号“[]”中的示例占位符替换为您项目的具体参数和描述，使其成为可直接交付的文档内容。
• 可将“核心提示词”部分的内容直接输入给AI助手，作为生成详细PRD段落的指令，再结合您的专业知识进行修订与深化。