实战型MCP工具PRD需求文档提示词

角色定义与任务定位

请以“资深产品需求架构师”的身份，专注于为“MCP（模型上下文协议）工具”的研发团队撰写一份可直接指导开发与测试的《产品需求文档（PRD）》。你的核心目标是生成一份逻辑严密、描述精准、非技术背景人员也能清晰理解业务逻辑与功能细节的实战型文档，确保产品构想能无歧义地转化为可执行的技术任务。

适用场景

• 为全新的MCP工具（如模型连接器、插件管理器、上下文优化器等）从0到1撰写初始PRD。
• 对现有MCP工具进行重大功能迭代或模块重构时，更新与细化需求文档。
• 在跨部门（产品、开发、测试、运维）评审会上，作为需求对齐与讨论的基准文档。
• 作为后续撰写技术设计文档、测试用例、用户手册的权威输入依据。

核心提示词

可直接用于引导生成或构建文档框架的核心指令组合：

• “撰写一份关于[MCP工具具体名称，如：智能上下文路由网关]的PRD，文档需包含：产品概述、用户角色与画像、核心问题陈述、项目目标与成功指标。”
• “详细定义该MCP工具的‘功能需求’部分，按模块列出：上下文获取接口、协议解析引擎、响应格式化器、错误处理与日志模块。每个功能点需包含：功能描述、输入/输出规格、业务规则、优先级(P0/P1/P2)。”
• “阐述‘非功能需求’，包括：性能要求（如每秒处理请求数、延迟）、安全性要求（如身份认证、数据脱敏）、兼容性要求（支持哪些模型或平台）、可维护性与监控需求。”
• “生成‘用户故事与验收标准’部分，格式为：‘作为[某类用户]，我希望[执行某个操作]，以便于[达成某个价值]。’ 并为每个用户故事列出3-5条具体的、可验证的验收标准。”

风格方向

• 文体风格：采用客观、精准、无歧义的说明文风格。避免营销口吻和主观形容词，多使用“应”、“必须”、“将”等确定性词汇。
• 视觉基调：文档本身应呈现“专业蓝图”感，想象为一份架构图纸或技术白皮书。行文结构清晰，层级分明，关键信息高亮。
• 术语使用：准确使用MCP生态相关术语（如：上下文、工具调用、function calling、schema），并在文档开头提供术语表进行定义。

构图建议（文档结构）

• 1. 文档头：文档名称、版本号、撰写/修订日期、作者、状态（草案/评审/定稿）。
• 2. 修订历史：以表格形式清晰展示版本、日期、修改内容、修改人、审核人。
• 3. 引言：产品愿景、文档范围、目标读者、参考资料。
• 4. 综合描述：产品背景、用户痛点、解决方案概述、假设与依赖。
• 5. 需求详述（核心）：按“功能需求”、“非功能需求”、“用户故事与验收标准”分章节展开，这是文档的躯体。
• 6. 附录：术语表、UI原型链接、数据字典、API接口草案等。

细节强化

• 输入输出示例化：对于关键接口或数据处理流程，必须提供具体的JSON请求/响应示例，而非仅文字描述。
• 状态与流程可视化：用文字清晰描述关键业务状态机（如：上下文生命周期：创建->加载->使用->释放）或数据流图。
• 边界条件明确化：明确指出系统的限制、约束、不支持的情况以及异常处理流程（如：网络中断、协议版本不匹配、上下文超载）。
• 指标量化：所有性能、容量等需求尽可能量化（例如：“在95%的情况下，API响应时间应低于100毫秒”）。

使用建议

• 在使用核心提示词生成初稿后，请务必以“技术评审者”和“终端用户”的双重视角进行审阅，检查逻辑闭环与用户体验。
• 将“验收标准”作为与测试团队沟通的契约，确保每条标准都可被测试用例覆盖。
• 文档中可插入“[待确认]”、“[需与架构师讨论]”等标记，明确标识出尚未决策的部分，推动后续讨论。
• 本方案生成的是一份“内容完备的结构化提示”，您可将各模块提示词输入至大型语言模型，分步骤生成PRD各章节，再整合成文。