判断的解剖学 · 锚点 Skills 三层结构互动信息图

把"判断"这件被认为不可工程化的事拆成三层结构: (1) 锚点本人的心智模型与表达 DNA · (2) Wiki 沉淀的实体 / 人物 / 概念档案 · (3) Agent 流水线如何把上面两层组合起来代他打判断。本页以脱敏方式展示方法论本身, 不含具体客户 / 项目 / 财务数字。
vault · v3.1.1
release · v0.2.1
sensitivity · public
license · 方法论描述
Q1 · 核心判断逻辑

锚点判断时, 脑子里跑的是什么算法?

3 个心智模型 + 5 个打分镜头 + 一条 anti-fabrication 红线。判断 ≠ 直觉, 判断 = 触发-阈值-行动 + 跳步识别 + 反方排除, 跑完一遍才落笔。
Q2 · Wiki 的维度

Wiki 到底沉淀了什么? 不沉淀什么?

3 类档案: entities (公司) / people (人物) / concepts (概念框架)。Wiki 是被 ingest 出来的"背景", 不是判断本身; 判断在 reports/, 单向引用 Wiki。
Q3 · Agent 怎么代判

Agent 不是锚点, 凭什么打他的判断?

6 阶段流水线 · 7 调研维度 · 1 anchor + 6 维度评委合议。Agent 不替锚点打分, 它输出 anchor_delta = 评委 − 锚点, 让锚点自己反思跳步。
JUMP TO §1 · 核心判断逻辑 §2 · Wiki 维度与内容 §3 · Agent 代判机制

SECTION 1 锚点判断的核心逻辑 3 心智模型 · 5 打分镜头 · anti-fabrication 红线

1.1 · 三个心智模型 (点开看例子)

MODEL 01

触发-阈值-行动

不在抽象状态做决定, 必须具名触发。
公式
具名触发事件 (谁/何时/做了什么) + 量化阈值 (什么数字达到 X) → 执行什么动作
反面教材 (Skill 检测后会暂停)
"市场存在品牌混淆", "客户感知不清晰" — 没有具名触发的抽象状态, 不能作为判断起点。 Skill 检测到这种 PRD 直接回 "请提供至少一个具名触发事件" 暂停。
在 Skill 里的落点
Phase 1 Step 1.3 触发事件具象度检查 · 检查失败即暂停, 不硬继续。
MODEL 02

跳步识别

显式标"比表面权重更看重的证据"。
公式
列出表面的证据权重 → 显式标记我实际给的权重 → 差值 = 跳步。跳步本身是数据, 不是错误。
举例
"6 个维度的调研显示战略方向都对, 但客户当面一句反馈让我心证从 7 跳到 4。" — 这种"客户当面 > 调研报告"的权重跳步必须写出来, 否则 reviewer 看不到决策的真实结构。
在 Skill 里的落点
Phase 3 Synthesis 必含 "Leverage Map" — 列出每个变量的权重 + 数据源, 让跳步显式可见。Phase 4 evaluator 镜头 #1 (Reasoning Soundness) 检查是否有未标注的跳步。
MODEL 03

反方排除

心理已排除的选项也写出来, 标清楚理由。
公式
列出 3-5 个反方主张 → 对每个写出排除理由 → 留下未排除的当作真正在赌的命题。
陷阱 (反方写得太弱)
"反方主张: 也许可以不做" — 这是稻草人, 不是真反方。真反方应该是 "X 公司 2024 同样情况下选了 B 方案, 一年后业绩 +30%, 我们凭什么这次选 A?"
在 Skill 里的落点
每位维度评委 review 必填 adversarial_view 三字段 (if_thesis_wrong / contrary_signal_observed / base_rate_warning), skill_lint 阻断 commit。详见 §3 末尾。

1.2 · 五个打分镜头 (点 / 悬停五角看每个镜头打什么)

5 镜头 所有评委共用 推理一致 Reasoning 证据耦合 Evidence 反方处理 Counter 可证伪性 Falsifiability 现实韧性 Resilience

① Reasoning Soundness · 推理一致

问: 这判断从证据到主张的 Trace 是否自洽? 有跳步未标注?
9-10覆盖 PEST 3 层以上, 跳步全部显式标记, 同类历史 base rate 已对照
6-8主体推理合理, 但 1-2 个权重跳步未标记 (例: "我比较看重客户当面反馈" — 没说原因)
≤ 5结论与证据之间有未连接的环节; 或推理只依赖单一框架 (上限 6 分)
// 锚点视角偏重 · 评委身份: tian + 6 dim 全员适用 · doctrine 锚: PEST / Toulmin 论证结构

Anti-fabrication 红线 · 锚点视角的最大护栏

  • 不替锚点编造他没公开说过的话 — 引用必须 anchor 到具体 source (访谈日期 / Wiki link / 飞书文档)。
  • 不为他设想没表达过的内心戏 — 推论 ≠ 引用, 任何"锚点会觉得..."必须落到他公开过的同主题判断片段。
  • 不引用未来事件 — 包括尚未发生的会议 / 尚未签署的合同 / 尚未公布的数字。
  • research 材料不足时降低 confidence — 而不是补足, 在 review 中明确写「超出已知材料」并把 confidence 上限压到 0.5。
  • 议题与锚点公开判断领域无交集时拒绝打分 — 写 out-of-scope, declined, 不打分。

SECTION 2 Wiki 的维度与内容 3 类档案 · 31 entries · 编译产物 · 单向被引

2.1 · 三类档案 (点卡片切样本)

entities

实体 · 公司 / 组织

13
客户 / 竞品 / 合作伙伴 / 关键供应商, 凡是议题中出现的具名组织都建档。
某安全集团 · 某 AI 巨头 · 上游云厂商 · MDR 友商 ...
people

人物 · 决策者档案

6
锚点自己 + 关键 stakeholder (客户 CTO / 合作方负责人 / 高管)。注意: 在 Wiki 中只存公开身份, 私人信息严格不进。
锚点 (anchor) · 某客户 CXO · 某事业部高管 ...
concepts

概念 · 框架 / 方法论

12
锚点用过 / 在主张过 / 决策跳步常引用的概念。判断中以 [[_wiki/concepts/X]] link 引用, 不复制内容。
班委制 · 跨越鸿沟 · 卖 IQ · AI native · 涌现驱动 · 信任办公室 · 完整产品 ...

2.2 · Wiki ↔ MBA 的单向引用 (CLAUDE.md §3)

Wiki 与 MBA 是父子结构, 不是兄弟。信息流单向: raw/ → Wiki → reports/。 判断不进 Wiki — Wiki 只 ingest raw/ 原料, 不读 reports/ 正文 (仅由 sage-wiki 读其 metadata 维护反向链接)。 这条边界是设计原则, 不是性能优化: 把判断回灌进 Wiki 会破坏版本快照的不可变性。
RAW/ (源) tian-interviews/ feishu-laotian/ flomo/delta/ clippings/ market-reports/ 所有外部素材入口 (sage-wiki watch) ingest build_wiki.py _WIKI/ (编译产物) entities/ · 13 people/ · 6 concepts/ · 12 log.md (append-only) sage-wiki 全权 + 唯一写者 MBA 层 read-only 31 entries · alias 匹配 · 反向链接 markdown link 不复制内容 REPORTS/ (判断) <brand>/report.md versions/v{n}.md reviews/<judge>.md panel.yaml MBA Skill 全权写 version 冻结 · 永不可变 Phase 1 Context 段引用 Wiki 只读 metadata · 自动维护 Related Judgements 边界纪律 ❌ Wiki 不读 reports 正文 ❌ 判断不进 Wiki ❌ 评委不互读 ❌ versions/v{n} 不可改 违反任一 → skill_lint 阻断 commit。CLAUDE.md §2 + §3 设计原则, 不是性能优化

2.3 · Multi-anchor 架构 · anchors/<slug>/ 为每位老板隔离 (v0.2.1 · ADR-001/002)

从 v0.2.1 起, vault 引入 anchors/<slug>/ 子目录, 把per-anchor 数据 (该老板的 raw + perspective doctrine) 与通用 boss-skills (Phase 0-5 流水线 + 6 维度评委 + 5 镜头) 物理解耦。 一个 vault 可同时持有多个老板的判断系统, 互相隔离。
通用 SKILLS/ (锚点无关) skills/tian/ · /boss entry skills/tian-judgement-orchestrator/ skills/<6-dim>-perspective/ skills/laotian-adapter/ 开源 boss-skills 的"产品代码" 所有老板共用 Phase 0-5 · 评委 · 反方 · attribution 配置 (绑定) config.yaml anchor.slug: tian perspective_skill: ... panels/default.yaml anchor_slug: tian skill_path: anchors/tian/... 通用 ←→ 锚点的唯一绑定 /boss --panel <name> 切换 ANCHORS/ (per-anchor 数据) anchors/tian/ ← 默认锚点 perspective/SKILL.md (doctrine) raw/{interviews,feishu-laotian}/ anchors/<new-slug>/ ← 加新老板 ↑ 复制结构 3 步即可 每个老板的数据互相隔离, gitignored 默认 仅 README + perspective SKILL.md 入 git "建任何老板的知识库" 的承诺落点

SECTION 3 Agent 如何代替锚点打判断 6 阶段流水线 · 7 调研维度 · 1 + 6 评委合议 · anchor_delta

3.1 · 流水线 6 阶段 (点 phase 看输入 / 输出 / 时长)

每次 /boss <议题> 调用都走完 Phase 0 → 5 (FRESH 模式) 或 Phase 0 + 1E + 2E + 4E + 5E (EVOLUTION 模式)。每个 Phase 有明确的 input / output / gate / 失败模式。
PHASE 0
Router
~ 5s
PHASE 1
Context + PRD
2-5 min
PHASE 2
Parallel Search
8-15 min
PHASE 3
Synthesis
3-6 min
PHASE 4
Panel 打分
5-10 min
PHASE 5
Merge + Version
1-2 min

3.2 · 三层调用结构 · 不要混淆

7 调研维度 ≠ 6 评委维度 ≠ 5 镜头。这是 v3.1 反复纠正的概念错位 (CLAUDE.md §5.5)。 7 调研维度负责"采集什么"; 6 评委维度负责"如何评估"; 5 镜头负责"评估按什么尺子打分"。三层职责清晰, 不要做矩阵相乘。
第 1 层 · 采集 第 2 层 · 合成 第 3 层 · 评估 第 4 层 · 合议 7 调研维度 (并行 sub-agent) ① 触发事件链 (events & timing) ② 关键变量与阈值 (variables) ③ 法律/协议约束 (legal-constraints) ④ 客户感知信号 (customer-signals) ⑤ 竞品玩家动作 (competitor-moves) ⑥ 内部资源约束 (internal-resources) ⑦ 外部时机窗口 (external-timing) 每个 sub-agent 输出 raw_evidence/dim_n_*.md "采集什么" Lead 读所有 raw synthesis.md Executive Summary Leverage Map Fragile Edges Cross-dim Conflicts Citation Index 7 → 1 合成 广播 广播 锚点 (anchor) 心智模型 · 触发-阈值-行动 行业趋势 · PEST/Porter 战略目标 · 黄金圈/Rumelt 客户战略 · JTBD/ICP 产品战略 · BMC/Lean 组织战略 · 7S/Beer 经营战略 · Unit Econ 议题自动选 3-4 个上场 独立打分 · 互不可见 panel_summary dim 加权 anchor (锚点) anchor_delta 见 §3.4 5 镜头 (固定打分尺, 所有评委共用) ① Reasoning Soundness · ② Evidence-Thesis Coupling · ③ Counter-position Treatment · ④ Falsifiability · ⑤ Real-world Resilience

3.3 · Panel · 1 anchor + 6 dimension 评委 (点星座看 doctrine)

Anchor 评委 (锚点, 始终在场) 不参与维度加权, 只输出自己的"心证"作为基准。 6 位维度评委按议题类型 auto-select 3-4 位上场。两条隔离: anchor 用 mental_models, dim 用 doctrine, 互不读对方框架。
锚点 anchor 行业趋势 PEST / Porter 战略目标 黄金圈/Rumelt 客户战略 JTBD / ICP 产品战略 BMC / Lean 组织战略 7S / Beer 经营战略 Moat / LTV-CAC

3.4 · anchor_delta · 把"评委 - 锚点"显式化 (拖滑块或选预设)

Phase 5 不输出一个最终分, 而是输出两个分 + 一个 delta。这是项目的核心反共识: Agent 不替锚点打分, 它输出"自己的视角 − 锚点的心证"作为镜子, 让锚点反思自己有没有跳步未自知。|Δ| > 2.0 时飞书卡片高亮。
dim 加权 − anchor (锚点) = +0.05
+0.05
−3.0−2.0−1.00+1.0+2.0+3.0
锚点比维度评委更乐观 (Δ < 0) 对齐 (|Δ| ≤ 0.5) 维度评委比锚点更乐观 (Δ > 0)

3.5 · 反方机制内化 · 每份 review 必填 adversarial_view 三字段

CLAUDE.md §4.5: 反方不设独立"adversary 评委", 而是把反方机制分布式内化到每位维度评委的 review。三字段必填, 缺一字段 → skill_lint 阻断 commit。
FIELD 01
if_thesis_wrong
"如果本维度判断错了, 哪一环最脆弱?"
强迫评委把"我可能错"的具体环节写出来。一句话, 不能含混。例: "假设客户 CTO 留任, 但 12 月底他换人, 整个组织战略前提作废。"
FIELD 02
contrary_signal_observed
"近期观察到的反向信号?"
必须带 source (URL / Wiki link / 访谈引用)。没有反向信号也要写"未观察到", 不能空。例: "竞品 Q1 财报披露同一战略后 6 个月流失 18% 客户 [source]"。
FIELD 03
base_rate_warning
"同类决策历史 base rate?"
把"这次不一样"放回历史里检验。例: "B2B 子品牌隔离 5 案 base rate: 3 成成功, 7 成被合并回主品牌。这次的特殊性需要解释为何不在 7 成里。"