一份把「对开发人员有用的定律、理论、原则和模式」与「164 张方法论卡片（M01–M16）」放进同一套定位系统的深度归纳。结论先行：定律集只回答为什么与怎么做，几乎不回答用什么；而方法论与工具链，恰好补上缺失的那一层。
两份材料各自有价值，却都不足以单独成图。README.md 里 53 条定律被原作者平铺成「定律 / 理论 / 原则 / 模式」四块；chapter-core-methodology.html 里的 164 张方法论卡片按 M01–M16 编号铺开（已升级为六层：道—法—术—器—势—纪，M16 为「纪」沉淀层）。它们都是点。把它们放进这套六层视角，点才连成地图。
两套材料的天然互补关系如下：
53 条里大量是底层规律（道）、方法规则（法）与环境力量（势），极少具体技巧。
M06 稳定性之术、M08 高并发、M09 高可用、M10 高性能、M11 幂等、M13 安全——全是可落地的招式。
方法论正文引用的 K8s、Sentinel、Prometheus、CI 门禁，把术固化成可安装的兵器。
团队规模、业务阶段、监管周期——定律与谬论早就点破，只是常被忽略。
下面先精解框架，再把 53 条逐条归位，最后用 164 张方法论卡片把缺失的层补实。
框架源自《道德经》「道生之，德畜之，物形之，势成之」与《孙子兵法·势篇》。前五层构成纵向的抽象阶梯（道·法·术·器 纵向 + 势横贯），纪为方法论页新增的第六层——研发前段流程与软技能的沉淀层，不参与招式竖切而在器固化后收口。
npm install 的是器。| 层 | 核心问题 | 本质 / 定位 | 软件工程对应 | 识别判据 | 稳定性 |
|---|---|---|---|---|---|
| 道 | 为什么做？ | 根本规律、第一性原理、价值观、不变量 | 复杂度管理、康威定律、熵增、CAP、没有银弹 | 换语言/行业/规模仍成立 | 数十年 |
| 法 | 按什么框架做？ | 方法论、流程、规范、连接道与术的桥 | 敏捷/DevOps、DDD、SOLID、Code Review、变更三板斧 | 能画成阶段图/检查清单 | 数年 |
| 术 | 具体怎么做？ | 技巧、招式、可修炼的能力 | 设计模式、重构、幂等、熔断限流、灰度、混沌工程 | 需调参、有取舍、写代码 | 随情境 |
| 器 | 用什么做？ | 工具、平台、框架、放大器 | Git、K8s、Prometheus、CI/CD、AI 编程助手 | 能安装/引用/替换 | 一年一换 |
| 势 | 何时/何地做？ | 时机、环境、趋势、乘数因子 | 云原生、团队规模、业务阶段、监管、流量洪峰 | 阻力来自人而非事 | 动态环绕 |
将 README.md 的 53 条（34 定律 + 7 理论 + 10 原则 + 2 模式）逐条放进六层。结论：定律集在道、法、势三处密集，术偏薄，器为 0、纪也为 0。这两个「0」不是疏漏——定律描述规律，不提供工具；定律也不沉淀研发前段流程，那属于方法论的领地。
| 条目 | 原归类 | 核心断言（为什么层） |
|---|---|---|
| 奥卡姆剃刀Occam's Razor | 原则 | 如无必要勿增实体——换场景仍成立的极简公理 |
| KISS 原则Keep It Simple, Stupid | 原则 | 保持简单直白，底层世界观而非技巧 |
| YAGNI 原则You Aren't Gonna Need It | 原则 | 只为真实需要而建，对抗过度设计之本 |
| 复杂性守恒Tesler's Law | 定律 | 复杂度不可消灭只可转移——工程第一性原理 |
| 乔治·伯克斯定律All Models Are Wrong | 理论 | 模型皆近似，换领域仍成立 |
| 墨菲定律Murphy's Law | 定律 | 会出错终将出错——故障是常态而非异常 |
| 布鲁克斯法则Brooks's Law | 定律 | 后期加人更慢——规模与协作的不变量 |
| 康威定律Conway's Law | 定律 | 架构复刻沟通结构——组织即系统的道 |
| CAP 定理CAP Theorem | 定律 | 分布式不可三角同满——系统不变量 |
| 抽象泄漏Law of Leaky Abstractions | 定律 | 非平凡抽象必漏——抽象本质的道 |
| 过早优化Premature Optimization | 定律 | 未测先优是万恶之源——时序上的道 |
| 破窗效应Broken Windows | 定律 | 失序会传染——质量熵增的道 |
| 邓宁-克鲁格Dunning–Kruger | 定律 | 无知者不自知——人类认知的不变量 |
| 帕累托法则Pareto / 80-20 | 理论 | 少数原因主宰多数结果——分布不变量 |
| 汉隆剃刀Hanlon's Razor | 定律 | 能解释为蠢勿解为恶——归因的道 |
| 惠顿定律Wheaton's Law | 定律 | 别像个傻子——专业协作的价值观之基 |
| 条目 | 原归类 | 核心断言（为什么是法） |
|---|---|---|
| SOLID 设计原则SRP/OCP/LSP/ISP/DIP | 原则 | 面向对象设计的五条框架性规则 |
| DRY 原则Don't Repeat Yourself | 原则 | 单一权威来源——可写成规范 |
| 鲁棒性原则Postel's Law | 原则 | 严出宽进——协议设计的法 |
| 分布式计算谬论Fallacies | 原则 | 8 条错误假设——分布式设计的检查清单 |
| 盖尔定律Gall's Law | 定律 | 复杂系统必从简单系统演化——演进式方法 |
| 古德哈特定律Goodhart's Law | 定律 | 指标成目标即失效——度量设计的法 |
| 帕金森定理Parkinson's Law | 定律 | 工作膨胀填满时间——时间盒方法的依据 |
| 帕金森琐碎定理Law of Triviality | 定律 | 群议陷于琐细——评审聚焦的法 |
| 林纳斯定律Linus's Law | 定律 | 多眼显 bug——评审/开源流程之法 |
| 沃德勒定律Wadler's Law | 定律 | 讨论耗时与琐细成正比——评审分配的法 |
| 得墨忒耳定律Law of Demeter | 定律 | 只与直接协作者交谈——耦合控制的规则 |
| 隐式接口定律Hyrum's Law | 定律 | 可观测行为皆被依赖——API 兼容的法 |
| 柯林汉定律Kernighan's Law | 定律 | 代码太巧则无法调试——可读编码规则 |
| 坎宁汉姆定律Cunningham's Law | 定律 | 抛错答得正解—— eliciting 之法 |
| 切斯特森围栏Chesterton's Fence | 理论 | 不明原因不改——变更管理的法 |
| Unix 哲学Unix Philosophy | 模式 | 小而专、组合构建——架构组织之法 |
| Spotify 模型Spotify Model | 模式 | 按特性组队——团队拓扑之法 |
| 条目 | 原归类 | 核心断言（为什么是术） |
|---|---|---|
| 阿姆达尔定律Amdahl's Law | 定律 | 并行加速需调参计算——典型术 |
| 费茨法则Fitts's Law | 定律 | 目标距离/宽度决定耗时——UI 调参术 |
| 席克定律Hick's Law | 定律 | 选项数决定决策时——降选项术 |
| 侯世达定律Hofstadter's Law | 定律 | 估算总偏乐观——排期实践术 |
| 哈伯特定律Hutber's Law | 定律 | 改善即恶化——改动副作用评估术 |
| 柯林汉 / 得墨忒耳等跨层 | — | 部分「法」条目在具体场景即退化为术（见下注） |
注：术层天然偏薄。定律集的本职是概括规律，「具体怎么调」属于方法论（见第四节）。另：同一词会跨层——如「幂等」在道是「重复不应改世界」，在法为「写接口须定义幂等键」，在术为「唯一索引/状态机」，在器为「MQ 去重框架」。
| 条目 | 原归类 | 核心断言（为什么是势） |
|---|---|---|
| 摩尔定律Moore's Law | 定律 | 算力随时间翻倍——技术浪潮之势 |
| 梅特卡夫定律Metcalfe's Law | 定律 | 价值随用户数平方——网络效应之势 |
| 里德定律Reed's Law | 定律 | 效用指数扩增——社群网络之势 |
| 技术成熟度曲线Hype Cycle | 定律 | 高估短期低估长期——选型时机之势 |
| 邓巴数字Dunbar's Number | 定律 | 稳定关系上限 ~150——团队规模之势 |
| 普特定律Putt's Law | 定律 | 技术由管理与技术人主导——组织势能 |
| 90-9-1 法则1% Rule | 定律 | 极少人创造内容——社区参与之势 |
| 死海效应Dead Sea Effect | 理论 | 强者易走弱者易留——人才流失之势 |
| 呆伯特法则Dilbert Principle | 理论 | 庸者易被提拔离一线——组织异化之势 |
| 彼得原理Peter Principle | 理论 | 人被提到不胜任层——晋升天花板之势 |
| 舍基原理Shirky Principle | 理论 | 机构保它能解的问题——组织惰性之势 |
方法论页（chapter-core-methodology.html，M01–M16，164 卡）已升级为六层框架：道/法/术/器/势/纪。前五层构成「挂载关系」（道→法→术→器、势横贯全程），纪（M16）是沉淀层——研发前段流程与软技能，不参与招式竖切而在器固化后收口。下面用具体卡片把六层「接上地气」。
方法论正文引用的工具即「器」：发布回滚与门禁（G01）、可观测三支柱（G02/G03，对应 Prometheus、Loki、Jaeger）、HPA 冷却、Sentinel 熔断组件、CI 门禁等。它们把「术」固化成可安装、可替换的放大器。
纪（M16 研发前段流程与软技能）是方法论页升级六层时新增的沉淀层，也是整套框架的「收口」。它不参与招式竖切（道→法→术→器），而在器固化后把经验沉淀成可复用的组织资产。纪层内容：从需求澄清到知识沉淀的研发前段链路——模糊诉求→可验收判据、协作经验→可复用资产。定律集对研发前段流程与软技能同样为 0，这是它与方法论在「沉淀」维度的本质边界。
六层不是并列选项，而是有方向的「挂载关系」。前五层（道法术器势）构成主干，纪在末端沉淀收口。理解运动规律，才能避免在错误层级用力。
| 错位 | 表现 | 定律/方法论中的对应 |
|---|---|---|
| 以道代法 | 满嘴「要防患于未然」，却无三阶段责任人与检查清单 | 对应「重法轻术」的形式主义；M05.01 正是解法 |
| 以术代法 | 学了一堆熔断降级，却无框架挂起，工具越买越乱 | 定律集「法」厚而「术」薄，正易犯此错 |
| 以器代术 | 以为上了 K8s 问题就解决，忽略阈值/演练 | 方法论反复强调「器只放大法术，不替代」 |
| 逆势而为 | 方案正确，但在生态未熟/团队无共识时强推 | 「势」层的死海/呆伯特/彼得点破人与时机 |
把框架落到个人：你处在哪一层，该往哪发力；遇到争论，用四问快速定位层级。
| 角色阶段 | 应侧重 | 对应条目重心 |
|---|---|---|
| 初级工程师 | 精通器、苦练术 | 方法论 M06–M15 的术与器 |
| 高级工程师 | 深化术、理解法 | SOLID / DRY / 事前-事中-事后 |
| 架构师 / TL | 活用法、体悟道 | 康威 / 复杂性守恒 / 演进思维 |
| 技术管理者 | 读势、立道 | 死海 / 彼得 / 邓巴 / 业务阶段 |
反向检查：我们是在讨论「做什么」，还是在讨论「用什么做」？混着谈必然鸡同鸭讲。
一张地图的价值，不在于它标了多少点，而在于它让你知道自己站在哪、该往哪走。
三句话收束：
① 定律集是「道 + 法 + 势」的透镜——53 条帮你看清为什么与怎么做，却不留一件兵器（器 = 0）、不沉淀研发前段流程（纪 = 0）。
② 方法论是「道 + 法 + 术 + 器 + 势 + 纪」的锚——164 张方法论卡片把规律接成可跑的流程、可装的工具，M16（纪）进一步把经验沉淀成组织资产。
③ 真正的高手，是能在势中持道、以法驭术、善假于器、以纪沉淀的人。器术随浪潮更迭，沉淀下来的道与法与纪，才是你带得走的能力。