01原理
公地悲剧说的是一类结构：一份资源大家都能用，每个人多用一点，好处全归自己，代价却摊到所有人头上。生态学家哈丁 1968 年在《科学》杂志上用牧场举例：每个牧民多放一头牛，得到的是整头牛的收益，草场退化的损失却由全体牧民分担，所以每个人算下来都该再加一头，直到草场被吃光。没有人是坏人，每个人的账都算对了，合在一起却是灾难。
芒格把它看作斯密“看不见的手”的反面。看不见的手在产权清楚、代价和收益落在同一个人身上时成立；一旦代价能甩给别人，同样的自利就会把公共的东西推向耗竭。这也是他把它和激励放在一起讲的原因：公地悲剧本质上是一种激励结构的缺陷，不是道德问题。
对 AI 小团队来说，公地并不只是草场和渔场。开源项目维护者的注意力、文档站的带宽、公共基准测试、一个渠道的用户信任、团队内部共享的 GPU 配额和代码库质量，都是“谁都能用、没人单独付账”的资源。你既可能是放牛的人，也可能是那片草场。
为什么成立
机制在于收益和成本的不对称。设有 N 个使用者，某人多用一单位资源，自己拿到全部收益 b，资源损耗 c 由所有人分担，他只承担 c/N。只要 b 大于 c/N，多用就划算，哪怕 b 远小于 c、对整体是亏的。N 越大，个人感受到的代价越小，过度使用越严重。而且克制不会被奖励：你少用的那份，会被别人用掉。
解法并不只有哈丁说的私有化或政府管制。2009 年诺贝尔经济学奖授予埃莉诺·奥斯特罗姆，理由是她证明了公共资源可以由使用者组织成功管理：她研究了大量由使用者自己管理的渔场、牧场、森林和地下水，发现结果往往好于标准理论的预测，关键在于使用者自己制定的决策和执行规则。换句话说，公地悲剧是一个可以被改写的结构：把成本重新挂回使用者身上，或者让使用者共同定规矩、互相监督。
02芒格怎么说
芒格在 2003 年加州大学圣塔芭芭拉分校（UCSB）的赫伯·凯讲座上批评学院派经济学时，专门提到公地悲剧。他说曼昆的入门教科书把机会成本、激励和哈丁的公地悲剧并列为经济学原理，他说哈丁给经济学带来了与亚当·斯密那只仁慈的“看不见的手”并列的、作恶的“看不见的脚”，并认为哈丁的模型让经济学更完整。在同一场讲座里，他还把美国与中国的贸易困境说成“一种新的公地悲剧”：每个参与者都被锁在系统里，单方面退出改变不了结局。
the tragedy of the commons model, popularized by UCSB’s Garrett Hardin.
公地悲剧模型，由 UCSB 的加勒特·哈丁推广开来。
Hardin caused the delightful introduction into economics – alongside Smith’s beneficent invisible hand – of Hardin’s wicked evildoing invisible foot.
哈丁给经济学带来了一个妙趣横生的补充：在斯密那只仁慈的看不见的手旁边，多了一只哈丁的、作恶的看不见的脚。
you’ve just invented a new form of the tragedy of the commons. You’re locked in this system and you can’t fix it.
你刚刚发明了公地悲剧的一种新形式。你被锁在这个系统里，而且修不好它。
03怎么用
- 01
先认出你在用哪些公地
列一张清单：你的产品依赖哪些没付钱或付得很少的公共资源？开源库、公开数据、别人的网站内容、免费 API 额度、社区论坛。对每一项问两个问题：如果所有像你一样的公司都这样用，它还撑得住吗？如果它垮了，你的替代方案是什么？把关键依赖的维护者状况，当作供应商风险来看。
- 02
让自己的使用量“付账”
爬取数据时遵守 robots.txt，支持 ETag 和 Last-Modified 这类条件请求，只下载变化的部分，并设带宽上限；调用开源项目时，把赞助、上游补丁和高质量的问题报告当作成本的一部分，而不是可有可无的善举。成本不付，最后会以服务被封、项目停更的方式回到你身上。
- 03
如果你是被消耗的那一方，给使用加价
当你的资源（免费额度、支持渠道、悬赏计划）被大量低质量使用拖垮，先看是不是激励在招来它：免费且有奖励的入口最容易被刷。可以加门槛（实名、押金、用量阶梯）、去掉吸引滥用的奖励、或者把重度使用改成付费，让多用的人承担多用的成本。
- 04
团队内部的公地要有主人
共享 GPU 配额、共用的 API 密钥预算、代码库里的测试和文档，都是团队内部公地。每个人赶自己的进度时，最省事的做法就是透支它们。给每项共享资源指定负责人，把用量按人或按项目公开，把“留下比你来时更好”写进评审标准。
- 05
评估市场时，看公地会不会被抽干
如果你的商业模式建立在免费流量、公开数据或某个平台的宽松政策上，要想到你不是唯一一个这样做的人。当越来越多的公司涌向同一个免费资源，它要么被耗尽，要么所有者开始收费或关门。把这个时间点当作规划里的一个情景，而不是意外。
04案例
纽芬兰北方鳕鱼：五百年的渔场，一纸禁令关了三十年
纽芬兰外海的北方鳕鱼曾是世界上最大的鳕鱼渔场，支撑沿海社区约五百年。1950 年代以后，装了雷达、声呐的大型拖网船让捕捞的范围和深度大幅扩大，1968 年鳕鱼捕捞量达到约 81 万吨的峰值。1986 年科学家重新核算后认为总可捕量需要减半才能保住种群，但年度配额没有改。1992 年，加拿大渔业部长约翰·克罗斯比宣布暂停北方鳕鱼捕捞两年；1993 年面对六个鳕鱼种群同时崩溃，禁令延长为无限期。后来的研究估计，北方鳕鱼的产卵亲鱼量下降了约 99%。这次关闭是加拿大历史上规模最大的产业停摆，纽芬兰渔工和鱼厂工人有三万多人失业，直到 2024 年，加拿大政府才解除这片海域的鳕鱼商业捕捞禁令，总可捕量定为 1.8 万吨。这是公地悲剧的教科书版本：每条船多捕一网都是划算的，配额制定者面对的是渔民生计和政治压力，种群的损失却没有人单独承担，等到账单一起到期，整个渔场已经没有了。它也正好落在哈丁描述的结构上：资源有限、可被耗尽、使用者互相竞争；而奥斯特罗姆获奖时被引用的正是大量由使用者自己管好的渔场，说明问题不在“共享”本身，而在规则和成本由谁来定、由谁来担。[4][5][2][3]
XZ Utils：一个人的“无偿爱好项目”，几乎成了全世界服务器的后门
xz 压缩工具几乎存在于每个主流 Linux 发行版里，但它长期由一个人维护。2022 年 6 月，维护者拉塞·科林在邮件列表里回应用户催更时写道，他照顾这个项目的能力相当有限，主要是因为长期的心理健康问题，并提醒大家这是一个无偿的爱好项目；同一封信里他说，最近在和一位叫 Jia Tan 的贡献者合作，此人将来也许会承担更大的角色。2024 年 3 月 29 日，微软工程师安德烈斯·弗罗因德在 oss-security 邮件列表公开说明，他在 Debian 测试版上注意到 ssh 登录异常耗 CPU、valgrind 报错，一路追查发现 xz 的上游代码和发布包被植入了后门，影响 5.6.0 和 5.6.1 两个版本；漏洞编号 CVE-2024-3094，CVSS 评分 10.0，植入者正是 Jia Tan。所幸受影响版本还没进入大多数生产系统。这里的公地是维护者的注意力和信任：无数公司免费使用这个库，几乎没人分担维护成本，单人维护的疲惫成了攻击者可以利用的缝隙。[6][7][8]
Read the Docs 与 SourceHut：AI 爬虫把带宽账单和运维时间甩给小站
Read the Docs 为开源项目免费托管文档。它在 2024 年 7 月的博客里说，2024 年 5 月有一个爬虫下载了 73TB 压缩后的 HTML 文件，其中近 10TB 发生在一天之内，带宽费超过 5000 美元；原因是爬虫的 bug 让它反复下载同样的文件，而且没有限速，也不支持 ETag 和 Last-Modified。对方公司在收到邮件后承担了费用，但另一次 10TB 的抓取，联系邮箱直接退信。屏蔽 AI 爬虫后，可下载文件的带宽从每天约 800GB 降到约 200GB，降了 75%。代码托管平台 SourceHut 的创始人德鲁·德沃尔特在 2025 年 3 月写道，他每周有 20% 到 100% 的时间花在对付激进的 LLM 爬虫上，这些爬虫无视 robots.txt，专挑 git blame、每一页 git log 这类最耗资源的页面，用分散的住宅 IP 绕过限流，每周造成几十次短暂宕机。两家都是开源基础设施的提供者而不是大平台，公地是它们向公众开放的服务器：对爬虫方来说多抓一遍几乎免费，代价由提供者买单，最后的结果是更多网站对所有机器访问关门。[9][10]
05误用与边界
把一切共享资源都当成必然的悲剧
哈丁的牧场是一个思想实验，不是规律。奥斯特罗姆研究的大量渔场、牧场和地下水，使用者自己定规则、互相监督，管得比标准理论预测的好。看到共享资源就主张私有化或一刀切收费，会错过更便宜的办法：边界清楚的使用者群体、透明的用量、大家认可的惩罚。
把公地悲剧当成给自己搭便车的借口
“反正别人也在抓、也在白用，我克制也没用”，这句话对一时成立，对长期往往不成立。规则通常是在滥用之后才出现，最早被封、被拉黑的，常常是最显眼、最肆无忌惮的那一个；你依赖的资源如果被耗尽，你也一起出局。
分不清公地和外部性
公地悲剧的前提是资源有限、可被耗尽、使用者互相竞争。如果资源不会被用坏（比如一份开源代码被多复制一次），问题就不是过度使用，而是没人投入维护和改进，那更接近“搭便车”导致的供给不足，药方也不同：要的是资助和贡献机制，而不是限量。
06检查清单
下次做相关决策前逐条过一遍。勾选只保存在你的浏览器里。
08来源
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10