前端工程PRD需求文档完整流程提示词

角色定义与任务定位
请以“资深前端架构师”或“严谨的产品技术对接人”的身份，运用本方案。你的核心目标是：系统化地生成一份逻辑严密、细节清晰、对前端开发具有直接指导意义的《产品需求文档（PRD）》。这份文档应能精准传达产品意图，明确技术边界，并成为前端开发、测试及后续维护的可靠依据。

适用场景

从产品原型或交互稿转化为正式技术需求文档。
为复杂前端功能模块（如单页应用路由、状态管理、组件库集成）撰写专项需求。
在新项目启动或迭代规划时，建立统一、规范的需求描述标准。
面向外包或跨团队协作时，提供无歧义、可评估的技术需求说明。


核心提示词
以下提示词组合可直接用于生成文档框架或具体章节内容：

“作为一份前端工程PRD，文档首要目标是定义清晰的功能边界与技术实现路径。请从【项目概述与目标】开始撰写...”
“在【功能需求详述】章节，请为‘用户登录模块’列出：1. 功能描述；2. 输入/输出定义；3. 界面元素与交互逻辑；4. 前端验证规则；5. 与后端API的对接规范（包含请求方法、数据格式、成功/错误状态码处理）。”
“撰写【非功能性需求】部分，需具体涵盖：性能指标（如首屏加载时间<2秒）、浏览器兼容性列表（Chrome 90+， Safari iOS 14+）、响应式布局断点定义、可访问性（A11y）等级要求、以及核心代码的单元测试覆盖率目标。”
“在【数据与状态管理】部分，请描述关键前端数据模型（如User对象结构），并说明应用状态管理方案（如使用Vuex/Pinia模块还是React Context），定义状态流转图。”
“生成【部署与发布】检查清单，包括：构建环境变量配置、静态资源CDN上传规则、版本号标记规范、以及回滚预案。”


风格方向

文体风格：采用客观、精准、无歧义的说明文风格。避免营销性、情绪化描述。
术语使用：准确使用前端专业术语（如Props、生命周期、防抖节流、SSR），并对团队内可能产生分歧的术语提供简短解释。
表述基调：以“必须”、“应该”、“可以”等RFC 2119关键词来区分需求的强制性等级，体现文档的严谨性。


构图建议（信息组织架构）
将文档想象为一个层次分明的信息架构图，建议按以下逻辑“构图”：

顶层（远景）：项目概述、业务目标、用户角色。
中层（主干）：功能模块分解、用户故事/用例、流程图（业务流程图、页面流转图）。
底层（细节）：每个功能的UI/UX描述、数据接口定义、状态逻辑、异常处理。
支撑层（约束）：非功能性需求、兼容性要求、依赖项、假设与风险。


细节强化

接口定义：使用类似TypeScript的接口语法或表格，明确定义API请求/响应体的字段名、类型、是否必填、示例值及描述。
交互状态：详细描述按钮的多种状态（默认、悬停、点击、禁用、加载中）及其视觉与行为反馈。
边界情况：针对网络异常、数据为空、权限不足、输入超限等场景，给出明确的前端处理方案。
版本记录：在文档头部设立清晰的修订历史表，记录版本号、修改日期、修改内容、修改人。


使用建议

生成初稿后，请将核心“功能需求”和“接口定义”部分抽取出来，与后端开发、测试工程师进行专项评审，确保理解一致。
将“非功能性需求”作为前端技术选型和代码审查的客观依据。
在文档中嵌入或链接高保真设计稿、原型图的具体节点，实现图文互参，避免描述失真。
将本提示词方案中的“核心提示词”作为模板，在每次撰写新模块需求时进行填空和扩展，可大幅提升效率与规范性。