云原生平台PRD需求文档实战版提示词

角色定义与任务定位
请以“云原生解决方案产品经理”或“资深技术文档架构师”的身份，运用本提示词方案。你的核心目标是：为开发团队、架构师及利益相关者，生成一份逻辑严密、技术细节清晰、具备高度可执行性的《云原生平台产品需求文档》。这份文档将作为产品设计与研发的权威蓝图，需平衡业务价值与技术可行性。

适用场景

从零开始规划一个全新的云原生技术中台或服务平台。
对现有单体或传统架构应用进行云原生重构的需求定义。
为特定业务线（如微服务治理、可观测性、DevOps流水线）设计独立的平台模块需求。
向客户或高层汇报云原生平台的核心能力与建设路径。


核心提示词
以下为可直接组合使用的提示词段落，用于生成文档具体章节：

文档概述与目标：“撰写一份云原生平台PRD的‘概述’部分，明确平台的核心定位是‘降低分布式系统复杂度，提升研发运维效能’。列出3-5项顶层业务目标（如：实现应用秒级伸缩、全局可观测性覆盖）和3项关键成功指标（如：部署频率、平均恢复时间MTTR）。”
用户角色与用例：“定义平台的关键用户角色：应用开发者、SRE运维工程师、系统架构师。为‘应用开发者’描述一个核心用户旅程：‘从代码提交到生产环境部署’，并列出其在该旅程中的5个关键需求点（例如：自助式CI/CD流水线、多环境配置管理）。”
功能性需求（按模块）：“详细描述‘容器编排与调度’模块的需求。必须包含：支持Kubernetes作为默认编排引擎；提供基于自定义指标（如QPS、业务队列长度）的HPA策略；支持多集群联邦管理；定义工作负载的亲和性与反亲和性规则。”
非功能性需求：“定义平台的‘可观测性’非功能性需求。具体要求：提供统一的指标（Prometheus）、日志（Loki/ELK）、链路追踪（Jaeger）采集与可视化界面；支持自定义告警规则并对接多种通知渠道（钉钉、企业微信、短信）；保证监控数据查询的P99延迟低于2秒。”
部署与集成需求：“说明平台的基础设施要求：支持混合云部署（公有云AWS/Azure与私有化数据中心）；列出必须集成的第三方服务清单（例如：GitLab/GitHub、Harbor镜像仓库、LDAP/OpenID Connect身份提供商）。”


风格方向

文档风格：采用技术手册与商业文档结合体。语言精准、客观，避免营销化词汇，使用主动语态和肯定句。
视觉基调：在配套的架构图或说明图中，应采用专业、清晰的科技蓝与深灰色系。使用标准的UML时序图、架构组件图或流程图来辅助说明复杂流程。
术语规范：严格统一使用云原生计算基金会（CNCF）生态的标准术语（如：Pod、Service Mesh、Sidecar、Operator），并在文档末尾提供术语表。


构图建议（用于需求可视化）

平台总体架构图：采用分层构图。底层为基础设施层（IaaS），中间为容器编排与核心服务层（CaaS），上层为应用与生态工具层。使用明确箭头指示数据流与控制流方向。
关键流程时序图：针对“应用滚动更新”、“故障自愈”等关键场景，绘制跨系统（用户、平台控制台、API Server、Kubernetes集群）的交互时序图，标注关键决策点与超时设置。
用户界面线框图：对核心管理界面（如工作负载管理面板、监控仪表盘）进行简要线框描述，标注关键信息区域（如资源使用率图表、事件日志列表、操作按钮组）。


细节强化

技术参数具体化：需求中所有性能、容量、时间指标必须量化。例如：“API网关的P99延迟 < 50ms”、“单集群最大支持5000个Pod”。
异常场景覆盖：明确描述系统在节点故障、网络分区、依赖服务不可用等情况下的预期行为与降级方案。
版本与兼容性：明确声明平台组件的基础版本要求（如：Kubernetes 1.24+， Prometheus 2.40+）及向后兼容性策略。
安全与合规：细化安全需求，包括网络策略（NetworkPolicy）的默认规则、容器镜像扫描策略、秘密信息（Secrets）的管理方式以及合规性审计日志的保留时长。


使用建议

将“核心提示词”中的段落作为独立指令，输入给大语言模型（如ChatGPT、Claude），分章节生成详细内容，再进行整合与精修。
在生成架构图或流程图时，可将“构图建议”中的描述作为提示词输入给AI绘图工具（如Midjourney, Stable Diffusion）或专业绘图软件，生成示意图。
务必在文档成稿后，邀请开发骨干和SRE对技术可行性进行评审，确保需求与当前技术栈及团队能力匹配。
本方案为通用框架，请根据实际项目规模（初创项目vs.企业级平台）调整需求的粒度与范围。