云原生平台PRD需求文档结果优化提示词

角色定义与任务定位

请以云原生产品架构师兼技术文档策划者的身份，运用本方案。你的核心目标是：将一份关于云原生平台的功能性、非功能性需求描述，系统性地优化为一份逻辑清晰、视觉直观、可直接指导开发与测试团队落地的结构化PRD文档。你需要确保文档不仅文字准确，更能通过视觉化元素（如架构图、流程图、状态图）和结构化提示，精准传达云原生场景下的技术要点与设计意图。

适用场景

• 为全新的云原生平台（如容器平台、微服务治理平台、Serverless平台）撰写初始PRD。
• 对现有云原生平台的迭代功能（如弹性伸缩策略升级、服务网格集成、可观测性增强）进行需求细化与文档化。
• 将模糊的业务需求转化为具备明确技术边界和实现路径的云原生特性需求。
• 在跨团队（产品、开发、运维、测试）评审前，准备一份高度结构化、可视化的需求基准文档。

核心提示词

以下提示词组合可直接用于文档生成或辅助思考，请根据具体需求选取和组合：

• 架构可视化提示：生成一张基于 [例如：Kubernetes] 的云原生平台高阶架构图，清晰展示控制平面、数据平面、运维支撑模块及其交互关系。
• 需求条目化提示：将“高可用性需求”分解为具体的、可验收的条目，例如：1. 多可用区部署架构；2. 无状态服务实例数 ≥ 3；3. 核心组件故障自动转移时间 < 30秒。
• 流程定义提示：描述并绘制一个 [例如：基于GitOps的] 应用从代码提交到生产环境部署的完整自动化流水线，包括镜像构建、安全扫描、渐进式发布等关键节点。
• 非功能性需求量化提示：定义平台性能指标，如：P99 API响应延迟 < 100ms，单集群支持Pod数量 ≥ 5000，跨区域网络同步延迟 < 10ms。
• 技术选型与约束提示：明确说明必须兼容的云原生生态项目（如Prometheus, Istio, ArgoCD）及版本范围，或必须遵守的安全合规框架（如等保2.0、PCI DSS）。

风格方向

• 专业极简风：采用清晰的层级标题、一致的术语、留白充足的版式，避免冗余描述。色彩使用上，建议以科技蓝、深空灰为主色调，搭配少量提亮色（如绿色代表成功/健康，橙色代表警告）。
• 图表驱动叙事：文档应以逻辑图表为核心叙事工具。架构图采用容器化、微服务化的图标元素；流程图使用标准符号，并突出决策分支和异常处理路径。
• 面向实战的语调：使用肯定、明确的语句，多采用“必须实现”、“应支持”、“建议采用”等层级分明的措辞，直接关联到具体的云原生技术动作和交付物。

构图建议（文档视觉结构）

• 封面与版本历史：突出项目名称、核心目标、文档版本及修订记录，建立正式感。
• 全景架构图前置：在文档开头部分，放置一张总览式架构图，让读者快速建立整体认知。
• 模块化内容分区：将内容划分为“概述与目标”、“用户故事与用例”、“系统架构”、“详细功能需求”、“非功能需求”、“数据与接口定义”、“部署与运维方案”、“验收标准”等模块，每个模块配以摘要或关键图表。
• 图文紧密耦合：文字描述旁，尽可能附上对应的示意图、序列图或状态迁移图，实现“一图胜千言”的效果。

细节强化

• 精准术语：统一并明确定义术语，如“工作负载”、“服务网格边车”、“不可变基础设施”、“声明式API”。
• 环境与配置分离：明确区分开发、测试、预发、生产等不同环境的需求差异，以及配置管理的策略（如ConfigMap, Secret的使用规范）。
• 故障域与韧性设计：在需求中明确描述应对节点故障、可用区中断、网络分区等场景的设计方案和预期行为。
• 可观测性埋点：作为需求的一部分，明确要求关键业务流与平台组件的Metrics、Logs、Traces采集点与输出格式。
• 材质与质感隐喻：在图表中，可用不同质感区分组件，如：核心服务用光滑金属质感，数据存储用块状结构，网络流量用流动线条。

使用建议

• 迭代编写：先使用核心提示词搭建骨架和关键图表，再填充文字细节，遵循“从宏观到微观”的撰写顺序。
• 团队协同：将生成的架构图和流程草图用于早期团队评审，收集反馈并迭代优化，确保理解一致。
• 链接至代码：在PRD中，可以为关键需求项建立与设计文档、原型仓库或Issue跟踪系统的超链接，形成可追溯的需求链条。
• 提示词变体：针对特定场景，可将“核心提示词”具体化，例如：“生成一个展示服务A到服务Z，在服务网格中金丝雀发布流量权重逐步变化的序列图”。