进阶版开源模型产品需求写作提示词

角色定义与任务定位
请以“开源AI模型产品架构师”的身份，运用本方案。你的核心目标是：系统化地拆解与定义一款开源模型产品的功能、技术与非功能性需求，产出一份逻辑严密、细节清晰、可供开发团队直接执行与评估的PRD（产品需求文档），以推动项目高质量落地。
适用场景

为即将开发或迭代的开源大语言模型、文生图模型、多模态模型撰写产品需求。
向开源社区或内部技术团队清晰阐述模型的技术目标、能力边界与评估标准。
在项目初期，结构化地梳理模型的核心特性、依赖项和发布计划。

核心提示词
以下提示词组合可直接用于生成需求文档的特定章节，请根据实际情况填充“{变量}”。

需求概述： 撰写一份关于“{模型名称}”开源模型的产品需求文档。该模型旨在解决“{核心问题，如：高精度代码生成}”问题，目标用户是“{开发者/研究人员/特定行业从业者}”。首要目标是实现“{首要技术指标，如：在HumanEval基准上达到85%通过率}”。
核心能力定义： 详细定义模型的以下核心能力：1) 核心任务：{例如：文本补全、对话、指令遵循}；2) 支持上下文长度：{例如：128K tokens}；3) 支持输入/输出格式：{例如：文本、JSON、Markdown}；4) 知识截止日期：{例如：2024年7月}。
技术规格要求： 明确模型的技术参数：1) 模型架构：{例如：Decoder-only Transformer}；2) 参数量级：{例如：7B/13B/70B}；3) 预训练数据规模与构成：{例如：3万亿token，包含代码、学术论文、网页}；4) 量化支持：{例如：支持GPTQ/AWQ 4-bit量化}；5) 最低硬件部署要求：{例如：至少16GB VRAM的GPU}。
非功能性需求： 规定模型必须满足：1) 性能：{例如：在指定硬件上推理速度≥100 tokens/秒}；2) 可复现性：提供完整的训练脚本、超参数配置与数据清洗流程；3) 安全性：通过{例如：红队测试}，并内置{例如：拒绝有害请求}的机制；4) 许可协议：采用{例如：Apache 2.0}开源协议。

风格方向

文档风格： 采用技术报告与项目管理文档的结合体，语言精准、客观、无歧义。
表述基调： 理性、严谨、面向执行。避免市场宣传口吻，聚焦可验证、可测量的技术描述。
结构层次： 遵循“总-分-总”逻辑，从愿景到具体指标，再到实施路径，层层递进。

构图建议（信息架构）
将整份需求文档视为一个需要清晰“构图”的信息产品：

全景（文档首页）： 放置版本历史、修订记录、文档摘要与核心目标。
焦点（核心章节）： 将“核心能力定义”与“技术规格”作为视觉（阅读）焦点，使用加粗、列表突出关键数据。
层次（章节安排）： 按“背景与目标 -> 功能需求 -> 非功能需求 -> 数据与训练 -> 评估指标 -> 发布与维护”顺序构建层次。
留白（可读性）： 在关键指标和复杂描述前后预留“留白”，即使用段落间隔、列表和表格来增强可读性，避免信息过载。

细节强化

数据细节： 不仅说明数据量，还需描述数据来源分布、质量过滤方法、去重策略及可能的偏差说明。
评估细节： 明确列出所有评估基准（如MMLU、GSM8K、MT-Bench），并定义每个基准的“通过”阈值。包含效率评估（吞吐量、延迟）和成本评估（训练/推理FLOPs）。
交付物细节： 具体化交付物清单：模型权重文件格式（.safetensors）、推理代码示例、Docker镜像、微调教程、API接口文档（如OpenAI格式）。
协作细节： 明确社区协作接口，如Issue模板、贡献指南、代码审查标准。

使用建议

将“核心提示词”中的每一条作为独立段落或小节的写作起点，展开成详细描述。
在撰写时，不断自问：“这一条需求是否可被开发验证？是否会被不同的人理解为不同的意思？”以确保无歧义。
优先使用量化指标（数字、百分比、标准基准分数）代替定性描述（“很快”、“很好”）。
最终文档应同时服务于两类读者：技术决策者（看目标、看指标）和执行开发者（看参数、看脚本）。