开源模型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差异），避免合规风险。
对于多模态模型（如图像+文本），需特别补充多模态融合需求以及数据标注规范。