高阶版运维监控产品需求写作提示词

角色定义与任务定位

请以“资深运维产品专家”与“解决方案架构师”的双重身份，运用系统化思维与前瞻性视野，撰写一份面向企业级客户的《高阶运维监控平台产品需求文档》。你的核心目标是定义一款超越基础监控、具备智能洞察、自动化响应与可观测性深度整合的专业产品，确保需求在技术可行性、用户体验与商业价值上达到高标准。

适用场景

• 为从0到1设计新一代智能运维监控平台撰写PRD核心章节。
• 为现有监控产品进行“专业版”或“企业版”的功能升级与重构提供详细需求输入。
• 在向技术团队、管理层或客户阐述高阶监控产品蓝图时，提供结构化的内容支撑。

核心提示词框架

直接用于构建需求文档的核心叙述逻辑与关键词组合：

• 核心愿景：构建一个“以数据驱动、以AI赋能”的[统一可观测性平台]，实现从[被动告警]到[主动预测]、从[孤立监控]到[全栈关联分析]的范式转变。
• 核心能力：涵盖[指标(Metrics)、日志(Logs)、追踪(Traces)]的深度融合采集与存储；基于[机器学习]的[异常检测]与[根因分析]；支持[自定义SLO/SLI]的[服务等级目标管理]；具备[自动化闭环]能力的[智能告警与故障自愈]流程。
• 关键特性：[拓扑感知]的[服务依赖关系映射]；[多租户]与[细粒度权限控制]；[可自定义]的[数据可视化仪表盘]与[分析报告]；支持[开放API]与[主流生态工具链]集成。

风格方向

• 文档风格：采用严谨、清晰、客观的[技术方案描述]风格，避免营销化语言。强调[逻辑性]、[完整性]与[无歧义性]。
• 叙述层次：遵循“业务目标 -> 用户痛点 -> 解决方案 -> 功能详述 -> 非功能性需求”的递进结构。
• 术语使用：精准使用[可观测性]、[MTTR]、[数据降噪]、[混沌工程]等专业术语，体现行业深度。

构图建议（需求结构）

将产品需求想象为一幅架构蓝图，建议按以下“画面”分层展开：

• 远景层（背景与目标）：描绘市场趋势、客户核心痛点（如告警疲劳、故障定位难）、本产品要实现的战略价值。
• 架构层（整体方案）：勾勒平台整体架构图，说明[数据采集层]、[数据处理与存储层]、[分析引擎层]、[应用展示层]的核心组件与技术选型思路。
• 功能层（细节特写）：对关键功能模块进行特写，例如“智能告警模块”需详细描述[告警规则定义]、[动态阈值]、[告警分派策略]、[排班与升级]等交互流程与逻辑。
• 指标层（成功标准）：定义清晰的[成功指标]，如[平台自身可用性>99.99%]、[平均故障检测时间<30秒]、[平均根因定位时间<5分钟]。

细节强化

在描述具体功能时，注入以下细节以提升需求的专业度与画面感：

• 数据流转：描述“[通过eBPF技术无侵入采集基础设施指标]”，“[日志数据经过解析、索引后存入时序数据库]”。
• 用户交互：“支持[拖拽式]仪表盘编辑器，用户可[将查询结果以折线图、热力图、拓扑图等多种形式可视化]”。
• 智能分析：“根因分析引擎通过[关联规则挖掘]与[拓扑传播算法]，在数秒内[高亮标记最可能引发故障的源头服务或基础设施节点]”。
• 非功能需求：明确“[支持每秒百万级数据点写入]”、“[查询响应时间在亚秒级]”、“[前端界面支持暗黑模式与无障碍访问]”。

使用建议

• 将上述“核心提示词框架”作为需求文档各章节的标题或核心论点，展开成文。
• 在撰写具体功能点时，结合“细节强化”中的描述方式，使需求更具体、更可技术实现。
• 使用“构图建议”来检查需求文档的结构是否完整、层次是否清晰。
• 最终输出的文档，应能让开发工程师明确“做什么”和“做到什么标准”，也能让业务方理解产品的核心价值。