OKR/目标拆解助手

适用场景

• 季度目标定了一句「提升用户体验」，往下拆不出任何能开工的具体动作
• KR 写成「上线新版引导页」「完成系统重构」——季末谁也说不清算不算达成
• 目标挂在文档里三个月没人看，到季末才发现一半 KR 根本没启动
• 任务列了一长串，但没人核算过团队一周到底干得完多少，排期表纯属自我安慰
• 要给上级交一份 OKR，但不确定写得规不规范、会不会被打回来重写

核心能力

1. KR 可衡量性体检（本技能的核心差异点）：按 SMART 六维给每条 KR 打分（满分 100）——量化目标 30 分、基线 20 分、单位 10 分、负责人 15 分、时限 10 分、结果型表述 15 分。≥85 合格 / 70-84 待完善 / <70 不合格。

2. 伪 KR 识别：以「上线、完成、开发、推进、优化、搭建、召开、交付」等 20+ 动作型动词开头且不含任何指标信号词的表述，会被明确判为「这是任务不是关键结果」并给出改写方向。这是 OKR 落地时最高频、也最致命的错误——把动作当结果，等于给自己发了张无法验收的空头支票。

3. 三级拆解：目标 O → 关键结果 KR → 周任务，逐层展开，每层带负责人、衡量口径、工作量与周次。

4. 结构合理性校验：目标数超 5 个提示失焦；单目标 KR 超 5 条提示拆碎；单目标只有 1 条 KR 提示指标容易被钻空子；KR 无任何任务 → 标为「许愿型」。

5. 按人核算的周负载（不是按总量除人数）：逐周逐人累计人日，任一人超过个人上限即判超载并列出具体超出量。按周总人日除以人数会把「一人干 10 天、另一人干 2 天」算成正常，那是最容易骗过自己的算法。同时列出全周期空闲周，直接告诉你任务能往哪儿挪。

6. 风险识别：低信心 KR（<50%）、无任务支撑的 KR、不合格 KR、单点人力依赖（一人扛超过总量一半）、未指派到人的工作量、单周超产能排量。

7. 启动清单：把所有待修问题转成可勾选的 checklist，附 OKR 落地的两条硬要求（对齐会确认取数口径、每周固定检视）。

8. 盲区扫描（v1.0.2 新增）：一处扫出治理缺口——目标缺 why、KR 无负责人、KR 无截止时间、动作型 KR 待改写为结果型、任务未指派到人。这些「看得见但不显眼」的缺口往往是季末扯皮的根源，单列成章方便一次性补齐。

输入规范（缺失主动引导）

脚本输入为 JSON（完整字段说明见 references/input_template.json）：

{
  "team": "用户增长组",
  "period": "2026 Q3",
  "period_start": "2026-07-01",
  "period_end": "2026-09-30",
  "settings": { "weekly_capacity_days": 4 },
  "objectives": [
    {
      "id": "O1",
      "title": "让新用户在首周就用起来核心功能",
      "priority": "高",
      "owner": "李明",
      "why": "拉新预算烧了，但七日内动过核心功能的不到三分之一",
      "key_results": [
        {
          "id": "O1-KR1",
          "statement": "新用户首周核心功能激活率从 32% 提升到 50%",
          "baseline": 32, "target": 50, "unit": "%",
          "owner": "张伟", "confidence": 0.6,
          "tasks": [
            {"title": "重做新手引导：从 7 步压缩到 3 步", "owner": "张伟", "effort_days": 6, "week": 3},
            {"title": "AB 实验跑满两周并出结论", "effort_days": 3, "week": 8}
          ]
        }
      ]
    }
  ]
}

• 必填：objectives 数组，每个目标至少 title
• 强烈建议：每条 KR 填 baseline + target + unit（缺一样就要在体检里扣分）
• 可选：id（不填自动生成）、priority（高/中/低，默认中）、why、owner、due、confidence（0~1 或 0~100）
• 任务字段：title 必填，effort_days 默认 1，week 建议填（不填进「未排期」清单），任务也可直接写成字符串简写
• settings 全部可缺省：weeks 不填按周期日期推算（都没有则默认 12 周）、weekly_capacity_days 默认 4

缺失引导：用户只说「帮我拆一下这个季度目标」时，先按顺序问清四件事，再整理成上述 JSON：
- 这个周期你最想达成的 2-4 个方向是什么（对应 O）
- 每个方向 拿什么数字判定做到了、现在这个数字是多少（对应 KR 的 target 与 baseline）
- 每条 KR 谁负责、你估计有几成把握（对应 owner 与 confidence）
- 为了推动这些数字，具体要做哪些事、大概各花几人日、想排在第几周（对应 tasks）

如果用户答不上「拿什么数字判定」，不要替他编一个——直接告诉他这条目标当前还不具备立 KR 的条件，先想清楚衡量方式，否则拆得再细也是白拆。

处理流程

1. 与用户确认目标、衡量指标、任务清单，整理为输入 JSON，存为临时文件（如 okr.json）
2. 运行脚本：
   bash python scripts/breakdown_okr.py okr.json # 或显式指定输入 / 输出 python scripts/breakdown_okr.py --input okr.json --output okr_plan.md # 不改变输入文件，临时调整产能与周期周数 python scripts/breakdown_okr.py okr.json --cap 5 --weeks 8 # 也可从 stdin 读入 type okr.json | python scripts/breakdown_okr.py
3. 将输出的拆解方案原样呈现给用户
4. 重点讲解三处：不合格 KR 该怎么改（给出具体改写示例，别只说「要量化」）、超载周怎么挪（结合空闲周给具体建议）、低信心 KR 的兜底方案（提前约定退守线，别等季末摊牌）

脚本参数

退出码：0 成功 ｜ 2 输入内容非法（JSON 语法错、顶层不是对象、缺 objectives、week 越界等）｜ 3 文件不存在 / 读写失败 / 编码无法识别 ｜ 4 自检失败。

输出格式

markdown 拆解方案，包含七个部分：

• 一、结论速览：O/KR/任务计数与总人日、不合格与待完善 KR 名单、许愿型 KR 告警、目标数与 KR 数的结构性提醒
• 二、OKR 全景：目标 / 优先级 / KR / 关键结果 / 基线→目标 / 负责人 / 任务数 / 工作量 / 体检分 九列总表，按目标优先级排序
• 三、三级拆解明细：逐目标展开，每条 KR 附衡量口径、负责人、截止、信心、体检分，不达标的列出具体问题与改写提示，下挂周任务表（含未排期标记）
• 四、周排期与负载：逐周列任务数、合计人日、各人负荷明细、红黄绿负载判定；超载明细精确到「W几 · 谁 · 超出几人日」，并列出可承接的空闲周；单列未排期任务清单
• 五、风险提示：低信心 KR、无任务支撑 KR、不合格 KR、单周超产能人员、单点人力依赖、未指派工作量
• 六、下一步清单：可勾选的启动 checklist
• 七、盲区扫描（治理缺口）：目标缺 why、KR 无负责人、KR 无截止、动作型 KR 待改写、任务未指派到人，一次性列清便于补齐

（完整示例见 examples/sample_input.json → examples/sample_output.md）

异常处理

• objectives 缺失或为空数组 → 报错并提示至少需要 1 个目标
• 目标缺 title → 报错并指名是第几个目标
• 目标 id 重复 / 同一目标下 KR id 重复 → 报错并提示会导致引用错乱
• 任务缺 title → 报错并指名归属哪条 KR
• 任务 week 超出周期范围或非整数 → 报错并指名是哪条任务、合法范围是多少
• period_end 早于 period_start → 报错
• 日期格式不合法 → 指名字段名，提示应为 YYYY-MM-DD
• settings.weekly_capacity_days ≤ 0 或 settings.weeks ≤ 0 → 报错
• priority 不在「高/中/低」内 → 静默降级为「中」
• effort_days 非正数或缺失 → 按 1 人日
• confidence 填了 0~100 的整数 → 自动按百分比换算为 0~1
• 一条 KR 都没有 → 结论区明确指出「只是愿望清单，不构成 OKR」，不会假装体检通过
• JSON 解析失败 → 报出具体错误信息并退出码 2
• 输入为空 / 顶层不是 JSON 对象 / JSON 语法错 → 中文报错并退出码 2，不产生半截报告
• 输入文件不存在或是 GBK 编码 → 自动按 utf-8-sig → gbk 顺序兜底；均失败时退出码 3 并说明已尝试的编码
• 所有报错走 stderr，报告只走 stdout，便于 > 文件 重定向或管道串联

边缘用例

• settings 数值字段脏数据（如 "坏"、null、布尔）→ 自动回退默认值并告警，不中断
• KR 描述含竖线 | 或换行 → 渲染时转义为全角「｜」并去换行、超长截断，避免破坏表格列结构
• effort_days 为负 → 兜底为 1.0 人日，不报错
• 任务直接写成字符串（如 "整理需求文档"）→ 自动规整为 {title: ...}
• --cap / --weeks 命令行覆盖 优先级高于 settings 同名参数，便于不改输入文件临时压测排期
• 目标缺 why / KR 无负责人 / 无截止 → 不报错，但会在「盲区扫描」章节单独列出

自检

脚本内置 --selftest，覆盖 10 组用例 + 边界断言（基本拆解、不合格 KR 标记、盲区扫描、动作型 KR 改写提示、周超载判定、字符串简写任务、脏 settings、CLI 覆盖、超长 KR 描述不破表、负人日兜底、空 objectives 报错）。全部通过退出码 0，任一失败退出码 4。

python scripts/breakdown_okr.py --selftest

适用限制与免责声明

• 不连接任何 OKR/项目管理系统（不读写飞书 OKR、Tita、Worktile、TAPD、Notion 等），仅基于用户提供的文本做离线拆解；如需同步到系统，请自行复制或配合相应平台连接器
• 体检分数只反映「写得规不规范」，不代表目标本身有没有价值。一条 100 分的 KR 完全可能指向一个错误的方向——目标选得对不对，规则引擎判断不了，仍需业务判断
• 「伪 KR」识别基于动词与指标信号词的规则匹配，存在误判可能：少数以动作词开头的表述确实是合理结果（如「完成 A 轮融资」），此时可忽略该项提示
• 周负载测算基于用户自填的人日估算，不校验估算是否合理；人日普遍低估是行业通病，建议按估算值的 1.2-1.5 倍留余量
• 信心指数由用户自填，不做交叉验证；产出的风险提示是形式检查结果，不构成对项目成败的预测
• 本技能产出的是规划草案，不替代团队对齐与管理决策，因目标设定偏差、排期不合理导致的后果由使用者自行承担