低代码应用PRD需求文档专业版提示词

角色定义与任务定位
请以一名资深低代码解决方案架构师或严谨的产品需求分析师的身份，运用结构化思维与清晰的业务逻辑，撰写一份专业、详尽且可直接用于低代码平台开发的需求文档（PRD）。你的核心目标是：将模糊的业务需求转化为低代码平台上可配置、可实现的明确功能点、数据模型与交互流程，确保文档兼具业务视角与技术落地性。

适用场景

为内部业务流程（如审批、报销、CRM）构建低代码应用时，撰写启动文档。
向低代码开发团队或公民开发者传递清晰、无歧义的功能与数据需求。
在敏捷开发中，快速定义版本迭代（如V1.0核心功能）的范围与规格。
标准化低代码项目的需求输入，确保文档质量与可追溯性。


核心提示词
（请将以下提示词组合或选择使用，作为生成请求的核心指令）

“作为低代码产品经理，请撰写一份关于【员工请假审批】应用的PRD。文档需包含：项目概述、用户角色（员工、部门经理、HR）、核心流程的泳道图描述、数据实体（请假单、审批记录）及其字段、界面布局（列表页、表单页、仪表盘）的线框图描述，以及非功能性需求（如权限控制规则）。”
“生成一份结构化PRD，主题是【会议室预约管理系统】。要求明确：业务目标、用户故事（作为…我希望…以便…）、系统功能清单、主要数据模型关系图（用文字描述）、关键业务规则（如预约冲突检查逻辑），以及低代码平台相关的实现约束说明（如使用平台自带的日历组件）。”
“请以专业需求文档格式，详细描述一个【客户服务工单跟踪】低代码应用的需求。重点包括：工单状态流转图、各角色（客服、客户、管理员）的操作权限矩阵、工单表单的详细字段定义（类型、必填、来源）、报表与统计需求（如按状态分类的工单数量统计看板）。”


风格方向

文档风格：专业、严谨、结构化。采用分章节、多级标题、要点列表的方式组织内容，避免冗长段落。
语言调性：客观、精准、无歧义。使用“应”、“必须”、“建议”等明确的需求描述词汇，避免模糊的“可能”、“大概”。
视觉化辅助：在描述流程、数据关系、界面布局时，优先采用“用文字描述图表”的方式（如：“绘制泳道图，泳道包括：申请人、审批人、系统…”），为后续可视化设计提供精确脚本。


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

顶层结构：采用经典PRD框架：1. 文档修订历史；2. 项目概述（目标、范围、用户）；3. 功能需求详情；4. 非功能需求；5. 附录（术语表等）。
功能详述构图：对每个核心功能模块，按“功能描述 -> 用户流程 -> 业务规则 -> 数据字段 -> 界面元素”的层次展开。
流程构图：用“触发条件 -> 流程步骤 -> 分支判断 -> 结束状态”的逻辑链描述业务流程，明确每一步的责任角色与系统动作。


细节强化

数据模型：明确定义每个实体的字段名、数据类型（文本、数字、日期、选项列表）、是否必填、默认值及关联关系（如：一张“订单”关联多个“订单项”）。
业务规则：将业务逻辑转化为明确的“如果…那么…”规则语句。例如：“如果请假天数超过5天，那么必须经由二级经理审批。”
权限细节：具体到“角色-对象-操作”级别，如：“部门经理可以‘查看’和‘审批’本部门所有员工的请假申请，但不可‘删除’。”
低代码特性：指出可考虑使用平台特定组件（如表单生成器、流程引擎、报表模板）来实现的部分，使需求更贴合低代码开发模式。


使用建议

在使用核心提示词时，将【】中的主题替换为您的具体业务场景，并可根据需要增删强调的重点（如更侧重流程或更侧重数据）。
生成初稿后，请重点检查“业务规则”和“数据字段”部分是否足够明确、无二义性，这是低代码开发直接配置的依据。
可将生成的PRD文本直接导入知识库，或将其中的结构化描述（如流程步骤、字段列表）复制粘贴到项目管理工具或低代码平台的需求模块中，作为开发任务的创建基础。
此提示词方案同样适用于对已有PRD进行查漏补缺或结构化优化，可针对薄弱环节（如缺少权限定义）进行定向扩写。