01原理
间接学习说的是：一个人一辈子能亲身经历的事很少，能犯的错也有限，而且有些错只能犯一次。别人已经试过、失败过、记录下来的东西，是一座现成的、几乎不要钱的实验库。不去用它，等于坚持用自己的身体去重做所有实验。
芒格在 1986 年的演讲里把这件事讲成了反话：想过得痛苦，就只从自己的经历里学。他提醒台下的学生，人类常见的灾难几乎都不新鲜，酒驾、邪教、重复前人明显错误的生意失败，都是有人早就踩过的坑。紧接着他讲了另一半：不只是别人的失败，别人最好的成果也要学，牛顿就是先把前人的工作吃透，才说出自己站在巨人的肩上。
到 1994 年，他把间接经验放回了自己的整套方法里：孤立的事实记不住、用不上，要挂在一个由多种模型组成的格栅上，而挂上去的经验，既有自己的，也有别人的。换句话说，读一个失败案例的价值，不在于记住那个故事，而在于把它归到某个机制下面，下次在另一个场景里认出同一个机制。
对十人以内的 AI 公司，这个模型的分量更重。你们的预算、跑道和声誉都承受不起太多次亲身试错，而这个行业恰好每周都有别人的事故、复盘和漏洞报告公开发布。别人花几个月、几百万美元换来的教训，你花一个下午就能读完。
为什么成立
为什么成立？第一是成本结构。亲身试错的成本由你独自承担，有时是不可逆的；间接学习的成本只是时间和注意力。只要别人的情况和你足够相似，读一次复盘的期望收益远高于成本。第二是样本量。一个团队几年里只能碰到几十次值得学的失败，一个行业每年公开的事故和复盘是成千上万。只看自己的样本，你对风险的估计会被极少数亲身经历左右。
心理上，人偏偏不爱这样学。亲身经历鲜活、带情绪，记得牢；别人的教训抽象、隔着一层，容易被一句“我们不一样”打发掉。过度自信让人觉得那是别人能力不够，自己不会犯；单个组织又往往不愿公开自己的失误，教训就锁在内部。所以真正有效的间接学习，常常要靠制度：有人负责收集，有人负责分类，报告的人不受惩罚，读的人有固定的时间去读。
02芒格怎么说
芒格最集中讲这个模型，是 1986 年在哈佛学校的毕业演讲。他用反着说的方式开出“保证痛苦的药方”，第二条就是：凡事只从自己的亲身经历里学，尽量少从别人的成败里学。他接着说，人类常见的灾难几乎没有原创性，生意失败多半是在重复前人显而易见的错误；另一面是不学前人最好的成果，他拿牛顿“站在巨人肩上”作反例。1994 年在南加大商学院，他把这件事放进格栅：经验分间接和直接两种，都要挂到模型上才算用得上。2007 年在南加大法学院，他又引了西塞罗的话，说不知道自己出生前发生过什么的人，一辈子像个孩子。
My second prescription for misery is to learn everything you possibly can from your own personal experience, minimizing what you learn vicariously from the good and bad experience of others, living and dead.
我开的第二个痛苦药方是：一切尽可能从你自己的亲身经历中学，尽量少从别人——活着的和死去的——的好坏经历中间接地学。
How little originality there is in the common disasters of mankind
人类常见的灾难里，原创的成分少得可怜。
And you've got to array your experience—both vicarious and direct—on this latticework of models.
你还得把你的经验——间接的和直接的——都排列到这个模型格栅上。
A man who doesn't know what happened before he was born goes through life like a child.
一个人如果不知道自己出生之前发生过什么，一辈子都像个孩子。
03怎么用
- 01
建一个“别人的事故”文件夹，按机制归档
指定一个人，每周花一小时收集和你们产品形态相近的公开事故、复盘和漏洞报告，比如智能体误删数据、提示注入导致数据外泄、账单失控。每条只记三件事：发生了什么、根本机制是什么、在我们的系统里对应哪个位置。按机制而不是按公司归档，这样半年后你看到的是“同一类错误出现了七次”，而不是七个零散的故事。
- 02
做任何新功能前，先查有没有人做过并失败
在设计评审的模板里加一栏“前人怎么失败的”：上线一个新的工具调用能力、一种新的定价、一个新的分发渠道之前，先找三个做过类似事情的团队，看他们公开讲过的坑。找不到，要写明找过哪里；找到了，要写明这次的设计怎么避开。这一栏空着不许过评审。
- 03
向最好的人学，不只向出事的人学
芒格在同一段话里把别人的好经验和坏经验并列。除了读事故，也要读做得好的团队怎么做：他们的评测怎么搭、权限怎么分、定价怎么试。挑两三个你认为在某件事上做得最好的团队，把他们公开的方法逐条和你们的现状对比，差在哪里就写下来，排进下个月的计划。
- 04
让内部的小事故也变成别人能读的材料
间接学习也适用于公司内部：一个人踩过的坑，应该让另外九个人不用再踩。规定任何影响用户或花掉意外成本的事，48 小时内写一页复盘，只讲事实和机制，不追究个人。复盘写得诚实的人要被感谢，而不是被追责，否则下一次就没人写了。
04案例
莱特兄弟：先把已知的全学一遍，再加上自己的一点
莱特兄弟在代顿开自行车店。按史密森学会的记述，1896 年他们读到德国滑翔先驱李林塔尔在一次滑翔中坠亡的报道，重新燃起了对飞行的兴趣。1899 年 5 月底，威尔伯写信给史密森学会（学会 6 月 2 日收到），要该学会出版过的飞行资料，信里说自己是个爱好者，不是那种抱着一套私人理论的怪人，他想先利用一切已知的东西，再尽可能添上自己的一点，帮助后来最终成功的人。史密森学会寄去几本小册子和一份书单，他又花一美元买了兰利的《空气动力学实验》。传记作者汤姆·克劳奇称这是史密森学会历史上最重要的一次通信。按学会的说法，研读这些资料一年多之后，兄弟俩已经接近解决平衡和操控问题；1903 年 12 月 17 日，奥维尔完成了 12 秒的动力飞行。这正是芒格讲的两面：别人的死亡让他们看清了真正的难题，别人的成果让他们不必从零开始。[4]
TWA 514：六周前已经有人差点撞上同一座山
1974 年 12 月 1 日，TWA 514 航班在云中进近华盛顿杜勒斯机场，机组误解了管制许可，下降到 1800 英尺，撞上弗吉尼亚的一座山顶，机上无人生还。据 NASA 航空安全报告系统（ASRS）的回顾，六周之前，一架联合航空的飞机遇到了类似的许可误解，差一点撞上同一座山。机组落地后向公司报告，联合航空向自己的飞行员发了警示，但当时没有任何渠道把它告诉其他航空公司。事后业界认定，安全信息必须在整个航空界共享。1975 年 8 月，美国联邦航空局和 NASA 签署协议：联邦航空局出资并提供豁免条款，NASA 作为中立第三方收集和分析报告，报告自愿、保密、不用于处罚。系统 1976 年 4 月开始运行，到 2016 年已处理超过 130 万份报告。一家公司的教训没能变成另一家公司的知识，代价是一架飞机；ASRS 做的，就是把间接学习变成制度。[5]
AI 事故数据库：照着航空业的样子，给 AI 失败建一个公共档案
2020 年 11 月，肖恩·麦格雷戈发表论文介绍 AI 事故数据库。他的出发点是：航空这类成熟行业会把真实世界的失败收进事故数据库，而智能系统在现实中造成伤害时没有共享的记录，各家公司于是反复犯同样的设计、开发和部署错误。数据库首批收录了一千多份事故报告。项目现由非营利组织负责任 AI 协作组织维护，执行主任是麦格雷戈本人，有一名主编负责事故编辑；它的介绍页把自己类比为交通领域的事故数据库和计算机安全领域的漏洞编号库，收录标准有意放得很宽，拿不准的也鼓励提交。这是一个人员很少的组织在做的事，但对小团队的用处很直接：上线一个面向用户的 AI 功能之前，可以先在库里按场景检索，看看同类系统在别人那里出过什么事。[6][7]
西蒙·威利森的“致命三要素”：把十几家产品的漏洞归成一个机制
独立开发者西蒙·威利森长期记录针对大模型产品的提示注入攻击。2025 年 6 月 16 日，他把这些案例归纳成“致命三要素”：一个智能体同时能读私人数据、会接触攻击者可控的内容、又能向外发送信息，攻击者就能骗它把私人数据送出去。文中列出的出过此类问题的产品包括微软 365 Copilot、GitHub 官方 MCP 服务器、GitLab Duo、ChatGPT、谷歌 NotebookLM、亚马逊 Q、Slack、Mistral Le Chat、xAI 的 Grok 和 Anthropic 的 Claude iOS 应用等。他说多数漏洞被厂商很快修复，通常是堵上外传的通道；但当用户自己把几种工具组合起来时，厂商就保护不了他们，唯一安全的办法是不让三者同时出现。这些都是大公司的产品，付学费的也是大公司；对一个正在给智能体接工具的小团队，这篇文章相当于一份免费的事故合集，而且已经替你归纳到了机制层面。[8]
05误用与边界
只读幸存者的经验
公开讲经验的多半是成功者，他们的做法被写成方法论，而用同样做法失败的人没有发言机会。只从成功故事里学，你学到的可能只是运气。读别人的经验时，至少要同时找同类做法的失败案例，看成功的条件是不是你也具备。
照搬结论，不看条件
别人的教训来自别人的处境：规模、客户、模型版本、监管环境都可能不同。大公司因为合规砍掉的功能，未必是你也该砍的；去年某个模型做不到的事，今年可能已经能做到。间接学习要学的是机制，而不是结论，每次都要问一句：让那件事发生的条件，在我们这里成立吗？
读得太多，做得太少
收集别人的复盘很容易变成一种看起来勤奋的拖延。间接学习的目的是少犯可避免的错，而不是替代你自己的实验。有些事只有亲手做了才知道，尤其是你的用户怎么反应。读到的教训要么变成一条具体的设计约束或检查项，要么就不必再读第二遍。
06检查清单
下次做相关决策前逐条过一遍。勾选只保存在你的浏览器里。
08来源
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8