进阶版云原生平台PRD写作提示词

角色定义与任务定位

请以“云原生平台产品架构师”或“资深技术产品经理”的身份，运用本方案。你的核心目标是：为下一代或迭代升级的云原生平台，撰写一份具备技术前瞻性、架构清晰度与商业说服力的《产品需求文档》。这份文档需超越基础功能描述，深入阐述平台的技术选型、架构演进、运维哲学及生态价值。

适用场景

• 规划全新云原生平台产品线，定义其核心差异化特性。
• 为现有云原生平台（如容器平台、微服务治理平台）规划重大版本升级，引入服务网格、Serverless、混沌工程等进阶能力。
• 向技术决策层、研发团队及投资人阐述平台的技术愿景与实施路径。
• 作为研发团队进行系统设计与开发迭代的权威输入与共识基准。

核心提示词

以下提示词组合可直接或稍作修改后，用于文档章节生成或AI辅助写作：

• 平台愿景与定位： “定义一个面向混合云与边缘计算场景的、以应用为中心的云原生平台，其核心价值在于通过统一的抽象层，实现应用的全生命周期智能化管理与极致弹性。”
• 核心能力阐述： “详细描述平台在‘不可变基础设施’、‘声明式API’、‘Operator模式’和‘GitOps工作流’上的具体实现方案与带来的运维范式转变。”
• 架构演进重点： “对比从传统Kubernetes发行版到‘平台工程’理念的演进路径，重点说明内置的开发者自服务门户、内部开发者平台及策略即代码的集成方案。”
• 非功能性需求： “明确平台在多租户隔离、可观测性（链路追踪、日志、指标的统一）、安全性（零信任网络、秘密管理、合规扫描）及成本优化（智能资源调度与计费）方面的设计目标与验收标准。”

风格方向

• 技术专业与精准： 准确使用云原生领域术语（如Sidecar、CRD、HPA、Service Mesh），避免模糊表述。
• 结构化与层次化： 文档结构遵循“业务目标->用户故事->功能特性->技术规格”的逻辑链条，大量使用列表、表格和架构图进行说明。
• 前瞻性与务实结合： 在描述技术愿景时，引用行业趋势（如FinOps、AIOps）；在定义需求时，关联具体的用户痛点与使用场景。
• 价值导向： 每个功能模块的描述，都应明确其带来的商业价值（如降本增效、加速交付、提升稳定性）。

构图建议

（此处的“构图”指文档内容的结构布局与视觉化表达思路）

• 总-分-总结构： 开篇用“平台全景架构图”总览，随后各章节分解对应模块，最后以“版本演进路线图”收尾。
• 对比图运用： 使用“传统架构 vs. 云原生架构”、“平台能力演进对比”等图表，直观展示差异与优势。
• 流程与状态图： 为关键工作流（如应用发布回滚流程、故障自愈流程）绘制序列图或状态机图。
• 层次化架构图： 绘制从基础设施层、容器编排层、服务治理层到应用定义层的清晰分层架构。

细节强化

• 技术选型理由： 不仅说明“用什么”（如选择Istio而非Linkerd），更要阐述“为什么”，包括社区生态、性能数据、团队技能匹配度等。
• 可观测性具体指标： 列出必须监控的黄金指标（延迟、流量、错误、饱和度），并定义SLO/SLI的具体计算方式。
• 运维与故障处理： 描述关键故障场景（如控制平面故障、节点大规模失效）的应急预案与恢复步骤。
• 生态集成清单： 明确列出与CI/CD工具链、日志系统、监控告警平台、安全合规工具的官方支持集成列表。
• 成功度量标准： 定义平台上线后的成功关键指标，如应用部署频率、变更失败率、平均恢复时间、资源利用率等。

使用建议

• 将“核心提示词”中的语句作为各章节的写作起点或提纲，进行扩展和细化。
• 在撰写具体功能时，遵循“用户故事 -> 验收标准 -> 技术实现要点”的三段式描述法。
• 使用“风格方向”作为文档的润色指南，确保全文调性统一、专业。
• 参考“构图建议”与“细节强化”来查漏补缺，确保文档既具备战略高度，又包含可执行的工程细节。
• 最终文档应是一份“活”的文档，建议使用版本控制工具管理，并随着项目进展持续迭代更新。