# Company Ogsm Review

> 从上级视角审查圈子、业务线、产品线或职能部门 OGSM。默认只需输入上级/公司 OGSM 与下级/部门 OGSM，即可输出父子承接图、规范性反馈和逐条修改建议；当用户补充已批准承接政策、分工矩阵、SP、BP/预算、组织边界和经营证据时，升级为正式治理复核。支持语义对齐与组织批准的不走样承接两种 profile，不内置任何组织的战略、业务、人员或指标内容。用户要求 OGSM 检查、OGSM 评审、父子承接、部门自查、SP/BP/预算一致性或 OGSM 不走样拆解时使用。

- Skill: `binbingoes/company-ogsm-review` (Agent Skill, multi-file: 12 files)
- Install (CLI): `npx skillmds@latest add binbingoes/company-ogsm-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/binbingoes/company-ogsm-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: binbingoes (https://skillmd.com/u/binbingoes)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/binbingoes/company-ogsm-review

---


# 公司级 OGSM 下级审查

## 🔴 CHECKPOINT · STOP｜先验政策与父子类型

任何分析前，必须逐字输出并填写这六行；省略即表示审查未完成：

```text
审查模式：<双文档自查/正式治理复核/资料预检/历史回测>
承接标准适用性：<通过/自查 profile（未正式验证）/不适用（语义对齐）/GAP/冲突；policy metadata>
S→O：<通过/失败/语义承接/未审；parent_id→child_id>
M→G：<通过/失败/语义承接/未审；parent_id→child_id>
上级 S/M 具名承接覆盖：<x/y；无人承接 ID>
SP/BP 一致性：<通过/冲突/GAP/未审；source revision 或“增强材料未输入”>
```

方法边界：

- “S/M 原样成为下级 O/G”在本 skill 中定义为被审组织批准的`OGSM 不走样承接标准`，用于确定性拆解与审计；它不是所有 OGSM 流派都必须遵循的唯一普适理论。
- 只有政策名称、版本、适用周期和批准状态明确，且政策明确要求 exact text inheritance 时，下面的逐字继承规则才作为 P0 硬门。
- 政策缺失、草案、过期或与被审周期冲突时，`承接标准适用性`写 `GAP/冲突`：两份 OGSM 可读就进入 `semantic_alignment` 双文档自查；用户明确选择严格 profile 时，把严格映射列为未验证的修改标准/压力测试。不得把其他 OGSM 级联方式判成“普适错误”，正式治理结论保持`未审`。
- 双文档自查可由用户选择 `approved_no_distortion` profile。此时按不走样标准给修改建议，但若没有政策版本与生效证据，必须注明“自查 profile，非正式 policy 验证”，不得升级为正式通过。
- 用户未指定严格 profile 且未提供批准政策时，使用 `semantic_alignment`：检查每条下级 O/G 是否可追溯到上级 S/M、意图和红线是否保留、贡献是否可衡量；不要求逐字一致。

政策适用时的不可变规则：

- 上级 S 必须移动到本级 O，文本保持原样；本单元任务、客户和范围只写在 `scope`，不得写进 O 原文。
- 上级 M 必须移动到本级 G，文本保持原样；本单元目标值、基线和贡献公式只写在 G 的附属字段，不得写进 G 原文。
- 禁止写“把上级 S/M 拆成、转化成或具体化为本级 O/G”。正确动作是“原文继承到 O/G，范围与数值另列”。
- 若上级 S 被写在本级 S，结论固定为：`S→O 失败`。若上级 M 被写在本级 M，结论固定为：`M→G 失败`。

只有六行均完成后，才进入规范性与内容分析。

## 任务边界

站在上级经营与组合管理视角审查一个或多个下级单元。先选择审查模式：

1. `双文档自查`（默认）：只需上级/公司 OGSM 与下级/部门 OGSM。目标是让负责人知道哪里未承接、哪里写法不合格、具体如何修改；增强材料缺失不阻断本轮反馈。
2. `正式治理复核`：在双文档基础上增加批准政策、分工矩阵、SP、BP/预算、组织边界、经营证据与身份核验，才可给正式治理判定。
3. `资料预检`：上级或下级 OGSM 任一不可读时，只列输入缺口和准备动作。
4. `历史回测`：只按被审周期当时有效的政策、SP 与 BP 判断。

结果分成两条独立结论：

1. `规范性`：O/G/S/M/A 是否按 OGSM 标准书写、可衡量、可问责、可复盘。
2. `内容合格度`：是否按选定 profile 承接上级 OGSM；正式治理复核还要判断是否与同周期 SP、BP/预算和经营口径一致。

不替管理层批准目标、预算、任命或绩效结果。没有来源的数字、责任人和判断统一标为 `GAP`；有冲突的内容标为 `CONFLICT`。

## 输入契约

### 双文档自查的最小输入

1. 上级/公司 OGSM：至少可识别 O/G/S/M、周期、版本或更新时间。
2. 下级/部门 OGSM：至少可识别 O/G/S/M；Owner、周期、版本缺失时仍继续审查，并把缺口写进修改建议。

两份文档均可读时，必须直接给出逐条映射、规范性反馈和修改建议。不得因为缺 SP、BP、预算、分工矩阵或通讯录核验而拒绝自查；这些缺失只限制正式结论和扩展一致性检查。

### 正式治理复核的增强输入

正式治理复核必须取得以下七包材料：

1. 承接政策：组织批准的 `OGSM 不走样承接标准`，含 policy name、revision、status、`effective_from`、`effective_to`、`effective_periods` 和是否要求逐字继承。
2. 公司/上一级 OGSM：含版本、周期、S/M 编号和公司级 A Owner。
3. 公司 S/M 分工矩阵：说明哪些 S/M 由当前单元承接，其他 S/M 由谁承接。
4. 当前单元 OGSM：含 O/G/S/M/A、版本、Owner 和适用周期。
5. 同周期公司 SP：至少含战略选择、Where to Play、How to Win、明确不做和阶段目标。
6. 同周期公司 BP/预算：至少含承诺、预测、基线、预算行、里程碑、释放/停止条件和数据口径。
7. 组织与证据包：单元边界、收入/客户/SKU/渠道/共享成本归属、实际数据、Owner/Due/Check/Evidence。

先建立来源登记表：`source_id / title / revision / effective_from / effective_to / period / owner / status`。

只把用户本次提供、连接器返回或用户明确授权读取的材料登记为证据。仓库中的 `tests/`、`examples/`、`test-prompts.json` 及占位数据只用于测试 skill，真实审查时禁止读取、运行或引用它们来补齐用户材料。用户声称“材料已提供”但当前任务拿不到正文时，仍按材料不可读处理。

组织批准必须单独核验，不得从材料是否完整或措辞是否正式推断。AI 生成摘要、AI 修订稿、dry-run、已创建文档、计划交付、未批准修订、会议摘要和高层口头支持都只算工作产物，不算批准证据。只有同时具备`批准人/决策机构`、`被批准的精确版本`、`批准状态`、`生效周期`和可回读的`真实决策回执或记录`，才能把政策、OGSM、SP、BP/预算或例外升级为组织批准；任一缺失均标 `GAP/未批准`，正式治理结论不得写“通过”。

所有公司 A、下级 A、数据 Owner 和他处承接人必须通过公司权威通讯录实时反查为个人。不得接受计划提交者自建的“people”表作为身份证明。若当前环境可访问飞书，使用只读通讯录查询核验姓名与个人 `open_id`；若无法核验，只能预审，不能正式“通过”。

责任角色必须分开登记，不能互相推定：

| 角色 | 只证明什么 | 不得据此推定 |
|---|---|---|
| `access_contact` 权限联系人 | 能协助开通或定位材料 | 业务结果 A、提交人、数据 Owner |
| `submitter` 提交协作人 | 提交或维护了版本 | 业务结果 A、批准人 |
| `business_accountable` 业务结果 A | 对业务结果最终问责 | 数据定义或权限管理责任 |
| `data_owner` 数据 Owner | 对指标定义、来源和质量负责 | 业务结果 A |

正式源不可读时只记录已证实的角色，进入资料预检；不得把权限联系人、提交协作人、相邻业务负责人或文档所有者自动写成当前单元的业务结果 A。

如果上级或下级 OGSM 任一不可读，进入`资料预检`。若两份 OGSM 可读但增强材料不全，仍完成`双文档自查`，只是不输出正式“通过”。历史材料只使用当时有效的组织规则；把当前规则另列为压力测试，不得倒查后制造误报。

## 组织批准后的核心承接法则

当且仅当开头的`承接标准适用性`为`通过`，把以下规则作为 P0 硬门，不做宽泛的“相关性”判断：

```text
上一级 S = 下一级 O
上一级 M = 下一级 G
下一级 S = 再下一级 O
下一级 M = 再下一级 G
```

具体执行：

- 下级 O 必须原样保留所承接的上级 S 文本；单元范围、客户和边界写在独立的 `scope` 列，不得改写 S。
- 下级 G 必须原样保留所承接的上级 M 文本；本单元基线、目标值、贡献公式和数据源写在独立字段，不得改写 M。
- `S→S`、`S→G`、`M→M`、`M→O`、只写“支持/协同/相关”均不算承接。
- 每一条上级 S、每一条上级 M 都必须出现具名公司 A 和具名下级承接人。没有人承接即 `暂停`。
- 一个上级 S/M 可以由多个下级单元按互斥范围共同承接，但必须写清范围、汇总公式和去重规则；“共同负责”不能替代单一 A。
- 当前单元未承接的上级 S/M，必须在公司分工矩阵中标明其他具名承接人和决策依据；否则公司组合覆盖仍为 `GAP`。
- 支持方只进入 `C/S` 或依赖列，不计入 S/M 承接覆盖率。

后续报告直接沿用开头 CHECKPOINT 的六行结果，不要重复复述规则或再次输出同一组硬门。

如果材料把上级 S 放在本级 S，必须明确写：`失败：上级 S 没有成为本级 O；把上级 S 从本级 S 移到本级 O，并保持原文。` 不能写成“原样复制上级 S 不合格”。

如果材料把上级 M 放在本级 M，必须明确写：`失败：上级 M 没有成为本级 G；把上级 M 从本级 M 移到本级 G，并保持原文。` 不能建议把上级 M “拆到本级 G/M”。本单元目标值、基线和贡献公式是 G 的附属字段；本级 M 只衡量本级 S。

先读 [references/parent-child-mapping.md](references/parent-child-mapping.md)，再建立逐条映射。未经映射，不进入写法评分。

## 审查流程

### Step 1｜锁定周期、版本与边界

确认：

- 当前使用双文档自查、正式治理复核、资料预检还是历史回测；
- 不走样承接政策是否已批准、版本化，并在被审周期内生效；
- 公司 OGSM、下级 OGSM、SP、BP/预算是否同一决策周期；
- 当前单元是圈子、业务线、产品线、平台还是职能部门；
- 当前单元服务谁、控制什么、不控制什么；
- 产品、客户、渠道、国家、价格带、收入、成本、预算和共享能力是否与其他单元重叠；
- 规则在被审周期内是否有效。

版本冲突时并列展示，不静默选一个。双文档自查将其列为高优先级修改项；正式治理复核中，关键周期、版本或边界冲突未关闭则判 `暂停`。

### Step 2｜建立公司 S/M 承接总账

逐条列出全部上级 S/M，不只列当前单元想承接的部分：

| parent_id | 上级原文 | 公司 A | 当前单元是否应承接 | child_id | 下级原文 | 下级 A | scope | 汇总/去重 | 状态 |
|---|---|---|---|---|---|---|---|---|---|

执行两次检查：

1. `单元检查`：当前单元的 O/G 是否按选定 profile 承接上级 S/M；严格 profile 检查原文继承，语义 profile 检查可追溯、意图/红线保留和可衡量贡献。
2. `组合检查`：有分工矩阵时检查全部上级 S/M 是否至少有一个具名下级承接人，且没有范围冲突或结果重复计数；无矩阵时明确“仅能检查当前单元，无法证明组织组合全覆盖”。

正式治理复核可运行确定性结构检查：

```bash
python scripts/validate_review.py review.json --format markdown --verify-owners-live
```

JSON 字段见 [references/input-schema.md](references/input-schema.md)。双文档自查不要求先构造 JSON；脚本通过只代表正式模式的结构门通过，不代表战略内容获批。

`--verify-owners-live` 会只读查询飞书通讯录，核对 `name/open_id/tenant`。省略该参数时，脚本允许做离线结构检查，但 `formal_pass_possible` 固定为 `false`。

### Step 3｜检查 OGSM 书写规范性

按 [references/checklist.md](references/checklist.md) 检查：

- `O`：严格 profile 使用所承接上级 S 的原文；语义 profile 必须可追溯到上级 S、保留意图和边界，不另造无来源口号。
- `G`：严格 profile 使用所承接上级 M 的原文；语义 profile 必须可追溯到上级 M。两种 profile 都要把基线、目标、公式、来源、数据 Owner、复核日列清。
- `S`：写清选择、机制、控制点、因果桥和明确不做；不是动作清单。
- `M`：衡量本级 S，每条 S 至少包含结果指标、领先指标和红线/停止指标；不是里程碑清单。
- `A`：关键行动有单一 Owner、Due、Check、Evidence、依赖和资源来源。

圈子/业务线最多保留 1—3 个关键战略机会；职能部门最多保留 1—3 个下游价值结果。职能部门没有直接收入时，使用周期、质量、采用、复用、风险避免、SLA 和下游经营贡献，不强造收入指标。

### Step 4｜检查公司 SP 一致性

仅在用户提供同周期 SP 时执行；否则写 `未审（增强材料未输入）`，不阻断双文档自查反馈。

逐项回答：

1. 下级承接的 O/G 是否指向公司 SP 中同周期的战略选择和阶段目标？
2. 本级 S 是否服务公司 Where to Play / How to Win，还是擅自增加战场、客户、国家、价格带或产品线？
3. 是否保留公司明确不做、退出和资源上限？
4. 是否把渠道/客户要求、AI 工具、活动或组织动作误写成战略？
5. 是否用旧 SP 或未来 SP 的目标替代本周期口径？

任何下级战略与有效 SP 正面冲突且无批准例外，判 `暂停`。触碰安全、质量、诚信、隐私或合规红线，判 `终止`。

### Step 5｜检查公司 BP/预算一致性

仅在用户提供同周期 BP/预算时执行；否则写 `未审（增强材料未输入）`，不阻断双文档自查反馈。

逐项核对：

- 周期、币种、收入、管理利润/利润口径、现金、毛利、单位资源产出分母和数据源一致；
- 下级 G 的基线、承诺、预测、挑战值不混写；
- 下级目标可汇总到公司 BP，且客户/SKU/渠道/收入/共享成本不重复；
- 每个 G 有对应 BP 里程碑，每项关键预算购买明确的最小证据；
- 每项不可逆投入有释放条件、停止条件、authority 和复核日；
- AI 只在采用并改善周期、质量、成本、转化或经营结果时计价值，不用 token、调用量、培训数代替结果。

公司 BP 与下级 G 数字冲突、无法汇总或重复计数，关键结论判 `暂停`，并指定 Resolver、Due、Check。

### Step 6｜检查经营闭环

双文档自查至少检查 `上级 S/M → 下级 O/G → 下级 S/M` 是否连通；只有 BP、预算、证据和月度实际可读时，才检查完整经营闭环。

对每个下级 G 追踪：

```text
公司 SP → 公司 OGSM S/M → 下级 O/G → 下级 S/M
→ BP 里程碑 → 预算行 → 最小证据 → Release/Stop
→ 月度实际 → Gap → 根因 → 纠偏 → 复核结果
```

缺任一关键 Owner、Due、Check、Evidence 或停止门，不能判“闭环”。

### Step 7｜给出双结论与总判定

双文档自查先分别判定：

- `规范性：合格 / 部分合格 / 不合格 / 无法判断`
- `内容承接：已对齐 / 部分对齐 / 未对齐 / 无法判断`
- `自查总判定`取较低结果，并给出按优先级排序的 3—7 项修改建议。缺增强材料时写清“未审范围”，但不能因此省略可由两份 OGSM 直接得出的修改建议。

正式治理复核再分别判定：

- `规范性：通过 / 验证 / 暂停 / 终止`
- `内容合格度：通过 / 验证 / 暂停 / 终止`

总判定取两者较低结果，并受 P0 硬门覆盖。只使用：

| 结论 | 条件 |
|---|---|
| 通过 | 严格父子承接、SP/BP 一致、边界去重、指标证据、责任与复盘均闭合；只在已批准范围内执行。 |
| 验证 | 方向与映射成立，但证据或部分指标未闭合；只允许小额、可逆、带停止门的验证。 |
| 暂停 | 资料/版本缺失、S/M 漏接或改写、无人承接、SP/BP 冲突、口径不可汇总、关键闭环缺失。 |
| 终止 | 命中红线，或核心价值/商业闭环已被证伪。 |

上级或下级 OGSM 不可读时写 `暂不评分（双文档不完整）`。仅增强材料不全时，完成双文档自查并写 `正式治理结论：未审`，不要输出伪精确分数。

## 正式治理复核 P0 硬门

仅在正式治理复核中，任一命中不得“通过”。双文档自查若命中，应判`部分对齐/未对齐`并给修改方案，不得停止反馈：

- 不走样承接政策未批准、未版本化、对被审周期不生效，或未明确要求 exact text inheritance；
- 上级 S 未原样成为下级 O；
- 上级 M 未原样成为下级 G；
- 任一上级 S/M 没有具名承接人；
- 支持方被冒充为承接人，或多人“共同负责”但无单一 A；
- 公司 OGSM、SP、BP/预算周期或版本不清；
- 下级目标与公司 BP 冲突、无法汇总或重复计数；
- 下级策略超出公司 SP 主战场且无批准例外；
- 关键数字缺定义、公式、基线、来源、Owner 或复核日；
- 关键预算无证据购买、Release/Stop、authority 或复核日；
- 安全、质量、诚信、隐私、合规或重大信任红线未闭合。

## 失败恢复

| 触发条件 | 一线处理 | 仍未解决 |
|---|---|---|
| 公司 S/M 没有编号 | 临时按文档顺序编号并注明 `JUDGMENT` | 要求公司 Owner 确认编号；此前不得正式通过 |
| 严格 profile 下级改写了上级 S/M | 把上级原文恢复为下级 O/G，范围和指标拆到独立字段 | 正式复核中负责人拒绝恢复时判 `暂停` |
| 缺公司 S/M 分工矩阵 | 审当前单元映射，同时列出全部未确认 S/M | 组合覆盖保持 `GAP`，不得声称公司已闭环 |
| SP/BP 与 OGSM 周期不一致 | 按生效期分账，当前规则只做压力测试 | 无法确认历史有效版本时，正式治理结论未审；双文档自查继续 |
| 职能部门无直接收入 | 改查下游价值、周期、质量、采用、风险和 SLA | 仍无法指向公司 S/M 或 BP 结果时判 `暂停` |
| 数字口径冲突 | 并列定义、来源和差值，指定 Resolver | 关闭前相关 G 判 `暂停` |
| 结构脚本报错 | 按错误补字段或修正类型后重跑 | 用人工矩阵兜底并披露未通过确定性验证 |

## 反例黑名单

不要：

- 把“方向一致”“支持公司战略”当作父子承接；
- 严格 profile 下允许 `S→S`、`M→M` 或语义近似映射蒙混过关；
- 严格 profile 下为了适配下级表述而改写上级 S/M；
- 只检查当前单元想接的条目，忽略公司其他 S/M 是否无人承接；
- 用表格完整、措辞漂亮或高目标抵消 SP/BP 冲突；
- 用当前战略规则直接裁判历史 OGSM；
- 把预测、挑战目标、订单、出货、压货、活动量或 AI 调用量当作承诺结果；
- 给职能部门强造收入，或只看活动、会议、培训和招聘数量；
- 平均冲突数字、静默选择一个版本、重复计算共享结果；
- 把 skill 自带的合成测试数据、示例人名或占位 ID 当作被审组织的真实证据；
- 把权限联系人、提交协作人、文档所有者或相邻业务负责人自动认定为当前业务结果 A；
- 用负责人短反馈替代完整审查，或在短反馈中堆入超过 3 项修改；
- 因外发而删除全部分模块数据，或在隐私检查记录里复述公司合并敏感值；
- 未确认收件人、内容和发送身份就真实发送消息；
- 把 AI 生成摘要、dry-run、创建文档、会议摘要、未批准修订或口头支持当成组织批准；
- 替管理层自动批准预算、任命、绩效或终止决定。

## 输出路由

严格使用 [references/output-template.md](references/output-template.md)，并按证据量只选一种模式：

- `资料预检`：上级或下级 OGSM 任一不可读、只有摘要或无法识别 O/G/S/M 时使用。输出六行检查点、输入缺口和准备动作。
- `双文档自查`：两份 OGSM 均可读时默认使用。输出六行检查点、逐条父子映射、规范性与内容承接双结论、未审范围、3—7 项修改建议和可直接替换的建议写法。
- `正式全版`：七包材料可读、周期版本明确、承接政策适用且人员身份已由权威目录核验时使用。输出来源表、全部 S/M 承接总账、规范性、SP/BP、经营闭环、修改项和裁决题。
- 用户明确要求完整报告时可输出全版，但缺失项仍标 `GAP`，总判定不得升级。

双文档自查中的每项修改建议必须写清“问题—为什么—怎么改—验收标准”；Owner/Due 未提供时写 `待负责人填写`，不得虚构。正式模式必须给出 Owner、Due、Check。

### 交付边界附加规则

这些规则不新增审查模式，只约束审查结果如何被压缩、外发和发送。

#### 负责人短反馈

用户要求私信、群消息或负责人短反馈时：

1. 先完成并保留对应的资料预检、双文档自查或正式全版；短反馈不能替代完整审查证据。
2. 另输出一段人话短反馈，只保留结论、最多 3 项优先修改，以及上级/公司外发版、当前单元 OGSM、Skill 说明三类链接。
3. 正式源不可读时明确写“资料预检/暂不评分”，只请求补权限、确认正式源和业务 A，不把二级证据写成正式结论。

#### 外发数据边界

用户要求隐藏公司整体数据但保留分模块数据时，使用以下 privacy profile：

- `company_consolidated`：公司整体合并目标/实际、覆盖全部模块的汇总或小计、未分配差额、抵消项、勾稽关系，以及可直接倒推出公司整体合并口径的占比或公式。外发时隐藏。
- `module_level`：单个业务线、圈子、产品线或中后台模块自身口径。用户已授权外发时保留，不得因“脱敏”而整表删除。
- 若多个模块值与桥接字段可直接复算公司合并口径，只隐藏汇总、差额、占比或桥接关系；保留获准的模块原值。
- 输出 `privacy_check_record`，只说明隐藏了哪些类别、保留了哪些类别及是否关闭反推风险；不得在记录中复述敏感值。

#### 🔴 CHECKPOINT · STOP｜真实发送

任何消息真实发送前，必须让用户明确确认：`收件人`、`消息内容`、`发送身份（用户或机器人）`。三项任一未确认时只输出草稿或 dry-run，不调用发送接口。发送后记录 `message_id` 并回读核验发送人、正文和关键链接。

## 完成门

完成双文档自查必须满足：

- 上级与下级 OGSM 的版本/周期/可读状态已说明；
- 已逐条建立上级 S/M 与下级 O/G 的承接关系，无法映射的条目明确列出；
- O/G/S/M/A 规范性逐项判定；
- 已给出规范性与内容承接双结论、未审范围和 3—7 项可执行修改建议；
- 每项建议含问题、原因、改法和 Check，未提供的 Owner/Due 明确标 `待负责人填写`。
- 若用户要求负责人短反馈，完整审查仍保留；短反馈不超过 3 项修改并包含三类链接。
- 若用户要求外发脱敏，已区分 `company_consolidated` 与获准的 `module_level`，并给出不复述敏感值的 `privacy_check_record`。
- 若已真实发送消息，用户已确认收件人、内容和身份，且已记录并回读 `message_id`。

完成正式治理复核还必须满足：

- 七包材料的版本、周期和读取状态明确；
- 不走样承接政策的批准状态、版本、`effective_from/effective_to/effective_periods` 和 exact-text 要求明确；
- 全部上级 S/M 的承接去向和公司 A 明确；
- 当前单元应承接的 S/M 已严格变为本级 O/G；
- O/G/S/M/A 规范性逐项判定；
- 公司 SP、BP/预算一致性逐项判定；
- 跨单元边界、汇总公式和去重规则明确；
- P0 硬门全部通过；
- 缺口、Owner、Due、Check、决策 authority 和下一复核日明确。