HOW IT WORKS · 系统如何运作

从一句话议题,到一份能被证伪的判断

boss 不是"问 AI 要个答案"。它把一次判断拆成 五层:怎么进来、拿什么当原料、 按什么流程走、产出什么、以及事后怎么验证自己错没错。 这一页把整套机制画成一张图,再逐层拆开讲。

这一页讲「怎么运作」。 想直接上手,看 接入总览;想看评委体系细节,看 评委全景; 想看方法论为什么这么设计,看 产品与方法论

SECTION 1 · 全景

整个系统,一张图

自上而下是一次判断的生命周期;最下面那条回路是关键——它让系统能从自己的错误里学, 而不是每次从零开始。

L1 入口层 同一套判断引擎,六种进入方式
飞书机器人15 个场景各一个入口 · 群里发文档即评
/boss <议题>Claude Code slash command
run_pipeline_local.py本地 CLI · 唯一能连完整知识库
MCP · 3 工具prepare / submit / render
HTTP 三连自带模型 (BYOM)
公开体验台免 token · 服务端代跑
L2 知识层 判断的原料 · 由 sage-wiki 单向编译
锚点访谈最高权重信源
飞书历史材料经三通道过滤层
个人笔记增量金句 / 决策复盘
网页剪藏常规 ingest
行业报告数据点 / 趋势
评审文档受控入库管线
↓ 编译成 实体 · 人物 · 概念 · 摘要 四类结构化条目,供流水线按需检索。
⚠ 单向:知识流进判断,判断产出永不回流进知识库—— 否则版本快照的不可变性、评委的独立性、归因的历史轨迹全会被污染。
L3 判断流水线 7 个阶段 · 每步产物可审计
0
路由
新判断
还是迭代
1
立题
拉知识
定维度
人工确认
GATE 1
人点头才走
2
并行调研
多个子代理
各查一维
3
合成
杠杆 / 脆弱边缘
跨维矛盾
4
评委打分
互不可见
独立出分
5+6
合议 · 导出
冻结版本
三套导出
Phase 4 是核心:一位锚点评委(人的心证基线)+ 若干维度评委(各持一套 doctrine), 在同 5 把尺子上独立打分,彼此看不到对方的评语。维度评委还必须填写「如果我错了,哪一环最脆弱」。
L4 产出层 既要好读,也要可审计
判断书滚动更新的当前版本
版本快照写入即永久不可变
各评委独立评语分歧本身就是数据
案例档案原始证据 + 归因计划
交付件飞书卡片 / md / html / pdf
L5 回路层 让系统从自己的错误里学 · 这是最容易被省掉、也最不该省的一层
30 / 90 / 365 天归因定时器自动到期检查
失败卡片按 6 类归因:事实 / 框架 / 流程 / 归类 / 验证 / 落地
战略 OS 台账决策与行动 append-only
↺ 回流:判断在 30/90/365 天被证伪或部分证伪 → 生成失败卡片 → 按类型分别去修 知识层的事实评委的判断框架、或流程本身下一次判断因此比这一次更准——这才是"判断力工程化"里的"工程化"。
SECTION 2 · 逐层

每一层在解决什么问题

设计不是为了复杂,每一层都对应一个"如果没有它会怎样"。

解决什么问题如果没有它关键机制
L1 入口 判断要在人本来就在的地方发生,而不是逼人换工具 再好的方法论也没人用 同一引擎多入口;场景化配置(每个场景自己的评委组与评分口径)
L2 知识 判断要有可追溯的事实底座,不能靠模型脑补 幻觉、张冠李戴、无法审计 单向编译;引用必须锚到来源;材料不足要明说而不是编
L3 流水线 把"想清楚"拆成可检查的步骤 一步到位的答案没法复核,也没法定位错在哪 阶段产物落盘;人工确认闸;评委独立打分;强制写反方
L4 产出 判断要冻结得住,事后能翻回去看当时是怎么想的 事后诸葛亮,无法归因 版本快照不可变;评委评语各自独立留存
L5 回路 让系统知道自己错了,并把教训固化回去 永远在重复同一类错误 下判断时就写好证伪条件;到期自动核对;失败卡片按类型改对应环节
SECTION 3 · 横切

贯穿五层的闸门与纪律

判断对象常常涉及具体客户、人物、数字与条款。这套系统默认所有内容都是机密的, 靠分级而不是靠自觉来管控。

出口脱敏闸

任何内容出到公网前必过,fail-close(拦不住就不放行)。命中即阻断并留待人工复核。

公开层预检

公开站内容部署前硬规则扫描:真名、客户名、内部链接一律拦下。

提交期不变量

评委缺少反方字段、评语格式畸形,直接阻断提交——纪律靠工具执行,不靠记性。

四级敏感度

公开 / 内部 / 机密 / 仅锚点。默认机密,越权发布需显式降级。

SECTION 4 · 走一遍

跟着一次判断从头走到尾

以「某产品线明年要不要扩张」为例,看数据在五层之间怎么流动。

时刻发生了什么落下了什么
T+0有人在飞书里 @ 机器人,或在终端敲一条命令创建一个案例档案
T+1min系统去知识层拉这家公司、相关人物、相关概念的背景冻结一份"当时的背景快照"
T+3min草拟调研提纲:这次要查哪 5-7 个维度、请哪几位评委停下来等人确认(GATE 1)
T+15min确认后,多个子代理并行去查各自那一维每维一份原始证据
T+25min合成:哪些是决策的关键变量、哪个假设最可能被证伪、各维之间哪里打架一份合成稿
T+35min评委各自读合成稿独立打分,互相看不到——维度评委还得写「我要是错了,错在哪」每人一份独立评语
T+45min合议出报告,冻结版本,算出锚点与维度评委的分歧值,推卡片回飞书判断书 + 不可变的版本快照
T+30 天定时器到期,自动去核对当初写下的证伪信号确认 / 部分成立 / 被证伪
被证伪时生成失败卡片并归类,按类型去修事实、修框架、或修流程下一次判断因此更准
为什么中间要停下来让人确认?全自动不是更快吗?+

因为调研方向错了,后面全白跑。GATE 1 卡在最便宜的位置——此时只花了几分钟,改提纲成本极低; 等跑完全流程才发现问错了问题,成本是几十倍。

这也是这套系统的基本立场:决策永远是人做的,系统负责把判断的过程摊开、让人看得见、能反驳。

为什么评委之间要互相保密?+

只要能看到别人的评分,就会向均值靠拢——这是众所周知的锚定效应。一旦发生, 多评委就退化成"一个评委 + 几个复读机",分歧信息全部丢失

而分歧恰恰是最有价值的部分:锚点和维度评委差得远,往往正说明这里有值得想清楚的东西。

为什么版本快照不能改?发现写错了也不能改?+

不能。快照的用途是记录"当时是怎么想的"——一旦允许回头修,归因就失去了基准, "我们早就知道"会悄悄取代"我们当时判断错了"。

纠错的正确方式是发新版本。新旧版本之间的差异本身就是有价值的记录。

知识库为什么不能吃判断产出?看起来挺方便的。+

会同时破坏三件事:版本快照的不可变性(判断被重新编译进知识后又流回判断)、 评委的独立性(读到了本不该读的历史评语)、归因的历史轨迹 (同一家公司的多次判断被"整合",而差异本身就是数据)。

唯一的例外是受控的:评审收到的原始提交文档(评审的输入)可以经过滤后沉淀进知识库; 但报告、评语、案例档案(评审的产出)永远不进。

想动手试:接入总览(四条路径对照与最小示例)· 想看评委体系:评委全景 · 想读方法论:手册