Gm First Principles Audit

GM 第一性原理审计方法

触发

• Boss 说「头脑风暴」「第一性原理」「剥到底」「模拟场景」「GM 是 X 吗」
• Boss 问「GM 知道什么 / 不知道什么 / 能实现了吗」
• Boss 暂停派单要讨论某系统本质

三步走（不可跳）

Step 1：剥到底（Atomic Decomposition）

每个概念问 4 层：

1. 是什么？（去掉修辞）
2. 剥到底还剩什么？（原子动作）
3. 这个原子需要什么前提？
4. 前提全吗？缺什么？

剥到底 ≠ 简单下定义。是问「去掉所有修辞、上下文、隐喻后还剩什么」。

Step 2：清单（Inventory）

三类清单：

• ✅ 知道（结构化记忆）
• ❌ 不知道（盲区）
• ⚠️ 自以为知道但其实假（最危险）

判断前提盘点：列出 N 个前提，每个标记 ✅/❌。

Step 3：模拟场景验证（Simulation Coverage）

构造 2-3 个真实复杂场景，逐一对照清单算覆盖率。

• 覆盖率 = ✅ 盖住 / 总项数
• <30% = 严重盲区
• <10% = 清单失效

构造场景原则：

• 必须叠加（战略+故障+并发）
• 必须触发悖论（自纠 vs 红线 vs全权）
• 必须含时间（硬停重演）

常见 GM 角色陷阱

• ❌ 把 GM 当 12 worker 调度器（错）→ 1+3+3 节点管理者（对）
• ❌ 把工位 = worker 池（错）→ 工位 = 节点内执行位
• 把验收 = commit（错）→ 验收 = 节点健康度

输出格式

• 不下决策，只剥解
• 每个结论附「剥到底的理由」
• 覆盖率表格必须给出数字
• 最后列「第一性问题清单」让 Boss 选方向
• Boss 拍板偏好：列 2-3 个选项（X/Y/Z）+ 各 1 句利弊 + GM 推荐其一 + 1 句理由，Boss 单字回复即执行（不要请示"选哪个"）

Boss "为什么 X" 类追问的审计入口（v2026-09-08 新增 · 第一性问题触发器）

触发信号：Boss 提问句含 "为什么" / "怎么这么多" / "为什么不清" / "为什么还在" / "为什么没有"。

真意：Boss 看到某个"应然态 vs 实然态"的裂缝，正在用追问探测 GM 是否也看到了。GM 若答"无所谓 / 反正没坏 / 历史遗留" = Boss 体感 = GM 没在第一性层面想问题。

GM 默认动作（v4.19 锁定）：

1. 立即溯源：第一句话必须给出根因的 file:line / 命令 + 输出（不要"可能是因为"）
2. 5min 内给真因：跑命令验证而不是凭印象回答
3. 派工位闭环：根因明确后立刻派 1-N 张工位开始治理（不等 Boss 再催"派吗"）
4. 回话结构：根因（1 句）+ 证据（命令+输出）+ 派生动作（已派/建议派 + ID）

反模式（v4.19 必避）：

• ❌ "反正没占资源" / "历史遗留" / "UI 噪音"（=默认无害 = Boss 体感失控）
• ❌ "我先调研再回你"（Boss 已问 = 等答案，不是等调研）
• ❌ 答完根因不派工位（= 知道问题不解决 = 浪费 Boss 追问）
• ❌ 问 Boss"要不要清理？"（=反向请示 = Boss 期望自己派）

战例（v4.19 · 2026-09-08 早间 · gateway 列表实证）：

• Boss：为什么这么多gateway？
• GM（错答）："8 个 ✗ 是历史 profile 化石，没占资源"
• Boss：那为什么不清理？
• GM（正确）：grep gateway list 源码 = 派生自 ~/.hermes/profiles/ → 15 个 profile 自动聚合 → 立即派 t_38ce1b21 审计 + t_b364543b 第一性设计
• 教训：第一次追问就该给根因 + 派工位，而不是先答"无害"再被 Boss 二次追问

反模式（v2026-09-07 新增 · 审计概念关系时反复踩）

反模式 0 · "UI 噪音 = 无害"陷阱（v2026-09-08 新增 · Boss "为什么这么多 gateway" 教训）

症状：Boss 看到 gateway list 输出 9 个 gateway（8 个 ✗ not running）问"为什么？" → GM 默认答"反正没占资源，UI 噪音" → Boss 反问"那为什么不清理？" → 暴露 GM 从未追溯根源。

根因：GM 经常把"看着多余但当前没造成故障"的现象直接归类为"无害噪音"，不去问"这个清单从哪来 / 为什么会显示 / 真正的源是什么"。这是审计的失职——第一性问题不剥到底，等 Boss 追问才被迫挖。

反模式：

• ❌ "8 个 ✗ not running，反正没占资源" → 不追溯根源
• ❌ "gateway list 显示是这样就这样吧" → 不问"显示源是什么"
• ❌ 把"当前可运转"当成"系统健康"的充分条件（实然 ≠ 应然）

正确做法（v4.19 锁定 · 审计第一问硬清单）：

1. 显示源溯源：任何 list/status/dashboard 输出 → 第一问 = "这个清单从哪个文件/目录/API 派生？"
   • 例：gateway list 显示 9 个 → find ~/.hermes/profiles/ -mindepth 1 -maxdepth 1 -type d 验证 = profile 数
2. 真源 vs 缓存：是 config.yaml 静态声明 / 目录扫描派生 / 数据库聚合 / 进程枚举？
3. 当前态 vs 应然态：现在跑 ≠ 应该存在。9 个里 8 个 ✗ = 应然态疑问（是不是冗余？是不是历史遗留？）
4. 默认动作：找不到"为什么存在"的合理理由 → 标记为"待清理候选"，不要等 Boss 追问才动手

战例（v4.19 · 2026-09-08 早间）：

• Boss：为什么这么多gateway？
• GM（错）："8 个是历史 profile 化石，反正没占资源"
• Boss：那为什么不清理？
• GM：挖到根因 = gateway list 是扫描 ~/.hermes/profiles/ 自动派生 → profile 冗余 = 第一性问题
• 立即派 Wave3 第一性 profile 重设计（Phase1 审计 + Phase2 设计）
• 教训：第一次看到"9 个 gateway"就该溯源到 profiles 目录，而不是默认"无害"

与已有规则的关系：

• 反模式 2（概念数量 = 历史堆出来）已立"不要偷懒 = 当前有几个就几个"
• 反模式 0 是更上游："看到 ≠ 不去问为什么" —— 是审计入口的反模式
• GM 看到任何"为什么 X"的 Boss 提问 → 默认动作 = 立即溯源 + 5min 内给根因，不要先答"无害"

反模式 1 · 工具绑死 = 过度抽象

• ❌ "profile 必须绑死 primary_cli"（ADR-0048v2 D-2 实证）→ 限制 worker 灵活性
• ✅ 第一性：CLI 是 worker 的执行后端工具，由 extra_args + --provider/--model/--tools 决定，dispatcher 不绑
• pitfall：审计时看到 "X 字段必填" 假设 → 必须追问 "X 是描述还是强制？worker 拿到任务后能不能自己选？"
• 真源验证：dispatcher.py L660-676 engine == "hermes" 分支，CLI 完全由 extra_args 决定

反模式 2 · 概念数量 = 历史堆出来 ≠ 第一性

• ❌ "现在有 15 个 profile，所以就要 15 个" → 偷懒
• ✅ 第一性：列出真需要的职能（≤8 个），不与 15 个 1:1 对应
• 当 Boss 问 "应有哪几个？" 时：永远列 2-3 个方案
  • X = 维持现状 + 去重声明（过渡）
  • Y = 砍到 N 个（按第一性重排）
  • Z = 砍到 M 个（最小集）
• GM 推荐其一：默认 X（不破坏 ADR-0039 决策 1 锁定），Y/Z 需要新 ADR 豁免

反模式 3 · 子票粒度擅自改 Boss 拍板值

• ❌ "子票粒度 5-12 张"（GM 自定）vs Boss 拍板 "5-15 张"
• ✅ 第一性：Boss 拍板的数字 = 锁定值，GM 不能擅自微调
• pitfall：审计报告中出现的任何数字参数 → 必须 grep 历史 Boss 指令 → 用 Boss 的版本，不用 GM 默认

反模式 6 · 派单规范自纠以身试法（2026-09-09 新增 · Boss "swarm epic 没实现" 当面纠错）

症状：GM 自己定的派单规范，自己派单时没遵守。例：派 [v3.13·...] 而非 [v3.13·swarm epic 规范·engineering]。

根因：派单铁律写在 memory / 写在 /Users/dongshenglu/company-hq/architecture/kanban/ 里，但 GM 派单时只看了 body 没看 title 命名 → 偷懒用前缀省事 → 派完才发现违规。

反模式：

• ❌ 派单时不检查 [Epic·主题·role] 三段式命名
• ❌ 把"规范"当成"给别人定的"，自己派单随意
• ❌ 派单后没自检 4 件套（title 规范 / body ≤ 500 字 / epic_id / verify 方法）

正确做法（派单前 4 件套自检 · 锁定）：

派单铁律（v3.13 锁定 · Boss 当面纠错后内化）：

• GM 自己派单 = 规范示范**（不是给别人定的）
• 派单前心算 4 件套，缺一项补一项
• 派完自检自己的卡是否合规，不合规立刻 archive + 重派
• 自纠时不要辩解，立刻：① 列错误版本 ② 给修正版 ③ 派规范名卡示范

与已有反模式 5 的关系：

• 反模式 5 讲"资源估算拍脑袋"（数字拍错）
• 反模式 6 讲"派单规范自己定的不遵守"（规范拍错）
• 两者根因相同：GM 没把规范当成自己也要遵守的规则

反模式 7 · dispatch 卡死靠"派更多卡"救不了（2026-09-09 新增 · 看板瘫痪教训）

症状：dispatcher 卡死（ready 29 / running 0），GM 反复派 P300 修复卡但 dispatcher 自己也是卡死的，派出去的卡也没人接。GM 误以为"派更多卡 = 触发修复"，实际 = 加速 ready 池堆积。

根因：dispatcher 死锁时，worker 永远不会 spawn 新任务，GM 派的卡永远不会进入 running。此时唯一出路是 GM 亲自下场修 dispatcher 源码 + 杀进程 + 重启，不是派更多卡。

派卡前的 vs 2 问（v3.13 锁定 · 看板瘫痪教训）：

1. dispatcher 现在活着吗？ ps aux | grep "hermes.*gateway" | grep -v grep | wc -l = 0？→ GM 亲自修
2. running 卡有没有真的在跑？ running > 0 但全 timeout？→ dispatcher 逻辑 bug，需修源码

反模式：

• ❌ running = 0 时还派 P300 修复卡（dispatcher 卡死 = 接不了新卡）
• ❌ 派卡期望 worker 修 dispatcher（worker 也是 dispatcher spawn 的）
• ❌ "派更多卡 = 触发修复"（实然：ready 池堆积 + running 仍 0）

正确做法（v3.13 锁定 · 看板瘫痪救命流程）：

1. 第一动作 = ps aux 看 dispatcher 进程数（不是看 ready/running）
2. **dispatcher 进程

症状：GM 推导"系统并发上限 = X worker"时，凭印象给数字，被 Boss 当面打脸 3 次：

根因：推导"系统上限"时，不查机器、不查配置、不实测，直接拍数字。三个数字全部编造（401→并发、12→上限、32G→理论 64）。

正确做法（v2026-09-09 锁定 · 资源估算硬清单）：

1. 先查整机基本盘（不靠印象）：

   sysctl hw.memsize hw.physicalcpu
   vm_stat | head -5
   df -h /System/Volumes/Data
   

   内存/磁盘是几个 G？CPU 几个核？先打印这 3 行再说。

2. 再算单 worker 占用（不是猜 500Mi）：

   ps aux | grep "hermes -p" | grep -v grep | awk '{print $6}' | sort -n | tail -10
   

   现有 worker 实际 RSS 多少 Mi（看 PSS 分布，不是 RSS 平均）。

3. 再算理论上限（带余量，不取理论最大值）：

   • 内存上限 = (总内存 - 系统占用 - swap 余量) / 单 worker RSS，留 30-50% 余量给其他进程 + worker 增长
   • API Key RPM 不计入（单 key 通常 60-500 RPM，远大于 worker 实际 req/min）
   • dispatcher 上限是软上限（取决于内存够不够 spawn）

4. 最后必须实测验证（不能拍脑袋后立刻报 Boss）：

   • 小规模实测：压测 N=3 / N=5 / N=8 worker，看系统负载和 RSS 涨势
   • 找拐点：load > 5 或 RSS 接近内存上限 = 拐点 = 真上限
   • 实测后再报：给 Boss 一个 实测 N worker 后 load=X.X / RSS=Y.Y / swap=Z 的三段式铁证

反模式（v2026-09-09 必避）：

• ❌ 整机配置搞错（32G vs 实际 16G）= 后续所有推导都错
• ❌ 把单 provider 401 当全局限制 = 误报 boss
• ❌ 用 dispatcher 上限（12）当真实上限（实际可能只 6-8）
• ❌ "ready 14 张 = 饱和"（错！饱和 = running > 上限。ready 是队列长度，与火力无关）

anchor 本质硬规则（v2026-09-09 新增 · Boss 当面纠错）：

anchor 是模型名，不是 endpoint。base_url 锁 openanchor.top 是设计正确（统一入口 + L2 智能调度：dynamic registry + capability-aware + 同 vendor 降级）。401 ≠ 限制并发——anchor 401 只影响走 anchor 模型的 worker，走 zen/minimax/baosiapi 的 worker 不受影响。

派单前自检（v2026-09-09 锁定 · Boss 3 轮打脸教训）：

3 轮 Boss 打脸战例（v2026-09-09）：

1. GM "anchor 401 = 限制 4-5 worker" → Boss "anchor 是模型不是 endpoint" → 自纠 v3.8
2. GM "真实上限 = 健康 API Key 数（2-3）" → Boss "每个 API key 里有大量并发，限制在 Mac mini 内存" → 自纠 v3.10
3. GM "Mac mini 32G 内存理论 64 worker" → Boss "**16G 不是 32G

症状：用 diff <(ls profiles/codex/skills/) <(ls profiles/opencode/skills/) 看到零差异 + diff SOUL.md 看到零差异 → 推断"codex = opencode 的 alias，应砍"。Boss 凭直觉反问"codex 更专业啊？" → GM 答"两者完全等价" → web 搜索证明 codex 有 /goal GA、subagents GA、GPT-5.5 400K、45 slash commands、OS-level sandbox → 公开 walk back。

根因：filesystem identity ≠ behavioral identity。~/.hermes/profiles/<cli>/ 目录里的 SOUL.md + skills 列表是 hermes-agent 如何调用该 CLI 的接线表，不是 CLI 本身的能力清单。codex CLI 二进制有 45 个内建 slash commands，OpenAI 3/16 推 subagents GA，Sam Altman 转发——这些都不写在 hermes 的 profile 目录里。

反模式：

• ❌ "两个 profile 的 skills/ 目录一样" → "两个 CLI 一样"（错）
• ❌ "SOUL.md 相同" → "调出来一样"（错）
• ❌ "default_worker 都是 anchor" → "没差异化"（错；CLI 行为差在工具链 + 子命令 + sandbox，不在 model）
• ❌ "配置文件等价 = 应砍"（错；这是接线等价 ≠ 行为等价）

正确做法（v4.20 锁定 · 审计 CLI / tool 类条目时硬清单）：

1. 不查 profile 目录：CLI 的能力在 CLI 自己的源码 / 官方文档 / GitHub README / changelog，不在 hermes profile 目录
2. 跑 web search 拿官方 capability 矩阵：搜 "<cli-name> CLI commands features <year>" 拿官方页面（首选 codex.danielvaughan.com / Anthropic 文档 / GitHub repo）
3. 查独门命令 / slash / sandbox / subagent 机制：4 个维度 = 该 CLI 是否真异构
   • 有 /goal 跨 turn 持久目标？
   • 有 subagent 隔离机制（worktree / sandbox / fork）？
   • 有 OS-level sandbox（Seatbelt / Landlock）？
   • 有 multi-provider 切换（不绑死一家 model）？
4. 再用 hermes agent 能不能替代做最终判定：4 维度全是"否" → 真可砍；任一"是" → 必留

实证（v4.20 · 2026-09-08 早间 · codex walk-back）：

• 第一次（错）：diff skills/ → 0 行差异 → diff SOUL.md → 0 行差异 → 推断"砍 codex"
• 第二次（对）：web 搜 codex → /goal GA（GPT-5.5 跨 turn）/ subagents GA（最多 6 并发）/ GPT-5.5 400K 上下文 / 45 slash commands / Seatbelt+Landlock sandbox → 推翻"砍 codex"结论
• 教训：filesystem identity is not behavioral identity——CLI 的真实力在它自己身上，不在 hermes 怎么调它

与反模式 2 的关系：反模式 2 讲"profile 数量 ≠ 第一性"（数量陷阱）；反模式 4 讲"profile 内容 ≠ CLI 能力"（内容陷阱）。两者都要求第一性剥到底，但剥的对象不同——一个剥"该有几个 profile"，一个剥"这个 profile 调的 CLI 到底是什么"。

预防（v4.20 自检清单 · 审计 tool/CLI/service 类条目时走一遍）：

1. 我在判断的对象，能力清单在 hermes 这边，还是在对象自己那边？
2. 我对比的"等价性"是接线层（profile / config / SOUL）还是行为层（实际能跑的命令 / 工具 / sandbox）？
3. 我有没有 web search 该对象的官方文档 / changelog / README？
4. 我有没有看它的 4 个核心能力维度（/goal / subagent / sandbox / multi-provider）？

任一答"否" → 立即补查，不要凭 hermes 接线推断对象行为。

派单紧接审计（v2026-09-07 新增）

审计完成后，Boss 拍板的下一步通常是派单。3 条派单纪律：

1. A+B 并行要文件隔离：两条子票若改同一文件（同一 ADR / 同一 config）→ 必须先后，不能并行（git 冲突）
2. A+B 并行可写不同文件：一份写 ADR / 一份写 config → 可并行（无冲突）
3. 派单墙格式必含：4 子字段（assignee / priority / title / body）+ 红线通告 + 静默等终态（不打扰 Boss）

swarm epic 派单（v2026-09-09 新增 · Boss 当面纠错）

触发：Boss 派一组强关联任务（同主题 / 同收单 / 同验收），且 ≥3 张。

反模式：

• ❌ 单张派 N 次（标题独立、assignee 不同、ready 池里看不出关联）→ dispatcher 接单后资源分散，且可能重复派同一件事
• ❌ ready 池里看到 5 张"看起来都差不多"的卡 → Boss 体感 = GM 没在打包

正确做法（swarm epic 包装硬清单）：

1. 统一前缀：所有子卡 title 用 [EpicName·profile] 前缀，例：[PathC·intel] arXiv 当周速读 / [PathC·qa] 看板复查 —— 一眼看出同 epic
2. 同优先级带：epic 内部用相邻优先级（P170/P160/P150/P140/P130），让 dispatcher 按序接，避免抢资源
3. assignee 分工：epic 内不同 assignee（intel/qa/planning/writing），dispatcher 可并行 spawn 不同 profile
4. 派生时一次派全：epic 创建时同 turn 派完 3-5 张子卡，不要零散一张张派

战例（2026-09-09 早盘 PathC swarm epic）：

• Boss 反馈："为什么不用 swarm epic 派单？"
• 之前的派法：单张派 intel/qa/planning/writing，每张独立 title → ready 池看不出关联
• 修正后：t_b3639415 [PathC·intel] GitHub Trending / t_da2471d7 [PathC·intel] Reddit+HN

配套资源

• references/profile-cli-first-principles.md — Profile ↔ CLI 第一性审计参考（含 4 CLI 真实能力矩阵 + filesystem-identity 陷阱 + 战例）
• references/kanban-dispatch-emergency.md — 看板派单 / dispatch 卡死 / max_runtime 真修复的实战流程（2026-09-09 实证）

红线

• Boss 说「先不要派」= 立即停手，只分析
• 不要替 Boss 决策（剥到底后让 Boss 选）
• 不要拍脑袋给权重/概率（L1 校准假象）
• 审计后的派单：Boss 单字回复（"派"/"a"/"派啊"）= 立即执行，不再问"派哪张"