编程定律Tier List：哪些是真知，哪些该被淘汰？

当程序员开始给"定律"打分

编程世界里流传着许多以人名命名的"定律"，从康威定律到布鲁克斯定律，它们被写进教科书、挂在会议室墙上，甚至成为技术决策的依据。但它们真的都配得上"定律"二字吗？在一期 TheStandup 播客中，几位资深开发者对这些定律进行了一场毫不留情的 Tier List 评级，结果出人意料——有些被奉为圭臬的定律被打入冷宫，而一些常被忽视的观察却被推上神坛。

这篇文章将带你梳理这场讨论的核心观点，并加入一些延伸思考：当 AI 编程工具日益普及时，这些几十年前总结的规律还站得住脚吗？

S 级：康威定律——比你想的更普适

不只是组织架构图

康威定律的经典表述是："设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。"多数人把它理解为"团队结构决定代码结构"——比如负责结算的团队和负责购物车的团队会产出两套不同的用户数据模型，然后靠胶水代码勉强拼在一起。

但讨论中一位开发者给出了更深刻的解读：康威定律本质上描述的是信息传递效率。一个人脑内的信息传递最快，两人对话稍慢，跨团队沟通更慢，跨公司协作最慢。因此，每当系统中增加一道沟通边界，跨越该边界的演进就会变慢，而不需要跨越边界的部分则能更快迭代。

微前端只是康威定律的"补丁"

按照这个逻辑，微服务、微前端这些架构模式并非单纯为了让开发更轻松，而是在降低康威定律带来的沟通成本。大公司里动辄数千人的工程组织，混乱是常态——你不可能知道所有事情在发生什么，于是只能通过架构隔离来缩小"爆炸半径"，让每个团队能按自己的节奏交付。

这也解释了一个常见误区：Google 的某些架构实践在 Google 内部合理，是因为它有对应的组织规模和信息传递成本；小团队照搬只会徒增复杂度——毕竟你隔壁工位就是写结算代码的同事，直接喊一嗓子比建一套微服务架构高效得多。

AI 时代依然成立

最耐人寻味的是，讨论者认为康威定律甚至不限于人类组织。当多个 AI agent 协作时，它们之间的通信链路、测试环节、编译器反馈都会形成"慢速连接"，这些瓶颈会导致系统在不同模块中以不同速度演进——这与人类组织的表现如出一辙。康威定律因此被评为 S 级：它足够底层，足够持久。

被高估的定律：布鲁克斯定律与霍夫施塔特定律

布鲁克斯定律：人手≠速度

"向一个已经延迟的项目增加人力，只会让它更延迟。"这条来自《人月神话》的观察，在 Tier List 上被评为 C 级甚至更低，理由是它不可靠。

反例比比皆是：有时候加入一个合适的人，项目立刻起死回生；有时候加入一个糟糕的人，按时交付的项目反而被拖垮。讨论者指出，这条定律诞生于 IBM System 360 时代，彼时的开发环境与今天差异巨大。如今借助 AI 工具，新成员理解代码库的速度远超从前——你可以直接让 AI 梳理仓库历史、解释某个技术选择的来龙去脉，过去需要数周才能建立的上下文，现在可能几分钟就能获得八成。

更关键的是，许多延迟项目的问题根源不在工程本身：销售承诺了三个月交付一个两年的项目，此时增加人手只会让更多人在会议室里争论架构，而不是让代码写得更快。

《人月神话》是弗雷德里克·布鲁克斯（Frederick P. Brooks Jr.）于1975年出版的软件工程经典，基于他在IBM领导System/360操作系统开发的经验。书中提出“人月”作为工作量单位的神话——认为人力与时间可以简单互换，并强调“概念完整性”需要少数架构师主导。布鲁克斯定律正是对“加人就能加速”这一直觉的反驳，其核心机制包括沟通成本随人数呈平方增长、新成员需要学习上下文、以及任务不可分割性。然而，该定律的原始语境是大型单体系统、瀑布式开发、缺乏现代协作工具的时代；如今模块化架构、持续集成和AI辅助理解代码库，都在改变“加人”的边际成本。

霍夫施塔特定律：不确定性才是真相

"事情总是比你预期的更耗时，即使你已经考虑到了霍夫施塔特定律。"这条定律被评为"不可靠"，因为它的预测能力太弱——有时你预计要一个月的事，30 分钟就搞定了；有时你觉得简单的改动，一个月后还在调试。

讨论者提出了一个替代观察：真正稳定的规律或许是"工作会膨胀以填满给定的时间"（帕金森定律），以及"无论截止日期定在哪天，事情总会在那附近完成"。

霍夫施塔特定律由侯世达（Douglas Hofstadter）在1979年的《哥德尔、艾舍尔、巴赫》中提出，原文是：“事情总是比你预期的更耗时，即使你已经考虑到了霍夫施塔特定律。”它属于一种自指式的幽默观察，而非可量化的预测模型。其价值在于提醒人们规划时存在系统性乐观偏差，但缺陷也在于此：它几乎无法证伪，因为任何超时都可以被归因于“没考虑到这条定律”。与之互补的帕金森定律（工作会膨胀以填满可用时间）则提供了更可操作的管理视角——通过设定紧迫的截止日期来压缩不必要的膨胀。两者结合，更能解释为什么项目时间总在截止日期附近收敛。

AI 正在改写的老定律

杰森定律：六个月后，代码如同陌生人

"离开六个月后，你自己的代码看起来像是别人写的。"这条定律在 AI 时代被评为 F 级——因为现在可能六个月都用不着，AI 生成的代码你根本没看过。

但讨论中出现了一个有趣的反对意见：一位开发者表示，回到自己写的代码往往比读别人的代码更容易，原因不在于代码质量，而在于底层假设的一致性。你知道自己不会用某些写法，知道自己习惯的抽象方式，这些默认设定大幅减少了认知负担。只有当你的编码风格发生剧烈变化时（比如突然尝试纯函数式风格），才会出现"认不出自己代码"的情况。

杰森定律（Jason's Law）并非学术界的正式命名，而是编程社区中流传的一种经验观察，常被表述为“任何你六个月没看过的代码，都像是别人写的”。它反映了人类记忆的脆弱性和上下文依赖：编写代码时，你持有大量未显式记录的底层假设——为什么选择这个数据结构、为什么绕过那个API、哪些边界条件已经考虑过。这些“隐性知识”在离开项目后迅速衰减。在AI辅助编程普及后，该定律的适用性受到挑战：一方面，AI生成的代码可能从未被人类仔细阅读，谈不上“忘记”；另一方面，AI可以快速梳理仓库历史和提交信息，帮助重建上下文，从而部分抵消记忆衰减。

古德哈特定律：指标变成目标的那一刻

"当一个指标成为目标，它就不再是一个好指标。"这条定律获得了 A 级评价，但讨论者对它的适用范围做了重要限定。

在编程领域，很多指标是"硬"的——启动时间、首次渲染时间，这些测量的是真实的东西，很难被扭曲。但当指标是间接的、模糊的，问题就来了：如果公司考核"每人每月消耗多少 AI token"来推动 AI 工具 adoption，员工完全可以在夜里跑一个空转循环来刷量。如果绩效与"减少启动时间的 PR 数量"挂钩，工程师可能会故意先引入性能退化，再分批修复来刷 PR 数。

讨论者用 Netflix 的案例做了延伸：当"用户观看时长"成为核心指标后，内容质量的门槛可能被不断拉低以换取更多观看——指标达成了，但产品原本的价值主张可能被侵蚀。

古德哈特定律得名于英国经济学家查尔斯·古德哈特（Charles Goodhart），他在1975年关于货币政策的研究中指出：“当一项指标成为目标时，它就不再是一个好指标。”其底层逻辑是激励扭曲：一旦人们知道某个数字被用于考核，就会调整行为来优化该数字，而非优化数字所代表的本意。在软件工程中，这解释了为什么代码行数、缺陷数量、甚至AI token消耗量等指标一旦与绩效挂钩，就容易产生刷量行为。与古德哈特定律相关的还有坎贝尔定律（Campbell's law）和“指标游戏”（metric gaming）现象，它们共同提醒：选择指标时需评估其被操纵的难易程度，硬性技术指标（如启动时间）比软性行为指标更难扭曲。

那些"真但无用"的定律

林纳斯定律：足够多的眼球让所有 bug 变浅

"只要足够多的用户使用一个 API，你在契约中承诺什么都无关紧要——系统的所有可观察行为都会被某人依赖。"这条定律被评为 S 级，因为开源世界里充满了"意外行为变成事实标准"的案例：Go 语言的 for 循环曾经不复制循环变量，导致无数人踩坑，但官方花了十几个版本才敢修改，因为已有代码依赖了这个行为。

然而另一条常被引用的"林纳斯定律"——"足够多的眼球让所有 bug 变浅"——却被打入"待定区"。讨论者认为它"显然为真但毫无信息量"，就像买更多彩票会增加中奖概率一样，正确但无用。而且 Linux 本身也并非没有 bug，人多并不自动等于质量高。

坎宁安定律与"安妮定律"

"在互联网上获得正确答案的最佳方式不是提问，而是发布错误答案。"这条定律被讨论者戏称为"安妮定律"——因为有人（据说是一位叫 Annie 的用户）在 Reddit 上总结过一套更精确的操作：先礼貌地提问，然后用小号发布一个傲慢且错误的答案，等着别人来纠正。

讨论者认为，随着专家们被社交媒体上的噪音消耗殆尽，这条定律的效果正在下降——有能力的回答者可能早已取关。但在特定小众社区（如宝可梦卡牌收藏），它依然有效。

软件变慢定律：S 级的时代诊断

"软件变慢的速度快于硬件变快的速度。"这条 Wirth 定律获得了全场最高的共识。讨论者分享了一个实验：让 AI 在一个慢速虚拟机上测试 DOM 元素的增删速度，结果是微秒级别——从纯技术角度看，现代浏览器的操作已经极快。但用户感受到的卡顿却无处不在，因为功能膨胀、抽象层堆叠和依赖膨胀吞噬了硬件红利。

一位开发者半开玩笑地总结："我们到了用神经网络跑在显卡上来生成帧的时代，因为做不出好的图形了。"这背后是对行业趋势的真实焦虑——每一代软件都在更多功能、更复杂架构和更快交付的压力下，牺牲了响应速度。

结语：定律是思考的起点，不是答案

这场 Tier List 最有趣的发现或许是：真正经得起推敲的编程定律，往往描述的是信息流动和人类认知的底层约束（康威定律、古德哈特定律），而那些试图预测具体项目管理结果的定律（布鲁克斯、霍夫施塔特），在环境变化面前显得脆弱。

AI 工具正在改写许多传统经验——新人上手速度、代码理解成本、甚至"谁是代码作者"的定义都在变化。但康威定律揭示的沟通成本、古德哈特定律揭示的激励扭曲，这些根植于组织和人性的规律，恐怕会比任何具体技术都更长久。

下次你在会议室里听到有人引用某条"定律"来支持某个决策时，不妨先问一句：这条定律的原始语境是什么？它今天还成立吗？