ai-ops/prd/PM审核报告.md

PM 审核报告

总体评级：B

评级说明：PRD 整体结构完整，用户旅程覆盖较全，AC 基本满足 SMART 原则，商业化闭环有框架但缺乏财务量化。存在 1 处 P0 级范围不一致、1 处 P0 级错误码冲突，以及工期估算严重偏乐观的问题。建议在进入 TechLead 评审前修复 P0/P1 问题。

---

优点

1. 用户旅程覆盖完整：主流程（监控看板、配置审计回滚、告警处置）+ 异常流程（自愈失败、告警飙升、回滚失败）+ 边缘流程（无人处理告警、数据源丢失、误触发变更）全部覆盖，并配有 F-1~F-8 的独立失败路径表。
2. AC 量化程度高：12 条 AC 中，90% 以上包含明确的数值约束（如 <2s、<3s、30s、90 天、50 条规则、100 条/页），可直接转化为 QA 测试用例。
3. In/Out of Scope 边界清晰：明确排除了下游大模型监控、基础设施层监控、AI 自动扩缩容、外部监控系统整合，避免范围蔓延。
4. 技术约束明确：统一 Go 1.22+ / 标准库 net/http / pgx / go-redis，禁止引入 Gin/Echo；支持独立运行与集成运行双模式；数据库表名强制 ai_ops_ 前缀，减少集成冲突。
5. 发布策略安全：分 4 阶段上线，自愈规则强制"沙盒模式"验证（>=10 次模拟），并设计了一键关闭自愈的权限开关，风险控制意识强。
6. 竞品分析有价值：对 LiteLLM、Sub2API、NewAPI、FreeRide 的对标分析到位，差距分析直接转化为产品机会点。

---

发现问题（按严重度分类）

P0 — 阻塞性问题（必须修复后才能进入开发）

编号	问题	影响	位置
P0-1	范围冲突：供应商智能切换未在 PRD 正文 In Scope 中明确纳入，但功能清单将其作为 Phase 3 核心模块（3.4，含 16+ 个任务）	该功能涉及自动路由变更、供应商探测、Fallback 链管理，本质上属于"自动化配置变更/扩容决策"，与 Out of Scope 第 3 条"不做自动扩容决策"存在擦边风险；且 In Scope 第 1 条明确"不含下游大模型服务"，而供应商切换直接依赖下游供应商接口。若不加明确界定，开发阶段极易产生范围争议。	PRD §3 In Scope / 功能清单 模块 3.4
P0-2	错误码不一致：PRD 场景 F 与 AC-8 规定回滚失败错误码为 OPS_AUD_4101，但功能清单 3.3.2 使用 AUDIT_ROLLBACK_TARGET_LOST	接口契约冲突，前后端/QA 无法对齐，将导致集成测试失败。	PRD §4 场景 F、§5 AC-8 / 功能清单 3.3.2
P0-3	工期估算严重偏离实际：功能清单列出 138 个任务，总估算仅 18 人天（平均每个任务不足 1 小时），未包含联调、集成测试、Bug 修复、文档、评审、返工时间	该估算极可能导致项目延期、资源不足、质量下降。按行业常规，Go 后端 + 前端 + 测试的完整交付，138 个任务至少需要 68 周（3040 人天）以上。	功能清单 "任务估算汇总"
P0-4	自愈动作"重启实例"在功能清单中遗漏具体任务：PRD AC-6 明确列出"重启实例"为可选自愈动作之一，但功能清单 3.1.2 的自愈执行后端任务仅覆盖"切换备用路由、限流、触发脚本"，未提及"重启实例"的实现任务	功能遗漏，QA 无法验收该自愈动作。	PRD §5 AC-6 / 功能清单 3.1.2

P1 — 重要问题（强烈建议修复）

编号	问题	影响	位置
P1-1	双重失败判定线：PRD §2 定义"开发期间任何一周内告警噪声率 >20% 或自愈规则误触发导致生产事故，即判定失败"；§8.3 又定义"上线 30 天内 MTTR 未下降至 <20min / 自动化覆盖率 <30% / 噪声率 >15% / 自愈误触发 1 次"进入救援模式	两条判定线的时间边界（开发期 vs 上线后）、指标阈值（20% vs 15%）、触发条件不统一，团队无法判断应以哪条为准。	PRD §2 成功定义、§8.3 失败判定线
P1-2	In Scope 使用"包括但不限于"：第 1 条"包含但不限于：gateway/..."	"包括但不限于"是范围管理中的高风险词汇，为后续需求蔓延留下口子。应改为封闭列表，或明确"仅包含以下模块"。	PRD §3 In Scope #1
P1-3	通知渠道定义不一致：PRD AC-4 要求"Webhook、邮件、飞书/企业微信至少 2 种"，但功能清单 2.3.2 和 3.4.3 出现了"钉钉"，且备份切换链为 Webhook→邮件→飞书→企微	若最终未实现钉钉，功能清单需同步删除；若实现，PRD AC-4 需更新。	PRD §5 AC-4 / 功能清单 2.3.2、3.4.3
P1-4	AC-7 "审计日志必须不可篡改"缺乏技术实现定义：未说明是通过 WORM 存储、哈希链、数字签名还是仅通过数据库层禁止 UPDATE/DELETE 来实现	QA 无法验证"不可篡改"，不同实现方式的成本和合规等级差异巨大。	PRD §5 AC-7
P1-5	AC-8 "操作前值有效"定义模糊：未明确"有效"的判定标准（非空？JSON 可解析？符合当前 Schema？）	可能导致回滚接口在边界情况下行为不一致。	PRD §5 AC-8
P1-6	级联故障回退（F-6）未在 AC 中体现：PRD §6 F-6 描述自愈级联故障时"自动恢复上一步操作前的状态"，但 AC-6 仅提到"若未解除则升级为人工告警"，未要求验证级联回退能力	功能清单 3.1.3 有任务，但 AC 缺失，QA 无法据此验收。	PRD §6 F-6 / §5 AC-6
P1-7	容量预测算法缺乏可测试标准：AC-9 要求"按当前增长率预测触达资源上限时间"，但注明"仅供参考，不自动执行扩容"，且未定义预测准确率、置信区间或最大可接受偏差	"仅供参考"导致该功能无法被 QA 有效验收，开发完成后可能沦为无法量化的"演示功能"。	PRD §5 AC-9
P1-8	缺少 UI/UX 最低兼容性要求：PRD 和功能清单均未规定浏览器支持范围、移动端适配策略、最低分辨率	前端工程师缺乏约束，可能在交付后因兼容性问题返工。	PRD 全文
P1-9	角色权限矩阵过粗：AC-12 仅定义 3 个角色的一句话权限，缺少页面级/API 级权限对照表（如"运维人员能否导出审计日志？""查看者能否导出 CSV？"）	功能清单 G1 中"管理员（可管理用户）"超出了 PRD 定义（PRD 未提用户管理），进一步加剧不一致。	PRD §5 AC-12 / 功能清单 G1

P2 — 改进建议（建议纳入后续迭代）

编号	问题	建议
P2-1	商业化闭环缺少 ROI 量化模型	补充"当前运维人力成本 = X 人月 × Y 元/人月，目标释放 40% 后节省 Z 元/月"的计算示例，使北极星指标与财务指标挂钩。
P2-2	竞品分析中的技术设计模式未融入 PRD 正文	将 CustomBatchLogger、DigestEntry、DualCache 等设计模式从竞品分析报告迁移到 PRD 技术约束或架构建议章节，避免设计阶段遗漏。
P2-3	发布策略缺少阶段门控的量化验收标准	阶段 2 进入阶段 3 的条件目前是"无 P1 以上告警 72h"，建议补充"告警噪声率 <10%""通知渠道成功率 >95%"等可量化门控。
P2-4	未定义生产部署拓扑	建议明确是单集群还是多集群部署，自愈动作"重启实例"在 K8s 与裸金属环境下的实现差异巨大。
P2-5	审计日志 90 天保留期未评估存储成本	高并发场景下全量 JSON 审计日志的存储量可能极大，建议补充日志压缩/归档策略或存储成本上限。
P2-6	PRD 自检清单声称"没有使用优化、支持、友好、尽量、快速等模糊词"，但正文中仍存在"等""等相关指标"等模糊表述	建议将 In Scope 中的"等"字去除，改为封闭列表；功能清单中的"等相关能力"也需同步清理。

---

改进建议（优先级排序）

1. 立即修复 P0 问题：

   • 在 PRD §3 In Scope 中明确加入"供应商智能切换（含健康探测、Fallback 链、策略化路由）"或将其移入 Out of Scope；若纳入，需在 AC 中补充对应的验收标准。
   • 统一回滚失败错误码为 OPS_AUD_4101，功能清单同步修正。
   • 重新进行工时估算，建议采用"任务 × 复杂度系数 + 联调缓冲（20%）+ 风险缓冲（15%）"的方式，输出 30~40 人天的 realistic estimate。
   • 在功能清单 3.1.2 中补充"重启实例"自愈动作的实现任务（如调用 K8s API 或主机 agent）。

2. 本周内修复 P1 问题：

   • 合并/统一失败判定线，建议按"上线后 30 天"为统一时间窗口，阈值取更严格的版本（噪声率 <15%）。
   • 删除 In Scope 中的"包括但不限于"，改为封闭枚举；如确需扩展，规定"新增范围需经 PM+TechLead 双签"。
   • 明确 AC-4 通知渠道的最终列表（是否含钉钉），并同步更新功能清单的备用切换链。
   • 在 AC-7 中补充"不可篡改"的实现方式（建议：数据库层禁止 UPDATE/DELETE + 应用层只追加写入）。
   • 补充 UI 最低兼容性要求（如：Chrome/Firefox/Edge 最新 2 个版本，最小宽度 1280px）。
   • 细化角色权限矩阵到 API 级别，建议以表格形式列出各角色对关键接口的 CRUD 权限。

3. TechLead 阶段前补充：

   • 将竞品分析中的设计模式建议提炼为 PRD 架构约束章节（如告警批量化、摘要窗口、双缓存机制）。
   • 为容量预测（AC-9）补充可测试标准，例如"预测值与实际值的平均绝对百分比误差（MAPE）<30%"或至少提供趋势方向判断准确率。
   • 明确生产部署拓扑（K8s vs 裸金属 vs 混合），影响自愈动作设计。

---

审核结论

维度	评分	说明
用户旅程完整性	A-	主/异/边缘流程全覆盖，但级联回退未在 AC 中闭环
AC 可测试性	B+	大部分量化精确，但"仅供参考""有效""不可篡改"等不可测试
In/Out of Scope 清晰度	B	主体清晰，但"包括但不限于"和供应商切换造成范围争议
成功指标与失败判定	B-	指标量化，但存在双重标准，时间边界模糊
商业化闭环	B-	有框架但缺 ROI 量化，外部收益链条弱
功能清单一致性	C+	与 PRD 存在错误码冲突、渠道不一致、任务遗漏、估算失真
模糊词汇控制	B+	主体控制良好，"等"字和"包括但不限于"需清理

建议行动：修复 P0-1~P0-4 后，可进入 TechLead 评审；P1 问题建议在技术方案评审前同步闭环。