智能诊断指挥官

核心原则

快速定位问题根因，减少MTTR

诊断的价值不在于产出报告，而在于缩短从问题发现到根因定位的时间。每多一分钟不确定，就多一分钟的风险暴露和资源浪费。

编排理念

1. 健康度先行，竞品跟进：先诊断自身健康度定位问题，再追踪竞品动态寻找外部原因，内外结合才能完整归因
2. 诊断数据驱动竞品应对：健康度诊断的瓶颈结论直接决定竞品追踪的重点方向和应对策略优先级

编排协议

编排协议遵循 orchestrator-protocol.md 统一标准。

Pipeline

pipeline: diagnosis-orchestrator
version: 7.0

post_pipeline:
  - action: stage-summary
    output: output/phase-reports/pm-monitoring/diagnosis-orchestrator.md

stages:
  - id: phase-1
    name: "健康度诊断"
    depends_on: []
    skills: [diagnosis-health]
    parallel_with: [phase-2]
    gate:
      condition: "健康度评分偏差±10%以内"
      fail_action: "校准评分模型或补充数据"

  - id: phase-2
    name: "竞品追踪"
    skills: [diagnosis-competition]
    parallel_with: [phase-1]
    gate:
      condition: "竞品动态已追踪"
      fail_action: "补充竞品数据源或延长追踪周期"

  - id: phase-3
    name: "竞品监控报告"
    depends_on: [phase-2]
    skills: [competitor-monitoring-report]
    gate:
      condition: "竞品监控报告经人类审核确认"
      fail_action: "补充分析或修改应对建议"

  - id: phase-4
    name: "产品下线方案"
    depends_on: [phase-1]
    skills: [product-sunset-plan]
    trigger: 产品下线需求
    gate:
      condition: "产品下线方案经人类审核确认"
      fail_action: "补充分析或修改迁移方案"

阶段执行计划

#### 调用 diagnosis-health

Skill: diagnosis-health
输入:
  performance_data: APM/监控系统
  availability_data: 监控系统
  user_satisfaction: 反馈系统
  business_metrics: 数据分析平台
  competitor_dynamics: diagnosis-competition → 竞品报告（可选）
输出: output/pm-monitoring/diagnosis-health/
验证: 数据采集完整率≥90%；评分计算准确性；趋势预测偏差±10%；瓶颈识别覆盖率≥90%
模式: 🤖→👤

#### 调用 diagnosis-competition

Skill: diagnosis-competition
输入:
  competitor_data: 竞品监控系统
  self_data: 产品数据平台
  market_data: 行业报告（可选）
  historical_tracking: diagnosis-competition → 历史报告（可选）
输出: output/pm-monitoring/diagnosis-competition/
验证: 竞品覆盖完整性≥90%；功能变更识别及时性≤7天；策略可执行性≥80%
模式: 🤖→👤

#### 调用 competitor-monitoring-report

Skill: competitor-monitoring-report
输入:
  competitor_tracking: diagnosis-competition
  competitor_analysis: market-competitor-analysis（可选）
  monitoring_period: 用户提供（可选）
输出: output/pm-monitoring/competitor-monitoring-report/
验证: 动态覆盖完整（产品/市场/舆论3维度均有分析）；威胁评估有依据；应对建议可执行
模式: 🤖→👤

#### 调用 product-sunset-plan

Skill: product-sunset-plan
输入:
  health_diagnosis: diagnosis-health
  retention_data: retention-management（可选）
  sunset_target: 用户提供（下线对象）
  sunset_reason: 用户提供（下线原因）
输出: output/pm-monitoring/product-sunset-plan/
验证: 影响评估完整（用户/收入/品牌3维度）；迁移方案可行；数据处置合规；时间线可执行
模式: 🤖→👤

阶段总结（post_pipeline）

所有业务阶段执行完成后，必须立即生成阶段总结文档：

动作: 生成阶段总结
输入:
  所有子Skill输出: output/pm-monitoring/
  人类决策记录: 本轮执行中的人类决策点及结果
输出: output/phase-reports/pm-monitoring/diagnosis-orchestrator.md
验证: 阶段总结文档已生成，6项结构（执行概览/关键发现/决策记录/产出清单/风险与待办/下游衔接）均非空
下游衔接:
  primary:
    target: iteration-orchestrator
    reason: 诊断完成，根据诊断结论调整迭代计划
    input_mapping:
      diagnosis_output: "output/pm-monitoring/diagnosis-health/ + competitor-monitoring-report/ → iteration-decision输入"
  alternatives:
    - target: monitoring-orchestrator
      reason: 诊断结论为需建立监控预警
      condition: 诊断发现产品缺乏有效监控覆盖时
    - target: growth-orchestrator
      reason: 诊断结论为增长瓶颈，需增长策略
      condition: 健康度下降主因为增长乏力时
    - target: product-sunset-plan
      reason: 健康度极低且无改善空间，需制定下线方案
      condition: 健康度评分<30分且连续3个周期无改善时
  special_cases:
    - target: diagnosis-health
      reason: 仅需健康度诊断，无需完整诊断编排
      condition: 已有竞品数据，仅需产品健康检查时
模式: 🤖

⏸ 阶段卡口：阶段总结文档已生成且6项结构均非空 → 未通过：补充缺失结构项后重新生成

阶段卡口

下游衔接

• 诊断完成 → iteration-orchestrator（调整迭代计划）
• 缺乏监控覆盖 → monitoring-orchestrator
• 增长乏力 → growth-orchestrator
• 健康度极低 → product-sunset-plan
• 仅需健康检查 → diagnosis-health

人类决策点

异常处理

变更记录

• v1.0: 初始版本
• v2.0: 结构优化
• v3.0: 新增 competitor-monitoring-report（竞品监控报告）、product-sunset-plan（产品下线方案）
• v4.0: 改造为子Skill执行协议+阶段执行计划模式，增加命令式调度规则
• v5.0: 执行步骤替换为编排理念，新增异常处理表
• v6.0: 编排协议优化——将"读取子Skill定义并代理执行"改为"使用Skill工具显式调用子Skill"；新增Pipeline定义（YAML声明式执行图）；阶段执行计划改为调用指令格式；调度规则合并入编排协议
• v7.1: 阶段总结强化——Pipeline新增post_pipeline定义；调用规则第6条改为强制执行；阶段执行计划新增阶段总结执行指令；阶段卡口新增阶段总结校验；异常处理新增阶段总结生成失败策略
• v8.0: 更新子Skill下游引用——monitoring-anomaly/monitoring-dashboard/monitoring-escalation → monitoring-pipeline，iteration-backlog/iteration-prioritization → iteration-decision
• v9.0: 新增 quality-acceptance（质量验收）——从pm-05迁移；Pipeline新增quality-acceptance触发阶段；阶段执行计划新增quality-acceptance调用；阶段卡口新增质量验收报告已审核；人类决策点新增质量验收放行决策
• v10.0: 移除 quality-acceptance——统一归属 monitoring-orchestrator，消除跨编排器重复调度；Pipeline移除quality-acceptance触发阶段；阶段执行计划移除quality-acceptance调用；阶段卡口新增质量验收转交说明；新增下游衔接推荐