连锁门店产品需求文档实战版提示词

角色定义与任务定位
请以连锁零售业务资深产品专家的身份，运用体系化的门店运营知识与产品设计思维，为以下目标生成内容：撰写一份专业、严谨、可直接指导开发与落地的《连锁门店产品需求文档》。你的核心任务是确保文档内容紧密贴合连锁业态的多门店管理、标准化复制、本地化运营及数据驱动决策等核心诉求，输出内容需具备高度的专业性与实操性。

适用场景

为新门店上线或现有门店升级数字化管理系统（如POS、CRM、供应链系统）撰写需求。
为覆盖多门店的统一运营功能（如会员通、库存调拨、营销活动下发）制定产品方案。
为优化特定门店经营环节（如排班、巡检、订货、报表分析）设计产品功能模块。
向技术、设计、测试及业务部门清晰传达跨门店协同的业务逻辑与产品规则。


核心提示词
（以下提示词组合可直接用于引导生成或作为文档章节框架）

文档标题与版本：[具体系统/模块名称]产品需求文档（PRD）- 连锁门店版 V1.0
文档目标：明确本PRD旨在解决[例如：提升门店订货效率、实现总部-门店营销联动、统一会员积分消耗规则]问题，覆盖[直营/加盟]门店类型，支撑[门店数量级]规模下的业务运营。
业务背景与痛点：描述当前连锁门店在[具体业务环节，如手工盘点、活动信息不同步]存在的效率低下、数据不准、标准不一等问题，及其对经营成本与用户体验的影响。
功能需求清单：按[门店端/总部后台/移动端]角色，列出功能模块（如“智能补货建议”、“多门店业绩对比仪表盘”、“店长每日任务推送”），并说明优先级（P0/P1/P2）。
核心业务流程：使用“当[触发条件]，则[系统动作]，并通知[相关角色或系统]，最后[结果状态]”的句式，描述跨角色、跨门店的关键流程（例如：当总部创建促销活动，则自动下发至选定门店POS系统，店长确认后生效，并同步更新前端价格标签）。
非功能性需求：明确要求系统支持[例如：高峰时段500家门店同时在线、断网后POS机离线销售与数据恢复、不同城市门店的商品价格差异化配置]。
成功指标（Metrics）：定义可量化的验收标准，如“门店员工平均订货耗时减少30%”、“营销活动门店执行率达成95%”、“系统月度平均无故障时间>99.5%”。


风格方向

专业严谨：采用客观、精准的书面语，避免口语化和模糊描述。大量使用“应”、“需”、“禁止”、“当...时”等确定性词汇。
结构化与可视化：强调使用分级标题、编号列表、流程图、状态图、原型图索引来组织内容，使逻辑一目了然。
业务导向：所有功能描述必须关联到具体的业务价值（降本、增效、增收、风控、提升体验），而非单纯的技术实现。
考虑周全：需涵盖正常流程、异常处理（如审核驳回、网络中断）、数据权限（如A店店长不能查看B店数据）、以及与其他系统的接口边界。


构图建议（文档结构框架）

1. 文档概述：项目背景、目标、范围、名词解释、读者对象。
2. 整体业务架构图：展示总部、区域、门店之间的信息流与业务关系。
3. 角色与权限矩阵：清晰定义总部管理员、运营经理、区域督导、店长、店员等角色的操作权限与数据视野。
4. 详细功能说明（主体部分）：按模块分节，每节包含：功能描述、用户故事（作为XX角色，我希望...以便于...）、业务流程/规则、界面原型说明、数据字段定义。
5. 全局规则与约束：包括数据同步机制、审批流规则、通用计算逻辑（如分成、积分）、合规性要求。
6. 非功能性需求：性能、安全、可靠性、兼容性要求。
7. 运营与部署计划：上线步骤、数据迁移、门店培训、支持方案。
8. 附录：相关文档链接、版本修订记录。


细节强化

数据字段：定义关键字段时，注明其类型、长度、是否必填、来源（如手动录入/系统计算/接口同步）及示例（如“商品SKU编码：字符型，长度20，唯一，示例：SP202403150001”）。
业务规则：使用“如果...那么...否则...”的格式精确描述规则（例如：“如果门店库存低于安全库存，那么系统在店长工作台显示‘紧急补货’预警，否则显示库存正常”）。
异常场景：针对每个主要流程，思考并列出至少1-2个异常情况及其处理方式（例如：“门店提交盘点差异报告后，总部驳回，报告状态应更新为‘已驳回’，并需填写驳回理由通知门店”）。
专业术语：准确使用“坪效”、“人效”、“动线”、“DC（配送中心）”、“SOP（标准作业程序）”、“翻台率”（餐饮）等行业术语，并可在名词解释部分统一说明。


使用建议

在生成具体内容前，先用“核心提示词”部分的关键句搭建文档骨干目录。
撰写时，时刻自问：“这个需求，对一家新开门店和一家成熟老店，实施起来有区别吗？”以确保方案的普适性与可扩展性。
将“风格方向”与“构图建议”作为检查清单，在完成初稿后逐项核对，确保文档的专业度与完整性。
“细节强化”中的要点是提升文档质量与可实施性的关键，应作为重点填充内容，避免需求歧义。
最终输出的PRD，应能让开发工程师明确“做什么”，让测试工程师知道“验什么”，让业务方理解“得到什么价值”。