Skill: houtonghoutong/xgjk-bp-audit (version 3.5.0)

--- name: bp-audit description: BP目标体系全面审计工具：对BP进行五大板块审计——基础合规性审计、向上对齐审计、向下承接审计、GAP 差异分析、数值对齐审计。 覆盖结构完整性、内容质量、逻辑自洽、对齐正确性、承接覆盖率、数值定义与算法、上下级差异识别等维度。 内置数据查询能力，当用户需要对BP目标体系进行系统性审计诊断时使用。 user-invocable: true metadata: { "openclaw": { "emoji": "🎯" } } --- # BP 目标体系全面审计 — 索引 本文件提供**能力宪章 + 能力树 + 按需加载规则**。详细审计规则见 `references/`，使用示例见 `examples/`。 **当前版本**: v3.5 (Write Support for Child KR/Action) **接口版本**: 所有业务接口统一使用 `/open-api/bp/*` 前缀，自带 `appKey` Header 鉴权，不依赖网关。 ## 审计执行核心原则（Mandatory） 1. **问题与建议对齐**：每次审计输出问题清单时，**必须同时输出对应的修改建议（Action/Recommendation）**。严禁只抛出问题而不给方案。 2. **灵活的向上承接**： - **允许创新目标**：**组织和个人 BP 均允许**存在“非承接性”的目标（即无向上对齐的目标）。这被视为局部主动性或业务创新，不应判定为严重错误。 - **内容大于形式**：组织和个人 BP 的内容范畴均允许大于上级要求的范畴。 - **审计动作**：若发现无向上对齐的目标，仅需记录并提醒用户核实是否为有意为之，标注为“轻微：核实是否为自主创新/非承接项”。 3. **内容穿透要求**：虽然允许创新，但组织 BP 必须确保上级下达的任务在下级有明确 ID 承接。 4. **权重强制原则**：所有审计输出（无论是组织还是个人 BP）**必须包含建议权重（提供初始建议值）**。即便系统中权重字段为空，也必须根据战略重要性给出建议权重。 ## 审计模式核心差异：组织 BP vs. 个人 BP 为了确保审计深度符合管理要求，审计时必须根据被审计对象的类型（组织 vs. 个人）应用差异化规则： ### 1. 组织 BP (Organizational BP) — 侧重“战略闭环与责任分解” - **核心逻辑**：组织 BP 是战略承接的载体。 - **输出要求**：必须包括 **BP 内容检查、向上对齐审计、向下承接审计、修改建议、建议权重（仅提供初始值）**。 - **目标命名**：必须是“组织状态”的静态定格（如：`XX中心年度营收目标已达成`）。 - **审计深度 (必检)**： - **向下承接闭环**：组织目标的每一个 KR 和 Action 必须有对应的子部门或子组织负责人。**严禁“悬空举措”**（举措没人接）。 - **跨部门协同**：涉及多部门的 Action，必须检查协作边界和主责部门。 - **战略覆盖率**：必须检查上级（集团/中心）的核心要求是否在下级部门中被“全量承接”，不能漏项。 ### 2. 个人 BP (Individual BP) — 侧重“个人承诺与因果逻辑” - **核心逻辑**：个人 BP 是岗位职责与贡献的承诺。 - **输出要求**：必须包括 **BP 内容检查、向上对齐审计、修改建议、建议权重（仅提供初始值）**。 - **目标命名**：必须是“个人承诺状态”的静态定格（如：`本人负责的XX项目交付已完成`）。 - **审计深度 (必检)**： - **人责匹配 (Personnel Rule)**：**硬性校验**「下级目标责任人 = 上级组织 Action 承接人」。 - **G-R-A 因果律**：审计 KI 是否真的能推导出 KR，KR 是否足以验证 Goal。拒绝“为了写而写”的废话举措。 - **SMART 衡量标准**：KR 必须具备可审计的数据源（SAP/CRM 等）和明确的正负偏差阈值。 ## 五大审计板块 | # | 板块 | 说明 | 规则文档 | |---|------|------|---------| | 1 | 基础合规性审计 | BP 本身信息检查：结构完整性、内容质量、逻辑自洽性 | `references/quality-rules.md` | | 2 | 向上对齐审计 | 我和上级的承接：对齐正确性、对齐完整性、人员匹配 | `references/upward-check-rules.md` | | 3 | 向下承接审计 | 下级跟我的承接：承接正确性、完整性、数值覆盖、协作约束 | `references/downward-check-rules.md` | | 4 | GAP 差异分析 | 拉通上下级差异：承接差、执行差、逻辑差 | `references/gap-analysis-rules.md` | | 5 | 数值对齐审计 | 从“提数字”到“定义数字”：数值定义、属性、算法、关联场景 | `references/numerical-audit-rules.md` | ### 板块一：基础合规性审计（BP 本身信息） | 检查点 | 说明 | 严重等级 | |--------|------|---------| | 结构完整性 | 必须包含 G-R-A 三层结构，层级深度符合组织要求 | 严重 | | 内容质量 | 描述是否具体、可衡量、有明确行动指向 | 一般 | | 逻辑自洽 | KI 是否能推导出 KR 的达成，KR 是否能验证 Goal 的完成 | 严重 | | 衡量标准 SMART | KR 衡量标准是否满足 SMART + 最小完备要求 | 严重 | | 汇报周期 | 举措周期 ≤ KR周期 ≤ 目标周期 | 一般 | | 举措颗粒度 | 举措是否具体可执行、可承接 | 一般 | | 语义定义 | 目标禁动词、KR 描述可验收状态、举措描述具体行动 | 一般 | | 必填项完整 | 责任人/承接人、起止时间、汇报周期是否填写 | 严重 | ### 板块二：向上对齐审计（我和上级的承接） | 检查点 | 说明 | 严重等级 | |--------|------|---------| | 对齐正确性 | 完整结构是否支撑上级意图（严禁只看名称） | 严重 | | 衡量标准支撑 | KR 衡量标准能否支撑上级要求的达成 | 严重 | | 行动方向一致 | KI 行动方向是否与上级意图吻合 | 一般 | | 人员匹配 | 下级目标责任人 = 上级举措承接人 | 严重 | | 对齐完整性 | 是否存在选择性承接 or 职责盲区 | 严重 | | 层级正确性 | 对齐路径是否符合层级规则（中心→集团KR，部门→中心KI，员工→部门KI） | 严重 | ### 板块三：向下承接审计（下级跟我的承接） 仅在有下级数据（`向下承接` 非空，即 Markdown 中非 `向下承接：无`）时执行。 | 检查点 | 说明 | 严重等级 | |--------|------|---------| | 承接正确性 | 下级目标完整结构是否正确承接本级任务 | 严重 | | 承接身份匹配 | 上级举措承接人 = 下级目标责任人 | 严重 | | 承接完整性 | 核心任务是否有人承接，是否存在悬空 | 严重 | | 多承接协作 | 多部门承接时交付物边界是否明确 | 一般 | | 冗余性 | 是否存在不合理的重复承接 | 轻微 | | 数值指标覆盖 | 数值类指标口径一致性和覆盖率 | 严重 | ### 板块四：GAP 差异分析（拉通上下级差异） | 检查点 | 说明 | 严重等级 | |--------|------|---------| | 承接差 | 上级核心要求是否在本级和下级中层层衰减 | 严重 | | 执行差 | 下级汇总能力/指标是否足以支撑本级目标达成 | 严重 | | 逻辑差 | 上下级之间是否存在口径不一或理解断层 | 一般 | | 数值 GAP | 数值类指标上下级差异量化分析 | 严重 | | 能力 GAP | 非数值类能力要求的覆盖缺口 | 一般 | ### 板块五：数值对齐审计（从“提数字”到“定义数字”） | 检查点 | 说明 | 严重等级 | |--------|------|---------| | 数值定义 | 是否明确了数值的业务边界与口径（含税/币种/范围） | 严重 | | 数据属性 | 是否明确数值是原始产出还是计算结果 | 一般 | | 底层算法 | 计算结果类数值是否提供了清晰的数学公式（A+B-C） | 严重 | | 数据来源 | 是否指定了验收数值的数据源系统（SAP/CRM/人力等） | 一般 | | 关联场景 | 是否明确了指标的对冲关系及应用场景（预警/考核） | 一般 | ## 内置数据查询与写入（10 个接口） 数据查询和受控写入通过 `scripts/bp-audit/bp_api.py` 执行，默认输出 Markdown 格式（`--format md`）。 **脚本调用方式**（从工作区根目录执行）： ```bash python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py <action> [options] --format md ``` > **`--format md` 为推荐默认用法**，将 API 返回的 JSON 转为紧凑 Markdown 自然语言，可节省 **67-80%** 的 token。仅在需要原始 JSON 结构时使用 `--format json`。 ### 可用 action 一览 | action | 说明 | 必填参数 | 可选参数 | |--------|------|----------|----------| | `get_all_periods` | 查询所有 BP 周期列表 | 无 | `--name` | | `get_group_tree` | 获取某周期下的分组树（**数据量极大，500KB+，仅在搜索无果时兜底使用**） | `--period_id` | `--only_personal` | | `get_task_tree` | 获取某分组下的目标/KR/举措树 | `--group_id` | 无 | | `get_goal_detail` | 获取目标详情（含所有 KR 和举措） | `--task_id` | 无 | | `get_key_result_detail` | 获取关键成果详情（含所有举措） | `--task_id` | 无 | | `get_action_detail` | 获取关键举措详情 | `--task_id` | 无 | | `search_task` | 按名称模糊搜索任务 | `--group_id`、`--name` | 无 | | `search_group` | 按名称模糊搜索分组 | `--period_id`、`--name` | 无 | | `add_key_result` | 根据目标 ID 新增下级关键成果 | `--goal_id`、`--name` | 其他字段见下方写入说明 | | `add_action` | 根据成果 ID 新增下级关键举措 | `--key_result_id`、`--name` | 其他字段见下方写入说明 | ### 数据层级 ``` 周期 (Period) ← 如"2026年BP"，顶层时间维度 └─ 分组 (Group) ← 树形结构，分为组织分组(org)和个人分组(personal) └─ 目标 (Objective) └─ 关键成果 (Key Result) └─ 关键举措 (Action) ``` ### 标准下钻流程 1. `get_all_periods` → 找到目标周期的 ID（若用户未指定周期，选 `status=1` 的启用周期） 2. **定位分组**（按优先级选择，严禁无脑拉全量树）： - **优先**：若用户给了 `group_id` → 直接使用，跳过搜索 - **优先**：若用户给了分组名称 → `search_group` 按名称模糊搜索（轻量，通常 <5KB） - 搜索结果**唯一** → 直接使用该 `group_id` - 搜索结果**多个** → **必须向用户确认**是哪一个，列出每个结果的名称、类型、`层级编码` 等区分信息（Markdown 搜索结果表中的列），让用户选择后再继续 - 搜索结果**为空** → 提示用户检查名称，或换关键字重试 - **兜底**：仅当搜索无结果且用户未指定任何分组信息时 → `get_group_tree` 获取完整分组树（**注意：此接口返回数据量极大，可达 500KB+，严重消耗 token，非必要不调用**） 3. **定位任务**（同样优先搜索）： - **优先**：若用户给了 `task_id` → 直接使用，跳过搜索 - **优先**：若用户给了任务名称 → `search_task` 按名称模糊搜索 - 搜索结果**唯一** → 直接使用该 `task_id` - 搜索结果**多个** → **必须向用户确认**是哪一个，列出每个结果的名称、类型、`分组`、`编号` 等区分信息（Markdown 搜索结果表中的列），让用户选择后再继续 - 搜索结果**为空** → 提示用户检查名称，或换关键字重试 - **兜底**：仅当搜索无结果时 → `get_task_tree` 获取任务树再定位 4. 根据任务类型调用对应详情接口： - 目标 → `get_goal_detail`（返回含所有 KR 和举措的完整信息） - 关键成果 → `get_key_result_detail`（返回含所有举措的完整信息） - 关键举措 → `get_action_detail` 输入完整性规则（强制）： 1. 所有 ID 参数必须保持字符串原样传递，严禁 `parseInt` 或 `Number` 转换 2. 每个审计结论必须附带**证据引用**（对象名称、层级关系、关键字段、关键数值） 3. 审计结论必须标注严重等级（严重/一般/轻微） 脚本使用规则（强制）： 1. **执行器规则**：`.py` 脚本用 `python3` 执行。**严禁混用解释器**。 2. **先读文档再执行**：执行脚本前，必须先阅读 `openapi/bp-audit/api-index.md` 获取完整入参说明。 3. **入参以 openapi/ 文档为准**。 4. **搜索优先原则（token 节约，强制）**：当用户提供了分组名称或目标名称时，**必须优先使用 `search_group` / `search_task` 模糊搜索定位**，严禁直接调用 `get_group_tree` 拉取全量分组树。`get_group_tree` 返回数据量极大（500KB+），严重浪费 token，仅在搜索无结果时作为最后兜底手段。 5. **Markdown 输出优先（token 节约，强制）**：所有脚本调用**必须使用 `--format md`**，将 JSON 转为紧凑 Markdown，节省 67-80% token。仅在用户明确需要原始 JSON 时才使用 `--format json`。 6. **写入操作需显式用户意图（强制）**：`add_key_result` / `add_action` 只能在用户明确要求“新增/补充下级成果或举措”时调用，严禁在审计过程中擅自创建任务。 ## 写入能力（新增下级成果 / 下级举措） 当用户明确要求直接修改 BP、补写内容、补充下级任务时，可使用以下两个写入接口： 1. `add_key_result` - 接口：`POST /bp/task/v2/addKeyResult` - 作用：在指定目标下纯新增一个关键成果，不影响已有成果 - 必填：`--goal_id`、`--name` 2. `add_action` - 接口：`POST /bp/task/v2/addAction` - 作用：在指定关键成果下纯新增一个关键举措，不影响已有举措 - 必填：`--key_result_id`、`--name` 常用可选参数： - `--rule_type` - `--required_index` - `--plan_start_date` - `--plan_end_date` - `--owner_ids` - `--owner_dept_ids` - `--collaborator_ids` - `--copy_to_ids` - `--supervisor_ids` - `--observer_ids` - `--upward_task_id_list` - `--weight` - `--description` - `--measure_standard` - `--action_plan` - `--upload_sp_file_dtos` - `--body_json` 字段规则： - 多 ID 字段使用逗号分隔字符串传入，例如 `--owner_ids "1001,1002"` - `--upload_sp_file_dtos` 传 JSON 数组字符串 - `--body_json` 可直接传原始 JSON 对象；若与显式参数同时提供，显式参数覆盖同名字段 ### 写入前的 ID 发现流程（默认路径） **默认假设：用户通常不给 ID，只给周期、组织/人员节点、目标或成果名称线索。skill 必须先自行定位 ID，再执行写入。** #### 场景 A：新增下级关键成果（最终需要 `goal_id`） 1. 根据用户给的周期信息，用 `get_all_periods` 确认 `period_id` 2. 根据用户给的节点名称（部门/人员/组织），用 `search_group --period_id ... --name ...` 定位 `group_id` 3. 根据用户给的目标名称，用 `search_task --group_id ... --name ...` 定位目标任务 4. 从搜索结果中筛选 `type = 目标` 5. 若结果唯一，直接取该任务 `id` 作为 `goal_id` 6. 若结果多个，必须把候选项列给用户确认，禁止猜测 7. 可选：先 `get_goal_detail --task_id <goal_id>` 复核上下文后，再执行 `add_key_result` #### 场景 B：新增下级关键举措（最终需要 `key_result_id`） 1. 根据周期信息定位 `period_id` 2. 根据节点名称定位 `group_id` 3. 根据成果名称，用 `search_task --group_id ... --name ...` 搜索任务 4. 从搜索结果中筛选 `type = 关键成果` 5. 若结果唯一，直接取该任务 `id` 作为 `key_result_id` 6. 若结果多个，必须列出编号、分组、名称让用户确认 7. 可选：先 `get_key_result_detail --task_id <key_result_id>` 复核当前成果及已有举措，再执行 `add_action` #### 搜索不到时的兜底路径 1. `search_group` 无结果：提示用户补充更准确的节点名称；只有完全无法搜索时才允许 `get_group_tree` 2. `search_task` 无结果：允许调用 `get_task_tree --group_id ...` 手动在树里定位 3. 若用户只给“某节点上的某个目标/成果”，但名称不完整，必须先把候选项列出来让用户确认，不能自行假设父任务 推荐执行顺序： 1. 先根据周期 + 节点名称 + 目标/成果名称，自行完成 ID 发现 2. 明确要新增的是“关键成果”还是“关键举措” 3. 用 `get_goal_detail` 或 `get_key_result_detail` 复核父任务上下文 4. 再执行写入 action 5. 写入成功后，回查详情接口，确认新节点已经挂载到正确父任务下 示例： ```bash python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \ --goal_id "2014631829004374017" \ --name "新增 Q2 业绩增长点" \ --measure_standard "新增签约客户数 >= 20" \ --plan_start_date "2026-04-01" \ --plan_end_date "2026-06-30" \ --format md ``` ```bash python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_action \ --key_result_id "2014631829004374018" \ --name "拓展三线城市分销商" \ --measure_standard "签约 10 家以上" \ --owner_ids "1234567890123456789" \ --format md ``` ```bash # 用户不给 ID 时的完整链路示例：先找 group_id，再找 goal_id，最后新增 KR python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_group \ --period_id "<period_id>" \ --name "华东销售一部" \ --format md python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_task \ --group_id "<group_id>" \ --name "年度收入目标已达成" \ --format md python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \ --goal_id "<goal_id>" \ --name "新增渠道收入增长点" \ --format md ``` ## 审计执行自检清单 (v3.4 规避清单 — 强制) 在输出审计报告前，必须检查以下 6 项： 1. **[编码优先]**：表格中是否全部使用 `fullLevelNumber`（如 A8B8-1）作为唯一标识？严禁显示原始数据库 ID。 2. **[权重补全]**：即便 API 返回权重为 0 或空，是否已根据战略意图在 `Weight` 列给出建议初始值？ 3. **[对象覆盖]**： - **组织 BP**：是否覆盖了 **内容检查、向上对齐、向下承接** 三项？ - **个人 BP**：是否覆盖了 **内容检查、向上对齐** 两项？ 4. **[静态事实]**：是否对所有含动词的目标/KR 给出了“已完成”状态的修改建议？ 5. **[穿透深度]**：是否对组织 BP 的每一个 KI 执行了“向下承接”记录核验？ 6. **[修改位置]**：How (Action) 列是否明确指出了修改位置（目标/成果/举措）？ ## 审计流程 ### 第一步：确定审计范围 1. 获取启用周期：调用 `get_all_periods`，筛选 `status=1` 的启用周期 2. 定位分组或目标（**搜索优先，严禁默认拉全量树**）： - 若用户给了 `task_id` 或 `group_id` → 直接使用 - 若用户给了分组名称 → 调用 `search_group` 模糊搜索定位（轻量高效）；**若返回多个结果，必须列出区分信息让用户确认，禁止自行猜测** - 若用户给了目标名称 → 先通过 `search_group` 定位分组，再通过 `search_task` 定位目标；**同样，多个结果必须让用户确认** - 若搜索无结果 → 提示用户检查名称或换关键字；仅当用户完全未指定时 → 才调用 `get_group_tree`（**此接口数据量极大，是最后兜底手段**） ### 第二步：获取审计数据 根据审计入口获取完整数据： - 目标用 `get_goal_detail`（返回含所有 KR 和举措的完整信息） - 关键成果用 `get_key_result_detail` - 关键举措用 `get_action_detail` **关键数据字段**（Markdown 输出中的呈现）： - `向上对齐`：向上对齐的上级任务列表（如 `- 向上对齐（N项）：` 下的列表，每项含名称、`[分组名]` 和 `id`） - `向下承接`：向下承接的下级任务列表（如 `- 向下承接（N项）：` 下的列表，格式同上） - `人员`：参与人列表，含角色（如 `- 人员：张三(责任人), 李四(承接人)`） - `**衡量标准**`：KR 特有的衡量标准（加粗呈现） - `周期`：汇报周期（在 `状态：xx | 周期：xx | 时间：xx` 行中，格式如 `month+20`） - `时间`：计划时间区间（在同一行中，格式如 `2026-01-01 ~ 2026-12-31`） ### 第三步 + 第四步：逐板块审计并即时输出（流式输出，强制） **核心原则：审完一个板块，立即输出该板块的审计结果，不要等全部审完再一次性输出。只执行意图路由决定的板块，不多不少。** 用户应该能看到报告在一段一段地生成，而不是等很久后突然全部出现。 #### 3.1 先输出报告标题和审计范围 拿到审计数据后，**立即先输出**报告标题和审计对象信息（审计范围要体现实际执行的板块）： ``` # XX 2026年度BP 审计报告 ## 审计概要 - 审计对象：... - 审计范围：基础合规性审计（板块一） ← 根据实际执行板块填写 - （评分和总结留到最后补充） ``` #### 3.2 板块一：基础合规性审计 → 立即输出（所有模式必执行） 1. 加载 `references/quality-rules.md` 2. 基于已获取的本级数据执行审计 3. **审计完成后立即输出板块一的完整结果**（结构完整性、内容质量、逻辑自洽、衡量标准、汇报周期、语义定义、必填项，每个检查项逐一列出具体问题对象） 4. 若意图路由仅需板块一 → 跳到 3.6 输出汇总；否则继续下一板块 #### 3.3 板块二：向上对齐审计 → 立即输出（仅在意图路由包含时执行） 1. 加载 `references/upward-check-rules.md` 2. 获取上级任务详情（如需要） 3. 执行审计 4. **审计完成后立即输出板块二的完整结果**（对齐正确性逐项表、对齐完整性、人员匹配、层级正确性） 5. 若意图路由不含板块三 → 跳到 3.6 输出汇总；否则继续 #### 3.4 板块三：向下承接审计 → 立即输出（仅在意图路由包含时执行） 1. 加载 `references/downward-check-rules.md` 2. 获取下级任务详情（如需要） 3. 执行审计 4. **审计完成后立即输出板块三的完整结果**（承接正确性逐项表、承接身份匹配、承接完整性、数值覆盖明细） 5. 若意图路由不含板块四 → 跳到 3.6 输出汇总；否则继续 #### 3.5 板块四：GAP 差异分析 → 立即输出（仅全面审计/GAP分析时执行） 1. 加载 `references/gap-analysis-rules.md` 2. 基于前三个板块的数据执行分析 3. **审计完成后立即输出板块四的完整结果**（承接差追踪表、执行差、逻辑差、数值GAP穿透表、综合评估） #### 3.6 板块五：数值对齐审计 → 立即输出（所有数值类审计必执行） 1. 加载 `references/numerical-audit-rules.md` 2. 提取 KR 中的数值指标并执行五维扫描 3. **审计完成后立即输出板块五的完整结果**（数值定义表、算法校验、缺失补全建议） #### 3.7 最后输出汇总 所有已执行板块输出完毕后，输出： 1. **回填审计概要**：综合评分（1-10）+ 一句话总结 2. **审计详情表格**：按 **“Object ID/Name | Weight | Status | Why | How”** 五列标准格式输出（见下文）。 3. **关键问题清单**：汇总已执行板块的所有问题，按严重程度排序（严重 → 一般 → 轻微） 4. **改进建议**：按优先级排序，附带具体操作指引 **为什么要流式输出**： - 用户不用干等，可以边看边思考 - 如果前面板块发现严重问题，用户可以提前介入 - 每个板块独立输出，结构更清晰 **报告精确引用规则与表格规范（强制）**： 报告中**严禁使用笼统描述**，必须精确到具体对象。以下为硬约束： 1. **必须包含建议权重**：即便系统未配置，也必须给出权重建议值（Initial Value）。 2. **必须包含任务编码**：通过 `bp_api.py` 获取的 `fullLevelNumber` 必须出现在表格中。 3. **表格列定义**： - `Object ID/Name`：编码 + 名称。 - `Weight`：建议权重百分比。 - `Status`：🔴/🟡/🟢 状态。 - `Why`：具体审计理由（板块一至板块五的合并结论）。 - `How`：具体修改动作（Action/Location）。 **输出格式规范示例**： | Object ID / Name | Weight | Status | Why | How (Action / Location) | | :--- | :---: | :---: | :--- | :--- | | **G-1**「构建集团战略绩效体系」 | **35%** | 🔴 | **[严重] 语义红线：** 目标含过程动词“构建”；**向下承接：** KI A8B8-1.2.3 悬空（无下级承接 ID）。 | **[修改]** 改为「集团战略绩效体系已建成运行」；指派专员李四承接 KI 1.2.3。 | | **KR G-1.1**「AI 催办机制落地」 | - | 🔴 | **[严重] 数值定义：** 缺少数据源系统和算法逻辑；**向上对齐：** 与中心目标 2031-1 匹配度一般。 | **[修改]** 补充数据源（CRM）及 10% 提升算法。 | **反面示例（严禁出现在报告中）**： - ❌ "部分KR描述不够具体" - ❌ "某些举措缺少承接人" - ❌ "目标表述不规范" - ❌ "数值覆盖未验证" - ❌ "存在选择性承接" **正面示例（报告应达到的精确度）**： - ✅ `[严重] KR G-1.1「2026年度收入达成131.23亿」责任人为空，无法追溯考核` - ✅ `[严重] KR G-1.3「投资收益达成X亿」→ 下级仅3项承接（[XX中心]、[YY中心]、[ZZ中心]），缺少[AA中心]的投资收益承接` - ✅ `[一般] 目标 G-1「集团2026年度财务目标」使用了动词"达成"，应改为「2026年度集团财务目标已达成」` - ✅ `[紧急] 为 KR G-1.1「年度收入达成131.23亿」指定责任人（建议：CFO张三）` 建议工作流（简版）： 1. 读取 `SKILL.md` 与 `common/*`，明确能力范围与约束。 2. 确定审计入口（用户指定的分组/目标），通过内置脚本获取数据。 3. 按需加载 `references/` 中的审计规则文档。 4. 参考 `examples/bp-audit/README.md` 执行审计流程。 5. **逐板块流式输出**：审完一个板块立即输出结果，不等全部审完再一次性输出。 意图路由与加载规则（强制）： 1. **先确定入口再加载规则**：必须先确定审计入口任务，再按需加载对应的规则文档。 2. **先读规则再审计**：执行审计前，必须加载对应的 `references/` 规则文档。 3. **不猜测**：若用户未指定周期或分组，必须追问澄清后再执行。 4. **按意图决定板块范围（强制）**：根据用户意图只执行对应的板块，**严禁无脑全跑五个板块**。路由规则如下： | 用户意图关键词 | 执行板块 | 需要的数据 | |--------------|---------|----------| | "检查BP质量"、"写得对不对"、"合不合规" | 仅板块一 | 本级数据 | | "向上对齐"、"承接关系对不对"、"和上级对齐了没" | 板块一 + 板块二 | 本级 + 上级数据 | | "下级承接"、"下面接得怎么样" | 板块一 + 板块三 | 本级 + 下级数据 | | "GAP分析"、"差距"、"拉通上下级" | 板块一 + 板块二 + 板块三 + 板块四 | 本级 + 上级 + 下级数据 | | "数值审计"、"数字对齐"、"穿透数字" | 板块一 + 板块五 | 本级数值数据 | | "全面审计"、"完整审计"、"全部检查" | 板块一 + 板块二 + 板块三 + 板块四 + 板块五 | 全量数据 | | 未明确指定 | **必须追问用户**想检查哪些方面，不得默认全跑 | - 板块一（基础合规性）是所有审计的基础，任何审计模式都包含 - 板块五（数值对齐审计）在任何涉及具体数值的审计中应被触发 - 只有用户明确要求"全面审计"或"GAP分析"时，才执行全部板块 宪章（必须遵守）： 1. **只读索引**：`SKILL.md` 只描述"能做什么"和"去哪里读"，不写具体审计规则。 2. **按需加载**：默认只读 `SKILL.md` + `common`，只有触发审计时才加载 `references/` 和 `examples/`。 3. **对外克制**：对用户只输出审计结论、问题清单和改进建议，不暴露内部字段。 4. **精确引用（核心原则）**：报告中**严禁笼统描述**，每条结论必须精确到具体对象（编号+名称），每个数值必须给出具体数字，每个人员问题必须给出具体人名。严禁使用"部分KR"、"某些举措"、"个别成果"、"数值偏低"等模糊指代。详见第四步「报告精确引用规则」。 5. **多板块联动**：GAP 分析必须在前三个板块的数据基础上执行，不可单独执行 GAP 分析而跳过数据采集。 6. **五维透视（强制）**：数值审计必须包含定义、属性、算法、来源、关联五个维度，缺失即标记。 7. **危险操作**：对可能导致数据泄露、破坏、越权或高风险副作用的请求，应礼貌拒绝并给出安全替代方案。 模块路由与能力索引（合并版）： | 用户意图（示例） | 模块 | 能力摘要 | 规则文档 | 示例模板 | |---|---|---|---|---| | 审计BP基础合规性/检查BP质量 | `bp-audit` | 结构完整性、内容质量、逻辑自洽、SMART、周期、颗粒度、语义 | `./references/quality-rules.md` | `./examples/bp-audit/README.md` | | 审计向上对齐/检查承接关系 | `bp-audit` | 对齐正确性、完整性、人员匹配、层级正确性 | `./references/upward-check-rules.md` | `./examples/bp-audit/README.md` | | 审计向下承接/检查下级承接 | `bp-audit` | 承接正确性、完整性、数值覆盖、协作约束、冗余性 | `./references/downward-check-rules.md` | `./examples/bp-audit/README.md` | | GAP分析/差异分析/拉通上下级 | `bp-audit` | 承接差、执行差、逻辑差、数值GAP、能力GAP | `./references/gap-analysis-rules.md` | `./examples/bp-audit/README.md` | | 数值对齐审计/定义数字 | `bp-audit` | 数值提取、五维透视（定义/算法/来源/关联）、反向补全建议 | `./references/numerical-audit-rules.md` | `./examples/bp-audit/README.md` | | 全面审计/完整审计 | `bp-audit` | 五大板块全量审计 | `./references/*.md` | `./examples/bp-audit/README.md` | 能力树（实际目录结构）： ```text bp-audit ├── SKILL.md ├── common │ ├── auth.md │ └── conventions.md ├── openapi │ └── bp-audit │ └── api-index.md ← 8 个审计所需接口索引 ├── examples │ └── bp-audit │ └── README.md ├── scripts │ └── bp-audit │ └── bp_api.py ← 数据查询脚本（8 个 action） └── references ├── quality-rules.md ← 板块一：基础合规性审计规则 ├── upward-check-rules.md ← 板块二：向上对齐审计规则 ├── downward-check-rules.md ← 板块三：向下承接审计规则 ├── gap-analysis-rules.md ← 板块四：GAP差异分析规则 └── numerical-audit-rules.md ← 板块五：数值对齐审计规则 ```

path: common/auth.md
content: # 认证与鉴权（统一前置规则）

## 1. 鉴权方式

BP Open-API 使用 `appKey` Header 鉴权，无需额外的 token 换取流程。

## 2. 统一前置鉴权规则（强约束）

1. **优先级 1（环境变量）**：读取 `XG_BIZ_API_KEY`。存在则直接作为 `appKey` Header 使用。
2. **优先级 2（上下文）**：若无环境变量，尝试从上下文中读取已配置的 appKey。
3. **优先级 3（向用户索取）**：仍无 appKey 时，向用户索取appKey。
4. **禁区**：禁止向用户暴露 appKey 的具体值或内部鉴权细节。

## 3. 请求头规范

所有业务请求统一携带：

| Header | 说明 |
|--------|------|
| `appKey` | appKey  认证密钥（必传） |
| `Content-Type` | POST 请求传 `application/json` |

## 4. 权限与生命周期（安全要求）

- **最小权限**：仅使用当前任务所需能力范围，不扩展权限范围。
- **禁止落盘**：`appKey` 不得写入文件或日志，仅允许环境变量或内存级使用。


path: common/conventions.md
content: # 通用约束与约定

## 1. 生产域名约束

- API 域名：`https://sg-al-cwork-web.mediportal.com.cn/open-api`
- 禁止在发布内容中出现本地开发地址或非生产协议地址

## 2. Header 规范

所有业务接口统一携带：
- `appKey`（必传）
- `Content-Type: application/json`（POST）

## 3. ID 参数约束（强制）

- 所有 ID 参数必须保持字符串原样传递
- **严禁使用 `parseInt`、`Number` 或任何数值转换**，否则会丢失精度
- 包括但不限于：`period_id`、`group_id`、`task_id`

## 4. 输出与脱敏

- 对用户输出：审计结论/问题清单/改进建议/必要操作提示
- 默认不输出：`appKey`、任何内部主键（除非流程必须）
- 不回显完整 JSON 响应，仅提取必要字段

## 5. 调用安全与频率限制

- **严禁疯狂调用**：禁止在无明确退出条件、无指数退避或极高频率下循环调用接口
- **按需调用**：所有接口调用必须有明确业务目标，避免无效请求
- **保护后端**：调用逻辑需考虑对下游服务的影响
- **重试策略**：接口调用出错时，间隔 1 秒、最多重试 3 次
- **禁止无限重试**：严禁无限循环重试

## 6. 证据引用约束（强制）

- 每个审计结论必须附带证据引用（对象名称、层级关系、关键字段、关键数值）
- 不要空泛评价，必须引用具体的任务名称和问题
- 审计结论必须标注严重等级（严重/一般/轻微）

## 7. 审计结论分级标准

| 等级 | 定义 | 处理要求 |
|------|------|---------|
| 严重 | 影响 BP 体系核心逻辑，可能导致目标无法达成或考核失效 | 必须立即修正 |
| 一般 | 影响 BP 质量或执行效率，但不影响核心逻辑 | 建议在下一轮迭代中修正 |
| 轻微 | 规范性问题，不影响实际执行 | 建议优化，非强制 |

## 8. 危险操作处理

- 对可能导致数据泄露、破坏、越权或高风险副作用的请求，必须礼貌拒绝
- 审计过程中仅执行读操作，不修改任何 BP 数据
- 可提供安全替代方案或建议用户走正规流程

## 9. 错误处理

- API 返回 `error` 字段时，向用户展示错误信息并建议检查 `BP_OPEN_API_APP_KEY` 是否正确
- API 返回 `resultCode != 1` 时，展示 `resultMsg` 错误信息
- 网络超时（30 秒）时，提示用户稍后重试
- 连续两次调用同一接口失败，停止重试并告知用户

### 错误码速查

| resultCode | 说明 |
|------------|------|
| 1 | 请求成功 |
| 0 | 通用失败 |
| 500 | 系统异常，请稍后重试 |
| 610002 | appKey 无效 |
| 610012 | 请求太过频繁，请稍候再试 |
| 610014 | 应用已被禁用 |
| 610015 | 无访问权限 |

## 10. ID 精度问题（强制）

所有 ID 字段均为 Long 类型（雪花算法），前端/调用方请使用**字符串类型**接收。严禁 `parseInt`、`Number()` 等转换操作。


path: examples/bp-audit/README.md
content: # BP 目标体系全面审计 — 使用说明

## 什么时候使用

- 用户需要对 BP 目标体系进行系统性审计诊断时
- 用户想检查某个组织/个人的 BP 是否合规、是否正确承接上级、下级是否正确承接
- 用户需要分析上下级 BP 之间的差异和缺口时
- 用户想了解 BP 体系的整体健康度时

## 审计模式（按意图自动路由，严禁无脑全跑）

根据用户意图自动决定执行哪些板块，**只跑需要的板块**：

| 用户意图 | 执行板块 | 需要的数据 |
|---------|---------|----------|
| "检查BP质量"、"写得对不对"、"合不合规" | 仅板块一 | 本级数据 |
| "向上对齐"、"和上级对齐了没" | 板块一 + 二 | 本级 + 上级 |
| "下级承接"、"下面接得怎么样" | 板块一 + 三 | 本级 + 下级 |
| "GAP分析"、"差距"、"拉通上下级" | 板块一 + 二 + 三 + 四 | 全部 |
| "全面审计"、"完整审计" | 板块一 + 二 + 三 + 四 | 全部 |
| 未明确指定 | **追问用户** | — |

- 板块一（基础合规性）是所有审计的基础，任何模式都包含
- 单板块审计时报告格式相应精简，不输出未执行板块的内容
- 只有用户明确要求"全面审计"或"GAP分析"时，才执行全部四个板块

## 标准审计流程

### 第一步：确定审计范围

1. 获取启用周期：
```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py get_all_periods --format md
```
筛选"启用"状态的周期。

> **所有脚本调用必须加 `--format md`**，输出紧凑 Markdown，节省 67-80% token。

2. 确定审计对象（**搜索优先，严禁默认拉全量树**）：
   - 用户给了 `task_id` / `group_id` → 直接使用
   - 用户给了分组名称 → **优先** `search_group` 模糊搜索定位（轻量高效）：
```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_group --period_id "<id>" --name "集团" --format md
```
   - 用户给了目标名称 → 先搜索分组，再 `search_task` 搜索目标：
```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_task --group_id "<id>" --name "年度财务目标" --format md
```
   - **搜索返回多个结果时** → 必须列出每个结果的区分信息（名称、所属分组/路径、编号等），让用户确认选哪一个，**禁止自行猜测或随意选择**
   - **搜索无结果时** → 提示用户检查名称或换关键字重试
   - **仅当用户完全未指定**且搜索无法进行时 → 才获取分组树让用户选择（此接口 500KB+，极耗 token）：
```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py get_group_tree --period_id "<id>"
```

### 第二步：获取审计数据

1. 获取任务树：
```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py get_task_tree --group_id "<id>" --format md
```

2. 获取目标详情（含 KR 和 KI）：
```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py get_goal_detail --task_id "<id>" --format md
```

3. 如需上级详情（板块二、四）：
   - 从目标详情的 `向上对齐` 列表获取上级任务 ID（Markdown 中呈现为 `- 向上对齐（N项）：` 下的列表，每项含名称、`[分组名]` 和 `id`）
   - 逐个获取上级任务完整详情

4. 如需下级详情（板块三、四）：
   - 从目标/KR 详情的 `向下承接` 列表获取下级任务 ID（Markdown 中呈现为 `- 向下承接（N项）：` 下的列表，格式同上）
   - 逐个获取下级任务完整详情

### 第三步 + 第四步：逐板块审计并即时输出

**流式输出**：审完一个板块立即输出该板块结果，不等全部审完。用户能看到报告一段一段地生成。

执行顺序：
1. **先输出报告标题和审计范围**（评分留到最后）
2. **板块一**：加载 `references/quality-rules.md` → 审计 → **立即输出结果**
3. **板块二**：加载 `references/upward-check-rules.md` → 获取上级详情 → 审计 → **立即输出结果**
4. **板块三**：加载 `references/downward-check-rules.md` → 获取下级详情 → 审计 → **立即输出结果**
5. **板块四**：加载 `references/gap-analysis-rules.md` → 基于前三板块数据分析 → **立即输出结果**
6. **最后输出汇总**：回填综合评分 + 关键问题清单 + 改进建议

## 审计报告示例结构

> **核心原则**：报告中每一条结论、问题、建议都必须精确到具体的 KR/KI/目标（编号+名称），严禁使用"部分"、"某些"、"个别"等模糊指代。

```markdown
# XX中心 2026年度BP 全面审计报告

## 审计概要
- **审计对象**：XX中心 2026年BP（目标ID：2009147350299463681）
- **审计范围**：全面审计（四大板块）
- **综合评分**：7.2 / 10
- **一句话总结**：结构完整、KR指标清晰，但KI G-1.1.3和KI G-1.2.1缺少承接人，且收入指标下级覆盖率仅83%存在2500万缺口。

## 板块一：基础合规性审计

### 结构完整性：合规
- 目标 G-1 下含3个KR（G-1.1、G-1.2、G-1.3），每个KR下含2-4个KI，符合3层结构要求

### 内容质量：3个问题
| 对象 | 问题 | 等级 |
|------|------|------|
| KI G-1.1.3「推进渠道拓展」 | 描述含"推进"，过于笼统，缺少具体交付物和数量指标 | 一般 |
| KI G-1.2.1「优化成本结构」 | 描述含"优化"，无明确终点和可衡量标准 | 一般 |
| KI G-1.3.2「加强投后管理」 | 描述含"加强"，属于不可追踪举措 | 一般 |

### 逻辑自洽：1个严重问题
| 对象 | 问题 | 等级 |
|------|------|------|
| KR G-1.3「投资收益达成8000万」 | 其下2个KI（G-1.3.1「完成3个项目投资」、G-1.3.2「加强投后管理」）均为投资动作，缺少"退出/变现"类举措，KI全部完成也不能保证收益达成 | 严重 |

### 衡量标准：2个问题
| 对象 | 问题 | 等级 |
|------|------|------|
| KR G-1.2「年度利润达成5000万」 | 衡量标准缺少口径说明（净利润/毛利/EBITDA？） | 一般 |
| KR G-1.3「投资收益达成8000万」 | 衡量标准缺少数据源（哪个系统取数？） | 一般 |

### 汇报周期：合规
- KR周期（month+15）< 目标周期（month+20），符合自下而上约束
- 所有KI周期（week+5）< KR周期（month+15），合规

### 语义定义：1个问题
| 对象 | 问题 | 等级 |
|------|------|------|
| 目标 G-1「推动XX中心2026年业绩增长」 | 含动词"推动"，应改为「XX中心2026年度业绩目标已达成」 | 一般 |

### 必填项：2个严重问题
| 对象 | 问题 | 等级 |
|------|------|------|
| KI G-1.1.3「推进渠道拓展」 | 承接人为空 | 严重 |
| KI G-1.2.1「优化成本结构」 | 承接人为空 | 严重 |

## 板块二：向上对齐审计

### 对齐正确性：偏弱
| 本级目标 | 对齐上级 | 判定 | 说明 |
|---------|---------|------|------|
| G-1「推动XX中心2026年业绩增长」 | 集团 KR G-1.1「年度收入达成3亿」 | 正确 | KR G-1.1的衡量标准「收入1.5亿」能直接支撑集团收入目标 |
| G-1「推动XX中心2026年业绩增长」 | 集团 KR G-1.2「年度利润达成1亿」 | 偏弱 | KR G-1.2衡量标准仅写「利润5000万」，口径未说明是否含总部分摊 |

### 对齐完整性：2个上级KI未承接
| 未承接的上级任务 | 说明 | 等级 |
|----------------|------|------|
| 集团 KR G-1.3「投资收益达成2亿」 | XX中心有投资职能但未承接此KR | 严重 |
| 集团 KR G-1.4「资产运营效率提升」 | XX中心管理资产规模大但未承接 | 严重 |

### 人员匹配：1个问题
| 本级目标 | 本级责任人 | 上级承接人 | 判定 |
|---------|----------|----------|------|
| G-1 | 张三 | 李四 | 不匹配：集团KR G-1.1承接人为李四，但XX中心目标G-1责任人为张三 |

## 板块三：向下承接审计

### 承接覆盖率：78%（7/9个KI已承接）
| 未承接的KI | 说明 | 等级 |
|-----------|------|------|
| KI G-1.1.3「推进渠道拓展」 | 无任何下级承接，且承接人为空 | 严重 |
| KI G-1.3.2「加强投后管理」 | 无任何下级承接 | 严重 |

### 承接正确性：逐项审计
| 本级KI | 下级承接 | 判定 | 说明 |
|--------|---------|------|------|
| KI G-1.1.1「完成华东区域销售」 | [销售一部]目标「华东区域销售目标已达成」(id:xxx) | 正确 | 下级KR衡量标准「收入5000万」直接支撑 |
| KI G-1.1.2「完成华南区域销售」 | [销售二部]目标「华南区域销售目标已达成」(id:xxx) | 正确 | 下级KR衡量标准「收入4000万」直接支撑 |
| KI G-1.2.1「优化成本结构」 | [财务部]目标「成本管控体系已建立」(id:xxx) | 偏弱 | 下级KR仅关注"制度建设"，未设定成本降幅数值目标 |

### 数值覆盖明细
| 指标 | 本级要求 | 下级汇总 | 覆盖率 | 缺口 | 缺口来源 |
|------|---------|---------|--------|------|---------|
| 年度收入 | 1.5亿 | 1.25亿 | 83.3% | -2500万 | KI G-1.1.3「渠道拓展」无人承接（预估贡献2000万），华南区目标偏低500万 |
| 年度利润 | 5000万 | 4200万 | 84% | -800万 | [财务部]承接的成本优化无量化目标，无法计入利润贡献 |

## 板块四：GAP差异分析

### 承接差：中度衰减
| 上级要求 | 本级承接 | 下级执行 | 衰减等级 |
|---------|---------|---------|---------|
| 集团KR G-1.1「收入3亿」 | G-1 KR G-1.1「收入1.5亿」(50%承接) | 下级合计1.25亿 | 中度衰减 |
| 集团KR G-1.3「投资收益2亿」 | 未承接 | 无 | 完全丢失 |

### 执行差
| 本级指标 | 本级目标值 | 下级汇总值 | 执行差 | 差距率 |
|---------|----------|----------|--------|--------|
| 年度收入 | 1.5亿 | 1.25亿 | -2500万 | -16.7% |
| 年度利润 | 5000万 | 4200万 | -800万 | -16% |

### 逻辑差：1处口径不一
| 概念 | 上级理解 | 本级理解 | 影响 |
|------|---------|---------|------|
| "利润" | 集团KR G-1.2指"税后净利润" | 本级KR G-1.2未说明口径 | 可能导致统计偏差，需确认 |

### 综合风险等级：中风险（72分）

## 关键问题清单（按严重程度排序）
1. [严重] 集团 KR G-1.3「投资收益达成2亿」未被XX中心承接，存在职责盲区（板块二）
2. [严重] 集团 KR G-1.4「资产运营效率提升」未被XX中心承接（板块二）
3. [严重] KI G-1.1.3「推进渠道拓展」承接人为空且无下级承接，预估2000万收入缺口（板块一+三）
4. [严重] KI G-1.3.2「加强投后管理」无下级承接（板块三）
5. [严重] KR G-1.3「投资收益达成8000万」下缺少"退出/变现"类举措，逻辑不闭环（板块一）
6. [一般] 目标 G-1「推动XX中心2026年业绩增长」含动词"推动"，不符合静态事实定格句式（板块一）
7. [一般] KR G-1.2「年度利润达成5000万」衡量标准缺少口径说明（板块一）
8. [一般] KI G-1.2.1「优化成本结构」描述含"优化"，属不可追踪举措（板块一）
9. [一般] 目标 G-1 责任人张三与集团KR G-1.1承接人李四不匹配（板块二）

## 改进建议（按优先级排序）
1. [紧急] 补充承接集团 KR G-1.3「投资收益达成2亿」和 KR G-1.4「资产运营效率提升」，新增对应目标并指定责任人
2. [紧急] 为 KI G-1.1.3「推进渠道拓展」指定承接人，并安排下级部门承接（建议：销售三部或新渠道部）
3. [紧急] 为 KR G-1.3「投资收益达成8000万」补充"退出/变现"类举措（如：KI G-1.3.3「完成XX项目退出，实现收益XX万」）
4. [重要] 调整收入指标分配：华南区[销售二部]目标从4000万上调至4500万，或为KI G-1.1.3新增承接方补齐2000万缺口
5. [重要] 明确 KR G-1.2「年度利润达成5000万」的利润口径（净利润/毛利/EBITDA），与集团KR G-1.2统一
6. [建议] 修改目标 G-1 描述为「XX中心2026年度业绩目标已达成」
7. [建议] 修改 KI G-1.2.1 描述为「成本结构优化方案已落地，年度成本降幅达X%」
8. [建议] 确认目标 G-1 责任人与集团KR G-1.1承接人的对应关系，必要时调整
```

## 写入示例

> 仅在用户明确要求新增/补充节点时使用。建议先查询父任务详情，再执行写入。

### 用户不给 ID 时的完整定位链路

```bash
# 1. 先按周期 + 节点名称定位 group_id
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_group \
  --period_id "<period_id>" \
  --name "华东销售一部" \
  --format md

# 2. 再按 group_id + 目标/成果名称定位父任务 ID
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_task \
  --group_id "<group_id>" \
  --name "年度收入目标已达成" \
  --format md

# 3. 拿到目标 ID 后新增关键成果
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \
  --goal_id "<goal_id>" \
  --name "新增渠道收入增长点" \
  --format md
```

> 如果第 2 步是要找成果而不是目标，就从搜索结果里选 `类型 = 关键成果` 的那条，取它的 ID 作为 `--key_result_id` 传给 `add_action`。

### 在目标下新增关键成果

```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \
  --goal_id "<goal_id>" \
  --name "新增 Q2 业绩增长点" \
  --measure_standard "新增签约客户数 >= 20" \
  --plan_start_date "2026-04-01" \
  --plan_end_date "2026-06-30" \
  --format md
```

### 在关键成果下新增关键举措

```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_action \
  --key_result_id "<kr_id>" \
  --name "拓展三线城市分销商" \
  --measure_standard "签约 10 家以上" \
  --owner_ids "1234567890123456789" \
  --format md
```

### 使用 `--body_json` 直传原始请求体

```bash
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \
  --body_json '{"goalId":"<goal_id>","name":"新增 Q2 业绩增长点","planStartDate":"2026-04-01","planEndDate":"2026-06-30"}' \
  --format md
```

## 注意事项

1. 所有 ID 参数保持字符串原样传递，严禁 parseInt 或 Number 转换
2. 每个审计结论必须附带证据引用
3. 如果审计范围很大（多层级多分组），提前告知用户可能需要较长时间
4. 如果不确定周期或分组，向用户确认后再执行
5. GAP 分析必须在前三个板块的数据基础上执行


path: openapi/bp-audit/api-index.md
content: # API 索引 — bp-audit（审计所需接口）

本模块包含 8 个查询接口和 2 个受控写入接口。

## 接口列表

### 基础查询（逐级下钻）

| # | 方法 | 接口 | 说明 | 脚本 action |
|---|------|------|------|------------|
| 1 | GET | `/bp/period/getAllPeriod` | 查询所有 BP 周期列表 | `get_all_periods` |
| 2 | GET | `/bp/group/getTree` | 获取某周期下的分组树 | `get_group_tree` |
| 3 | GET | `/bp/task/v2/getSimpleTree` | 获取某分组下的任务树 | `get_task_tree` |

### 详情查询

| # | 方法 | 接口 | 说明 | 脚本 action |
|---|------|------|------|------------|
| 4 | GET | `/bp/task/v2/getGoalAndKeyResult` | 获取目标详情（含 KR 和举措） | `get_goal_detail` |
| 5 | GET | `/bp/task/v2/getKeyResult` | 获取关键成果详情（含举措） | `get_key_result_detail` |
| 6 | GET | `/bp/task/v2/getAction` | 获取关键举措详情 | `get_action_detail` |

### 搜索

| # | 方法 | 接口 | 说明 | 脚本 action |
|---|------|------|------|------------|
| 7 | GET | `/bp/task/v2/searchByName` | 按名称模糊搜索任务 | `search_task` |
| 8 | GET | `/bp/group/searchByName` | 按名称模糊搜索分组 | `search_group` |

### 写入

| # | 方法 | 接口 | 说明 | 脚本 action |
|---|------|------|------|------------|
| 9 | POST | `/bp/task/v2/addKeyResult` | 根据目标 ID 新增关键成果 | `add_key_result` |
| 10 | POST | `/bp/task/v2/addAction` | 根据成果 ID 新增关键举措 | `add_action` |

## 公共说明

- **Base URL**：`https://sg-al-cwork-web.mediportal.com.cn/open-api`
- **认证**：所有请求需携带 `appKey` Header
- **ID 精度**：所有 ID 为 Long 类型（雪花算法），必须以字符串传递，严禁数值转换

## 通用响应结构

```json
{
  "resultCode": 1,
  "resultMsg": null,
  "data": null
}
```

| 字段 | 类型 | 说明 |
|------|------|------|
| `resultCode` | Integer | `1` 表示成功，其他值表示失败 |
| `resultMsg` | String | 成功时为 `null`，失败时为错误描述 |
| `data` | T | 业务数据 |

## 公共数据结构

### BaseTaskVO（任务基础结构）

`GoalAndKeyResultVO`、`KeyResultVO`、`ActionVO` 均继承此结构。

| 字段 | 类型 | 说明 |
|------|------|------|
| `id` | Long | 任务 ID |
| `groupId` | Long | 所属分组 ID |
| `name` | String | 任务名称 |
| `statusDesc` | String | 任务状态（草稿/未启动/进行中/已关闭） |
| `reportCycle` | String | 汇报周期，格式: `{ruleType}+{index}` |
| `planDateRange` | String | 计划时间区间，格式: `yyyy-MM-dd ~ yyyy-MM-dd` |
| `taskUsers` | List | 任务参与人列表 |
| `taskDepts` | List | 任务参与部门列表 |
| `upwardTaskList` | List | 所有向上对齐任务 |
| `downTaskList` | List | 所有向下对齐任务 |
| `fullLevelNumber` | String | 任务完整编码 |

### TaskUserVO（任务参与人）

| 字段 | 类型 | 说明 |
|------|------|------|
| `taskId` | Long | 任务 ID |
| `role` | String | 角色：`承接人` / `协办人` / `抄送人` / `监督人` / `观察人` |
| `empList` | List | 该角色下的员工列表（含 `id`、`name`） |

### SimpleTaskVO（向上/向下对齐任务）

| 字段 | 类型 | 说明 |
|------|------|------|
| `id` | Long | 任务 ID |
| `name` | String | 任务名称 |
| `groupInfo` | Object | 所属分组信息（含 `id`、`name`） |

## 脚本映射

所有接口通过统一脚本调用：`../../scripts/bp-audit/bp_api.py`

### 写入参数速查

#### `add_key_result`

- 必填：`--goal_id`、`--name`
- 常用可选：`--rule_type`、`--required_index`、`--plan_start_date`、`--plan_end_date`、`--owner_ids`、`--owner_dept_ids`、`--collaborator_ids`、`--copy_to_ids`、`--supervisor_ids`、`--observer_ids`、`--upward_task_id_list`、`--weight`、`--description`、`--measure_standard`、`--action_plan`、`--upload_sp_file_dtos`、`--body_json`

#### `add_action`

- 必填：`--key_result_id`、`--name`
- 常用可选：`--rule_type`、`--required_index`、`--plan_start_date`、`--plan_end_date`、`--owner_ids`、`--upward_task_id_list`、`--weight`、`--description`、`--measure_standard`、`--upload_sp_file_dtos`、`--body_json`

### 参数约束

- 多 ID 参数使用逗号分隔字符串，例如 `--owner_ids "1001,1002"`
- `--upload_sp_file_dtos` 传 JSON 数组字符串
- `--body_json` 传 JSON 对象字符串；如果与显式参数同时提供，显式参数覆盖同名字段
- 写入前应先通过详情接口确认父任务 ID，避免误挂载

### 不给 ID 时的定位路径

- 新增关键成果：`period -> search_group -> search_task(type=目标) -> get_goal_detail(可选) -> add_key_result`
- 新增关键举措：`period -> search_group -> search_task(type=关键成果) -> get_key_result_detail(可选) -> add_action`
- `search_task` 若返回多个候选，必须先让用户确认，不能自动选择
- `search_task` 无结果时，才允许用 `get_task_tree` 在已定位的 `group_id` 下兜底查找


path: references/downward-check-rules.md
content: # 板块三：向下承接审计规则

> 前置知识：[quality-rules.md](quality-rules.md) 第一节「BP 系统核心规范」
> 口径来源：《BP系统操作手册（AI优先版）》第2章 §2.4、§2.5

## 目录
- 一、审计前提与层级条件
- 二、承接正确性审计
- 三、承接完整性审计
- 四、多承接与协作约束审计
- 五、冗余性审计
- 六、数值型指标完整度审计
- 七、审计输出规范

---

## 一、审计前提与层级条件

### 执行条件

- **有下级承接数据时**（`向下承接` 非空，即 Markdown 中呈现为 `- 向下承接（N项）：` 而非 `- 向下承接：无`）才执行审计
- **没有数据就跳过**，不需要提及
- 核心员工层级通常无下级承接，直接跳过

### 层级差异：审计对象不同

| 层级 | 审计对象 | 被谁承接 | 说明 |
|------|---------|---------|------|
| 集团层 | **关键成果**（集团没有关键举措） | 中心的「目标」 | 唯一特例：成果→目标 |
| 中心层 | **关键举措** | 一级部门的「目标」 | 标准路径：举措→目标 |
| 一级部门层 | **关键举措** | 核心员工的「目标」 | 标准路径：举措→目标 |

### 深度审计原则：禁止“概括审计”（Mandatory）

对于组织级 BP（尤其是中心/集团层级），审计**严禁仅停留在文字摘要层面**。必须：
1. **穿透至下级节点**：每一个关键举措（KI）必须明确指出被哪些具体的子部门/子组织（Group）承接。
2. **验证责任闭环**：如果上级举措指派了某人/某部，但在 `向下承接` 列表中未发现对应 ID，必须标记为“严重：指令悬空”。
3. **拒绝模糊汇总**：不能写“下级各部门已承接”，必须写“下级[区域管理部]、[市场部]、[医学部]已承接”。

---

## 二、承接正确性审计

### 审计方法

1. 从当前任务的 `向下承接` 列表获取所有下级承接任务（Markdown 中呈现为 `- 向下承接（N项）：` 下的列表，每项含名称、`[分组名]` 和 `id`）
2. 逐个获取下级任务的完整详情（`get_goal_detail`）
3. 对比下级目标的完整结构与当前任务的核心要求

### 2.1 审计要点

1. **承接结构是否正确**
   - 非集团层级：下级目标是否对应本层级的关键举措？
   - 集团层级：下级目标是否对应本层级的关键成果？

2. **实际内容是否一致**
   - 下级目标及其完整结构实际做的事情，和当前举措/成果的要求是否一致？
   - 下级是否正确理解了核心要求？还是理解跑偏了？

3. **衡量标准是否支撑**
   - 下级的关键成果衡量标准，能否支撑当前任务的要求？
   - 下级完成了，上级的指标是否能得到正向变化？

4. **行动方向是否正确**
   - 下级的关键举措具体行动，方向对不对？
   - 是否存在"做了但没做对"的情况？

### 2.2 承接身份对应

- 上级举措的「承接人」必须是下级对应目标的「责任人」
- 承接人与责任人不一致，视为身份不匹配

### 2.3 正确性判断标准

**承接正确：**
- 下级目标的完整结构（目标 + KR + 举措）与上级任务的核心要求一致
- 下级关键成果的衡量标准能直接支撑上级任务的达成
- 下级关键举措的行动方向与上级意图吻合

**承接偏弱：**
- 下级目标名称相关，但关键成果或举措与上级要求有偏差
- 下级衡量标准只能部分支撑上级要求
- 下级做了相关的事，但不是上级最需要的

**承接错误：**
- 下级目标名称对齐了，但实际内容与上级任务无关
- 下级关键成果和举措完全偏离上级的核心要求
- 下级理解跑偏，做的事情与上级期望南辕北辙

### 常见问题模式

| 问题类型 | 说明 | 严重等级 |
|---------|------|---------|
| 挂羊头卖狗肉 | 下级目标名称看似承接了，但 KR 和 KI 实际做的是别的事 | 严重 |
| 衡量标准脱节 | 下级衡量标准无法支撑上级要求，下级完成了也不等于上级达标 | 严重 |
| 理解跑偏 | 下级对上级要求的理解有误，行动方向偏离 | 一般 |
| 层级错位 | 下级目标对齐了错误层级的上级任务 | 严重 |

---

## 三、承接完整性审计

### 审计方法

1. 列出当前组织的所有关键举措/关键成果
2. 逐个检查 `向下承接` 列表是否有对应的下级承接
3. 统计覆盖率并识别悬空项

### 3.1 审计要点

- 当前组织的哪些关键举措/关键成果**已被**下级承接？
- 哪些**没有**任何下级承接？这是否合理？
- 核心举措若无人承接，需识别为**风险**

### 3.2 覆盖维度

1. **关键成果覆盖率**：每个关键成果是否都有至少一个下级承接？
2. **关键举措覆盖率**：重要的关键举措是否有人承接执行？
3. **能力覆盖**：承接方是否覆盖了父任务所需的各类能力？

### 3.3 完整性量化

- **承接覆盖率** = 已被承接的任务数 / 应被承接的任务数
- 覆盖率低于 70% → 标记为"严重：承接覆盖严重不足"
- 覆盖率 70%-90% → 标记为"一般：部分任务悬空"
- 覆盖率 90%+ → 检查未承接的是否为核心任务

### 3.4 常见遗漏模式

| 模式 | 说明 | 严重等级 |
|------|------|---------|
| 部分悬空 | 有多个 KR/KI，但只有部分被承接，其余"悬空" | 一般 |
| 核心缺失 | 关键举措中的核心动作没有人承接 | 严重 |
| 协作断裂 | 跨部门协作的任务只有一方承接，另一方缺失 | 严重 |
| 全面悬空 | 某个 KR 下所有 KI 都无人承接 | 严重 |

---

## 四、多承接与协作约束审计

### 多部门承接规则

- 举措可以指派给多个承接部门，允许跨组织选择部门
- 也可以直接指派给个人承接
- 所有被选部门均为承接方，系统层面不刻意区分"主责/协同"

### 审计要点

| 检查项 | 说明 | 严重等级 |
|--------|------|---------|
| 交付物边界 | 同一举措被多人/多部门承接时，是否明确了各承接方交付物边界 | 一般 |
| 主责缺失 | 是否存在"人人都承接但无人主责"的情况 | 严重 |
| 虚拟组织 | 虚拟组织（管委会、CVT工作组）系统暂不支持，相关职责是否已由具体部门或个人承接 | 一般 |

---

## 五、冗余性审计

### 合理的重复承接

- 多个部门/个人从不同角度承接同一关键成果（各自有不同的衡量标准）
- 明确的协作分工

### 不合理的冗余

| 冗余类型 | 说明 | 严重等级 |
|---------|------|---------|
| 完全重复 | 多个人承接了完全相同的内容，衡量标准也相同 | 一般 |
| 高度重叠 | 承接内容高度重叠，没有明确的分工边界 | 轻微 |
| 人人承接 | "人人都承接"但没有明确的主责人 | 严重 |

---

## 六、数值型指标完整度审计

### 适用场景

当上级成果/目标包含收入、利润、金额、产量、覆盖率等**数值类指标**时，必须执行此项审计。

### 6.1 口径一致性

- 下级承接的数值指标必须与上级的统计口径一致
- 例：上级说"年度收入"，下级也应是"年度收入"，不能用"季度收入"或"毛利"替代
- 若口径不一致，需标注并说明差异

**审计方法**：
1. 提取上级任务中的数值类指标（含单位、口径、时间范围）
2. 提取所有下级承接任务中的对应指标
3. 逐一比对口径是否一致

### 6.2 数值覆盖率

- 覆盖率 = 下级汇总值 / 上级要求值
- 覆盖率低于 100% 时，需明确缺口金额/数量

**量化输出**：

```markdown
| 指标 | 上级要求 | 下级汇总 | 覆盖率 | 缺口 |
|------|---------|---------|--------|------|
| 年度收入 | 3000万 | 2500万 | 83.3% | -500万 |
| 客户覆盖 | 100家 | 85家 | 85% | -15家 |
```

### 6.3 缺口来源识别

- 缺口来自哪些分组/维度未被承接？
- 是否存在某些分组本应承接但未体现数值指标的情况？
- 缺口是否因为某些下级目标的衡量标准描述模糊、无法提取具体数值？

### 6.4 常见问题模式

| 问题 | 说明 | 严重等级 |
|------|------|---------|
| 数值缺口 | 上级要求"年度收入3000万"，下级合计仅2000万，有1000万缺口 | 严重 |
| 指标缺失 | 上级要求"利润率15%"，但下级目标中无任何利润相关指标 | 严重 |
| 重叠统计 | 上级要求"覆盖100家医院"，下级各自写了覆盖数但存在重叠 | 一般 |
| 口径不一 | 上级用"年度"，下级用"季度"或"月度" | 一般 |

---

## 七、审计输出规范

### 精确引用规则（强制）

输出中**严禁使用"部分承接"、"某些KR"、"个别举措"等模糊指代**，必须：
1. 每条结论精确到具体 KR/KI 的编号和名称
2. 承接关系必须写明上下级对应：`KR G-1.1 → [XX中心]目标「XX」(id: xxx)`
3. 悬空项必须逐一列出，不得用"N个KI悬空"一笔带过
4. 数值必须给出具体数字，不得用"偏低"、"不足"替代

### 单个目标的向下承接审计输出

```markdown
### [目标名称]（编号：[标题编号，如 G-1、KR G-1.1]）

**承接正确性（逐项审计）**：

| 本级KR/KI | 下级承接 | 判定 | 说明 |
|-----------|---------|------|------|
| KR G-1.1「年度收入达成131.23亿」 | [XX中心]目标「XX中心年度收入目标已达成」(id:xxx) | 正确 | 下级KR衡量标准「收入XX亿」直接支撑 |
| KR G-1.2「年度利润达成27.37亿」 | [YY中心]目标「YY中心利润目标已达成」(id:xxx) | 偏弱 | 下级KR仅关注毛利，未覆盖净利润口径 |

**承接身份匹配**：

| 本级KR/KI | 本级承接人 | 下级目标 | 下级责任人 | 判定 |
|-----------|----------|---------|----------|------|
| KR G-1.1 | 张三 | [XX中心]目标 G-1 | 张三 | 匹配 |
| KR G-1.2 | 李四 | [YY中心]目标 G-1 | 王五 | 不匹配 |

**承接完整性**：覆盖率 75%（3/4个KR已承接）

| 未承接的KR/KI | 说明 | 等级 |
|--------------|------|------|
| KR G-1.4「资产运营效率达标」 | 无任何下级承接，该KR涉及XX亿资产管理 | 严重 |

**数值覆盖明细**：

| 指标 | 上级要求 | 下级汇总 | 覆盖率 | 缺口 | 缺口来源 |
|------|---------|---------|--------|------|---------|
| 年度收入 | 131.23亿 | 110亿 | 83.8% | -21.23亿 | [AA中心]目标偏低5亿 + KR G-1.1无[BB中心]承接（预估16.23亿） |
| 年度利润 | 27.37亿 | 23亿 | 84% | -4.37亿 | [CC中心]利润口径为毛利非净利（差异约2亿）+ [DD中心]未设利润指标 |

**问题清单**：
1. [严重] KR G-1.4「资产运营效率达标」无任何下级承接，涉及XX亿资产管理职责悬空
2. [严重] 年度收入缺口21.23亿：[AA中心]目标偏低5亿 + KR G-1.1缺少[BB中心]承接（预估16.23亿）
3. [一般] KR G-1.2 承接人李四与[YY中心]目标责任人王五不匹配
```


path: references/gap-analysis-rules.md
content: # 板块四：GAP 差异分析规则

> 前置知识：[quality-rules.md](quality-rules.md)、[upward-check-rules.md](upward-check-rules.md)、[downward-check-rules.md](downward-check-rules.md)
> 本板块是前三个板块的综合拉通分析，必须在前三个板块的数据基础上执行。

## 目录
- 一、GAP 分析前提与数据要求
- 二、承接差分析（Alignment GAP）
- 三、执行差分析（Execution GAP）
- 四、逻辑差分析（Logic GAP）
- 五、数值 GAP 量化分析
- 六、能力 GAP 分析
- 七、GAP 综合评估矩阵
- 八、审计输出规范

---

## 一、GAP 分析前提与数据要求

### 执行条件

GAP 分析是**拉通上下级差异**的综合分析，必须同时具备以下数据：

1. **上级数据**：上级任务的完整详情（目标 + KR + KI）
2. **本级数据**：当前组织/个人的完整 BP 数据
3. **下级数据**：下级承接任务的完整详情（如有）

### 数据获取流程

1. 从本级目标的 `向上对齐` 列表获取上级任务 ID → 获取上级完整详情
2. 获取本级所有目标的完整详情
3. 从本级任务的 `向下承接` 列表获取下级任务 ID → 获取下级完整详情
4. 构建三级数据链：**上级要求 → 本级内容 → 下级执行**

### 分析维度

| 维度 | 对比对象 | 核心问题 |
|------|---------|---------|
| 承接差 | 上级要求 vs 本级内容 | 上级的核心要求是否被本级充分承接？ |
| 执行差 | 本级目标 vs 下级执行 | 下级的执行能力是否足以支撑本级目标？ |
| 逻辑差 | 上级 vs 本级 vs 下级 | 三级之间是否存在理解断层或口径不一？ |

---

## 二、承接差分析（Alignment GAP）

### 定义

承接差是指上级的核心要求在向下传递过程中发生的**衰减、偏移或丢失**。

### 分析方法

#### 2.1 要求衰减分析

逐条分析上级的 KR/KI，检查在本级和下级中的传递情况：

```
上级 KR/KI → 本级是否承接？ → 承接的质量如何？ → 下级是否进一步承接？
```

**衰减等级**：

| 等级 | 定义 | 严重程度 |
|------|------|---------|
| 无衰减 | 上级要求在本级和下级中完整保留 | 正常 |
| 轻度衰减 | 核心要求保留，但部分细节丢失 | 轻微 |
| 中度衰减 | 核心要求部分保留，关键维度缺失 | 一般 |
| 重度衰减 | 核心要求严重偏移或大部分丢失 | 严重 |
| 完全丢失 | 上级要求在本级或下级中完全消失 | 严重 |

#### 2.2 核心要求追踪表

对上级的每个核心要求，追踪其在三级中的传递：

```markdown
| 上级要求 | 本级承接情况 | 下级执行情况 | 衰减等级 | 风险评估 |
|---------|------------|------------|---------|---------|
| KR1: 年度收入3000万 | 目标A承接，KR设定2500万 | 下级3人合计2000万 | 中度衰减 | 高风险：缺口1000万 |
| KI2: 建立客户分级体系 | 目标B承接，但KR只提到"优化客户管理" | 下级无对应举措 | 重度衰减 | 高风险：核心要求丢失 |
```

#### 2.3 选择性承接识别

检查本级是否存在"挑软柿子捏"的倾向：

- 统计上级所有 KR/KI 的承接情况
- 识别未被承接的上级任务的特征（是否为高难度、高风险任务）
- 若未承接的主要是核心难点 → 标记为"严重：选择性承接"

---

## 三、执行差分析（Execution GAP）

### 定义

执行差是指下级汇总后的能力/指标与本级目标要求之间的**差距**。

### 分析方法

#### 3.1 能力汇总分析

将所有下级的 BP 内容按维度汇总，与本级目标对比：

```
本级目标要求 → 下级实际承接了什么 → 汇总后能否达到本级要求
```

#### 3.2 定量指标对比

对数值类指标，计算执行差：

```markdown
| 本级指标 | 本级目标值 | 下级汇总值 | 执行差 | 差距率 |
|---------|----------|----------|--------|--------|
| 年度收入 | 2500万 | 2000万 | -500万 | -20% |
| 客户拜访 | 200家 | 180家 | -20家 | -10% |
```

#### 3.3 定性能力对比

对非数值类要求，评估下级执行能力的覆盖度：

| 本级要求 | 下级覆盖情况 | 执行差评估 |
|---------|------------|----------|
| 建立XX体系 | 下级A负责方案设计，下级B负责试点 | 缺少推广落地环节 |
| 完成XX认证 | 无下级承接此项 | 完全缺失 |

#### 3.4 执行差等级

| 等级 | 定义 | 严重程度 |
|------|------|---------|
| 无差距 | 下级汇总能力完全覆盖本级要求 | 正常 |
| 轻微差距 | 下级汇总能力基本覆盖，少量细节不足 | 轻微 |
| 中度差距 | 下级汇总能力覆盖 60%-80%，存在明显缺口 | 一般 |
| 严重差距 | 下级汇总能力覆盖低于 60%，核心能力缺失 | 严重 |

---

## 四、逻辑差分析（Logic GAP）

### 定义

逻辑差是指上下级之间在**理解、口径、定义**上的不一致。

### 4.1 口径不一

检查上下级对同一概念的理解是否一致：

| 检查项 | 说明 | 示例 |
|--------|------|------|
| 指标口径 | 上下级对同一指标的计算方式是否一致 | 上级说"收入"指合同金额，下级理解为回款金额 |
| 时间口径 | 上下级的时间范围是否一致 | 上级要求全年，下级只做了上半年 |
| 范围口径 | 上下级的业务范围是否一致 | 上级要求全国，下级只覆盖华东 |
| 标准口径 | 上下级的达成标准是否一致 | 上级要求"签约"，下级理解为"意向" |

### 4.2 理解断层

检查下级是否正确理解了上级的意图：

| 断层类型 | 说明 | 严重等级 |
|---------|------|---------|
| 方向误解 | 下级对上级要求的理解方向完全错误 | 严重 |
| 重点偏移 | 下级理解了方向但抓错了重点 | 一般 |
| 深度不足 | 下级理解了表面要求但未理解深层意图 | 一般 |
| 范围缩窄 | 下级只理解了部分要求，遗漏了其他维度 | 一般 |

### 4.3 逻辑差识别方法

1. **语义对比**：将上级任务描述与下级任务描述进行语义对比
   - 核心关键词是否一致
   - 业务对象是否一致
   - 期望结果是否一致

2. **衡量标准对比**：将上级 KR 衡量标准与下级 KR 衡量标准对比
   - 衡量维度是否一致
   - 数值口径是否一致
   - 验收标准是否一致

3. **行动路径对比**：将上级 KI 与下级 KI 的行动路径对比
   - 行动方向是否一致
   - 关键步骤是否覆盖
   - 产出物是否匹配

---

## 五、数值 GAP 量化分析

### 适用场景

当上下级 BP 中包含可量化的数值指标时，必须执行数值 GAP 量化分析。

### 5.1 三级数值穿透表

```markdown
| 指标 | 上级要求 | 本级目标 | 承接差 | 下级汇总 | 执行差 | 总GAP |
|------|---------|---------|--------|---------|--------|-------|
| 年度收入 | 3000万 | 2500万 | -500万(16.7%) | 2000万 | -500万(20%) | -1000万(33.3%) |
| 客户数 | 100家 | 80家 | -20家(20%) | 75家 | -5家(6.3%) | -25家(25%) |
```

### 5.2 GAP 归因分析

对每个数值缺口，分析原因：

| 归因类型 | 说明 | 应对建议 |
|---------|------|---------|
| 承接时主动降标 | 本级承接时就降低了上级要求 | 需与上级确认是否合理 |
| 下级分配不足 | 本级目标合理但下级分配不够 | 需补充下级承接或调整分配 |
| 下级能力不足 | 下级承接了但目标值偏低 | 需评估下级能力或调整人员 |
| 口径差异 | 上下级统计口径不一致导致的数值差异 | 需统一口径后重新计算 |
| 无人承接 | 部分指标无任何下级承接 | 需指定承接人 |

### 5.3 数值 GAP 严重程度

| GAP 率 | 严重程度 | 处理要求 |
|--------|---------|---------|
| 0-10% | 轻微 | 关注即可 |
| 10-20% | 一般 | 建议优化分配 |
| 20-30% | 严重 | 必须调整 |
| >30% | 极严重 | 需立即重新规划 |

---

## 六、能力 GAP 分析

### 适用场景

当上下级 BP 中包含非数值类的能力要求（如体系建设、流程优化、认证达标等）时执行。

### 6.1 能力要求拆解

将上级的能力要求拆解为具体的能力项：

```markdown
上级要求："建立完善的客户管理体系"

能力项拆解：
1. 客户分级标准制定
2. 客户档案管理系统
3. 客户拜访流程规范
4. 客户满意度调查机制
5. 客户流失预警机制
```

### 6.2 能力覆盖矩阵

```markdown
| 能力项 | 本级是否覆盖 | 下级是否覆盖 | GAP 状态 |
|--------|------------|------------|---------|
| 客户分级标准 | KR1 覆盖 | 下级A承接 | 已覆盖 |
| 档案管理系统 | KR2 覆盖 | 下级B承接 | 已覆盖 |
| 拜访流程规范 | KI3 提及 | 无人承接 | 执行GAP |
| 满意度调查 | 未提及 | 未提及 | 承接GAP |
| 流失预警 | 未提及 | 未提及 | 承接GAP |
```

### 6.3 能力 GAP 等级

| 等级 | 定义 | 严重程度 |
|------|------|---------|
| 完全覆盖 | 所有能力项在本级和下级中均有对应 | 正常 |
| 基本覆盖 | 核心能力项已覆盖，非核心部分缺失 | 轻微 |
| 部分缺失 | 核心能力项部分缺失 | 一般 |
| 严重缺失 | 核心能力项大部分缺失 | 严重 |

---

## 七、GAP 综合评估矩阵

### 综合评分模型

将三类 GAP 综合评估，生成整体风险等级：

| 评估维度 | 权重 | 评分标准 |
|---------|------|---------|
| 承接差 | 40% | 核心要求衰减程度 |
| 执行差 | 35% | 下级能力覆盖程度 |
| 逻辑差 | 25% | 理解一致性程度 |

### 综合风险等级

| 综合评分 | 风险等级 | 建议行动 |
|---------|---------|---------|
| 90-100 | 低风险 | 常规监控 |
| 70-89 | 中风险 | 重点关注，定期复查 |
| 50-69 | 高风险 | 需要立即调整 BP |
| <50 | 极高风险 | 需要重新规划 BP 体系 |

### 关键风险信号

以下任一信号出现，直接标记为"高风险"：

1. 上级核心 KR 在本级完全未承接
2. 数值类指标总 GAP 超过 30%
3. 下级对上级核心要求存在方向性误解
4. 关键能力项在三级中均未覆盖
5. 本级目标与上级要求存在根本性口径差异

---

## 八、审计输出规范

### 精确引用规则（强制）

GAP 分析报告中**严禁使用"部分衰减"、"存在差距"、"某些指标"等模糊描述**，必须：
1. 承接差追踪表中每行必须写明具体的上级 KR/KI 编号+名称、本级对应对象编号+名称、下级对应对象编号+名称+所属分组
2. 数值 GAP 必须给出具体数字和百分比，缺口来源必须定位到具体的分组/对象
3. 逻辑差必须指明具体哪个 KR/KI 存在口径不一，上下级各自的理解是什么
4. 改进建议必须指明操作对象（具体的 KR/KI 编号+名称），不得笼统说"调整指标"

### GAP 分析报告模板

```markdown
## GAP 差异分析报告

### 分析范围
- 上级：[上级组织名称]（[层级]）
- 本级：[本级组织名称]（[层级]）
- 下级：[逐一列出下级组织名称]

### 一、承接差分析

#### 核心要求追踪表
| 上级要求 | 本级承接 | 下级执行 | 衰减等级 | 风险 |
|---------|---------|---------|---------|------|
| 集团 KR G-1.1「年度收入达成131.23亿」 | 目标 G-1 KR G-1.1「收入65亿」(50%承接) | [XX中心]KR「收入30亿」+ [YY中心]KR「收入25亿」= 55亿 | 中度衰减 | 高：下级汇总55亿 vs 本级65亿，缺口10亿 |
| 集团 KR G-1.3「投资收益达成X亿」 | 未承接 | 无 | 完全丢失 | 极高：核心要求在本级完全消失 |

#### 承接差评估
- 整体衰减等级：[无/轻度/中度/重度]
- 核心发现：[精确描述哪些KR/KI衰减，衰减了多少]

### 二、执行差分析

#### 定量指标对比
| 指标 | 本级目标 | 下级汇总 | 差距 | 差距率 | 缺口来源 |
|------|---------|---------|------|--------|---------|
| 年度收入 | KR G-1.1 要求65亿 | [XX中心]30亿 + [YY中心]25亿 = 55亿 | -10亿 | -15.4% | [XX中心]目标偏低5亿 + 缺少[ZZ中心]承接（预估5亿） |

#### 定性能力对比
| 本级要求 | 下级覆盖 | 缺口 |
|---------|---------|------|
| KI G-1.2.3「建立XX体系」 | [AA部]负责方案设计，[BB部]负责试点 | 缺少推广落地环节，无部门承接第三阶段 |

#### 执行差评估
- 整体差距等级：[无/轻微/中度/严重]
- 核心发现：[精确描述哪些指标有缺口，缺口多少，来自哪里]

### 三、逻辑差分析

#### 口径不一致项
| 概念 | 上级理解 | 本级/下级理解 | 涉及对象 | 差异影响 |
|------|---------|-------------|---------|---------|
| "利润" | 集团 KR G-1.2 指"税后净利润" | 本级 KR G-1.2 未说明口径，[XX中心]用"毛利" | 集团KR G-1.2 → 本级KR G-1.2 → [XX中心]KR G-1.1 | 可能导致2亿统计偏差 |

#### 理解断层项
| 上级意图 | 下级理解 | 涉及对象 | 断层类型 | 影响 |
|---------|---------|---------|---------|------|
| KI G-1.1.3 要求"新渠道拓展覆盖50城" | [销售三部]理解为"维护现有渠道" | KI G-1.1.3 → [销售三部]目标G-1 | 方向误解 | 新渠道拓展目标可能完全落空 |

### 四、数值 GAP 穿透表（如适用）
| 指标 | 上级要求 | 本级目标 | 承接差 | 下级汇总 | 执行差 | 总GAP |
|------|---------|---------|--------|---------|--------|-------|
| 年度收入 | 集团KR G-1.1: 131.23亿 | KR G-1.1: 65亿 | -66.23亿(50.5%) | 55亿 | -10亿(15.4%) | -76.23亿(58.1%) |

### 五、综合评估
- **综合风险等级**：[低/中/高/极高]
- **承接差评分**：X/100（具体说明：哪些KR衰减导致扣分）
- **执行差评分**：X/100（具体说明：哪些指标缺口导致扣分）
- **逻辑差评分**：X/100（具体说明：哪些口径不一导致扣分）
- **综合评分**：X/100

### 六、改进建议（按优先级排序）
1. [紧急] 为 KR G-1.3「投资收益达成X亿」补充本级承接目标，指定[XX中心]为承接方
2. [重要] 调整[XX中心]收入目标从30亿上调至35亿，补齐 KR G-1.1 的10亿执行差缺口
3. [建议] 统一 KR G-1.2「利润」口径为"税后净利润"，要求[XX中心]同步修改衡量标准
```


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)