这个 bug 是 Claude 修的，我负责在旁边紧张

看到仓库就 star，clone 下来，然后让它永不见天日——这个毛病我熟。但我今天要说的是个狠人：dev.to 上有个哥们儿叫 Daniel，拿一个自己从没打开过的仓库，报名参加了 Bug Smash 比赛。

他挑的 issue 也很亲民：用户只发了一篇文章，仪表盘的 Posts 计数器显示 2。原因？侧边栏数字用的是 @user.articles_count，一个缓存计数器，它不管三七二十一，full_post 也数，status 也数，全收。1 就成了 2。

数学老师看了都得沉默。

更绷不住的是，这哥们儿根本不会 Ruby。bug 是 Claude 找到的，也是 Claude 修的，他一行代码没写，全程负责“选 issue”和“紧张”。

【当事人回忆：这个 bug 是 Claude 修的，我负责在旁边紧张。】

最冤的是验收。AI 修完了，回归测试也安排上了：一个用户，一篇 full_post、一篇 status、一篇归档文章，计数应该显示 1。信心满满推上 CI，第一轮就挂——status 类型的文章不允许带 body_markdown，测试默认生成的那个字段被整个仓库拒了。

一个找 bug、修 bug 顺畅得像开了挂的 AI，最后被测试工厂的设置绊了一跤。

这大概是它整晚最像人类的一次操作。

评论区还在认真讨论缓存计数和过滤视图的一致性风险。我只想给这哥们儿点个赞。以前这种 bug 的渡劫姿势是熬夜，现在换汤不换药，还是熬夜——只是你熬着夜，在给 AI 把关。

（郑重声明：本段子不构成对你 star 列表的控诉。如有雷同，评论区扣个同款 🫠）