| name | okr-cascade-diagnosis |
| description | Diagnose OKR cascade alignment and team-level differences. Use when a user provides company-level OKRs and team/department OKRs and wants to check: (1) whether team OKRs properly support company OKRs, (2) which company OKRs have no team coverage (floating targets), (3) which team OKRs have no company OKR linkage (self-spinning), (4) quality scoring per team, (5) conflicts or resource contention between teams. Triggers on phrases like "诊断OKR对齐", "检查OKR级联", "OKR cascade", "OKR alignment", "团队OKR差异", "identify OKR gaps", "OKR诊断", "级联诊断". |
OKR Cascade Diagnosis
Diagnose alignment between company-level OKRs and team/department OKRs, and surface team-level differences.
前置确认（Inversion）
开始诊断前追问：
- 公司当前最关心什么：增长？利润？稳定？融资？
- 哪些团队之间有已知的协作摩擦？
- 是否存在尚未决策的战略方向（如新产品/出海）？
⛔ 如果公司级OKR未提供 → 暂停，"没有公司OKR无法做级联诊断"
Input Format
基础输入（必填）
【公司级OKR · 年度/季度】
O1：xxx
KR1：xxx（目标值：xxx）
KR2：xxx
【团队A · Q1 OKR】
O1：xxx
KR1：xxx（标注对应公司OKR：O1-KR1，若无则填"无"）
增强输入（选填，填写后诊断质量大幅提升）
【公司背景】
- 公司阶段：求增长 / 求利润 / 求融资 / 海外突破 / 组织稳定
- 今年最重要的1-2个战略主题：
- 收入基准目标 vs 拉伸目标（如有区分）：
【产品线信息】
- 产品线A：成熟度（成熟现金牛 / 高速成长 / 孵化探索）+ 客户类型 + 主要收入来源
- 产品线B：（同上）
- 各产品线是否独立团队，还是共用研发/产品：
【组织结构】
- 各团队职责边界（谁对收入负责/谁对获客负责/谁对稳定性负责）
- 支撑部门服务重点（如：运维主要服务云网，售后主要服务飞跨）
- 行政/保障部门有哪些：
【历史数据】
- 上年度实际收入：
- 本年度基准目标 / 拉伸目标：
- 关键战略动作（如：新建分公司/新产品立项/海外扩张）：
如果增强输入缺失，照常运行诊断，但所有推断性结论标注置信度（高/中/低）。
前置：业务成熟度分层
在诊断前，先对每条产品线/业务线做成熟度分类，用不同标准评估：
| 成熟度 | 典型特征 | OKR评估标准 |
|---|
| 成熟现金牛 | 收入稳定、客户规模大 | 营收、利润、成本效率、稳定性 |
| 高速成长 | 高增长预期、产品化 | 获客漏斗、留存复购、DAU、市场扩张 |
| 孵化探索 | 客户少、验证阶段 | 场景验证、种子用户、价值贡献，不考核收入 |
注意：用成熟业务标准评估孵化业务是最常见的误判来源。
Diagnosis Steps
Run all six modules. Output each as a clearly labeled section.
Module 1: Alignment Matrix（对齐矩阵）
Build a table mapping each company KR → which teams cover it:
| 公司OKR | 覆盖团队 | 覆盖KR数 | 置信度 | 状态 |
|---|
| O1-KR1 | 销售、市场 | 3 | 高 | ✅ |
| O1-KR2 | 无 | 0 | — | 🔴 悬空 |
状态说明：
- ✅ 多团队有效承接，逻辑清晰
- ⚠️ 单团队承接或承接不完整（单点失败风险）
- 🔴 无团队承接（公司目标悬空）
置信度说明：
- 高：团队KR文本与公司KR直接对应，无需推断
- 中：逻辑上能支撑，但措辞不同，存在推断
- 低：仅通过语义猜测，建议人工确认
⛔ CHECKPOINT: 对齐矩阵确认
- 如果 🔴 悬空目标 >2个 → 暂停，优先讨论悬空目标，再继续后续Module
Module 2: Self-Spinning Detection（自转检测）
对每条无法映射到公司OKR的团队KR，先做类型判断，再给出建议：
类型A — 战略遗漏：这类工作本应有公司OKR支撑，是公司级漏写了
→ 建议：补公司级KR，或在现有O下挂靠
类型B — 真正自转：团队自发工作，与公司战略无关
→ 建议：降优先级或删除
类型C — BAU保障型：公司必须做的基础经营动作，但不需要挂靠战略OKR
→ 建议：保留，标注为"经营保障型"，不纳入OKR对齐评分
类型D — 孵化探索型：孵化业务的能力建设和验证动作，允许不与现有公司OKR直接挂钩
→ 建议：按孵化逻辑评估，不用成熟业务标准苛责
Module 3: Numeric Logic Check（数字逻辑校验）
标准数字校验
对可量化公司KR，检查各团队贡献之和是否能覆盖公司目标：
公司KR：全年新签100家
各团队加总：85家，缺口15家 ⚠️
增长漏斗完整性检查（如有获客类目标）
检查"曝光→线索→有效线索→注册→付费→成交→收入→复购"各层是否都有团队承接：
| 漏斗层级 | 承接团队 | 目标数字 | 状态 |
|---|
| 线索量 | xxx | xxx | ✅/⚠️/🔴 |
| 有效线索 | xxx | xxx | |
| 成交 | xxx | xxx | |
| 收入 | xxx | xxx | |
注意：识别漏斗口径统一问题——"有效线索"的定义是否在获客团队和销售团队之间对齐。
基准目标 vs 拉伸目标分层检查
如公司存在"基准目标"和"拉伸目标"，分别校验：
- 团队承接是否能覆盖基准目标（确保基本盘）
- 拉伸目标的缺口来自哪里（新产品/新市场/超额增长）
Module 4: Quality Scoring Per Team（质量评分）
标准评分（用于成熟业务和成长业务）：
对每个团队OKR，在4个维度各打1–5分：
评分标准 → 见 references/scoring-criteria.md
孵化业务特殊评分标准：
孵化阶段的团队，用以下替代评分：
| 维度 | 说明 |
|---|
| 场景清晰度 | 是否明确了验证哪个场景 |
| 种子用户质量 | 目标用户是否精准，数量是否合理 |
| 学习导向 | KR是否设计成能产生洞见（而非只追数字） |
| 价值贡献 | 对主产品/主业务的粘性贡献是否明确 |
Module 5: Inter-Team Conflicts（跨团队冲突）
识别OKR之间的目标张力：
| 张力类型 | 涉及团队 | 冲突描述 | 风险等级 | 建议决策方 |
|---|
| 速度 vs 稳定性 | 产品 × 技术 | xxx | 🔴/🟡/🟢 | xxx |
| 获客规模 vs 线索质量 | 市场 × 销售 | xxx | | |
| 收入增长 vs 利润质量 | 业务 × 财务 | xxx | | |
常见张力模式：
- 增长 vs 稳定：前台冲量 vs 后台可用性（尤其当应用产品依赖基础设施时）
- 渠道 vs 效率：新渠道（线下/品牌）CPL高 vs 效果型成本控制目标
- 孵化节奏 vs 主产品需要：BI/新产品能力建设速度 vs 主产品增长所需的粘性支撑
横向对齐检查（Horizontal Alignment）
检查同层团队之间的目标是否存在：
- 目标重叠：两个团队对同一结果都声称负责，但没有明确分工
- 目标互斥：一个团队的增长目标依赖另一个团队的稳定，但两者未协商
- 资源争夺：同一个关键资源（如技术团队、营销预算）被多个团队同时依赖
输出：横向对齐问题清单，建议召开跨团队对齐会
Module 6: Cross-Business-Line Dependency Risk（跨业务线协同风险）
本模块在多产品线独立作战的组织中尤为重要。
识别产品线之间的依赖关系，检查是否有对应的协同KR承接：
| 依赖关系 | 被依赖方 | 依赖方 | 是否有协同KR | 风险 |
|---|
| A的增长依赖B的稳定供给 | 云网/基础设施 | 飞跨/应用层 | 无 | 🔴 |
| C的价值依赖A的客户场景 | 飞跨 | BI | 无 | 🟡 |
对每个无协同KR的跨线依赖，建议补充的协同机制：
- 联合容量规划会（确认资源供给能否支撑增长目标）
- 跨线里程碑对齐（确认能力就绪时间点）
- 跨线升级决策路径（谁来拍板跨线冲突）
Output Format
按以下结构输出完整报告：
## 诊断前提：业务分层
## Module 1：对齐矩阵
## Module 2：自转检测
## Module 3：数字逻辑校验
## Module 4：质量评分
## Module 5：跨团队冲突
## Module 6：跨业务线协同风险
## 核心发现（Top 3根本性问题）
## 优先行动建议（按紧迫度分级）
使用中文输出，除非用户OKR为英文。
Transparency 原则提醒
OKR应对全员公开可见。建议将本输出：
- 同步到团队共享文档（飞书/Notion/Wiki）
- 发送给直属上级和相关依赖团队
- 在季初全员会议上公开宣读
References
- 评分标准详情 → references/scoring-criteria.md
- 诊断提示词 → references/diagnosis-prompts.md
