MCP工具PRD需求文档高阶版提示词

角色定义与任务定位

请以“资深产品架构师”或“高级技术产品经理”的身份，运用系统化思维与结构化表达，为“MCP（Model Context Protocol）工具”的规划与开发，撰写一份专业、详尽、可执行性强的产品需求文档（PRD）。你的核心目标是产出逻辑闭环、边界清晰、技术可实现的文档，为开发团队提供明确指引，并作为项目管理的核心依据。

适用场景

• 为全新的MCP工具（如客户端、服务器、插件或管理平台）撰写从0到1的完整PRD。
• 对现有MCP工具进行重大功能迭代或模块重构时，更新和细化需求文档。
• 向技术团队、测试团队及项目干系人清晰传达工具的设计意图、功能规格与非功能性要求。
• 作为评估开发工作量、制定项目排期和进行技术方案评审的基础输入材料。

核心提示词

以下提示词组合可直接用于引导生成过程，建议作为文档章节的骨架：

• 撰写一份关于【MCP工具名称，如：MCP Server管理控制台】的高阶PRD。
• 文档需包含：1. 版本与修订历史；2. 项目概述（背景、目标、成功指标）；3. 用户角色与画像；4. 功能需求清单（按模块划分，含优先级）；5. 详细的工具调用流程与API接口规范；6. 非功能性需求（性能、安全性、兼容性、可维护性）；7. 数据模型与状态设计；8. 部署与运维要求；9. 风险与假设；10. 附录（术语表、参考链接）。
• 重点描述工具的核心价值：如何简化MCP服务器管理、如何优化工具发现与加载流程、如何提供可视化的配置与监控能力。
• 明确工具调用的具体场景：例如，“支持通过RESTful API动态注册/注销工具”、“提供CLI命令一键启动附带特定工具集的MCP服务器”。

风格方向

• 文体风格：专业、客观、精确。采用技术文档的书面语，避免营销口吻和模糊表述。
• 逻辑结构：采用自上而下的金字塔结构，从宏观目标到微观细节，层层递进，确保可追溯性。
• 视觉隐喻：在描述架构或流程时，可借用“中枢神经系统”、“插件化积木”、“仪表盘与控制台”等比喻，辅助理解，但需在附录中提供严谨的技术图示说明。

构图建议（文档结构布局）

• 封面与目录：明确文档标题、版本、作者、日期，并提供清晰的目录结构。
• 主体内容流：按照“Why-What-How”的顺序展开：先阐述背景与目标（Why），再定义功能范围与用户（What），最后深入系统设计与实现细节（How）。
• 重点突出：对“工具调用”这一核心部分，采用独立章节，结合序列图、状态图或表格进行说明，使其一目了然。
• 附录与引用：将数据字典、API详细字段、第三方依赖等细节置于附录，保持主文档的简洁与流畅。

细节强化

• 功能需求：使用“作为[用户角色]，我希望[达成目标]，以便[获得价值]”的用户故事格式进行描述，并附上验收标准（Given-When-Then）。
• 工具调用细节：具体说明工具暴露的协议方法、输入/输出参数的数据结构、错误码定义、认证授权机制以及调用频率限制。
• 质量属性：量化非功能性需求，例如：“在标准配置下，工具列表查询API的P99延迟应低于100毫秒”、“支持同时管理至少50个MCP服务器实例”。
• 边界说明：明确说明本工具“不负责”的内容，如“不包含AI模型本身的训练与推理功能”，以界定范围。

使用建议

• 在生成具体内容前，先用核心提示词搭建出完整的文档目录框架。
• 将“高质量”的要求具体化，在提示词中明确“需要包含至少3个用户故事示例”或“需详细描述与LLM交互的数据流”。
• 生成后，请以技术评审的视角检查文档：所有功能是否都有对应的实现路径？所有术语是否定义一致？开发团队能否据此进行工作量评估？
• 此提示词方案可作为模板复用，每次使用时替换【】内的具体工具名称和特性，即可快速启动新PRD的撰写。