# 对开发人员有用的定律、理论、原则和模式（归纳版）

> 来源：[nusr/hacker-laws-zh](https://github.com/nusr/hacker-laws-zh)
> 抓取与归纳日期：2026-09-19
> 原文立场：作者**不提倡**其中任何一条，仅作解释与收录——它们都是理解软件工程与组织行为的"透镜"，而非金科玉律。

---

## 一、分类口径说明

原仓库 README 仅分两大区：**定律（Laws）** 与 **原则（Principles）**。但仓库标题点名了四类概念，本归纳按条目的**本质属性**重归为四类，便于检索：

| 分类 | 定义 | 条目数 |
|---|---|---:|
| **定律 Laws** | 可观测的经验性规律，常以统计、数学模型或反复验证的现象形式存在 | 34 |
| **理论 Theories** | 解释组织 / 系统运行行为的框架，多源自管理学与认知科学 | 7 |
| **原则 Principles** | 工程与设计上"应当遵守"的行动准则 | 10（SOLID 展开为 5） |
| **模式 Patterns** | 组织协作或架构设计的范式 / 哲学 | 2 |
| **合计** | | **53** |

> 注：原仓库将"乔治·伯克斯定律、切斯特森围栏、死海效应、呆伯特法则、帕累托法则、舍基原理、彼得原理"列在"原则"区，本归纳依其"解释性框架"属性改归"理论"。Unix 哲学、Spotify 模型依"范式"属性归"模式"。

---

## 二、定律 Laws

### L01　90-9-1 法则（90–9–1 Principle / 1% Rule）
- **核心**：在维基类网络社区中，90% 的用户只看不互动，9% 偶尔参与，仅 1% 持续创造内容。
- **与软件开发**：内部知识库 / 开源项目的贡献极度不均；不要指望全员写文档，应降低贡献门槛、识别并保护那 1% 的关键贡献者。

### L02　阿姆达尔定律（Amdahl's Law）
- **核心**：并行化带来的加速比受"必须串行执行的部分"限制：加速上限 = 1 / (1 − p + p/s)。
- **与软件开发**：优化前先算理论收益；若可并行比例 p 很小，堆机器收益有限。解释"为什么加核数后性能不线性提升"。

### L03　破窗效应（Broken Windows Theory）
- **核心**：环境中明显的失序（如破损窗户不修）会诱使更多、更严重的失序。
- **与软件开发**：代码劣质、坏味道、失败的测试不及时修，会"传染"团队，使整体质量持续下滑。及时还技术债是性价比最高的维护。

### L04　布鲁克斯法则（Brooks's Law）
- **核心**："在项目后期增加人手，只会让它更晚完成。"（类比：九个女人不能一个月生一个孩子）
- **与软件开发**：临近 deadline 加人反而拖慢——新人需要上下文、沟通成本随人数平方上升。预防靠可行估计 + 控制范围，而非加人。

### L05　CAP 定理（CAP Theorem / Brewer's Theorem）
- **核心**：分布式存储不可能同时满足一致性（C）、可用性（A）、分区容错性（P），分区发生时只能在 C 与 A 间取舍。
- **与软件开发**：选型与降级策略的底层依据（如 CP 的 ZooKeeper vs AP 的 Cassandra）。P 在现实网络中基本必选，故实质是 C/A 权衡。

### L06　康威定律（Conway's Law）
- **核心**：系统的技术边界会映射其组织的沟通结构。
- **与软件开发**：团队按职能切，系统就出"前端/后端/DBA"竖井；想出微服务，先按业务域组队（与 Spotify 模型、DDD 限界上下文呼应）。

### L07　坎宁汉姆定律（Cunningham's Law）
- **核心**："网上获得正确答案的最好方法，不是提问，而是发一个错误的答案。"
- **与软件开发**：评审、设计文档、故意抛砖引玉，比空等回答更高效。代码评审文化即此定律的正向应用。

### L08　邓巴数字（Dunbar's Number）
- **核心**：一个人能维持稳定社会关系的人数上限约 150。
- **与软件开发**：团队规模超过该量级，靠"默契"协作会失效，必须用清晰接口、文档、规范来替代人际记忆。解释"为何大团队要拆分"。

### L09　邓宁-克鲁格效应（Dunning–Kruger Effect）
- **核心**：能力不足者往往意识不到自己不足；懂的越少越容易高估自己。
- **与软件开发**：警惕"什么都敢改"的新手与"过度自信的估算"；用代码评审、测试、复盘对冲认知偏差。也提醒资深者保持谦逊。

### L10　费茨法则（Fitts's Law）
- **核心**：移动到目标的时间 ≈ 与目标距离 / 目标宽度 的函数。
- **与软件开发**：UI 交互元素应"大且近"；命令行 / API 的常用操作也要降低"认知距离"。可解释快捷键、工具栏布局的取舍。

### L11　盖尔定律（Gall's Law）
- **核心**："一个能用的复杂系统，必然从一个能用的简单系统演化而来；从零设计复杂系统多半失败。"
- **与软件开发**：先交付最小可用（MVP），再迭代复杂化；不要一上来就上"中台 / 微服务全家桶"。

### L12　古德哈特定律（Goodhart's Law）
- **核心**："当一个指标成为目标，它就不再是好指标。"
- **与软件开发**：KPI 一旦被考核就被博弈（如用代码行数衡量产出 → 堆废代码）。指标要多元、看趋势、不可单点优化。

### L13　汉隆的剃刀（Hanlon's Razor）
- **核心**："能解释为愚蠢的，就不要解释为恶意。"
- **与软件开发**：面对烂代码 / 故障，先假定是疏忽或信息不全，而非故意使坏；有助于对事不对人、建设性复盘。

### L14　席克定律（Hick's Law / Hick–Hyman Law）
- **核心**：决策时间随可选项数量对数增长（选项有序时）。
- **与软件开发**：减少菜单层级、配置项、一次性决策点；用默认值与渐进披露降低认知负荷。

### L15　侯世达定律（Hofstadter's Law）
- **核心**："即使把侯世达定律本身考虑进去，事情也总比你预计的久。"
- **与软件开发**：估算天然偏乐观；用缓冲、滚动规划、历史数据校准，而非承诺死日期。

### L16　哈伯特定律（Hutber's Law）
- **核心**："改善即恶化。"对系统的某处改进，可能让其他处恶化或隐藏退化。
- **与软件开发**：任何"优化"都要看全局副作用（如缓存提速但一致性风险上升）；用监控与回归测试兜住隐性退化。

### L17　技术成熟度曲线 / 阿马拉定律（Hype Cycle / Amara's Law）
- **核心**："我们高估技术的短期影响，低估其长期影响。"
- **与软件开发**：对新技术（AI、区块链…）既别在泡沫期all-in，也别在长期价值显现前错过；区分 hype 与实质生产力。

### L18　隐式接口定律（Hyrum's Law / 隐式接口定律）
- **核心**："当 API 用户足够多，你契约里承诺的已不重要——所有可观测行为都会被某人依赖。"
- **与软件开发**：公共 API 改任何行为（哪怕未文档化）都可能 breaking。强调契约测试、版本兼容、变更要慎重。

### L19　柯林汉定律（Kernighan's Law）
- **核心**："调试一开始就比写代码难一倍，所以若你把代码写得太巧妙，就没能力调试它。"
- **与软件开发**：拒绝过度聪明的技巧；可读性 > 炫技。可解释"为什么代码评审要禁止晦涩写法"。

### L20　林纳斯定律（Linus's Law）
- **核心**："足够多的眼睛，可使所有 bug 浮现。"
- **与软件开发**：开源 / 评审的发现力来源；但前提是代码可被读懂——与柯林汉定律互为约束（眼睛再多也看不懂烂代码）。

### L21　梅特卡夫定律（Metcalfe's Law）
- **核心**：网络价值 ≈ 用户数²。
- **与软件开发**：平台 / 网络效应的增长逻辑；也提示"先建连接再谈价值"。

### L22　摩尔定律（Moore's Law）
- **核心**：集成电路晶体管数约每两年翻一番。
- **与软件开发**：硬件红利长期存在，但已放缓——不能无脑指望"以后机器快了就好"；软件效率仍重要。

### L23　墨菲定律（Murphy's Law / Sod's Law）
- **核心**："凡可能出错的事，终将出错。"
- **与软件开发**：默认会出错：做防御性编程、幂等、重试 + 退避、混沌演练；把"异常路径"当一等公民。

### L24　奥卡姆剃刀（Occam's Razor）
- **核心**："如无必要，勿增实体。"假设最少的解释往往最接近真相。
- **与软件开发**：优先选简单方案；新依赖、新抽象、新模式都要有充分理由。与 KISS、YAGNI 一脉相承。

### L25　帕金森定理（Parkinson's Law）
- **核心**："工作会膨胀到填满所有可用时间。"
- **与软件开发**：排期越松越拖；用时间盒（timebox）、小迭代、WIP 上限制造紧迫感与节奏。

### L26　过早优化效应（Premature Optimization Effect）
- **核心**："过早优化是万恶之源。"（高德纳）在知道瓶颈前优化是浪费甚至有害。
- **与软件开发**：先正确、再测量、后优化；用 profiler 定位热点，而非凭感觉加缓存 / 改算法。

### L27　普特定律（Putt's Law）
- **核心**："技术由两类人主导——纯管理者与纯技术人。"配普特推论（技术领导要么不懂技术、要么脱离管理）。
- **与软件开发**：解释"技术 / 管理双通道"的必要性；优秀工程师应能被晋升而不被迫转管理。

### L28　里德定律（Reed's Law）
- **核心**：大型网络（尤其社交网络）的效用随规模**指数级**放大（强于梅特卡夫的平方）。
- **与软件开发**：社群 / 协作网络的网络效应比单纯连接更强；内部协作平台的价值同理。

### L29　复杂性守恒定律（Tesler's Law / 复杂性守恒）
- **核心**：系统总存在不可消除的复杂性；无意的复杂度可消除，本质复杂度只能转移（常转给用户）。
- **与软件开发**：别妄想"消灭"复杂度，要决定它落在哪一层；好的抽象是把复杂度关在正确边界内，而非甩给用户。

### L30　得墨忒耳定律（Law of Demeter）
- **核心**："别和陌生人说话。"对象只应与直接协作者交互，避免链式调用 `a.b.c.d`。
- **与软件开发**：降低耦合、提升可测性；对应"Tell, Don't Ask"与扁平的对象图。警惕过深的 getter 链。

### L31　抽象泄漏定律（Law of Leaky Abstractions）
- **核心**："所有非平凡的抽象，在某些时候都会泄漏。"（Joel Spolsky）
- **与软件开发**：ORM、容器、云都会在某刻暴露底层；使用者必须懂一点底层，才能在泄漏时排错。抽象省的是平时，不是关键时刻。

### L32　帕金森琐碎定理（Law of Triviality）
- **核心**：群体花在琐碎议题上的时间，与其重要性成反比（"自行车棚效应"Bike-shedding）。
- **与软件开发**：评审会容易在命名 / 缩进上耗光精力，却放过架构风险。用 RFC / 预先对齐目标，把讨论聚焦实质。

### L33　沃德勒定律（Wadler's Law）
- **核心**：语言设计中，讨论时间正比于要素"表面积"——语法 / 注释等琐碎处耗时最多，语义核心反而少争。
- **与软件开发**：警惕在边角语法、命名风格上过度纠结；把评审权重放在语义与接口契约上。

### L34　惠顿定律（Wheaton's Law）
- **核心**："别像个傻子一样。"（Wil Wheaton）倡导尊重、专业的协作氛围。
- **与软件开发**：健康的工程文化地基；与汉隆的剃刀配合，减少内耗、提升团队可持续性。

---

## 三、理论 Theories

### T01　乔治·伯克斯定律（All Models Are Wrong / George Box's Law）
- **核心**："所有模型都是错的，但有些有用。"
- **与软件开发**：架构图、估算、性能模型都是近似；用模型辅助决策，但别把模型当现实，持续用数据校准。

### T02　切斯特森围栏（Chesterton's Fence）
- **核心**："在弄清现有安排的原因前，不要去改它。"
- **与软件开发**：删代码 / 改设计前，先搞懂它为何存在（可能防着你不知道的坑）；避免"顺手重构"踩雷。

### T03　死海效应（Dead Sea Effect）
- **核心**：IT 团队中，能力强者易流失、弱者也易留下并沉淀——人才进出与效能成反比。
- **与软件开发**：技术债与人才流失互相强化；用成长空间、技术氛围留住骨干，是组织健康的关键指标。

### T04　呆伯特法则（Dilbert Principle）
- **核心**："企业倾向把最不胜任工作的人提拔到管理层，使其脱离一线。"
- **与软件开发**：解释"为什么管理者不懂技术"的现象；支持技术 / 管理双通道，避免逼高手去管人。

### T05　彼得原理（Peter Principle）
- **核心**："在等级制中，人会被提拔到其不胜任的层级为止。"
- **与软件开发**：晋升应基于新岗位所需能力而非旧岗绩效；配以支持、轮岗与双通道，避免"优秀工程师变糟糕经理"。

### T06　帕累托法则（Pareto Principle / 80–20 Rule）
- **核心**："多数结果由少数原因造成"——20% 的缺陷导致 80% 的崩溃，20% 的功能贡献 80% 价值。
- **与软件开发**：优先解决高频崩溃、聚焦核心功能；用二八分布做优先级与止损决策。

### T07　舍基原理（Shirky Principle）
- **核心**："机构会努力保留它们能解决的问题。"复杂方案可能让问题长期存在以证明自身价值。
- **与软件开发**：警惕"为中台而中台""为流程而流程"；工具 / 平台的价值应是消灭问题，而非养问题。

---

## 四、原则 Principles

### P01　鲁棒性原则 / 波斯特尔定律（Postel's Law / Robustness Principle）
- **核心**："对自己输出的要保守（严格合规），对他人输入的要宽容（宽松解析）。"
- **与软件开发**：协议 / API 实现经典准则；但宽容解析需有边界，否则会掩盖发送方错误、与隐式接口定律冲突——现代更强调"明确拒绝非法输入"。

### P02　单一功能原则（SRP, Single Responsibility Principle）
- **核心**：一个类 / 模块只因**一个**原因变化。
- **与软件开发**：SOLID 之首；高内聚低耦合的起点，让变更影响面可控。

### P03　开闭原则（OCP, Open/Closed Principle）
- **核心**：对扩展开放，对修改关闭。
- **与软件开发**：通过抽象与多态加功能而不改旧代码，降低回归风险；与策略模式、插件化密切相关。

### P04　里氏替换原则（LSP, Liskov Substitution Principle）
- **核心**：子类型必须能替换其基类而不破坏程序正确性。
- **与软件开发**：继承关系正确性的判据；违反 LSP 的典型是"正方形继承长方形"类陷阱，会引入隐蔽 bug。

### P05　接口隔离原则（ISP, Interface Segregation Principle）
- **核心**：不要强迫客户端依赖它用不到的方法。
- **与软件开发**：把胖接口拆小、按角色分组；前端按需取数、后端按能力分包都体现 ISP。

### P06　依赖反转原则（DIP, Dependency Inversion Principle）
- **核心**：高层模块不依赖低层细节，二者都依赖抽象。
- **与软件开发**：依赖注入 / IoC 容器（Spring）的理论基础；解耦业务与具体实现，便于测试与替换。

### P07　DRY 原则（Don't Repeat Yourself）
- **核心**："系统中每一处知识都应有单一、明确、权威的表达。"
- **与软件开发**：消除重复代码与重复逻辑；但注意"巧合的重复"不要强行抽象（参见"三次法则"）。

### P08　KISS 原则（Keep It Simple, Stupid）
- **核心**："保持简单直白。"
- **与软件开发**：能用简单方案就别上复杂框架；与奥卡姆剃刀、过早优化效应同气连枝。

### P09　YAGNI 原则（You Aren't Gonna Need It）
- **核心**："只在真正需要时才实现，不为臆想的未来写代码。"
- **与软件开发**：抵制过度设计；先满足当下，用演进应对变化，而非一次性堆可配置项。

### P10　分布式计算的谬论（Fallacies of Distributed Computing）
- **核心**：对分布式的 8 个错误假设：网络可靠、延迟为零、带宽无限、绝对安全、拓扑不变、单一管理员、运输成本为零、网络同构。
- **与软件开发**：微服务 / 云原生设计的"防坑清单"；每一条都在提醒：分布式系统的失败是常态，必须显式处理。

---

## 五、模式 Patterns

### M01　Unix 哲学（The Unix Philosophy）
- **核心**：软件组件应小而专、只做好一件事，通过组合简单单元构建系统。
- **与软件开发**：管道 `|`、单一职责 CLI、微服务"小而自治"的思想源头；与 SRP、KISS 同源。

### M02　Spotify 模型（The Spotify Model）
- **核心**：围绕"产品 / 特性"而非职能组队，提出小队（Squad）、部落（Tribe）、行会（Guild）、章节（Chapter）等结构。
- **与软件开发**：规模化敏捷的组织范式；与康威定律呼应——按业务域组队，系统边界自然对齐业务边界。

---

## 六、速查表

**定律（34）**：90-9-1 法则 · 阿姆达尔 · 破窗效应 · 布鲁克斯 · CAP · 康威 · 坎宁汉姆 · 邓巴数字 · 邓宁-克鲁格 · 费茨 · 盖尔 · 古德哈特 · 汉隆剃刀 · 席克 · 侯世达 · 哈伯特 · 技术成熟度曲线 · 隐式接口 · 柯林汉 · 林纳斯 · 梅特卡夫 · 摩尔 · 墨菲 · 奥卡姆剃刀 · 帕金森定理 · 过早优化 · 普特 · 里德 · 复杂性守恒 · 得墨忒耳 · 抽象泄漏 · 帕金森琐碎 · 沃德勒 · 惠顿

**理论（7）**：乔治·伯克斯 · 切斯特森围栏 · 死海效应 · 呆伯特 · 彼得 · 帕累托 · 舍基

**原则（10）**：鲁棒性 · SRP · OCP · LSP · ISP · DIP · DRY · KISS · YAGNI · 分布式计算谬论

**模式（2）**：Unix 哲学 · Spotify 模型

---

## 七、如何阅读这些条目

1. **它们是透镜，不是教条**：原文明确不提倡任何一条；结合你的上下文判断用哪条解释现象。
2. **彼此常有张力**：奥卡姆剃刀 vs 复杂性守恒；林纳斯定律 vs 柯林汉定律；鲁棒性 vs 隐式接口——张力本身才是思考的起点。
3. **工程落地看冲突**：选 SOLID 提升可维护性，但可能牺牲短期简单性（YAGNI/KISS）；用康威定律组队，但要防帕金森琐碎定理消耗评审。

---

## 八、五层 × 四分类 二维矩阵

> 本章在 README 既有的「定律 / 理论 / 原则 / 模式」四分类（横向）之上，叠加「道 — 法 — 术 — 器 — 势」五层认知框架（纵向），把全部 53 条条目定位到二维坐标，揭示其分布结构与覆盖盲区。

### 8.1 为什么需要二维视角

- **四分类只回答"它是什么知识"**：定律 / 理论 / 原则 / 模式是按条目**本体属性**切分，告诉你它是经验规律还是行动准则。
- **五层只回答"它在认知地图的哪一层"**：道（为什么）/ 法（大方向怎么做）/ 术（具体招式）/ 器（用什么）/ 势（借什么环境）。
- **二维交叉才暴露结构**：例如"所有原则都落在法层、没有一条在势层"——因为原则是**人定的行动准则**，而势是**客观环境规律**，二者在来源上天然互斥。单看任一维度都看不到这条结论。

### 8.2 五层定义（回顾）

| 层 | 一句话 | 回答的问题 | 知识性质 |
|---|---|---|---|
| **道** | 本质认知与第一性原理，含世界观与协作文化基调 | 为什么 | 不可违背，偏认知 / 价值观 |
| **法** | 方法论、设计准则、范式 | 怎么做（大方向） | 人定的纲领 |
| **术** | 可量化、可操作的具体技法 | 怎么落地的招式 | 人定的微观手法 |
| **器** | 工具、框架、平台、环境 | 用什么 | 外部实体 |
| **势** | 外部趋势、组织 / 生态势能 | 借什么环境 | 客观环境规律 |

### 8.3 矩阵总览（计数）

| 层 ＼ 类 | 定律 Laws | 理论 Theories | 原则 Principles | 模式 Patterns | 行计 |
|---|---:|---:|---:|---:|---:|
| **道** | 11 | 1 | 2 | 0 | **14** |
| **法** | 11 | 2 | 8 | 2 | **23** |
| **术** | 4 | 0 | 0 | 0 | **4** |
| **器** | 0 | 0 | 0 | 0 | **0** |
| **势** | 8 | 4 | 0 | 0 | **12** |
| **列计** | **34** | **7** | **10** | **2** | **53** |

**分布热力（字符示意，`▓` 密 / `▒` 中 / `░` 空）**：

```
        定律   理论   原则   模式
道      ▓▓    ▒     ▒     ░
法      ▓▓    ▒     ▓▓    ▒
术      ▒     ░     ░     ░
器      ░     ░     ░     ░
势      ▓     ▓     ░     ░
```

### 8.4 完整矩阵（带条目）

| 层 ＼ 类 | 定律 Laws | 理论 Theories | 原则 Principles | 模式 Patterns |
|---|---|---|---|---|
| **道** | L03 破窗 · L04 布鲁克斯 · L09 邓宁-克鲁格 · L13 汉隆 · L15 侯世达 · L23 墨菲 · L24 奥卡姆 · L26 过早优化 · L29 复杂性守恒 · L31 抽象泄漏 · L34 惠顿 | T01 伯克斯 | P08 KISS · P09 YAGNI | ∅ |
| **法** | L05 CAP · L06 康威 · L11 盖尔 · L12 古德哈特 · L16 哈伯特 · L18 隐式接口 · L19 柯林汉 · L20 林纳斯 · L30 得墨忒耳 · L32 帕金森琐碎 · L33 沃德勒 | T02 切斯特森 · T06 帕累托 | P01 鲁棒性 · P02 SRP · P03 OCP · P04 LSP · P05 ISP · P06 DIP · P07 DRY · P10 分布式谬论 | M01 Unix 哲学 · M02 Spotify 模型 |
| **术** | L02 阿姆达尔 · L07 坎宁汉姆 · L10 费茨 · L14 席克 | ∅ | ∅ | ∅ |
| **器** | ∅ | ∅ | ∅ | ∅ |
| **势** | L01 90-9-1 · L08 邓巴 · L17 技术成熟度曲线 · L21 梅特卡夫 · L22 摩尔 · L25 帕金森 · L27 普特 · L28 里德 | T03 死海 · T04 呆伯特 · T05 彼得 · T07 舍基 | ∅ | ∅ |

### 8.5 分布解读与关键洞察

1. **「器」行全空——最核心的盲区**
   53 条定律 / 理论 / 原则 / 模式，**没有任何一条属于"器（工具）"**。这类知识只告诉你"为什么"与"怎么做"，从不指定"用什么"。工具的空白，恰由 `core` 的 145 条方法论（Spring、Redis、MongoDB、DDD、整洁架构等具体技术栈）补足——**定律集给方向，方法论给器物**，二者叠合五层才完整。

2. **「法」层最密（23 条，占 43%）**
   工程准则密度最高，且横跨全部四类（定律 11 + 理论 2 + 原则 8 + 模式 2）。说明这套知识体系的**主体是"设计方法论"**：大量经验被提炼成了可遵循的准则（SOLID、CAP、康威、DRY…）。

3. **「势」层（12 条）只来自定律与理论，原则 / 模式全缺**
   这是结构性的：原则是**人定的行动准则**，模式是**人定的范式**，二者来源都是"主观共识"；而势是**客观环境规律**（网络效应、硬件趋势、组织人才流动）。"人定"与"客观"在来源上互斥，故势行的后两列天然为 ∅。

4. **「术」层薄（4 条）且全在定律**
   具体可量化技法（阿姆达尔加速公式、费茨 / 席克交互公式、坎宁汉姆"抛错得正解"）集中在定律类。其余三类几乎没有"术"——印证了"原则 / 理论 / 模式偏纲领、少微观招式"的特征。

5. **「道」层厚（14 条）且横跨三类**
   大量认知 / 文化第一性原理（墨菲、奥卡姆、复杂性守恒、抽象泄漏、KISS/YAGNI、惠顿 / 汉隆协作基调）落在道层，说明**工程的根基是认知与价值观，而非技巧**。

### 8.6 判层说明（透明化）

- 每条的层归属为本文基于 §8.2 定义的**二次归纳**，非原仓库标注；边界条目（如帕累托、奥卡姆、KISS/YAGNI）按"工程用法"而非"字面归类"判层。
- **帕累托**在本矩阵归「法」（工程优先级决策准则），而在 `../../index.html` 融合文章中按"世界本质的不平衡分布"归「道」——维度侧重不同，两条都合理，特此标注。
- 「器」行全空是**真实结论**而非遗漏：原仓库确无一条指向具体工具 / 框架。