把判断拆成可引用、可打分、可证伪的决策系统
boss-vault 是一个"判断力工程化"项目: 单一 Obsidian vault 内, 把锚点 (anchor) 的判断方法论 (ATELIER 6 字段) 编码成通用 boss-skills + per-anchor 数据 instance, 通过 1 锚点 + N 维度评委独立合议 + 30/90/365 attribution 把判断变成可引用、可打分、可证伪的决策系统。
单租户 · 非 SaaS · 非多租户 · 非云数据库 · 三种部署形态 (D1 Local / D2 Hermes / D3 Actions) 判断质量一致
clean clone · CI tests.yml + coverage 棘轮
01 需求
谁用 · 用来做什么 · 不做什么
一句话定位
把锚点 (anchor) 的判断方法论编码为通用 boss-skills + per-anchor 数据 instance, 通过 1 锚点 + N 维度评委独立合议 + 30/90/365 attribution 把判断变成可引用、可打分、可证伪的决策系统。Karpathy Wiki 在同一 vault 内沉淀外部素材, 通过单向引用给判断流水线提供 Context。
服务对象 (6 类角色)
| 角色 | 主要用法 | 频次 |
|---|---|---|
| 锚点 (视角持有者) | 飞书卡片回判断 / 查 30 天前判断当下状态 / 追反方 | 周 2-5 次 |
| 项目主理 (解读人) | CLI 触发 /boss / 抽审 review / 维护 panel | 日常 |
| CTO | 部署 / 审 PR / 维护 Hermes + sage-wiki | 周 |
| SuperIntern | 写 Skill / 改 doctrine / 跑 lint + smoke | 日常 |
| 评委 Agent (LLM) | 读 synthesis → 5 镜头打分 → 写 review.md | 每议题 4-7 次 |
| 审计者 (未来) | 读 versions/ + attribution.log, 不可写 | 季度 |
不服务对象 (out of scope)
- 本项目以外的客户 / 合作方 / 投资方 — vault 是锚点私域工作底稿, 不对外开放
- 简单事实问答 / 闲聊 / 创作 — 走 sage-wiki query 或普通 LLM
- 实时聊天 / IM bot — V0 不做对话式, 只做"提交议题 → 异步生成判断"
- 多租户 / SaaS — V3 之前坚持单租户、单机器
锚点判断的四个特点 (产品设计前提)
跳步识别为核心
weight_jump / timing_jump / exclusion_jump 是判断本体, 不是 bug。case.json 必填 jumps 字段。
反方排除为日常
先列反方再排除, 而非堆论据。adversarial_view 三字段对维度评委强制。
时机 (timing) 高权重
同一动作早一月 / 晚一月正确性会反转。Phase 1 PRD 必含 external_anchor 时窗。
不通用复用
对同一客户 30 天后未必适用, 差异本身就是数据 (EVOLUTION 模式)。
02 解决的问题
从"判断在头脑里"到"判断可引用、可验证"
4 大痛点 → 4 件事
| 痛点 | 现状 | 工程化后 |
|---|---|---|
| 写不下 | 判断散落在飞书 / 头脑 / 笔记里, 几个月就找不回 | 落 cases/C-YYYY-NNNN/case.json + reports/<brand>/report.md |
| 找不回 | 关键词搜飞书 / Obsidian 各种重命名, 30 分钟才找到 | sage-wiki query 一秒返回 + Wiki backlink 自动维护 |
| 不能验证 | 判断说"3 个月会X", 但 3 个月后没人记得 follow up | 30/90/365 checkpoint 自动调度 + Failure Card 6 类强制 |
| 不能扩充 | 新方法论被吸收靠"下次提" / 被遗忘 | Skill-Pack 化 + Git 版本控制 + dev-log 留痕 |
为什么是 LLM Agent 不是规则系统
- 判断具体内容强语境, 每个议题不可硬编码
- 评委体系模拟多视角, 需 LLM 在共同 synthesis 上各执 doctrine
- 数据来源 (飞书 / 访谈 / 行业报告) 半结构化, LLM 抽取性价比高
- 但关键纪律 (评委独立性 / 反方字段强制 / 版本不可变) 用规则强制, 不靠 LLM 自觉
03 架构
双层结构 · 单向引用 · 权责矩阵
双层与权责
Wiki 层
sage-wiki 全权写 _wiki/entities/people/concepts/. Claude Code 只读用作 Context, 永远不修改。
MBA 层
Claude Code 全权写 skills/ panels/ reports/ cases/ failure_cards/ scripts/. sage-wiki 永远不读这些目录。
不可变
reports/<brand>/versions/v{n}_*.md 写入后永远不可变. EVOLUTION 写 v{n+1}, 不修改 v{n}. pre-commit hook 阻断。
handbook-src/
VitePress 公开层 (ADR-008). 仅放方法论 / 框架描述 / 脱敏示例. 永不放 case/report 真实内容. check_public_safe.py + redact_check.py 双闸。
单向引用
| 方向 | 谁维护 | 触发 |
|---|---|---|
reports/ → _wiki/entities/ | Claude Code 在 Phase 1 写入 | 每次 FRESH 模式 |
_wiki/entities/ → reports/ | sage-wiki 在 Lint 时扫 metadata 自动追加 | 每次 sage-wiki compile |
04 数据流
Phase 0-5 + Attribution 标准节拍
3 个独立层次, 不要做矩阵相乘
| 层次 | 用途 | 例 |
|---|---|---|
| 7 调研维度 | Phase 2 派 sub-agent 用 — 采集什么 | 触发事件链 · 关键变量 · 法律约束 · 客户信号 · 竞品 · 内部资源 · 时机 |
| 6 评委维度 | Phase 4 评委切角度 — 如何评估 | industry-trend · strategic-vision · customer-strategy · product-strategy · org-strategy · financial-strategy |
| 5 镜头 | 所有评委固定打分项 — 按什么尺子 | reasoning_soundness · evidence_thesis_coupling · counter_position_treatment · falsifiability · real_world_resilience |
三种模式 (Phase 0 路由)
FRESH
首次判断. 全 Phase 1-5. 起 PRD → 派 N 维 sub-agents → 7 评委独立 → Lead 合议 → versions/v1.md
EVOLUTION
同 brand 重判. 跳 Phase 1 起草, Phase 1E Diff Plan, 只重跑 1-3 变化维度. 写 v{n+1}, 不动 v{n}.
REVIEW (ADR-007)
评议已含方案的 doc (不是 open question). Phase 0 doc parser, Phase 4 评委拿 review-context. 三段式 report.
05 当前进展
已进入运营期 · v1.9.0 · 10 评审机器人 + 1 分身 + 运维管理台全部上线
大节点 (v1.1 → v1.9)
已 ship 多场景评审引擎 · v1.2 → v1.4
一套引擎多副面孔 (scene/panel loader) · 11 场景 (10 OP2 评审 + 竞赛) · 13 真名评委 + 通用虚拟各持 doctrine · 竞赛/公司级真打分 (100 分制 sum_max, 配置里的尺子真在量)。
已 ship 报告自动可视化 + 换模型工程化 · v1.5 → v1.7
评审跑完自动渲富 HTML/PDF (评分卡+评级带+维度×评委热力图) 回推飞书 · LLM provider 一键切换 + 飞书 /model 运维命令 · OP2 评分标准 v2 · tag 即 Release。
已 ship 锚点认知对话式分身 · v1.8
基于锚点 doctrine 的单视角代理 (锚点认知分身): 对话 + 文档评议 · 三档置信【有据/推演/存疑】anti-fabrication · T0/T1/T2 收件人分级 + 对外 fail-close 脱敏。
已 ship 运维管理台 + 遥测底座 · v1.9
登录后只读运维后台 (6 页: 总览/机器人/任务详情/用量/分身观测/日志) · fail-open 遥测底座只记元数据 · 两层访问控制 (零信任网关 + 应用密码) · Cloudflare Tunnel 永久访问。
关键能力维度的完成度
06 已做开发
v1.1 → v1.9 版本线 · 每版一句话 (详见 changelog)
版本线
v1.2–v1.3 多场景引擎
一套引擎多副面孔 (scene/panel loader) · 多场景 VM 联调闭环 · LLM provider 一键切换 + 接第三方模型四层韧性兜底。
v1.4–v1.5 真打分 + 换模型工程化
竞赛/公司级 100 分制 sum_max 真打分 · 报告"出厂铭牌" · CLI 菜单 + 短命令 llm + 网关模型列表 + 评测 harness + 飞书 /model。
v1.6–v1.7 自动可视化 + 多机器人加固
评审跑完自动渲富 HTML/PDF 回推 · 交付前来源脱敏 · OP2 评分标准 v2 · 多机器人回推缺凭据显式告警 · tag 即 Release · 10 评审机器人全上线。
v1.8 锚点认知对话式分身
锚点认知分身 (persona): 对话 + 文档评议 · 三档置信 anti-fabrication · 长连接异步 fast-lane · 灰度观测 · T0/T1/T2 分级 + 对外脱敏。
v1.9 运维管理台 + 遥测底座
fail-open 遥测底座 (SQLite, 只记元数据) · 管理台 6 页 · 两层访问控制 + Cloudflare Tunnel · 白名单文件读 + CSP sandbox + 安全审计。
累积资产
- 11 场景机器人 — 10 OP2 评审 (公司级 / DIG / SCG / TSG / 5 专项) + 1 锚点认知分身 · 各持 scene panel + 真名/虚拟评委 doctrine
- 13 真名 + 通用虚拟评委 + 6 维度评委 doctrine · 1 anchor (tian) + meta skills (orchestrator/failure-card/attribution/...)
- ~56,000 行代码 — Python 52.2k (scripts 36.4k / tests 15.5k) + shell/web · 1273 unit tests · 覆盖比约 42%
- 3 公开界面 —
www/handbook/(VitePress) +www/(changelog/index/overview) + 运维管理台 (登录后) · Cloudflare Pages / Tunnel - always-on 运营 — VM 上 boss-hermes (API + /admin) / boss-review-worker / boss-feishu-ws systemd 常驻 · 中国飞书 → 海外 VM OUTBOUND 长连接
07 剩余
v0.6/v1.2 工程清单已基本落地 · 真实剩余仅 4 项 (2 可开工 + 2 人/时间闸住)
可立即开工 (纯工程 · P2)
R13 第二锚点试点
多锚点架构 (ADR-001/002 B 档) 从未真实承载第二个锚点。走一遍"3 步加锚点" (sub-vault + SKILL doctrine + panel) 验证架构 + 补单测。
R11 attribution 自动 fetch
把 30/90/365 checkpoint 的 data_source (marsdata / feishu) 从 stub 接真, 让 checkpoint 自动拉信号验证判断, 而非等人工。对"判断可被验证"内核最直接。
人 / 时间闸住 (等触发, 非纯工程)
- R1 锚点 doctrine 本人签收 — 6 份心智模型已 agent 逆向合成 (provenance 标记 + confidence≤0.6), 剩锚点本人在使用中渐进 face-validity 签收 + 真实 holdout 历史决策回测 (≥2/3 方向一致)。本地语料 + 锚点参与。
- 90d 盲测执行 — 框架 M1 就绪 (
--lock-framework-prediction锁预判 chmod 444), 等 2026 H2 真议题触发即可锁定, 90 天后回测方法论。
08 运营节奏
已从"开发冲刺"进入"运营 + 按需迭代" · 6 月那份 M2-M7 排期已作废 (见 §7)
常态运营回路
- 评审 — 飞书发文档给对应场景机器人 → 6 段报告 + 富 HTML/PDF 自动回推 → 管理台看 token/花费
- 对话分身 — 锚点认知分身 (persona) 对话 + 文档评议, 灰度观测落盘, 管理台"分身观测"看有据率
- attribution — 30/90/365 checkpoint (cron), 到期拉信号验证判断 (自动 fetch 待接, R11)
- 发版 — conventional commits → changelog → 推
v*tag → CI 自动发 Release + Cloudflare Pages 重建 - 运维 — 管理台实时看 11 机器人在线 / 用量 / 日志; 飞书
/model热切模型不重启
下一步触发条件 (非日期驱动)
| 项 | 触发条件 |
|---|---|
| R13 第二锚点试点 | 决定引入第二锚点 (有真实语料) 时开工 |
| R11 attribution 自动 fetch | 想让 checkpoint 免人工时开工 (纯工程) |
| R1 锚点 doctrine 签收 | 锚点本人在使用中渐进签收 (递延回路) |
| 90d 盲测执行 | 2026 H2 真议题触发 → 锁预判 → 90 天后回测 |
09 自动化开发的建议
让"工程化"再降一层 · 减少手工动作 · 减少漂移
已落地的自动化 (基线, 不要倒退)
✓ pre-commit 5/5 闸
redact_check (脱敏) · skill_lint · case.json schema · 飞书抓取工具 frontmatter · versions/ 不可变. 任一不过阻断 commit.
✓ GitHub Actions
docker-build · attribution checker (cron) · handbook deploy (Cloudflare Pages) · sitemap 自动更新.
✓ sage-wiki watch + ingest
raw/* 任何新文件入库 → entities/people/concepts 自动重编 + Related Judgements 自动追加.
✓ feishu-sync-watch + filter
飞书全量备份 → 三通道过滤 (结构化/文本/LLM 兜底) → anchor raw 自动入仓 · cron 触发.
建议加上 (按 ROI 排序)
A · 高 ROI · 1-2h 可落
A1 Codex CLI handoff pattern 固化
把 06-08 用过的 "Codex 审 → Claude 写交接 doc → Claude Code 执行" pattern 写成 SKILL: /code-review-handoff. 每个 sprint 末跑一次, 自动产出 P1/P2/P3 任务书 (像本次 dev-log 那种)。
A2 pytest 在 pre-push 跑
当前 pre-commit 只 lint, 测试要手跑. 加 pre-push hook 跑 pytest tests/unit -q --maxfail=3, 不过不让 push. 防止误 push 把 main 跑挂。
A3 dev-log auto-skeleton
Session 结束时 /dev-log-close 命令: 读 git log + diff stats + pytest 结果 + 上次 dev-log §8 建议 → 套模板自动起本次 §1-7 框架, 你只填 §3 关键决策 + §8 下次建议。
A4 changelog 自动起 entry
每周一从 conventional commits 自动生成 changelog draft (按 fix/feat/test/docs 分组, 链 PR), 人工编辑后 publish. 不要让 changelog 漂 (本次 06-02 ~ 06-09 漂了一周)。
B · 中 ROI · 半天-1天落
B1 Failure Card 自动起草
Attribution checker 发现 falsified → 自动起 FC-YYYY-NNNN draft, 按 6 类分类启发式归一类 (现有 classify_failure 模块), 人工只决定 confidence + 修复方向。
B2 EVOLUTION 自动建议
Failure Card / Wiki 一侧重大更新 (sage-wiki 检测 entities 修订) 时, 飞书 push "建议对 X brand 跑 EVOLUTION", 用户一键触发。
B3 文档新鲜度 audit
Cron 比对 docs/internal/PRD_* 修订日期 vs git log, 漂 > 30 天的 PRD 段飞书提醒. 配合 ADR-009 三件套异步签流程。
B4 handbook-src 自动 publish
handbook-src/* push → GitHub Action 跑 check_public_safe.py + redact_check.py → 双闸通过自动 npm run build → 推 Cloudflare Pages. 现在还是手跑。
C · 探索性 · 长周期
C1 议题 router 自动判别
用户飞书提议题 → LLM 自动判 strategic/customer/product/org/financial/cross_domain → 自动选 panel + 调研维度. 现需手指定 --panel.
C2 anchor_delta 历史分析
跨 50+ 议题统计 anchor_delta 分布, 发现"某维度系统性比 anchor 乐观" → 反过来校准 dim 评委 doctrine. 这是 doctrine 漂移检测。
C3 Skill quality_tier 评分
每月跑一遍 skill_lint --rubric, 自动算 Skill 质量分 → SuperIntern 看分排队改 doctrine. 现 quality_tier 是手填。
C4 mind 活体 / Sponsor Agent
M3 / M4 落地后, Sponsor 自动收到自己议题相关的 30d 信号 + 反方观点 + 跨议题模式. 这是 mind v2.0 方向, 不是 boss.
不推荐做的自动化 (反模式)
- 不要让 Wiki "整合"同一公司的多次判断 — 它们的差异本身就是数据 (CLAUDE.md §3.3)
- 不要把 case.json ingest 进 Wiki "图方便" — 违反 §2.1 ignore 边界, 这是设计原则
- 不要让评委读其他评委的 review — 独立打分是 panel 设计的核心
- 不要给 versions/v{n}_*.md 加任何"修订"机制 — EVOLUTION 模式产生 v{n+1}, 永远不动 v{n}
- 不要让 LLM 自动跳过 GATE 1 — Phase 2 派发 5 sub-agent 成本不小, 方向跑偏后果重