开源模型PRD需求文档结构化提示词

角色定义与任务定位

你应当以产品经理（AI方向）的身份，为某个开源模型项目撰写一份PRD（Product Requirements Document）需求文档。你的核心目标是：基于开源社区特性，从市场调研、用户痛点、功能定义、技术指标到交付验收，输出一份结构完整、逻辑严密、可被开发团队直接执行的实战型文档。这组提示词将帮助你从零到一构建文档骨架，并填充专业细节。

适用场景

• 为开源模型（如LLaMA、Stable Diffusion、Whisper等）编写商业化或社区协作版PRD。
• 在技术选型阶段，对比不同开源模型时快速生成需求文档初稿。
• AI创业团队、开源项目维护者用于向投资人、贡献者或内部团队阐述产品规划。

核心提示词

以下提示词建议直接复制到AI工具（如ChatGPT、Claude、文心一言）中使用，根据实际项目名称替换[开源模型名称]：

• “请以产品经理身份，为[开源模型名称]项目撰写一份PRD需求文档。文档需要包含：背景与目标、市场分析与竞品对标、用户画像与核心痛点、功能需求（细分核心功能与辅助功能）、非功能需求（性能、兼容性、可扩展性）、开源协议与社区治理策略、数据集与训练要求、部署与硬件需求、里程碑与验收标准。使用表格对比功能优先级，每条需求需注明验收标准。”
• “将上述PRD中的功能需求部分用MoSCoW方法（Must have / Should have / Could have / Won‘t have）重新组织，并解释为什么每个需求被归入该类别。”
• “请为[开源模型名称]的PRD补充一段风险分析，包括：许可证兼容风险、社区分叉风险、模型偏见与安全问题、硬件成本波动，并给出对应缓解措施。”

风格方向

• 专业严谨：采用正式书面语，避免口语化，使用“应/需/建议”等规范措辞。
• 结构化层次：章节标题清晰，段落间有逻辑递进，如从宏观到微观、从需求到实现。
• 数据驱动：在市场和竞品部分尽可能包含具体数字（如模型参数量、训练成本、社区Stars数）。
• 实战导向：每条需求应有明确的“Why”和“How”，而非空泛描述。

构图建议

虽然PRD是文本，但为了便于阅读，建议AI输出时遵循以下文档框架布局：

• 封面：项目名称、版本号、日期、作者、修改记录。
• 目录（如果输出较长）。
• 正文按三层标题结构：H1（章节）、H2（子节）、H3（具体项）。
• 关键对比使用表格（如功能优先级、性能指标）。
• 验收标准用编号列表（如：AC-001: 模型推理延迟不超过200ms）。

细节强化

• 在“功能需求”中，加入输入/输出规格示例（例如：输入为文本prompt，输出为JSON格式的意图分类结果）。
• 为“非功能需求”添加量化阈值：例如“模型权重要求：4比特量化后≤3GB”；“社区响应时间：Issue首次回复≤24小时”。
• 提及开源生态要素：依赖的框架（如PyTorch、Transformers）、兼容的硬件（NVIDIA A100/RTX 4090）、已知的限制（如不支持长上下文）。
• 包含版本迭代策略：当前版本（v1.0）只支持核心推理，未来版本（v2.0）计划加入微调接口。

使用建议

• 如果你需要快速生成初稿，直接复制“核心提示词”中的第一条，并替换模型名称和具体场景。
• 对于技术团队内部使用，可额外加入“技术附录”段落，涵盖模型架构图、接口设计schema等。
• 若面向投资人，建议在“市场分析”部分增加TAM/SAM/SOM估算，并突出开源模型的成本优势。
• 每次生成后，人工检查许可证条款是否准确（如Apache 2.0 vs MIT差异），避免合规风险。
• 对于多模态模型（如图像+文本），需特别补充多模态融合需求以及数据标注规范。