# BP月报Skill设计方案 ## 1. 设计目标 这个 skill 的设计目标不是“让 AI 会写月报”，而是“让 AI 按固定业务逻辑、固定步骤、固定约束来生成月报初稿”。 需要同时满足 4 个目标： - 可控：不能一次性自由生成全文 - 可追溯：每个判断都能回到 BP 或汇报证据 - 可复用：同一个 skill 能重复用于不同节点、不同月份 - 可滚动：下个月生成时能承接上个月基线 在当前版本基础上，还要再补 3 个设计目标： - 可确认：关键上下文可确认，但当前版本先不把复杂交互流程作为主改造目标 - 可修订：第一版生成后，要支持逐章逐节修订，而不是只能整篇重跑 - 可切换：支持“系统刷新”和“用户补料”两种更新模式 在当前业务确认后，还要再补 2 个设计目标： - 双报告：每个月同时产出 `AI基准草稿报告` 和 `用户复盘版报告` - 可控复盘：凡是 `🟡 / 🔴 / ⚫` 的判断块，都要有独立复盘载体，便于用户逐块补充 ## 2. 设计原则 ### 2.1 判断主轴和证据抓手分离 这是整个设计里最重要的一条。 - `判断主轴`：目标 -> 关键成果 -> 衡量标准 - `证据抓手`：目标汇报 + 成果汇报 + 举措汇报 这样设计的原因是： - 如果只看举措，容易把“做了动作”误写成“结果成立” - 如果只看成果，不读举措，又会丢掉大量真实进展证据 所以这个 skill 采用“双层结构”： - 成果层负责判断 - 举措层负责取证和补足进展细节 ### 2.2 先中间层，后成稿 不允许直接输出最终月报。 必须先经过中间层。 这样设计是为了压住两个问题： - AI 一次性全文生成时容易漂 - 同样的输入多跑几次，输出差异会很大 中间层就是这套 skill 的“控制面”。 ### 2.3 最终报告面向人，中间层面向系统 最终报告应该可读，优先显示名称，不显示一堆 ID。 中间层则允许保留结构化对象、任务层级、证据分层等控制信息。 因此设计上分成两类产物： - 面向人的产物：`05_report.md` - 面向控制和复核的产物：`00-04` ### 2.4 月报不是静态单次生成，而是滚动生成 设计上明确要求： - 写 2 月时要读 1 月 - 写 3 月时要读 2 月 - 写季报时要读季度内各月 否则每个月会像重新开新题，失去连续性。 ### 2.5 当前版本先聚焦 AI 基准稿生成 交互式修订流程后续再做，当前版本先把 AI 基准稿生成链路收紧。 当前优先级更高的是： 1. 直接支持 `periodId + groupId/BP组织节点ID + reportMonth` 2. 用固定月份归集口径稳定取数 3. 把中间层拆到足够细，保证后续任何修订都能落到小卡片而不是整章重写 ## 3. 适用范围 当前设计主要适用于： - 基于 BP 系统的月报生成 - 节点级、个人级 BP 汇报 - 需要保留中间产物和证据链的场景 不适用于： - 完全没有 BP 结构的自由汇报 - 没有周期、节点、汇报留痕的临时写稿 - 单纯润色已有定稿 ## 4. 输入设计 ### 4.1 最小输入 最小输入被收敛成 3 个字段： ```yaml period_id: groupId: report_month: ``` 原因： - `period_id` 决定取数边界 - `groupId / BP组织节点ID / node_name` 决定 BP 主体 - `report_month` 决定本月归集范围 ### 4.2 执行输入 真正进入执行后，仍然以这几个为核心： ```yaml period_id: groupId: report_month: ``` 如果用户暂时没有 `period_id` 或 `groupId`，才回退使用： ```yaml bp_period: node_name: report_month: ``` ### 4.3 可选输入 可选输入只在必要时使用： - `groupId` - `BP组织节点ID` - `employeeId` - 模板路径 - 规范路径 - 特殊口径说明 设计上明确避免把“人员信息、模板、进展数据”全都变成必填项，因为这些信息理论上应由系统上下文或 BP 系统自身解决。 ### 4.4 月份归集口径 当前版本将月份归集规则定死为： - 只按 `汇报日期` - 只按 `汇报月份` 不作为默认规则的有： - `关联时间` - 正文月份猜测 原因： - `关联时间` 会被补关联动作干扰 - 正文月份猜测不稳定，容易误判 ## 5. 输出设计 设计输出分两层： ### 5.1 过程层 基础骨架文件： - `00_intake.yaml` - `01_bp_anchor_map.yaml` - `02_source_inventory.md` - `03_evidence_ledger.md` - `04_cards/` 但设计上不能把过程层理解成“永远只有这 5 个文件”。 更准确的设计是： - 先定义一组固定主骨架文件 - 再允许围绕章节、小节、修订轮次动态扩展 动态扩展文件例如： - `04_cards/2.1_kr_01.md` - `04_cards/2.1_kr_02.md` - `04_cards/4.2_action_01.md` - `05_review_queue/2.1_kr_02_yellow.md` - `05_review_queue/4.2_action_01_black.md` - `06_revision_log.md` - `07_user_supplied_materials.md` ### 5.2 成稿层 - `05_ai_baseline_report.md` - `07_user_review_report.md` 这样拆分的目的是： - 过程层用于控制、复核、滚动承接 - `AI基准草稿报告` 用于提供系统自动生成的底稿 - `用户复盘版报告` 用于提供用户补充后的正式版本 但输出设计还要补第三层： ### 5.3 修订态输出 用于支持用户逐段修订： - 当前修订目标章节 - 当前修订目标小节 - 本次修订是否刷新系统证据 - 本次是否合入用户补充材料 - 本次使用的月份归集口径 - 本次修订改动了哪些判断 - 是否需要继续确认下一小节 ### 5.4 复盘队列输出 用于承载用户必须补充的信息点： - `05_review_queue/` 目录中的每一张卡都对应一个需要用户处理的判断块。 触发规则： - 只要 `关键成果` 或 `关键举措` 被判成 `🟡 / 🔴 / ⚫` 就自动生成一张复盘卡。 设计意图： - 不让用户直接在整章里乱改 - 不让多个待补点混在同一块里 - 方便追踪哪些问题已确认、哪些还未关闭 当前版本要求把更细颗粒度拆片彻底做完，至少落到： - 每个 `关键成果` 一张结构卡 - 每个 `关键举措` 一张结构卡 - 每个 `🟡 / 🔴 / ⚫` 判断块一张待复核卡 ## 6. 核心模块设计 ### 6.1 Intake 模块 作用： - 记录本次运行的周期、节点、月份 - 记录是否存在上月基线 - 记录模板和规范来源 输入稳定后，后续步骤才能保持边界一致。 ### 6.2 BP Anchor Map 模块 作用： - 把当前节点的 BP 骨架稳定下来 内容包括： - 目标 - 关键成果 - 衡量标准 - 关键举措 - 责任人 / 承接人 这个模块的设计意义是： 后续所有证据和判断都必须挂到这个骨架上，不能脱离 BP 结构自由发挥。 ### 6.3 Source Inventory 模块 作用： - 记录本月到底命中了哪些汇报、最终采纳了哪些汇报 - 标记作者、taskId、证据等级、附件状态 这个模块解决的是“来源清单”问题，而不是“判断问题”。 当前设计还应明确： - `命中原始工作汇报数` - `最终采纳证据数` 要分开记录。 如果同一类通知只是批量分发给不同组织，不应在最终采纳数里被重复放大。 另外还要再分清 3 层对象： - 被系统命中的原始汇报 - 经时间归集规则筛过后的候选汇报 - 最终被章节采用的证据 否则用户无法判断，到底是“没取到”，还是“取到了但没采用”。 ### 6.4 Evidence Ledger 模块 作用： - 把汇报内容转成可写月报的“进展事实” 重点字段包括： - 事项 - 对应层级 - 证据 - 具体进展 - 证据属性 这个模块的设计目标是把“原始汇报”翻译成“可用于章节写作的事实语言”。 它既服务于第 2 章的关键成果判断，也服务于第 4 章的关键举措判断。 ### 6.5 Section Cards 模块 作用： - 在成稿前先做结构化判断卡 它不是最终报告，而是“结构控制卡”。 里面会包含： - 章节使用了哪些证据 - 本章判断为什么成立 - 四灯是什么 - 缺口是什么 - 下月怎么承接 这是整个设计里最关键的稳定器。 其中第 2 章要额外强调： - 章节标题只是目标容器 - 真正的判断单元是 `关键成果` - 一个章节下可以有多个关键成果判断块 - 每个关键成果都要独立挂： - 当前状态 - 四灯判断 - 判断理由 - 人工确认 - 若为黄/红/黑灯时的整改方案与承诺时间 其中第 4 章也要额外强调： - 第 4 章不是简单罗列举措 - 真正的判断单元是 `关键举措` - 每个关键举措都要独立挂： - 当前进展 - 四灯判断 - 判断理由 - 人工确认 - 若为黄/红/黑灯时的整改方案与承诺时间 在后续设计里，这个模块还要承担“修订控制面”的职责。 也就是说，用户如果说： - “只修 2.2” - “只补 2.4 的流程线上化” - “只更新长期激励这一节的最新汇报” 系统首先应该回到 `04_section_cards`，而不是直接整篇重写。 但当前业务下，这里还要再往下拆一层： - `04_cards` - 负责承载 AI 的结构化判断 - 最小单元是 `关键成果卡` 或 `关键举措卡` - `05_review_queue` - 负责承载用户必须补充的复盘点 - 最小单元是一个 `🟡 / 🔴 / ⚫` 判断块对应的一张复盘卡 所以真正的最小修订单元，不再只是“小节”，而是“一个需要用户复核和补充的判断块”。 ### 6.6 Report Draft 模块 作用： - 把前面已经稳定的判断，写成符合模板的正文 这一步不再负责“发现事实”，只负责“表达事实”。 在当前设计里，这个模块实际上要产出两类报告： - `AI基准草稿报告` - `用户复盘版报告` ## 7. 交互流程设计 ### 7.1 第一轮交互 第一轮不应只说“给我 3 个参数”。 更合理的入口是： 1. 告诉用户当前可选 BP 周期 2. 让用户确认周期 3. 再确认节点名称和层级 4. 再问本次要： - 新生成 - 继续修订 - 局部更新 ### 7.2 第二轮交互 如果是“新生成”，则继续确认： - 月份 - 是否按系统最新汇报重取 - 本次月份归集口径 如果是“继续修订”，则继续确认： - 修哪一章 - 修哪一小节 - 是系统刷新还是用户补料 - 当前争议是否涉及时间归属 ### 7.3 后续交互 进入修订后，原则上按“判断块”为单位推进，而不是整篇推进。 原因： - 月报的真正修订动作通常集中在黄/红/黑灯块 - 这些判断块才是用户真正补料和纠偏的地方 - 第 1 章应该最后统一回写 ## 8. 证据模型设计 ### 8.1 证据分层 当前设计采用 4 层证据优先级： 1. 本人手动汇报 2. 本人回溯汇报 3. 他人手动汇报 4. AI 汇报 这个分层设计的原因是： - 关联关系不等于可信度相同 - 本人写的，最能代表该事项的直接判断 - 他人写的，更适合作辅证 - AI 汇报不能单独支撑强结论 ### 8.2 证据对象设计 当前设计规定： - 主证据对象应是原始在线汇报 - 不再默认把每条汇报正文落成本地 json 如果未来接口能返回 `reportId`，将采用： ```md [工作汇报标题](reportId=工作汇报id&linkType=report) ``` 如果当前接口没有 `reportId`，则退化成最小元数据表示： - 标题 - 作者 - taskId - 证据等级 这样设计是为了避免为了“保留证据”而生成大量冗余本地快照。 ### 8.3 附件设计 附件处理遵循“有则读、无则明示”的原则： - 如果接口有附件元数据，就纳入证据判断 - 如果接口没有附件字段，就明确标记“当前不可取” 设计上禁止假装已经读过附件。 ## 9. 更新模式设计 ### 9.1 系统刷新模式 定义： - 由 AI 主动重新从 BP 系统抓取最新 BP 和最新汇报 适用： - 用户怀疑旧证据不全 - 需要拿最新状态重算 - 某小节明显有新增汇报 ### 9.2 用户补料模式 定义： - 在现有骨架和现有证据上，合并用户新补的资料进行更新 适用： - 系统没有完整留痕 - 用户要补附件、会议纪要、临时说明 - 用户只想修某一小节，不想整章重抓 ### 9.3 两种模式的执行差异 - 系统刷新模式优先更新 `02_source_inventory` 和 `03_evidence_ledger` - 用户补料模式优先更新目标小节对应的 `03_evidence_ledger` 和 `04_section_cards` - 两种模式最后都回写 `05_report.md` 但在新的双报告模型下，这里应进一步明确： - 系统刷新模式优先更新 `04_cards` 和 `05_ai_baseline_report.md` - 用户补料模式优先更新 `05_review_queue`，再回写 `07_user_review_report.md` ## 10. 状态判断设计 ### 10.1 四灯即状态 设计上明确： - `🟢` - `🟡` - `🔴` - `⚫` 四灯本身就是偏离程度和状态判断，不再额外增加一层独立的“偏离判断”。 这样做的原因是： - 避免同一条事项出现两套颜色逻辑 - 降低理解成本 - 让报告更直观 ### 10.2 四灯依据 四灯判断综合以下因素： - 关键成果是否成立 - 衡量标准距离是否缩小 - 是否存在阻塞或风险 - 证据强度是否足够 这里要进一步区分两类情况： - 有证据，但证据不完整、存在压力、离标准还有差距：判 `🟡` - 已有明确异常、明确偏离、明确失败信号：判 `🔴` - 没有当月有效汇报、没有足够证据、导致系统无法判断该关键成果是否在推进：判 `⚫` 也就是说，“证据不足”不能一概归到黄灯。 如果已经不足到无法判断进展，就必须判黑灯。 ### 10.3 黑灯细分设计 黑灯不能只停留在“看不见”，还要区分“为什么看不见”。 但这里的类型判定不应由 AI 自动完成，而应交给人工复核。 人工复核时拆成三类： - `⚫ 未开展/未执行` 说明：该事项本月实际上没有做，因此系统里既没有关联，也没有证据。 要求：必须补“下月/下周期准备怎么做”，不能只写“待推进”。 - `⚫ 已开展但未关联` 说明：事项做了，但对应的工作汇报、会议纪要或材料没有关联到 BP。 要求：必须补“要去关联哪些材料/汇报”，并把这件事保留为持续提醒项，直到下个周期确认已补关联。 - `⚫ 体外开展但体系内无留痕` 说明：事项可能通过开会、线下沟通、外部文档推进了，但体系内没有留下可供判断的记录。 要求：必须补“要完善什么留痕方式”，例如会议纪要、正式汇报、材料归档；目标是让下个周期该层级可以被判断。 这个细分很重要，因为三种黑灯的整改动作不同。 设计上 AI 的职责是： - 先基于证据把事项判成 `⚫` - 明确告诉用户“AI 无法判断黑灯属于哪一类，需人工复核” - 把三种类型和对应要回答的问题明确列出 然后再由用户确认具体类型。 三种黑灯的整改动作不同： - 第一类要解决“没做” - 第二类要解决“做了但没关联” - 第三类要解决“做了但没留痕” ## 11. 双报告设计 ### 11.1 AI基准草稿报告 这是 AI 自动生成的基准稿。 作用： - 给用户一个结构完整、证据清晰、判断明确的初始版本 - 把所有 `🟡 / 🔴 / ⚫` 的问题先暴露出来 - 作为用户后续复盘和修订的起点 约束： - 允许 AI 给出基于当前证据的初始判断 - 不允许把它视为最终提交稿 ### 11.2 用户复盘版报告 这是用户基于 AI 基准稿完成补充和修订后的正式版本。 业务约束： - 用户可以修改任何内容 - 但所有 `🟡 / 🔴 / ⚫` 判断块必须补充解释 - `🟢` 不强制补解释，但允许修改 ### 11.3 为什么必须是双报告 因为当前业务不是“AI 直接代写最终报告”，而是： 1. AI 先给一个可复核的基准稿 2. 用户再完成带约束的复盘 如果不区分这两份报告，就会混淆： - 哪些内容是 AI 自动判断的 - 哪些内容是用户补充和确认的 - 哪些问题还未被解释 ## 12. 复盘卡设计 ### 12.1 为什么要单独有复盘卡 仅靠章节卡不够，因为章节卡主要解决“结构判断”问题，不解决“用户补充义务”问题。 当一个章节里同时有多个 `🟡 / 🔴 / ⚫` 时，如果不拆卡： - 用户容易一次改乱多个判断块 - 证据、解释、整改方案容易串在一起 - 后续无法追踪哪些判断块已确认、哪些仍待处理 ### 12.2 复盘卡触发规则 只要某个 `关键成果` 或 `关键举措` 被判成： - `🟡` - `🔴` - `⚫` 就应自动生成一张独立的小 markdown 复盘卡。 ### 12.3 复盘卡最小字段 建议至少包含： - `card_id` - `report_month` - `chapter_ref` - `anchor_type` - `anchor_name` - `light` - `ai_judgment_reason` - `evidence_refs` - `user_need_to_answer` - `user_response` - `rectification_plan` - `commitment_date` - `next_cycle_action` - `carry_forward` - `status` ### 12.4 复盘卡与双报告的关系 - `04_cards`：保存 AI 的结构化判断 - `05_review_queue`：保存用户必须补充的复盘点 - `05_ai_baseline_report.md`：保存 AI 基准稿 - `07_user_review_report.md`：保存用户复盘版 四者组合后，这套设计才能既可控、又可修订、又能滚动承接。 ## 13. 月份归集设计 真实业务里，汇报可能会补写、回溯写。 所以月份归集不能只写成一句“软规则”，必须把判断层次讲清楚。 ### 11.1 当前明确可用的结构化时间 当前至少有两个结构化时间： - `汇报时间` - `人工关联到 BP 的时间` 当前没有稳定的“月份标签”字段。 ### 11.2 当前不应直接作为默认主规则的来源 `正文里提到的月份` 目前不能直接作为默认归集主规则。 原因： - 可能是回顾往月事项 - 可能是补写 - 可能一句正文同时提到多个时间 - 如果直接交给大模型判断，误差不可控 因此设计上应明确： - 正文时间只能作为辅助信号 - 不能在没有人工确认的情况下直接决定归属月 ### 11.3 建议支持的 3 种归集模式 1. `report_time` 按汇报时间归集 2. `relation_time` 按关联时间归集 3. `structured_time_plus_manual_review` 先按结构化时间初筛，再对疑似回溯项人工确认 ### 11.4 当前更稳妥的默认方案 在没有月份标签之前，更稳妥的默认方案应是： - 默认按 `report_time` - 保留 `relation_time` 供排查 - 对正文中提到其他月份的记录，打上“疑似回溯”标记 - 由用户决定是否把这条证据改归到其他月份 这比“默认让大模型读正文判月份”更稳。 ## 12. 滚动基线设计 这个设计不是“每个月独立生成一篇新报告”，而是“滚动生成”。 因此在写下个月时，必须读取上个月： - `05_report.md` - `04_section_cards.md` 原因： - `05_report.md` 告诉系统“上个月怎么汇报的” - `04_section_cards.md` 告诉系统“上个月为什么这么汇报、哪些问题没关” 这样下个月就不会失去连续性。 ## 13. 用户可见层设计 最终报告是给业务和管理层看的，所以设计要求： - 用名称，不用裸 ID - 结论先行，证据跟随 - 重点写“具体进展”，不是只写“有证据” - 所有章节必须和模板结构一致 这也是为什么： - ID 允许存在于中间层 - 但不应出现在最终报告正文主视图中 ## 14. 当前实现形态 当前 skill 由三部分组成： - `SKILL.md` - `references/` - `scripts/` 其中： - `SKILL.md` 负责定义入口行为和总规则 - `references/` 负责存放业务说明、流程、schema、设计方案等 - `scripts/` 负责固化 BP 取数和证据采集逻辑 这是一种“文档规则 + 轻脚本”的混合实现。 ## 15. 当前边界与后续演进 ### 15.1 当前边界 - `reportId` 还没有稳定暴露 - 附件能力取决于上游接口 - 月份归集策略还没有完全产品化 - 正文时间目前仍只能做辅助提示，不能做默认硬规则 ### 15.2 后续演进方向 可以继续往下补： - 汇报在线链接能力 - 附件抓取与附件文本抽取 - 季报聚合逻辑 - 更自动化的一键执行入口 - 逐章逐节的交互式修订状态机 - 系统刷新 / 用户补料双模式执行器 - 月份归集策略配置器 - 时间归集争议项的人工确认面板 ## 16. 设计结论 这个 skill 的本质不是“一个 prompt”，而是一套： - 以 BP 业务对象为骨架 - 以汇报证据为依据 - 以中间层为控制面 - 以滚动月报为运行方式 - 以分步确认和逐段修订为交互方式 的结构化生成方案。