⚠️ 这篇是写给只会用聊天型大模型、最近又怕自己跟不上 AI 新工具的人。最烦的，就是看完一篇长文章，还是不知道这件事跟自己有没有关系、现在要不要跟。你刷到“18年老问题终于修了”这种消息，最容易做错的，不是没点进去看，而是看完以后按错重点：以为关键是某个高手终于啃懂了旧代码。代价也不小，后面几小时的时间和注意力，都会花到错方向上。你本来只想省下划走前的10秒，最后可能赔掉更久。[C002]
我后来真正记住的，不是“终于修了”这四个字，而是这句反常识判断：老bug的克星不是天才，是病例分布。[C002] 具体场景很像我们平时刷更新：本来准备顺手划走，又怕自己错过了会影响下一步判断的那一点。问题是，如果你只盯表面热闹，就会一直围着“谁厉害、谁看懂了旧代码”打转，看不到真正改变局面的那一步。
那句英文原话是“Core dump epidemiology: fixing an 18-year-old bug”[C001]。这里不用想得太玄，白话一点，就是：先把崩溃当成一批一批的病例去看，而不是一次一次单独救火。Ubuntu 的错误追踪系统里，有个关键做法叫崩溃指纹（crash signature）：把相似崩溃归成同一类，每新增一次就给这一类加一次计数，再用出现次数判断哪个问题最重要。[C003]
这一步看着像后台杂活，实际特别值钱。因为工程师看到的，不再是零散抱怨，而是一张能下手的地图：哪类崩溃最常见，哪类问题最该先修。这个系统首页还直接写明，它每天从数百万台机器收集数十万级错误报告。[C004] 数字本身不是重点，重点是样本终于够大，老问题不必继续主要靠运气复现，至少能先稳定地被看见。
所以我现在看这类更新，先不看它列了多少功能，也不先崇拜“终于有人搞懂了”。我先问三件事：有没有把相似错误分桶？有没有持续计数？样本够不够大，能不能排出轻重缓急？一条更新值不值得看，不看它列了多少功能，先看它会不会改掉你下一步的判断。
这也是我觉得它适合转发的原因。它更适合转给那种只会用聊天型大模型、又总怕自己慢半拍的人，因为它真正给你的，不是一串新名词，而是一个筛选消息的办法；不太适合只想追热词的人，也不太适合马上就要源码细节的人。真要转，就转给同样怕跟丢、又容易被热闹带偏的人。下次再刷到“老问题终于修了”，先别急着看热闹，先看它有没有把分桶和计数做起来。