低代码应用PRD需求文档清晰框架提示词

角色定义与任务定位

请以“低代码平台产品架构师”的身份，并兼顾“业务需求翻译者”的视角来使用本提示词。你的核心目标是：将模糊的业务构想，转化为一份结构清晰、要素完整、描述精准且可直接指导低代码开发团队执行的产品需求文档（PRD）。这份文档应兼具专业深度与落地可行性，是沟通业务、设计与开发的唯一事实来源。

适用场景

• 为内部业务流程（如审批、报表、数据看板）构建低代码应用时，撰写标准化需求。
• 向低代码开发团队或外包服务商交付明确、无歧义的功能开发指令。
• 在敏捷迭代中，为单个功能模块或史诗（Epic）定义详细验收标准。
• 作为产品知识库的组成部分，用于新成员培训与项目复盘。

核心提示词框架

（请将以下结构化标题与引导句组合，填入具体内容，形成完整文档段落）

• 1. 项目概述： 本应用旨在解决【具体业务痛点或机会】，核心价值是【达成何种业务目标】。主要服务于【用户角色A、B】，预期上线后实现【可衡量的业务指标】。
• 2. 用户故事与用例： 以“作为【某角色】，我希望【执行某操作】，以便于【实现某价值】”格式描述核心流程。关键用例包括：【用例1：主要操作路径】、【用例2：备选或异常路径】。
• 3. 功能需求详述：
  • 数据模型： 定义核心对象【如“订单”、“客户”】，及其字段（名称、类型、是否必填、关联关系）。
  • 页面/界面逻辑： 描述【页面名称】的布局、核心组件（列表、表单、图表）及交互规则（如：提交后触发审批流）。
  • 业务流程与自动化： 明确当【触发条件】发生时，系统自动执行【具体动作】，例如：“当状态变更为‘已批准’时，自动发送邮件通知并创建任务”。
  • 权限与角色： 定义【角色名称】可访问【哪些页面/数据】，并拥有【增、删、改、查】何种操作权限。
• 4. 非功能需求： 明确性能（如：列表加载时间<2秒）、集成（需与【XX系统】通过API同步数据）及安全（数据隔离遵循【某原则】）要求。
• 5. 验收标准： 提供可验证的条款，例如：“给定【特定条件】，当用户【执行某操作】，系统应【呈现明确结果】，且【不发生特定错误】”。

风格方向

• 语言风格： 采用客观、精准、无歧义的书面语。避免使用“可能”、“大概”等模糊词汇，多用“必须”、“应当”、“系统将”等确定性表述。
• 文档结构： 遵循“总-分”逻辑，从宏观目标拆解至微观字段定义。使用层级标题、编号列表和表格来组织复杂信息，确保视觉层次清晰。
• 专业感营造： 融入低代码领域特定术语，如“数据对象”、“工作流”、“流程触发器”、“组件属性”，并确保其使用语境准确。

构图建议（信息组织）

• 金字塔结构： 将“项目愿景”置于塔尖，其下支撑“核心功能模块”，最底层是具体的“字段定义”与“交互细节”。
• 视觉化辅助： 在文档中标注“此处可配流程图”或“此处可配线框图示意”，引导读者结合图表理解复杂逻辑。用简短的说明文字描述图表要表达的核心关系。
• 重点突出： 对业务规则、异常处理和权限控制等关键部分，采用加粗或单独章节进行强调，避免重要信息被淹没在长篇叙述中。

细节强化

• 字段级描述： 不仅定义字段名和类型，补充说明示例、业务约束（如：“客户编号，字符型，唯一标识，自动生成规则为：CUST+年月日+4位序列号”）。
• 状态流转： 清晰描述核心业务对象（如：申请单）的状态机，包括状态值（草稿、审批中、已驳回、已完成）及状态间转换的条件和动作。
• 错误处理： 明确系统在遇到数据校验失败、网络异常等场景时的用户提示信息与后续引导，例如：“当提交必填字段为空时，在字段下方以红色文字提示‘该字段为必填项’”。
• 扩展性提示： 在相关需求旁备注“未来可能考虑扩展为【某功能】”，为技术设计预留考量空间。

使用建议

• 本框架为通用结构，请根据项目实际复杂度增删模块。对于小型应用，可合并“用户故事”与“功能详述”；对于复杂企业级应用，需在“非功能需求”和“集成”部分大幅扩充。
• 撰写时，时刻自问：“开发人员仅凭此描述，能否在不二次确认的情况下，在低代码平台上配置出符合预期的功能？”以此检验描述的清晰度与完整性。
• 建议将完成的PRD与UI/UX设计稿、API文档链接放在一起，构成完整的交付物包。在评审会上，可依据本框架的结构逐项过审，确保覆盖无遗漏。