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.md2向上对齐审计我和上级的承接：对齐正确性、对齐完整性、人员匹配references/upward-check-rules.md3向下承接审计下级跟我的承接：承接正确性、完整性、数值覆盖、协作约束references/downward-check-rules.md4GAP 差异分析拉通上下级差异：承接差、执行差、逻辑差references/gap-analysis-rules.md5数值对齐审计从“提数字”到“定义数字”：数值定义、属性、算法、关联场景references/numerical-audit-rules.md

板块一：基础合规性审计（BP 本身信息）#

检查点说明严重等级结构完整性必须包含 G-R-A 三层结构，层级深度符合组织要求严重内容质量描述是否具体、可衡量、有明确行动指向一般逻辑自洽KI 是否能推导出 KR 的达成，KR 是否能验证 Goal 的完成严重衡量标准 SMARTKR 衡量标准是否满足 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其他字段见下方写入说明

数据层级#

text

周期 (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 先输出报告标题和审计范围

拿到审计数据后， 立即先输出 报告标题和审计对象信息（审计范围要体现实际执行的板块）：

text

# 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 / NameWeightStatusWhyHow (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.mdGAP分析/差异分析/拉通上下级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       ← 板块五：数值对齐审计规则