# Gm First Principles Audit

> Use for first-principles audit of GM or any system.

- Skill: `jajabong/gm-first-principles-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jajabong/gm-first-principles-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jajabong/gm-first-principles-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: jajabong (https://skillmd.com/u/jajabong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jajabong/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 件套自检 · 锁定）**：

| # | 自检 | 错答 | 对答 |
|---|---|---|---|
| 1 | title 是否符合 `[Epic·主题·role]`？ | `[v3.13·...]` | `[v3.13·swarm epic 规范·engineering]` |
| 2 | body 是否 ≤ 500 字？ | 1000+ 字长篇 | 拆 swarm epic 子卡 |
| 3 | epic_id 是否标注？ | 漏 | body 写明 epic 来源（如 `派生自 RFC-2.3`） |
| 4 | verify 方法是否明确？ | "看结果" | `metadata.X = ...` 列出铁证 |

**派单铁律（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 次：

| 轮次 | GM 拍脑袋 | Boss 纠正 | 错在哪 |
|---|---|---|---|
| 1 | "anchor 401 = 限制 4-5 worker" | "anchor 是模型不是 endpoint，401 ≠ 全局限制" | 把单 provider 401 等同全局 |
| 2 | "dispatcher 12 上限 = 真实上限" | "每个 API key 内有大量并发" | 错把 RPM 等同并发 |
| 3 | "Mac mini 32G 内存，理论 64 worker" | "**Mac mini 16G，不是 32G**，并发也就 8 个左右" | 整机基本配置都搞错 |

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

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

1. **先查整机基本盘**（不靠印象）：
   ```bash
   sysctl hw.memsize hw.physicalcpu
   vm_stat | head -5
   df -h /System/Volumes/Data
   ```
   内存/磁盘是几个 G？CPU 几个核？**先打印这 3 行再说**。

2. **再算单 worker 占用**（不是猜 500Mi）：
   ```bash
   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 轮打脸教训）**：

| 自问 | 错答（v2026-09-08 实测） | 对答 |
|---|---|---|
| "并发上限 = ?" | "API Key 健康度" / "dispatcher 12" / "32G 内存理论 64 worker" | "Mac mini **16G**，单 worker RSS 187Mi，swap 余量 384M，**实际 6-8 worker**" |
| "ready 14 张是 ?" | "饱和！" | "队列长度，与火力无关；饱和 = running > 上限" |
| "base_url 全锁 openanchor.top 是 ?" | "债，要拆 fallback" | "**设计**，anchor 是 L2 智能调度统一入口" |
| "走不通时怎么修 ?" | "改 base_url" | "**保留** base_url，修上游 vendor key 或换 model 名" |

**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"/"派啊"）= 立即执行，不再问"派哪张"