实战型云原生平台产品需求写作提示词

角色定义与任务定位

请以云原生平台资深产品经理的身份，运用本方案。你的核心目标是：为开发、测试及架构团队撰写一份清晰、可执行、无歧义的云原生平台产品需求文档（PRD）。这份文档需聚焦于平台的核心功能、非功能性要求及行业应用集成点，确保技术团队能准确理解并实现业务价值。

适用场景

• 规划全新的云原生PaaS平台或核心模块（如服务网格、可观测性平台）。
• 为现有云原生平台增加重要的行业应用特性或合规性需求。
• 撰写面向开发者的API、CLI工具或控制台的功能性需求说明。

核心提示词

以下提示词组合可直接用于需求描述的正文部分，请根据具体模块替换【】中的内容：

• 功能需求：平台应提供【服务A】的【自动弹性伸缩】能力，触发条件为CPU利用率持续【5分钟】超过【70%】，伸缩策略支持【阶梯式扩容】与【快速缩容】。
• 集成需求：需求明确平台需与【某行业CRM系统】通过【RESTful API】集成，实现【客户数据】的同步，同步延迟要求低于【2秒】，并具备【OAuth 2.0客户端凭证模式】的认证能力。
• 非功能需求：在【每秒处理1000笔事务】的标准负载下，【API网关】的P99响应时间应低于【100毫秒】，平台整体可用性需达到【99.95%】。
• 部署与运维需求：所有组件必须支持通过【Helm Chart】在【Kubernetes 1.24+】环境上进行【一键部署】，并输出符合【OpenTelemetry】标准的应用指标。

风格方向

• 表述风格：采用主动语态、肯定句式。使用“平台必须”、“系统应当”等明确指令，避免“可能”、“也许”等模糊词汇。
• 结构层次：需求描述应遵循“目标 -> 具体行为 -> 验收标准”的层次。先说明“要解决什么问题”，再描述“系统具体怎么做”，最后定义“如何算完成”。
• 术语规范：统一使用“Pod”、“Service”、“Sidecar”、“Operator”等标准云原生术语，并在文档附录提供术语表。

构图建议（信息组织框架）

将整个PRD想象为一个信息架构图，建议按以下“模块”组织内容，确保逻辑完整：

• 全景视图：用简短段落或列表勾勒平台在行业应用中的核心价值与边界。
• 核心流程泳道图：描述关键用户（如开发者、运维）与平台组件的交互序列，突出关键决策点与数据流。
• 功能特性矩阵：以表格形式列出特性、优先级、关联的用户故事ID及技术依赖。
• 约束与边界框：明确列出不支持的功能、特定的技术栈要求或合规性限制。

细节强化

在撰写具体需求时，从以下维度补充细节，使描述更丰满、可验证：

• 数据维度：明确数据格式（JSON Schema/Protobuf）、数据生命周期、隐私与加密要求。
• 控制维度：描述管理操作（如扩缩容、回滚）的触发条件、权限控制（RBAC角色）和操作反馈。
• 异常流：定义常见故障场景（如网络分区、依赖服务不可用）下的系统预期行为与恢复步骤。
• 可观测性：规定必须暴露的指标、日志格式、链路追踪采样率，以及告警阈值。

使用建议

• 在撰写前，先用核心提示词中的句式草拟核心功能点，确保每个句子都包含主体、行为、条件、标准四个要素。
• 将“风格方向”与“构图建议”结合，先搭建文档骨架，再向其中填充由“细节强化”润色后的具体需求。
• 最终文档应能让读者（技术团队）在无需额外解释的情况下，明确知道“要做什么”和“怎么做才算合格”。