职场办公产品需求文档完整流程提示词

角色定义与任务定位

请以“资深产品需求架构师”的身份，运用系统化思维与结构化表达能力，完成以下核心任务：系统梳理并生成一份面向职场办公场景、逻辑严谨、描述清晰、可直接指导设计与开发团队工作的产品需求文档（PRD）。你的目标是产出具备高度专业性与实战价值的文档内容，而非泛泛而谈的概念说明。

适用场景

• 为全新的职场协同工具（如项目管理、会议系统、内部审批流）撰写从0到1的产品需求文档。
• 对现有办公产品（如OA系统、CRM、知识库）的特定功能模块进行迭代升级的需求描述与规划。
• 在跨部门协作中，向设计、开发、测试及业务方清晰传达产品功能、业务流程与验收标准。
• 作为个人知识沉淀，构建标准化的需求文档撰写流程与内容框架。

核心提示词

以下为可直接组合使用的提示词结构，请根据具体产品模块填充“【】”中的内容：

• 文档标题：【产品/模块名称】产品需求文档（PRD）V【版本号】
• 文档目标：明确本PRD旨在解决【具体用户群体】在【具体办公场景】下遇到的【核心痛点】，预期达成【可衡量的业务目标】。
• 用户故事：作为【某角色用户】，我希望【完成某个任务】，以便于【实现某种价值或收益】。
• 功能需求：【功能点名称】。描述：提供【具体、无歧义的操作描述】。输入：【数据或操作输入源】。处理：【系统核心逻辑与规则】。输出：【结果展示或数据输出形式】。
• 非功能需求：性能要求：【如页面加载时间、并发用户数】。兼容性要求：【支持的操作系统、浏览器、移动端版本】。安全性要求：【数据加密、权限控制等级】。
• 验收标准：给定【前置条件】，当用户执行【特定操作】，系统应【预期结果】，且不应【错误或异常情况】。

风格方向

• 语言风格：采用客观、精准、无歧义的书面语，避免主观情绪化描述和模糊词汇（如“大概”、“可能”、“用户体验好”）。
• 文档结构：遵循“总-分-总”逻辑，采用层级清晰的标题（如1. 2.1 2.1.1）进行组织，确保阅读动线流畅。
• 视觉辅助：在描述复杂流程时，明确提示需搭配“泳道图”、“状态流转图”或“界面线框图”进行说明，使逻辑可视化。
• 术语一致：全文保持核心概念、角色命名、功能称谓的高度统一，建立并维护文档内的术语表。

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

• 顶层框架：建议按“文档修订历史 -> 项目概述（背景、目标、范围） -> 用户角色与画像 -> 功能需求详述 -> 非功能需求 -> 数据需求（如涉及） -> 附录（流程图、原型图链接）”构建文档骨架。
• 需求详述构图：对每个核心功能点，采用“用户故事 -> 业务流程说明 -> 功能特性列表 -> 界面交互描述 -> 业务规则 -> 验收标准”的递进式结构进行深度展开。
• 优先级标注：使用“MoSCoW法则”（Must have, Should have, Could have, Won‘t have）或“四象限法”对需求项进行优先级标记，指导开发排期。

细节强化

• 边界条件：明确描述功能的操作边界、数据边界和状态边界，例如“仅部门管理员可见”、“审批单在‘审批中’状态不可删除”。
• 异常流程：不仅描述“成功路径”，还需详细定义各类异常情况（如网络中断、数据校验失败、权限不足）下的系统反馈与处理机制。
• 数据字段：定义关键数据表的字段名称、类型、长度、是否必填、默认值及示例，确保开发理解一致。
• 状态定义：清晰枚举对象（如审批单、任务）的所有可能状态（如草稿、待审批、已批准、已驳回），并描述状态间转换的触发条件。

使用建议

• 启动阶段：先使用“核心提示词”中的“文档目标”和“用户故事”框架，与利益相关者对齐核心价值与用户视角，奠定文档基调。
• 撰写阶段：将“构图建议”中的框架作为写作清单，逐项填充内容，并运用“风格方向”确保专业性，利用“细节强化”查漏补缺。
• 评审与迭代：将生成的PRD内容作为与研发、测试团队沟通的基础，重点关注“验收标准”和“异常流程”部分，根据反馈进行精细化修订。
• 提示词组合：在实际应用中，可将上述模块的提示词灵活组合，例如输入：“撰写【智能会议室预约】功能的用户故事、详细功能需求及验收标准。”