多场景评委体系 (Multi-Scene Panel)

状态: ✅ 已实现 + VM 联调闭环 · v1.3.0 (2026-06-29) — scene_loader / panel_loader / op2_output 三层全部落地; 10 个场景上线; 两种场景类型 (review / competition) 各自经独立飞书机器人在云 VM 端到端跑通 (收文档 → 按场景路由 → 评委流水线 → 报告回推); 900 测试覆盖。此后新增第三种输出形态 meeting_summary —— review 型场景可产出多视角会议总结 deck + 大屏 PPTX, 而非打分报告 (见下「输出形态」)。

boss 的判断流水线最初围绕单一评委配置运行: 一套 6 维度评委 + 锚点, 一套 5 镜头, 一个交付入口。

但一家公司里, 判断的场景是分层、分类的:

不同层级 — 公司级 / 事业群级 / 事业部级的经营规划评审, 越往下越关注落地可行性, 越往上越关注战略一致性
不同业务 — 产品线、组织、客户战略各有侧重的评委组合
不同模式 — 常规评审 (锚点心证为基线) vs 竞赛 workshop (虚拟评委打分排名, 无锚点)

多场景评委体系的目标: 共用同一个 wiki 知识库与同一套锚点心智模型, 但让每个场景拥有独立的评委编组、评价维度、评分规则和交付入口 (飞书机器人)。

核心抽象: Scene (场景)

引入 Scene 作为 panel 的上层容器。一个 Scene = 一个部署单元 = 一个飞书机器人入口。

scenes/
└── <scene-slug>/
    ├── scene.yaml        ← 场景配置 (评委编组 / bot 绑定 / 白名单 / 脱敏 / 品牌前缀)
    ├── panel.yaml        ← 该场景的 panel (可继承默认 panel, 只覆盖差异)
    └── judges/           ← 该场景专属的虚拟评委 (可选)
        └── <judge-slug>/SKILL.md

三层职责清晰:

层	是什么	跨场景
Scene	部署单元 — 绑定一个飞书机器人 + 一套访问控制	各自独立
Panel	评审规则 — 评委编组 + 维度权重 + 评分镜头	可继承复用
Judge	评委身份 — 一套 doctrine 或一个角色 persona	可复用通用评委, 也可定义场景专属

什么共享、什么独立 是这套设计的关键纪律:

✅ 共享: wiki 知识库 (全场景同一个 _wiki/) · 锚点心智模型 (锚点只有一套心证) · 6 维度通用评委 · 5 镜头打分尺 · 30/90/365 attribution · 脱敏闸
🔀 独立: 评委编组 · 维度权重 · 评分镜头 · 飞书机器人 · 白名单与配额 · 报告品牌前缀

Panel 继承: 只描述差异

新场景很少需要从零定义 panel。多数情况下, 它在默认 panel 基础上做增删调权:

yaml

# scenes/<scene>/panel.yaml
extends: panels/default.yaml      # 继承默认 panel, 未覆盖字段自动沿用

judges_drop: [org-strategy]       # 移除不相关的维度评委
judges_add:                       # 追加场景专属评委
  - slug: fit-check
    skill_path: scenes/<scene>/judges/fit-check/SKILL.md

scoring_weights:                  # 调整 5 镜头权重 (默认均为 1.0)
  falsifiability: 1.5             # 例: 越靠近执行层, 可落地性 (可证伪) 权重越高

这让一个新场景的定义从"写一整套配置"收敛为"描述与默认有何不同", 既省事又让差异本身一目了然。

竞赛模式: 虚拟评委 + 自定义维度

竞赛 / workshop 场景与常规评审有两点本质不同:

无锚点 — 这是参赛方案的横向比拼, 不是锚点的个人决策, 因此 anchor_judge: null, 不输出 anchor_delta
自定义评分维度 — 5 镜头 (推理 / 证据 / 反方 / 可证伪 / 韧性) 是为"判断质量"设计的; 竞赛往往要换一套面向"方案优劣"的维度

yaml

anchor_judge: null
scoring_mode: sum_max_score       # 满分相加制 (默认是 5 镜头加权均分)

scoring_lenses_override:          # 完全替换 5 镜头, 各维带满分
  - { slug: biz_value,     display_name_cn: 业务价值,  max_score: 3 }
  - { slug: ai_depth,      display_name_cn: AI 含量,   max_score: 3 }
  - { slug: completeness,  display_name_cn: 完成度,    max_score: 2 }
  - { slug: innovation,    display_name_cn: 创新性,    max_score: 2 }

自定义维度是怎么"真打分"的

声明了 scoring_mode: sum_max_score, 这套维度就不只是"展示用标签" —— 流水线会让评委按这些维度逐项打分 (各自 0…满分), 而非套用通用 5 镜头:

评分阶段: 评委读到每个维度的满分与评分标准, 给出整数分。
合议阶段: 各维满分相加得总分 (如上例 3+3+2+2 = 满分 10)。常规评审 (公司级 100 分 7 维) 按门槛归一分级 (如 <60 重写 / <80 修改 / 否则进人工评审); 竞赛无门槛, 仅按总分排名。
排名榜: 竞赛报告会写入项目名 / 组名 / 各维度得分 / 总分, 排名工具据此自动出榜。

这正是 "5 镜头量判断质量, 自定义维度量方案优劣" 的落地: 两套尺子按场景各司其职, 同一套引擎驱动。

竞赛评委是角色化 persona (如"行业老兵""投资人视角""用户代表"), 不代入任何真实人物:

评委不是真人, 它是一组稳定的判断框架或一类经验视角。

竞赛结果面向更广的受众展示, 因此默认开启更强的匿名化与免责声明 — 评分是虚拟评委的参考意见, 不构成任何正式结论。

多机器人路由

一个进程同时接入多个飞书机器人, 按消息来源的 app_id 路由到对应场景:

飞书 (多个机器人)
  │  各机器人收到文档
  ▼
单进程多连接 (按 app_id 区分)
  │  app_id → 匹配 scene → 选对应 panel
  ▼
异步队列 → worker → 对应场景的评委流水线 → 报告回推原机器人

每个机器人有独立的白名单、配额与脱敏策略 — 公司级评审与事业部评审可以各自管控, 互不干扰。无 Scene 配置时, 系统回退到单机器人模式, 完全向后兼容。

场景类型 (scene_type)

v1.2.0 起, 场景有两种明确类型:

类型	触发	anchor	成绩公开	总分
`review`	经营规划 / 方案评审	`anchor_judge: tian` (默认)	内部	通常 100
`competition`	竞赛 / Workshop 横向评比	必须 null	必须公开	任意 (如 10)

scene_loader.load_scene() 在加载时校验类型约束 — competition 场景如果设了 anchor_judge 或 show_scores_publicly: false, 直接抛错阻断流水线。

评分模式与成绩渲染

当前仅支持 scoring_mode: sum_max_score:

总分: total_max_score(panel) = 所有 scoring_lenses 的 max_score 之和
等级 (与总分制无关, 均按百分比): S ≥ 95 / A ≥ 85 / B ≥ 70 / C ≥ 55 / D < 55
10 分制场景 (competition) 和 100 分制场景 (review) 的等级计算逻辑相同

scripts/op2_output.py 的 render_op2_6section() 输出 6 段式评审报告:

§1 总分 · §2 分项得分 · §3 必改项 · §4 补充建议 · §5 删减建议 · §6 一页汇总表

输出形态 (output_format): 打分报告 vs 定性总结

上面几节的成绩渲染都属于打分报告家族。但有一类场景要的产物不是分数, 而是多视角定性总结。output_format 就是描述"这个场景产出什么形态"的正交维度 —— 它和 scene_type 各管一件事:

output_format	形态	典型场景
`op2_6section`	打分报告 (总分 / 分项 / 必改 / 建议 / 删减 / 一页表)	经营规划 / 方案评审 (review)
`workshop_ranking`	打分 + 排名榜	竞赛 workshop (competition)
`meeting_summary`	定性总结 deck (每评委: 判断逻辑 + 3 亮点 + 3 不足 + 一句话评价)	会议本身的即时复盘

定性总结场景 (meeting_summary)

有一类评审对象不是一份计划书, 而是一场会议本身 —— 评审会开完、大会开完, 要立刻对"这场会的效果与内容"做多视角总结。它仍是 scene_type: review (保留锚点基线), 但产物形态全然不同:

产物是 deck, 不是分数: 每位评委从各自 doctrine 出发, 产出 [判断逻辑 + 3 个亮点 + 3 项不足 + 一句话评价], 汇成一份多页会议总结。
不设返工 / 优秀判决门槛: 定性总结是"给决策者一个多视角的盘点底座", 不是判决书, 因此不套用打分场景的 <60 重写 / <80 修改 门槛。
评委各自独立: 与打分场景一样, 评委互不可见彼此产出, 保持视角独立。

评审对象 = 会议纪要 / 议程与结论 / 录音转写 / 指定嘉宾演讲内容 —— 这正是它与"评一份方案"的核心差别: 管线相同, 差别只在 panel 维度与输出形态。

交付: markdown + HTML/PDF + 大屏 PPTX

meeting_summary 场景走一条与打分评审平行、独立的定性流水线 (meeting_summary_pipeline.py), 不进 Phase 0-5 打分 / 合议。产物:

markdown deck (report.md / meeting-summary.md) —— 随飞书卡片回推
HTML / PDF —— 同源多格式
大屏 PPTX (meeting-summary.pptx) —— 4:1 大屏展示版 (封面 + 每评委一页), 供会议现场大屏投放; best-effort 生成 (缺 python-pptx 只是不出 pptx, 不影响 deck 交付)

一句话: scene_type 决定"有没有锚点 / 成绩公不公开", output_format 决定"产出打分报告还是定性总结 deck" —— 两个正交维度, 组合出场景的完整面貌。工程实现见技术参考 §2.6。

共享评委资源池

scenes/shared-judges/ 存放可跨场景复用的专项评委 SKILL.md:

scenes/shared-judges/
├── first-principles/SKILL.md      ← 第一性原理评委
├── business-results/SKILL.md      ← 经营结果评委
├── op2-format/SKILL.md            ← OP2 报告格式评委
├── palantir-cto/SKILL.md          ← 数据平台 / AI 工程化视角 (⚠️ 虚拟角色)
├── liang-sheng/SKILL.md           ← 技术选型纪律 / 最后一公里 (⚠️ 虚拟角色)
└── capital-market/SKILL.md        ← 资本市场 / 市值管理视角 (⚠️ 虚拟角色)

⚠️ 带"虚拟角色"标注的评委均为基于公开观点构建的角色化视角, 不代表任何真实人物或机构。所有评委 SKILL.md 含标准 disclaimer + 必填 adversarial_view 三字段 (if_thesis_wrong / contrary_signal_observed / base_rate_warning)。

场景 panel 通过 skill_path: scenes/shared-judges/<slug>/SKILL.md 引用:

yaml

judges_override:
  - slug: tian
    judge_category: anchor
    skill_path: anchors/tian/perspective/SKILL.md
    always_active: true
  - slug: first-principles
    judge_category: dimension
    skill_path: scenes/shared-judges/first-principles/SKILL.md

场景决定评委类型

不同场景按 scene_type 用不同的评委编排，这是多场景体系的核心纪律：

	评审场景 (`review`)	竞赛场景 (`competition`)
评委	锚点心证 + 多维度评委（各持 doctrine）	单一虚拟评价助手
锚点	有（输出 anchor_delta）	无（`anchor_judge: null`）
成绩	内部，含锚点对照	公开排名

一套引擎，多副面孔：同一知识库与打分框架，按场景类型裁剪出恰当的评委组合。

评委 doctrine 的来源

维度评委的 doctrine 不是凭空写的，而是从带 source 锚点的公开材料蒸馏（演讲 / 文章 / 访谈 / 公开决策记录）。蒸馏纪律内建反捏造：

每条结论 / 引用必须锚定具体公开 source；source 置信弱时改 paraphrase
不编造私人信息或未来动态
角色化视角 ≠ 真实人物本人，所有评委含标准 disclaimer

这让评委既有稳定的判断框架，又可回溯到原始依据，避免"想象一个人会怎么说"的捏造风险。

命令行工具

bash

# 列出所有已定义场景
python3 scripts/scene_loader.py list

# 某场景全链路快速校验 (不调 LLM): scene → panel → 评委 SKILL 文件 → 约束检查
python3 scripts/smoke_e2e.py smoke-scene <scene-slug>
# 或通过 Makefile:
make smoke-scene SCENE=<scene-slug>

smoke-scene 适合在 CI 或 VM 联调前跑: 无 LLM 调用, 无磁盘写入, 失败即报具体错误路径。

一句话总结

一个知识库, 一套锚点, 多副面孔。 6 维度评委 + 5 镜头是稳定的内核; Scene 让这个内核按层级、按业务、按模式裁剪出恰当的评委组合, 通过各自的机器人触达对应的使用者。

文档	内容
本页	多场景评委体系 — 概念与设计原理
技术参考	配置 Schema / 关键脚本 API / OP2 输出格式 / 常见问题
VM 多场景部署	在云 VM 上启动多 bot，systemd 服务，验证检查清单
开发路线图	当前状态、P3 工程强化计划、anchor research SOP
ADR-012	引入多场景抽象的架构决策记录

多场景评委体系 (Multi-Scene Panel) ​

核心抽象: Scene (场景) ​

Panel 继承: 只描述差异 ​

竞赛模式: 虚拟评委 + 自定义维度 ​

自定义维度是怎么"真打分"的 ​

多机器人路由 ​

场景类型 (scene_type) ​

评分模式与成绩渲染 ​

输出形态 (output_format): 打分报告 vs 定性总结 ​

定性总结场景 (meeting_summary) ​

交付: markdown + HTML/PDF + 大屏 PPTX ​

共享评委资源池 ​

场景决定评委类型 ​

评委 doctrine 的来源 ​

命令行工具 ​

一句话总结 ​

相关文档导航 ​

多场景评委体系 (Multi-Scene Panel)

核心抽象: Scene (场景)

Panel 继承: 只描述差异

竞赛模式: 虚拟评委 + 自定义维度

自定义维度是怎么"真打分"的

多机器人路由

场景类型 (scene_type)

评分模式与成绩渲染

输出形态 (output_format): 打分报告 vs 定性总结

定性总结场景 (meeting_summary)

交付: markdown + HTML/PDF + 大屏 PPTX

共享评委资源池

场景决定评委类型

评委 doctrine 的来源

命令行工具

一句话总结

相关文档导航