# BP月报Skill业务说明 ## 1. 这个 skill 是做什么的 这个 skill 用来基于 BP 系统中的真实业务数据，生成结构固定、证据可追溯的月报或季报初稿。 它不是一个“写作润色工具”，也不是“拿模板一次性生成整篇报告”的大 prompt。 它的核心价值是把月报编写拆成可控的几个步骤，让输出更稳定、更可复核。 ## 2. 这个 skill 解决什么问题 在真实业务里，月报编写通常有这几个痛点： - 模板章节很多，容易一上来就写乱 - 同一个节点下有目标、成果、举措、汇报，信息来源分散 - 一次性让 AI 写全文，结果不稳定，每次说法都不一样 - AI 容易把“做了什么动作”误写成“已经达成结果” - 关联汇报很多，但不同作者、不同类型的汇报权重并不一样 这个 skill 的作用，就是把这些问题固化成一套统一流程： - 先确认周期、节点、月份 - 再读取 BP 目标、关键成果、衡量标准、关键举措 - 再拉取关联汇报并做证据分层 - 先生成中间层，再生成最终报告 但这个 skill 不应该只做“一次性自动生成”。 在真实使用里，它还必须支持“先生成第一版，再和用户逐段修订”。 所以现在业务上应把它理解成两个连续阶段： - `系统自动起草阶段` - `用户交互修订阶段` 进一步说，每个月至少应形成两份正式报告产物： - `AI基准草稿报告` - `用户复盘版报告` 二者关系是： - `AI基准草稿报告`：AI 基于 BP、汇报和模板生成的基准版本 - `用户复盘版报告`：用户基于基准稿补充、修正、解释后的正式复盘版本 ## 3. 这个 skill 依赖什么业务对象 这个 skill 围绕 BP 系统里的 4 类核心对象工作： ### 3.1 目标 `目标` 表示最终要达到的状态。 月报里，目标主要用来定义“这一条线到底在做什么”。 ### 3.2 关键成果 `关键成果` 是判断目标有没有达成的核心依据。 月报里的结果判断，优先依据关键成果。 ### 3.3 衡量标准 `衡量标准` 用来说明关键成果怎样算完成、怎样算偏离。 所以这个 skill 在写报告时，不是看“举措做了多少”，而是看“成果离衡量标准还有多远”。 ### 3.4 关键举措 `关键举措` 是为了实现成果而采取的动作路径。 它不是最终评价主轴，但它是非常重要的证据抓手，因为大量汇报会挂在举措上。 一句话概括： - `判断主轴`：目标 -> 关键成果 -> 衡量标准 - `证据抓手`：目标汇报 + 成果汇报 + 举措汇报 ## 4. 这个 skill 的最小输入是什么 最小输入只有 3 个： - `BP周期` 或 `periodId` - `节点名称`、`groupId` 或 `BP组织节点ID` - `月报月份` 例如： ```yaml bp_period: 2026年度计划BP node_name: 陈舒婷 report_month: 2026-03 ``` 或者： ```yaml bp_period: 2026年度计划BP node_id: 2029384010718834690 report_month: 2026-03 ``` 如果模板和填报规范已经固定，就不需要每次再重复提供。 当前阶段先聚焦“AI基准草稿报告”的稳定生成。 所以执行口径优先收敛成直接取数输入，而不是先做复杂交互。 推荐的执行输入协议是： ```yaml period_id: 1994002024299085826 groupId: 2029384010718834690 report_month: 2026-03 ``` 如果没有 `period_id` 或 `groupId`，再退回用 `BP周期 + 节点名称` 解析。 ## 5. 这个 skill 怎么判断证据优先级 不是所有关联汇报都同权。 这个 skill 采用下面的证据优先级： 1. 当前节点责任人或承接人本人写的手动汇报 2. 当前节点责任人或承接人本人写的回溯性汇报 3. 他人写的、但关联到同一事项的手动汇报 4. AI 汇报 这意味着： - 本人主证据最重要 - 他人汇报只能作为辅证 - AI 汇报只能做辅助摘要，不能单独作为强结论依据 ## 6. 这个 skill 怎么做月份归集 这个 skill 的月份归集规则现在定死为： - 只取 `汇报日期` - 按 `汇报月份` 进行取数 也就是说： - 默认不按 `关联时间` 归集 - 默认不依赖大模型去猜正文里提到的是哪一个月份 原因是： - `关联时间` 会被补关联动作干扰 - 正文时间判断容易误判 - `汇报日期` 是当前最稳定、最容易统一执行的口径 ## 7. 这个 skill 怎么判断四色灯 这个 skill 使用： - `🟢` - `🟡` - `🔴` - `⚫` 四灯本身就是偏离程度和状态判断，不再单独拆一层“偏离判断”。 通俗理解： - `🟢`：按计划推进，结果成立或阶段性目标已达成 - `🟡`：有真实推进证据，但存在风险、压力，或距离成果标准还有差距 - `🔴`：明确偏离、关键风险已影响结果判断，或已出现明显异常 - `⚫`：当月没有有效汇报/有效证据，导致根本无法判断进展 其中 `⚫` 后续人工复核时要在三类里选一种： - `⚫ 未开展/未执行`：这件事本月其实没做，所以没有关联也没有证据 - `⚫ 已开展但未关联`：这件事做了，但 BP 关联没补上，系统暂时看不到 - `⚫ 体外开展但体系内无留痕`：事情在体系外做了，但没有形成会议纪要、记录或可引用汇报 这里要特别强调：这三类不是 AI 直接判的，而是 AI 先判“黑灯”，再明确提示用户做人工复核。 所以黑灯不只是“看不到”，还要进一步让用户回答为什么看不到，以及下个周期怎么消灭这个黑灯。 在第 2 章里，红黄绿灯的判断对象不是章节标题本身，而是每一个 `关键成果`。 如果一个章节下面有多个关键成果，就要分别判断，而不是只给章节一个总灯色。 在第 4 章里，灯色判断对象不是整章，而是每一个 `关键举措`。 也就是说，第 4 章里的每条举措推进情况都要单独带灯，规则与其他章节一致。 如果判成 `⚫`，还必须继续输出： - `黑灯类型（需人工复核）` - `为什么是这个类型` - `整改方案` - `承诺完成时间` - `下周期具体举措` - `是否持续提醒至下周期` ## 8. 这个 skill 的标准流程是什么 这个 skill 不允许一步生成整篇报告，而是固定走下面几步： 1. `00_intake` 记录周期、节点、月份、基线 2. `01_bp_anchor_map` 读取目标、成果、衡量标准、举措骨架 3. `02_source_inventory` 记录本月采用了哪些汇报、作者是谁、证据等级是什么 4. `03_evidence_ledger` 把汇报转成“本月发生了什么进展” 5. `04_cards` 先做更细颗粒度判断卡片 6. `05_report` 最后才生成月报正文 当前必须落实的颗粒度不是“整章卡片”，而是： - `关键成果卡` - `关键举措卡` - `待复核卡` 其中： - 每个 `关键成果` 至少一张卡 - 每个 `关键举措` 至少一张卡 - 每个 `🟡 / 🔴 / ⚫` 判断块要单独生成一张 `待复核卡` ## 9. 这个 skill 的修订流程应该是什么 修订不应该粗暴地整篇重写，而应该分段进行。 建议按下面的颗粒度修订： 1. 先修第 2 章 2. 第 2 章按小节修 每个小节内部再按“关键成果”修 3. 每个小节先确认： - 当前 AI 判断是否准确 - 是否要补更多资料 - 是否要重取最新汇报 4. 第 2 章稳定后，再继续修第 3、4、5 章 5. 第 7、8 章根据前面缺口和风险再收口 6. 最后才回写第 1 章汇报综述 也就是说，后续和用户的互动应该以“小节”为基本修订单元，而不是以“整篇报告”为修订单元。 但在当前业务场景下，这个颗粒度还不够细。 因为只要某个判断块出现 `🟡 / 🔴 / ⚫`，用户就必须补充解释和后续动作。 所以真正的最小修订单元，不只是“小节”，而是“带灯判断块”本身。 也就是说，后续应该再拆出一层 `复盘卡 / 待补卡`： - 每个 `关键成果` 的黄/红/黑灯块可以是一张卡 - 每个 `关键举措` 的黄/红/黑灯块也可以是一张卡 这些卡片才是用户补料、纠偏、确认的最小单位。 但当前版本优先级更高的是先把这套“细颗粒度拆片”彻底落完，作为 AI 基准稿的稳定中间层。 交互流程本身先不作为当前版本的主要改造目标。 ## 10. 这个 skill 应该支持哪两种更新模式 业务上应该明确支持两种模式： ### 10.1 系统刷新模式 由 AI 重新去 BP 系统获取： - 最新 BP 结构 - 最新关联汇报 - 最新附件信息（如果接口可取） 适用场景： - 用户希望按当前系统里的最新状态重算 - 用户怀疑旧证据取少了、取漏了 - 用户希望刷新某个章节或某个小节 ### 10.2 用户补料模式 由用户主动补充材料，再由 AI 在现有骨架上更新。 补充材料可能包括： ## 11. 附件与在线汇报链接 这两项当前先保留为待接入能力： - 汇报附件内容读取 - 在线汇报直达链接 后续等新接口提供后，再把它们纳入正式取数链路。 在此之前，skill 不应伪造附件已读或伪造在线链接能力。 - 用户手动上传的汇报 - 会议纪要 - 附件 - 用户对某一小节的修正说明 - 管理层最新口径 适用场景： - 系统里没有完整留痕 - 某项判断需要用户补充业务背景 - 用户只想修某一段，不想整章重跑 这两种模式的关键区别是： - 系统刷新模式，优先信系统数据 - 用户补料模式，优先把用户新补的材料并入当前小节判断 ## 11. 这个 skill 的正式输出不应只有一份报告 每个月至少要有两份正式报告： ### 11.1 AI基准草稿报告 作用： - 提供系统自动生成的基准稿 - 作为用户后续修订的底稿 特点： - 允许 AI 先给出初始判断 - 允许出现 `🟡 / 🔴 / ⚫` - 会明确提示哪些地方需要用户补充解释 ### 11.2 用户复盘版报告 作用： - 作为用户补充、修正、复盘后的正式版本 特点： - 用户可以修改任何内容，不限于黄红黑灯块 - 但凡是 `🟡 / 🔴 / ⚫`，都必须补充解释 - `🟢` 不强制补解释，但允许修改 这意味着： - 不能把 AI 基准稿直接等同于最终月报 - 也不能把用户修订动作只理解成“补几个字段” - 它本质上是一次“带约束的人工复盘” ## 12. 为什么要增加独立的复盘卡 如果只保留章节卡，用户在修订时很容易： - 一次改动多个判断块 - 把证据、解释、整改方案改混 - 后续无法追踪哪些问题已经补齐、哪些还没补齐 因此设计上应该再补一层独立的小 markdown 文件： - `review_queue` 这里每一张卡都对应一个需要用户处理的判断块。 触发条件： - 只要某个 `关键成果` 或 `关键举措` 被判成 `🟡 / 🔴 / ⚫` 就应该生成一张独立的复盘卡，供用户逐块补充和确认。 ## 13. 为什么要保留中间产物 因为月报不只是“写出来”，还要“可复核、可滚动”。 中间产物有两个作用： - 让当前这次生成更可控 - 让下个月写月报时可以承接上个月的判断基线 比如写 3 月月报时，不只是看 3 月证据，还要参考 2 月： - 哪些事项是 `🟢` - 哪些事项是 `🟡` - 上月承诺的重点动作是什么 - 本月有没有兑现 但除了“滚动生成”，中间产物还有第三个作用： - 支持“分段修订” 例如用户说“只修 2.2 薪酬体系这一节”，这时 skill 不应该整篇重写，而应该回到： - `02_source_inventory` - `03_evidence_ledger` - `04_section_cards` 先只更新对应小节，再回写正文。 ## 12. 这个 skill 的输出是什么 最终会输出两类结果，但这里不能再写成“固定只有 5 个过程文件”。 更准确地说，应分成： - `固定主骨架文件` - `动态扩展文件` 固定主骨架文件用于保证每次运行都有统一主线。 动态扩展文件则用于适配： - 模板章节数量变化 - 小节级修订 - 时间归集争议项确认 - 用户补料 - 多轮修订记录 所以业务上不应该把“过程文件”理解成一个固定死的列表。 ## 12.1 固定主骨架文件 - `00_intake.yaml` - `01_bp_anchor_map.yaml` - `02_source_inventory.md` - `03_evidence_ledger.md` - `04_section_cards.md` ## 12.2 动态扩展文件 根据模板、小节和修订过程动态增加，例如： - `02a_time_attribution_check.md` - `04-2.1_section_card.md` - `04-2.2_section_card.md` - `04-3.1_section_card.md` - `06_revision_log.md` - `07_user_supplied_materials.md` ## 12.3 最终报告 - `05_report.md` 这就是可以继续给业务方看、再人工调整后提交的月报初稿。 但从业务设计上，还应该补一个“修订态输出”： - 当前修到哪一章 - 当前修到哪一小节 - 本次更新是系统刷新还是用户补料 - 本次更新影响了哪些判断 ## 13. 这个 skill 当前有哪些边界 目前已经能稳定完成月报主流程，但还有几个现实边界： - 当前接口不一定返回 `reportId` - 所以最终证据现在先采用“标题 + 作者 + taskId + 证据等级”的方式标记 - 如果后续接口补上 `reportId`，就可以直接切换成： ```md [工作汇报标题](reportId=工作汇报id&linkType=report) ``` 另外，附件读取能力也取决于上游接口是否真的返回附件信息。 如果接口没有暴露附件字段，这个 skill 会明确标记“当前不可读取”，而不是假装已经读过附件。 另外，从当前业务角度看，仍有一个待补的设计点： - 现在“自动起草”链路已经比较清楚 - 但“用户交互修订”链路还没有完全产品化 所以后续的重点不只是继续增强取数能力，还要把“逐章逐节修订”真正做成标准流程。 ## 14. 适合谁用 这个 skill 适合这几类场景： - 经营责任中心、职能中心、个人节点的月报编写 - 需要基于 BP 系统真实数据来做滚动汇报 - 希望 AI 生成过程稳定、可控、可复核 - 希望月报和季报都沿用同一套逻辑 ## 15. 一句话总结 这个 skill 不是“帮你一把写完月报”，而是“按 BP 业务逻辑，把月报生成和后续逐段修订都变成一套可重复执行的流程”。