高效云原生平台PRD需求文档提示词

角色定义与任务定位
请以“云原生平台产品负责人”或“资深技术产品经理”的身份，运用你对容器化、微服务、DevOps及云原生生态的深刻理解，核心目标是：生成一份结构清晰、技术精准、具备高度可执行性的《高效云原生平台》产品需求文档。这份文档将作为指导开发、测试、运维团队统一行动的蓝图，并确保最终产品在弹性、可观测性、自动化与成本效益上达到业界先进水平。

适用场景

从0到1规划一个全新的企业级云原生应用平台。
对现有传统中间件或PaaS平台进行云原生现代化重构。
为内部开发团队提供标准化的、自助式的云原生服务目录。
撰写用于项目立项、技术评审或对外合作的技术解决方案文档。


核心提示词
以下提示词组合可直接用于生成文档的各个章节，请根据实际情况填充具体细节：

文档概述：编写《高效云原生平台V1.0》产品需求文档，明确文档目的、范围、目标读者及术语定义。
产品愿景与目标：定义平台的核心价值主张：为研发团队提供“高效、稳定、安全、成本可控”的一站式云原生应用生命周期管理解决方案。关键目标包括：应用部署效率提升50%，资源利用率优化30%，实现99.95%的平台服务可用性。
用户角色与用例：详细描述平台核心用户角色：应用开发者、运维工程师、系统管理员、项目管理者。为每个角色绘制关键用户旅程图，例如：“应用开发者通过CI/CD流水线完成从代码提交到生产环境蓝绿发布的完整流程”。
功能性需求：分模块阐述需求：1. 容器编排与管理：基于Kubernetes，支持多集群管理、命名空间配额、工作负载（Deployment/StatefulSet/DaemonSet）的自动化部署与弹性伸缩（HPA）。2. 持续集成与交付（CI/CD）：提供可视化流水线编辑器，支持从代码仓库到镜像构建、安全扫描、自动化测试、多环境（开发/测试/生产）发布的完整流水线。3. 可观测性：集成日志（如Loki）、指标（如Prometheus）、链路追踪（如Jaeger）三大支柱，提供统一的监控仪表盘与告警策略。4. 服务网格：集成Istio或类似方案，实现细粒度的流量管理、熔断、限流与安全策略。5. 配置与密钥管理：提供统一的配置中心与安全的密钥管理服务。
非功能性需求：明确要求：安全性（镜像漏洞扫描、网络策略、RBAC权限控制）、高可用性（多可用区部署、故障自愈）、性能（API响应时间<100ms）、可扩展性（支持插件化扩展新能力）、兼容性（支持主流公有云及私有化部署）。
成功指标与验收标准：定义可量化的成功指标：平均部署时长、平台月度可用率、关键事务处理吞吐量、用户满意度调查得分。


风格方向

文档风格：采用专业、严谨、无歧义的技术文档风格。语言精确，避免模糊描述。
结构层次：逻辑递进，采用“总-分”结构。从业务背景到技术细节，从用户视角到系统实现。
视觉辅助：在文档中预留位置，用于插入系统架构图（如C4模型或部署架构图）、用户操作流程图、实体关系图（ERD）和数据流向图。


构图建议（信息架构与视觉隐喻）

整体架构图：采用分层架构图进行视觉表达：基础设施层（IaaS）、容器编排层（Kubernetes）、平台服务层（CI/CD、监控、网格等）、应用层。使用清晰的边界和箭头指示数据流与控制流。
流程示意图：使用泳道图描述跨角色的关键流程，如“应用发布流程”，清晰标注开发者、CI/CD系统、平台控制面、运行时环境等不同泳道中的动作与决策点。
仪表盘草图：描述平台管理控制台的首页仪表盘应包含的核心信息模块：集群健康状态、近期部署活动、资源消耗TOP榜、实时告警列表。


细节强化

技术选型描述：不仅列出组件（如Kubernetes, Prometheus, ArgoCD），更要简要说明选型理由与核心解决的能力痛点。
API与接口定义：对关键平台API（如应用部署API、查询服务状态API）给出请求/响应示例，明确方法、路径、参数和返回码。
异常处理与边界情况：详细描述关键操作失败场景下的处理逻辑与用户提示，例如：“当集群资源不足时，平台应拒绝部署并给出明确的资源申请指引”。
成本与资源规划：提供初步的资源预估模型，例如：管理100个微服务Pod所需的核心数、内存容量及存储空间。


使用建议

将上述“核心提示词”作为文档大纲，逐项展开填充具体内容，即可形成完整的PRD草稿。
在撰写“功能性需求”时，务必遵循“作为[用户角色]，我希望[达成某个目标]，以便于[获得某种价值]”的用户故事格式，确保需求以用户为中心。
生成文档后，建议组织跨部门（产品、研发、测试、运维）评审会，重点核对“非功能性需求”与“验收标准”的可行性与明确性。
此提示词框架具有扩展性，可根据实际项目复杂度，在“服务网格”、“安全合规”等模块下进一步深化二级或三级需求条目。