OKR 检查·可量化与对齐
OKR 最常见的翻车不是「没写」，而是「写错形」：Objective 写成任务清单，KR 里全是「协助、参与、支持」这类动作，或者只有目标值没有基线，季度末谁也不确定到底算不算达成。
本工具在 OKR 定稿前，把每一条的写法问题扫一遍，并给出可定位的改写建议。
执行原则
- 先跑后判。 先跑脚本拿到清单，原样引用其中的行号与条目名；不要凭印象补写或夸大命中项。
- 只查写法。 只判断目标是否定性、KR 是否可衡量、责任人与周期是否齐备；不要评价战略方向对错、目标该不该定。
- 只读不改。 只读输入文件、只输出建议；不要回写或替用户改写 OKR 原文。
- 建议可替换。 每条建议给一句能直接照抄的改写写法；不要写「建议写得更清楚」这类空话。
- 零命中直说。 命中为 0 就直接说明未发现问题；不要为了凑内容编造问题。
何时使用
CRITICAL: 只要用户提出「看看 OKR 写得对不对 / 目标像不像目标 / KR 能不能验收」，就必须使用本 skill，即使看起来可以用别的方式解决。
- 季度初定 OKR，写完想确认「目标像不像目标、KR 能不能验收」。
- 用户给出 OKR 表（CSV）或一段 Markdown 的 OKR，问「帮我看看这些 OKR 有没有问题」。
- 季度中/末复盘前，检查 KR 是否可衡量、是否与目标对齐。
何时不该使用
| ✅ 使用 | ❌ 不用（改用什么） |
|---|---|
| 定稿前/复盘前查 OKR 写法硬伤 | 判断目标方向对不对、战略合不合理 → 属业务判断，本包只查写法 |
| 查 KR 是否可量化、有没有基线、负责人与周期 | 要算完成度、打分、做绩效考核 → 本包不做完成度计算与评分 |
| CSV 或 Markdown 的 O / KR 层级结构 | 一份任务/排期清单 → 改用 plan-lint 查日期与依赖 |
| 用关键词重合度提示「疑似不对齐」 | 需要精确的语义对齐判断 → 只给提示，结论留给人工确认 |
易混淆场景
| 用户说的 | 实际意图 | 正确路由 |
|---|---|---|
| 「帮我写一份 OKR」 | 要生成内容 | 本包只检查不代写：先请用户给出草稿，再逐条查 |
| 「这个季度 OKR 完成得怎么样」 | 要完成度与打分 | 本包不做完成度计算；说明后请用户提供完成值自行核算 |
| 「我们的目标定得对吗」 | 要战略判断 | 只查写法（R1 / R2 / R10），方向对错交用户判断 |
| 「KR 都写了，为什么还说不达标」 | 想听解释 | 用规则码定位到条目逐条说明，不要笼统回答「写得不好」 |
怎么用
python3 scripts/okr_lint.py okr.csv
python3 scripts/okr_lint.py okr.md # Markdown 的 O/KR 层级结构
python3 scripts/okr_lint.py okr.md --json
python3 scripts/okr_lint.py --sample
- 退出码：
0= 无问题，1= 发现问题（便于接入 CI / 脚本）。 - 交付模板：OKR 检查报告模板。
输入格式
两种输入都支持，格式自动识别（也可按扩展名 .csv / .md 判定）。
1) CSV 表格
列名自动识别（大小写、空格差异兼容）：
| 角色 | 候选关键词 |
|---|---|
| Objective（目标） | Objective / 目标 / 目的 / goal / O |
| KeyResult（关键结果） | KeyResult / KR / 关键结果 / 关键成果 / 结果 |
| 负责人 | 负责人 / 责任人 / 执行人 / owner |
| 周期 | Quarter / 周期 / 季度 / 时间窗 / Q |
- 目标列留空的行，其 KR 自动归属到上一条目标。
- KR 缺负责人/周期时，会继承所属目标的负责人/周期。
2) Markdown 的 O / KR 层级结构
# OKR · 2026 Q4
## O1 提升用户满意度
- KR: 满意度从 80% 提升至 95%（负责人：张三）
- KR: 用户投诉量由 100 件降至 20 件
负责人：张三
周期：2026Q4
## O2 提升整体用户体验
- 服务器成本降低 30%
- 目标行：以
O…/目标/Objective开头（可带#标题）。 - KR 行：以
KR…/关键结果开头，或目标下的普通- / *列表项。 - 负责人 / 周期可写成独立行（
负责人：张三），也可内联在 KR 文本里。
检查项与规则码
| 规则码 | 含义 | 严重度 |
|---|---|---|
R1 O_TASK_LIKE |
Objective 写成任务（含完成/交付/上线/负责/推进/做好等动作词） | 高 |
R3 KR_NOT_MEASURABLE |
KR 无可量化表达（无数字/百分比，也无 ≥/≤/达到/降至 等） | 高 |
R2 O_HAS_NUMBER |
Objective 里塞了量化指标（应移到 KR） | 中 |
R4 KR_TOO_MANY |
单个 O 下 KR 超过 5 条 | 中 |
R5 KR_TASK_LIKE |
KR 是任务清单（协助/参与/支持/配合/跟进/推动等，无结果交付） | 中 |
R6 KR_NO_BASELINE |
KR 只有目标值、没有基线值 | 中 |
R7 KR_NO_OWNER |
KR 缺负责人 | 中 |
R9 O_KR_MISALIGN |
KR 与 Objective 关键词完全不重合（疑似不对齐） | 中 |
R10 O_VAGUE |
Objective 含无法验收的模糊词（更好/更强/提升整体/优化一切等） | 中 |
R11 DUPLICATE_KR |
KR 文本重复或高度相似 | 中 |
R8 KR_NO_CYCLE |
KR 缺周期 / 时间窗 | 低 |
输出示例（节选）
文件：okr.csv（格式：CSV）
=== OKR 质量体检报告 ===
目标数：3｜KR 数：10
问题合计 27 项：高 6 · 中 20 · 低 1
结论：存在硬伤（目标写成任务 / KR 无法衡量），先修再改
—— 高风险 ——
[R1] O3「完成2026年增长项目落地」写成了任务，不是目标（O3，第 12 行）
· 说明：出现动作词「完成」，Objective 应是定性方向，动作交给 KR/任务
· 建议：改写成「想达成什么状态」（如「用户更愿意复购」），去掉完成/交付类动词
[R3] O1-KR1「做好用户满意度提升」无法量化验收（O1-KR1，第 3 行）
· 说明：既没有数字/百分比，也没有 ≥/≤/达到/降至 等判定式
· 建议：补上可衡量的目标值（数量、比例、时限等）
—— 中风险 ——
[R4] O1 下有 6 条 KR，超过 5 条（O1，第 2 行）
[R6] O1-KR2「满意度达到95%」只有目标值、没有基线值（O1-KR2，第 4 行）
[R11] O2-KR2「服务器成本降低30%」与 O2-KR1 重复（O2-KR2，第 11 行）
设计边界
- 纯标准库 Python，只读，无网络请求，无
subprocess/eval；输入按 UTF-8（含 BOM）读取。 - 只做写法与结构性检查（目标定性、KR 可衡量、对齐、重复、责任人、周期），不做战略方向判断、目标合理性评估、完成度计算或绩效打分。
R9对齐判断为关键词启发式：通过中文二元组 + 英文/数字词的重合度判断，零重合才报「疑似不对齐」，属提示而非定论，需人工确认。R11重复判断基于文本归一化与关键词相似度，近似文本会归为「高度相似」。- 样例为构造的演示数据，人名与项目均为虚构。
