系统如何运作 · 五层架构
图示版见公开站 系统如何运作。 本页是文字版，便于检索与引用。
boss 不是"问 AI 要个答案"。它把一次判断拆成五层：怎么进来、拿什么当原料、按什么流程走、 产出什么、以及事后怎么验证自己错没错。
0. 一张图
┌─ L1 入口层 ─────────────────────────────────────────────────┐
│ 飞书机器人(多场景) · /boss · 本地 CLI · MCP · HTTP · 体验台 │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─ L2 知识层 ─────────────────────────────────────────────────┐
│ 锚点访谈 / 飞书历史 / 笔记增量 / 剪藏 / 行业报告 / 评审文档 │
│ │ 单向编译 (sage-wiki) │
│ ▼ 实体 · 人物 · 概念 · 摘要 │
│ ⚠ 单向：知识流进判断，判断产出永不回流 │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─ L3 判断流水线 ─────────────────────────────────────────────┐
│ 0 路由 → 1 立题 →【GATE 1 人工确认】→ 2 并行调研 → │
│ 3 合成 → 4 评委独立打分 → 5 合议+冻结版本 → 6 导出 │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─ L4 产出层 ─────────────────────────────────────────────────┐
│ 判断书(滚动) · 版本快照(不可变) · 各评委独立评语 · │
│ 案例档案(证据+归因计划) · 交付件(卡片/md/html/pdf) │
└──────────────────────────┬──────────────────────────────────┘
▼
┌─ L5 回路层 ─────────────────────────────────────────────────┐
│ 30/90/365 天归因 → 失败卡片(6 类) → 战略 OS 台账 │
└────┬────────────────────────────────────────────────────────┘
│ ↺ 回流：按失败类型分别去修
└──▶ 知识层的事实 / 评委的判断框架 / 流程本身横切五层：出口脱敏闸、公开层预检、提交期不变量、四级敏感度。
1. L1 · 入口层
解决的问题：判断要在人本来就在的地方发生，而不是逼人换工具。 没有它会怎样：再好的方法论也没人用。
| 入口 | 特点 |
|---|---|
| 飞书机器人 | 每个场景一个入口，各自的评委组与评分口径；支持群里发文档即评 |
/boss <议题> | Claude Code slash command |
| 本地 CLI | 唯一能连完整知识库、用全部参数、跑三套导出 |
| MCP（3 个工具） | 配一个 .mcp.json 即可，自然语言驱动 |
| HTTP 三连 | 自带模型（BYOM），正式集成用 |
| 公开体验台 | 免 token，服务端代跑，零门槛试用 |
接入细节见 接入总览。
2. L2 · 知识层
解决的问题：判断要有可追溯的事实底座，不能靠模型脑补。 没有它会怎样：幻觉、张冠李戴、无法审计。
原料经单向编译成实体 / 人物 / 概念 / 摘要四类结构化条目，供流水线按需检索。
关键纪律：
- 单向流动。知识流进判断，判断产出永不回流进知识库。
- 引用锚点历史观点必须给具体来源，给不出就降低置信度。
- 材料不足时明确写"超出已知材料"，而不是编。
唯一的受控例外：评审收到的原始提交文档（评审的输入）可经去重、分级、分类后 沉淀进内部知识库；但报告、评语、案例档案（评审的产出）永远不进。
3. L3 · 判断流水线
解决的问题：把"想清楚"拆成可检查的步骤。 没有它会怎样：一步到位的答案没法复核，也没法定位错在哪。
| 阶段 | 做什么 | 产物 |
|---|---|---|
| 0 路由 | 判断是新议题还是已有议题的迭代 | 模式选择 |
| 1 立题 | 拉知识背景，定 5-7 个调研维度与评委组 | 冻结的背景快照 + 提纲 |
| GATE 1 | 停下来等人确认 | 人点头才继续 |
| 2 并行调研 | 多个子代理各查一维 | 每维一份原始证据 |
| 3 合成 | 关键变量 / 最脆弱假设 / 跨维矛盾 | 合成稿 |
| 4 评委打分 | 各自读合成稿独立打分，互不可见 | 每人一份独立评语 |
| 5 合议 | 出报告、冻结版本、算分歧值 | 判断书 + 不可变快照 |
| 6 导出 | 三套导出（内部 / 脱敏 / 可视化） | 交付件 |
Phase 4 是核心：一位锚点评委（人的心证基线）+ 若干维度评委（各持一套 doctrine）， 在同一组固定的评分镜头上独立打分。维度评委还必须回答「如果这个判断错了，哪一环最脆弱」—— 缺这个字段直接阻断提交。
4. L4 · 产出层
解决的问题：判断要冻结得住，事后能翻回去看当时是怎么想的。 没有它会怎样：事后诸葛亮，无法归因。
- 判断书：滚动更新的当前版本
- 版本快照：写入即永久不可变
- 各评委独立评语：分歧本身就是数据，不做平均、不做整合
- 案例档案：原始证据 + 归因计划
- 交付件：飞书卡片 / md / html / pdf
5. L5 · 回路层
解决的问题：让系统知道自己错了，并把教训固化回去。 没有它会怎样：永远在重复同一类错误。
这是最容易被省掉、也最不该省的一层。
- 下判断时就写好证伪条件：30 / 90 / 365 天后各看什么信号
- 定时器到期自动核对：确认 / 部分成立 / 被证伪
- 被证伪 → 生成失败卡片并归类
- 按类型分别去修：
| 失败类型 | 触发条件 | 修哪里 |
|---|---|---|
| 事实错误 | 输入的事实就是错的 | 知识层的实体条目 |
| 框架错位 | 推理框架用错了 | 评委的判断框架 |
| 流程执行 | 步骤没走对 | 流水线本身 |
| 归类错误 | 议题被错误分类 | 路由规则 |
| 验证设计 | 归因指标本身有问题 | 证伪条件的写法 |
| 落地失效 | 决策的负责人/期限失效 | 决策模板 |
下一次判断因此比这一次更准——这才是"判断力工程化"里的"工程化"。
6. 贯穿五层的闸门与纪律
判断对象常涉及具体客户、人物、数字与条款。系统默认所有内容都是机密的， 靠分级而不是靠自觉来管控。
| 闸门 | 作用 |
|---|---|
| 出口脱敏闸 | 任何内容出公网前必过，fail-close；命中即阻断待人工复核 |
| 公开层预检 | 公开站部署前硬规则扫描：真名、客户名、内部链接一律拦下 |
| 提交期不变量 | 评委缺反方字段、评语格式畸形 → 直接阻断提交 |
| 四级敏感度 | 公开 / 内部 / 机密 / 仅锚点，默认机密 |
脱敏是「出口闸」，不是「入口闸」
内部知识库存原文——企业知识的价值就在原文，靠敏感度分级 + 私有存储保护； 只有出公网才脱敏。
曾经把出口闸误用成入库闸（命中机构名/财务数字就拦下降级），结果把最有价值的内容全拦了。 这是方向性错误。判断标准：先问这份内容会不会到公网——不会就存原文 + 分级，会才在出口处过闸。
7. 三条容易被问到的设计取舍
为什么中间要停下来让人确认？ 因为调研方向错了，后面全白跑。GATE 1 卡在最便宜的位置——此时只花了几分钟， 改提纲成本极低；等跑完全流程才发现问错了问题，成本是几十倍。 更根本的立场是：决策永远是人做的，系统负责把过程摊开、让人看得见、能反驳。
为什么评委之间要互相保密？ 只要能看到别人的评分就会向均值靠拢（锚定效应）。一旦发生，多评委就退化成 "一个评委 + 几个复读机"，分歧信息全部丢失。而分歧恰恰最有价值： 锚点与维度评委差得远，往往正说明这里有值得想清楚的东西。
为什么版本快照不能改？ 快照的用途是记录"当时是怎么想的"。一旦允许回头修，归因就失去基准， "我们早就知道"会悄悄取代"我们当时判断错了"。纠错的正确方式是发新版本， 新旧之间的差异本身就是有价值的记录。
硬红线
评分不作为绩效依据。 分数是给判断做诊断的，不是给人打绩效的—— 一旦用来考核，所有人会立刻开始优化分数而不是优化判断。
延伸阅读
- 接入总览 —— 四条接入路径对照与最小示例
- 评委全景 —— 评委体系细节
- 5 镜头 · 6 维度评委 · anchor_delta
- 30/90/365 attribution · Failure Card