使用我的大脑（AI替代思考的危险）Using My Fucking Brain

我现在很生气。不是生达里奥的气，也不是生山姆的气，更不是针对你——亲爱的读者。我是在生自己的气。

几天前，Sentry 出现了一个新的问题。我把链接复制过来，粘贴到我之前用 Claude Skill 构建的工具里，让 Claude 去调查一番。然后我请 Claude 提交一个 PR。这个 PR 被审核了，通过了，我也合并了它。

写下这部分内容让我感觉有点恶心：我根本没有亲自打开 Sentry 查看这个问题。也没有看 Claude 写的代码，更没有检查修复方案是否合理。这相当于把一封邮件转发过去，附言“有什么想法吗？”然后直接去吃午饭了。

当我意识到自己做了什么后，回去亲自进行了调查。打开了 Sentry，阅读了堆栈跟踪，查看了相关代码，从症状一路追查到原因再到解决方案。

和 Claude 的结果一样。好吧，至少这次是对的？

如果 Claude 错了，这篇文章就好写得多。我可以讨论幻觉问题，提醒大家小心，严肃地说一说生产环境中的软件，然后大家都会点头赞同。

但 Claude 是对的。可怕的是，就算它是错的，整个工作流程看起来也完全一样。

我是真的喜欢这些工具。我经常使用 Claude Code，为重复工作编写 Skills，让模型解释代码、找 bug、建议修复、总结长线程、起草乏味的文档。我不是站在 AI 洞穴外举着火炬挂上警告牌的人。此刻我正坐在洞穴里，笔记本开着，一边写文章一边让模型立刻帮我做事。

我之前写过“AI 可以帮你写代码，但不能替你做工作”。我依然相信这一点，可能比以前更信。这份工作的本质从来不是敲代码。工作是发现报告的 bug 只是表象；是反复读一遍堆栈中那行诡异的日志；是知道某个修复虽然技术正确却仍然不够全面。

这份工作就是你的大脑必须出现在现场的那部分。

有一种使用 AI 的方式，就像拥有第二个大脑。你打开问题，读错误信息，形成初步假设，再让模型挑战这个假设。让它搜索代码库，问还有什么能解释这个现象，让它写出修复方案的初稿。然后你阅读补丁，推敲细节，最后做决定。

这很棒，说实话可能就是理想状态。模型让你更敏锐，帮你保持对问题的整体把控，揪出你忽略的问题，把缓慢的流程变成高效的循环。

然后……就是我刚才做的事。

你还没读完问题就丢给机器。还没形成自己的理解就接受了它的解释。甚至还没搞清要修复什么问题就提交了 PR（！）。连 diff 都没看就让别人评审。因为检查通过、评审人批准，整个过程像在推进进度，你就点了合并。

要是幸运的话，几分钟后你会感到一阵胃部下沉。等等，我刚刚到底部署了什么？

我不觉得自己是特例。我们很多人在悄悄构建这样的流程：模型看到问题，模型读代码，模型写补丁，而我们只在最后一步来“认可”答案的形状。

如果我们不小心，就会让自己失去那些最初让我们变得有用的基本功训练。

需要明确的是，我并不介意代码是你自己敲出来的。我关心的是在部署之前你是否真正理解了它。我关心你能否解释这个 bug 为何发生、为什么这个修复是正确的、模型可能忽略了什么，以及什么情况下你会回滚代码。

因此，经过这次“事件”后，我制定了一条新铁律：如果仍无法解释变更的原因，就不能部署它。绝无例外。

这篇文章主要是写给自己的。我希望不是这样。我希望能以一种“功成名就”的姿态写下它，俯视那些粗心的工程师——他们匆忙将 AI 补丁合并到生产环境，而我这位“负责任的成年人”会仔细检查每一个 token。

不，事实并非如此。

我依然在这样做。我发现自己还没认真看内容就直接复制粘贴到模型里。我依然享受从问题直接跳到答案的那丝多巴胺快感。当模糊性变成 PR（合并请求）时，那种简洁感我也很喜欢。

但我不想成为那个不理解工作就点击合并按钮发布软件的人。

AI 应该让我思考得更好。它应该帮助我掌握更多上下文、看到更多可能性，并在大脑疲惫时帮我突破困境。

它绝不应成为逃避工作的舒适避风港。