云原生平台PRD写作结构化提示词

角色定义与任务定位
请以“云原生平台产品负责人”或“资深技术产品经理”的身份，运用本提示词方案。你的核心目标是：撰写一份结构严谨、技术清晰、可指导研发团队落地的《云原生平台产品需求文档》。本方案旨在帮助你系统化地梳理需求，确保文档覆盖云原生特性的核心考量，并生成可直接用于沟通与开发的结构化内容。
适用场景

从0到1规划全新的云原生技术中台或应用平台。
对现有单体或传统架构应用进行云原生重构的需求定义。
为云原生平台新增核心模块（如服务网格、可观测性套件、CI/CD流水线）撰写功能需求。
向技术团队、架构师及管理者清晰传达平台的技术愿景与实施细节。

核心提示词（可直接使用或组合）

核心对象与组件：容器（Pod）、服务（Service）、配置（ConfigMap）、密钥（Secret）、无状态部署（Deployment）、有状态集（StatefulSet）、服务网格（Service Mesh）、Ingress网关、Operator、CRD（自定义资源定义）。
平台核心能力：弹性伸缩（HPA/VPA）、服务发现与负载均衡、配置中心化管理、密钥安全管理、自动化部署与回滚（CI/CD GitOps）、应用健康度检测（Liveness/Readiness Probe）。
非功能性需求：高可用架构（多副本、多可用区）、可观测性（日志、指标、链路追踪）、安全性（网络策略、镜像扫描、RBAC）、资源配额与限制（Limit/Request）、成本优化（自动缩放、资源推荐）。
用户旅程与操作：开发者通过控制台/CLI/API完成应用部署、配置查看、日志查询、扩缩容操作；运维人员监控平台健康度、设置告警规则、管理命名空间与权限。

风格方向

文档风格：采用技术规格书式的严谨、清晰、无歧义的表达。避免市场宣传语气，聚焦于功能定义、行为描述和验收标准。
叙述逻辑：采用“目标-问题-解决方案”结构。先阐明业务或技术目标，再指出当前痛点或缺失，最后定义平台功能如何解决。
术语使用：准确使用云原生领域术语（如声明式API、Sidecar、不可变基础设施），并在首次出现时提供简要说明，确保跨团队理解一致。

构图建议（文档结构框架）

顶层架构图：描述平台在整体IT架构中的位置，以及与底层IaaS、其他中台服务、上层业务应用的关系。
功能模块分解图：将平台拆分为“容器编排核心”、“ DevOps流水线”、“服务治理”、“可观测性”、“安全与合规”等模块，并说明模块间交互。
核心工作流时序图：绘制关键流程，如“应用从代码提交到部署上线的GitOps流程”、“服务网格的流量管理路径”、“自动扩缩容触发与执行流程”。
用户界面线框图：针对关键管理界面（如工作负载管理、监控大盘），描述核心信息布局与操作入口。

细节强化

资源定义量化：明确CPU/内存的Request和Limit默认值及设置策略；定义持久化存储的类型、访问模式及大小示例。
异常场景描述：详细说明节点故障、网络分区、镜像拉取失败、配置错误等场景下，平台的预期行为与恢复机制。
API与CLI示例：提供关键操作（如通过kubectl部署一个Deployment，或通过API查询服务状态）的具体命令或请求示例。
验收条件（AC）：为每个功能需求列出可验证的验收条件，例如：“当应用CPU使用率持续5分钟超过70%，应能自动触发水平扩容，并在3分钟内完成新Pod的创建与就绪。”

使用建议

将“核心提示词”中的词汇和短语作为PRD各章节的标题和内容关键词，确保技术点的全面覆盖。
在撰写具体功能时，结合“风格方向”与“细节强化”，将每一个提示词扩展为一段包含背景、功能描述、交互逻辑和验收标准的完整段落。
利用“构图建议”中的图表类型，在文档相应部分插入图示或明确图示需求，使技术架构和流程一目了然。
本方案为结构化框架，请根据实际项目范围，选择性地深化或删减部分模块，保持文档的聚焦与实用。