专业版开源模型PRD需求文档提示词

角色定义与任务定位

请以“开源模型产品负责人”的身份，并怀抱“为开发者社区与贡献者创建一份清晰、可执行的技术蓝图”这一核心目标，来构思与撰写这份PRD。你的产出不是一份泛泛而谈的愿望清单，而是一份能够直接驱动模型设计、开发、测试及社区协作的权威文档。

适用场景

• 为全新的开源模型项目（如大语言模型、文生图模型、多模态模型）撰写初始版本的需求文档。
• 对现有开源模型进行重大版本迭代或新增核心功能（如架构升级、支持新模态、性能优化）时，更新PRD。
• 向潜在的技术贡献者、合作团队或资助方清晰阐述模型的技术目标、实现路径与评估标准。

核心提示词

以下提示词组合可直接用于生成或结构化您的PRD内容。请根据实际情况填充“{ }”内的具体信息。

• 项目概述与目标：“撰写开源模型‘{模型名称}’的PRD概述。首先，明确阐述该模型旨在解决的核心问题（如：在{特定任务}上达到{具体指标}，以弥补现有开源方案在{某方面}的不足）。其次，定义项目的核心原则：必须开源（许可证：{如Apache 2.0}）、注重可复现性、以及社区驱动。”
• 模型规格与架构：“详细定义‘{模型名称}’的技术规格。包括：1. 模型类型（如：仅解码器的Transformer）；2. 参数规模（如：7B/13B/70B）；3. 训练数据构成与来源原则（如：多语言文本配比、开源数据集清单）；4. 关键架构创新或选择（如：使用{RMSNorm}、{SwiGLU}激活函数、{旋转位置编码RoPE}）。”
• 功能与非功能需求：“列出‘{模型名称}’的具体需求清单。功能需求：1. 支持{上下文长度}；2. 具备{工具调用}能力；3. 实现{特定格式}的输出结构化。非功能需求：1. 性能：在{标准硬件}上推理速度达到{具体tokens/秒}；2. 可复现性：提供完整的训练脚本、超参数配置与数据预处理代码；3. 易用性：提供{Hugging Face}模型库集成与{基础示例}。”
• 评估与验证方案：“制定模型‘{模型名称}’的评估体系。明确：1. 核心评估基准（如：在{MMLU}、{GSM8K}、{HumanEval}等上的目标分数）；2. 负责任AI评估维度（如：偏见测评、安全性红队测试）；3. 评估脚本与结果提交的标准化流程。”

风格方向

• 文体风格：技术性、精确、客观。避免营销化语言，采用定义、列表、表格等形式清晰呈现。
• 文档结构：逻辑递进，建议采用“背景与目标 -> 详细规格 -> 需求清单 -> 开发里程碑 -> 评估方案 -> 附录（术语表、参考文献）”的经典结构。
• 视觉隐喻：在描述架构或数据流时，可借用“蓝图”、“管道”、“堆栈”等工程化比喻，增强技术读者的理解。

构图建议（用于辅助理解的图表描述）

• 系统架构图：“一张分层架构图：底层是数据收集与处理管道，中间层是模型训练框架（如Megatron-LM、DeepSpeed），顶层是模型服务与API接口，侧边标注社区贡献与CI/CD流程。”
• 开发路线图：“一个时间轴甘特图，清晰标注预训练、SFT、RLHF、评估、模型发布等关键阶段的起止时间和依赖关系。”
• 数据构成饼图：“一个展示训练数据来源与类型配比的饼图，例如：开源学术论文{30%}、经过滤的网页数据{50%}、代码仓库{20%}。”

细节强化

• 版本控制：明确PRD本身的版本号（如v1.0），并与GitHub的Milestone或Release关联。
• 术语定义：在文档开头或附录提供“关键术语表”，准确定义如“SFT”、“PPO”、“LoRA”等在本项目上下文中的具体含义。
• 假设与约束：清晰列出项目的前提假设（如：可获得足够的算力捐赠）和硬性约束（如：必须使用开源许可的数据）。
• 成功标准：将目标量化为可衡量的指标，例如：“模型在发布后6个月内，在Hugging Face开源大模型榜单相关维度进入前五名。”

使用建议

• 将上述“核心提示词”模块中的每一条，作为一个独立章节的撰写起点，展开成详实的段落。
• 在撰写“功能需求”时，务必使用“作为{用户角色}，我希望{实现某个功能}，以便于{达到某个价值}”的用户故事格式，使其更贴近开发者视角。
• 强烈建议将生成的PRD草案放入开源仓库（如GitHub Wiki或/docs目录），并开启“Discussion”功能，将其作为与社区共识的动态文档，而非静态文件。
• 定期回顾并更新PRD，特别是在项目遇到重大技术决策或社区反馈时，确保其始终是项目开发的“唯一可信源”。