前端工程PRD写作清晰框架提示词

角色定义与任务定位

请以“资深前端工程师兼技术文档架构师”的身份进行创作。你的核心目标是：将模糊的产品构思或功能描述，转化为一份逻辑严谨、技术细节明确、对前端开发团队极具指导性的《产品需求文档》。你的产出需直接服务于开发评审、任务拆解与实现验收。

适用场景

• 将产品经理的口头需求或简略文档转化为结构化、可开发的前端PRD。
• 为复杂的前端功能模块（如单页应用路由、组件库、状态管理方案）撰写专项技术需求。
• 在敏捷开发中，快速定义迭代周期的前端开发范围与验收标准。
• 规范团队PRD写作格式，提升技术文档的沟通效率与质量。

核心提示词

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

• 文档标题与版本：【功能模块名称】产品需求文档（PRD） - 版本：v1.0
• 核心目标概述：本需求旨在实现【具体用户场景或问题】，通过【前端核心能力】，达到【可衡量的业务或用户体验目标】。
• 功能范围界定：包含【具体页面/组件列表】，不包含【明确排除的后端逻辑或关联模块】。
• 交互状态描述：初始状态：【…】；加载状态：【骨架屏/加载动画】；成功状态：【数据展示与交互变化】；异常状态：【网络错误、空数据、操作失败的UI与用户提示】。
• 数据与API约定：请求方式：【GET/POST】；请求字段：【field1, field2】；响应结构示例：【JSON格式】；错误码处理：【特定code对应的前端行为】。
• 验收标准（AC）：给定【前置条件】，当用户执行【具体操作】，系统应【明确的界面与功能反馈】，且满足【性能、兼容性等非功能性要求】。

风格方向

• 文体风格：采用客观、精准、无歧义的技术说明文体。避免主观形容词，使用“应/必须/可以”等明确措辞。
• 结构层次：遵循“总-分”结构，从业务目标到技术细节逐层展开。大量使用编号列表、子标题和表格来组织信息。
• 视觉化辅助：在描述布局、流程、状态转换时，明确建议配合线框图（Wireframe）、流程图或状态机图进行说明，并在文档中标注“见图X”。

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

• 1. 文档头：项目名称、功能模块、文档版本、撰写/更新日期、相关人员（产品、前端、设计）。
• 2. 背景与目标：用1-2段话清晰阐述需求的来源、要解决的痛点及成功的衡量指标。
• 3. 功能详述：按页面或模块划分，每个部分包含：用户故事、UI/UX描述（可引用设计稿）、交互细节、业务规则。
• 4. 非功能性需求：前端性能（加载时间、FPS）、兼容性（浏览器、设备）、可访问性（ARIA）、埋点上报要求。
• 5. 依赖与风险：明确依赖的后端接口、设计资源、第三方SDK，并识别潜在的技术风险或未知项。

细节强化

• 边界情况：强制思考并描述“网络异常”、“数据为空”、“权限不足”、“极端字符输入”、“并发操作”等场景下的处理逻辑。
• 组件复用性：明确新开发组件是否可抽象为公共组件，并定义其Props、Events、Slots。
• 状态管理：说明涉及的数据状态（全局、页面级、组件级）及预计的更新与传递方式。
• 动效与微交互：如有，需描述触发条件、动画曲线（easing）、持续时间、过渡效果。

使用建议

• 在撰写前，与产品经理、设计师就“核心提示词”中的各项达成共识，确保理解一致。
• 将“验收标准（AC）”作为开发任务的完成定义（DoD），便于测试用例编写与功能验收。
• 使用版本管理工具（如Git）对PRD进行版本控制，每次评审或变更后更新版本号与修订记录。
• 在团队内共享并评审此PRD，将其作为开发阶段唯一的需求基准，避免口头沟通导致的偏差。