产品需求文档（PRD）提示词

何时使用

当你需要为某个明确范围的功能起草初版 PRD，并且希望获得坚实的技术与业务基准而非抽象大纲时，请使用此提示词。在提交给研发团队之前，请替换为你自己的产品实际情况、系统约束和团队指标。

提示词

## 角色
扮演一名资深产品经理。运用结构化系统思维和技术清晰度，同时保持文档对跨职能团队易于理解。

## 背景
BeaconHR 是一家面向中型医疗诊所的内部运营平台。目前，排班主管通过电话和实体白板协调突发的护士换班，导致重复排班和替班延误。BeaconHR 计划新增一个适配移动端的“换班申请（Shift Swap Requests）”模块。目标是在第二季度面向现有的 12 家区域诊所试点群体发布。

## 目标
撰写一份详尽的 PRD，明确点对点（P2P）换班申请、主管审批关卡以及审计日志更新的端到端工作流。

## 目标受众
主要读者为软件工程师、UI/UX 设计师和临床运营主管。提供明确无歧义的逻辑和可执行的验收标准，避免不必要的理论堆砌。

## 需求
包含以下内容：问题陈述；用户画像（发起员工、接收员工、诊所主管）；附带明确验收标准的用户故事；涵盖申请发起、同行确认和主管批准的功能规范；错误处理与边界情况（例如排班冲突、申请过期）；以及用于衡量功能采用率和换班流转时效的指标表。

## 约束条件
严格将范围限制在同一诊所网点和相同岗位级别内的 1:1 换班。切勿引入自动排班重新生成、薪资核算系统集成、跨网点调动或外部 SMS 短信网关。仅围绕所述场景展开。明确标注所有功能性假设。

## 语气与风格
保持简炼、严谨且偏重功能性。使用清晰明确的措辞（例如“必须”、“应该”），并使用结构化 Markdown 表格呈现状态流转和边界情况。避免空洞的行话或模糊的概括。

## 输出格式
直接按照标准化的产品文档标题输出 PRD。将架构假设和未决的开放性问题放在末尾的独立章节中。最后附上一份供工程和合规审批的依赖项核对清单。

## 避免事项
切勿臆断未提及的 API 能力或外部供应商工具。避免将功能需求与视觉设计规范混为一谈。切勿遗漏错误状态或边界条件。

## 成功标准
技术负责人能够据此评估技术工作量，QA 工程师能够直接根据需求推导测试用例，无需就核心业务规则反复确认。

## 澄清问题
仅在存在根本性阻碍需求起草的歧义时，最多提出三个针对性问题。否则，请基于合理的业务假设继续进行，并明确标记为待利益相关者验证的事项。

为何有效

• 场景为模型提供了具体的技术领域约束和用户角色，而非模糊的功能概念。
• 需求明确要求包含初稿中常被忽略的功能边界情况、验收标准以及显式错误状态。
• 约束条件明确排除了范围蔓延（Scope Creep），如自动化排班算法或外部薪资对接。
• 成功标准将输出锚定在工程就绪度和可测试性上，而非流于表面的形式完整。

定制化使用

使用 PromptDeck 构建专属版本，只需将虚构场景替换为你自己的业务背景、受众和约束条件即可。保留验证步骤，以确保最终结果能准确反映你目前掌握的事实。