bp-audit
# 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 ← 板块五：数值对齐审计规则
```
标签
skill
ai
