一句话总结：我选择将使用AI变为一种手动操作，因为我发现过度依赖它会导致能力逐渐退化。我建议大家谨慎对待将AI作为工作流程的核心部分。
2022年底，我第一次使用了AI工具，甚至早于ChatGPT的第一个版本。2023年，我开始在开发工作流程中使用基于AI的工具。最初，我对这些大型语言模型（LLM）的能力感到非常震撼。比如，我只需复制粘贴晦涩的编译器错误和C++源代码，AI就能告诉我错误出在哪里，这简直像魔法一样。
随着GitHub Copilot变得越来越强大，我开始越来越多地使用它。我还在我的编辑器中集成了其他各种LLM工具。使用AI成为了我工作流程的一部分。
然而，2024年底，我从代码编辑器中移除了所有LLM集成。虽然我偶尔仍会使用LLM，并且我认为AI对许多程序员来说可以非常有益，但为什么我不再使用AI驱动的代码编辑工具了呢？
特斯拉全自动驾驶（FSD）的启示
2019年到2021年，我开了一辆特斯拉。虽然我不会再做出同样的购买决定，但这并不是出于政治原因，而是因为特斯拉的汽车质量较低，价格过高，维修和保养也非常麻烦。
当我拥有特斯拉时，我尽可能多地使用全自动驾驶（FSD）功能。在高速公路上开启FSD，稍微放松一下，感觉非常棒。变道就像打转向灯一样简单，车子会自动完成。对我来说，驾驶就是上高速，开启FSD，偶尔告诉车子变道，然后听着音乐或播客放松。
如果你经常开车，你会知道在高速公路上驾驶时，很多事情都是自动完成的。保持车道和速度成为一种被动行为，不需要像读书那样的专注力，而是像走路一样，发生在你的潜意识中。
2019年到2021年，我几乎只开特斯拉进行长途驾驶。2021年后，我重新开普通汽车，这种转变完全出乎我的意料。在高速公路上驾驶需要我全神贯注，我不得不重新学习如何在不思考的情况下保持车辆在车道中央。
依赖特斯拉的FSD让我失去了自己进入“自动驾驶”状态的能力。
我与AI代码编辑器的经历
使用AI驱动的代码编辑器也有类似的体验。最初，我觉得在AI的帮助下，我的工作效率大大提高。我大部分时间做的工作并不复杂，AI就像开启特斯拉的FSD一样，我可以指导机器为我完成工作。
在业余时间，我开始在工作设备上使用个人账户进行一个副项目。在这个账户上，我没有访问Copilot和其他酷炫的AI工具的权限。这时，使用AI的感觉与我的特斯拉FSD故事非常相似。
我发现自己比一年前在基础软件开发方面的能力有所下降。突然之间，我清楚地意识到自己对AI工具的依赖有多深。每当我定义一个函数时，我都会在编辑器中停下来，等待AI工具为我编写实现。我甚至需要花些力气才能记住如何手动编写单元测试的语法。
随着时间的推移，AI在我的工作中也变得不那么有用。它不仅剥夺了我的乐趣，还让我在做出一些实现决策时感到不安。将决策外包给AI似乎更容易，但有时即使是最好的提示，AI也无法解决问题。很明显，由于我不经常练习基础知识，我在处理更复杂的问题时也变得不那么得心应手。
失去“指尖感觉”
** Fingerspitzengefühl** [ˈfɪŋɐˌʃpɪtsənɡəˌfyːl] 是一个德语词汇，字面意思是“指尖感觉”，意为直觉或本能，已被英语借用为外来词。它描述了一种高度的情境意识，以及能够最恰当和机智地做出反应的能力。1
定义“资深”是非常困难的。虽然在我看来，“资深”很大程度上体现在软技能上，但在技术硬技能方面，很多都归结为“指尖感觉”。你使用一种语言、框架或代码库的时间越长，你就越能培养出这种直觉，知道什么是正确的方法。那种“感觉不对劲”的直觉逐渐转变为“我们应该这样做”的直觉。
这种培养出来的直觉不仅仅体现在架构层面。很大一部分体现在底层细节中，比如何时使用指针（或哪种类型的指针），是使用断言还是检查，当标准库中有多个选项时选择哪一个（尽管资深C++程序员似乎仍然无法达成一致）。
这种直觉正是我在过度依赖AI工具时逐渐失去的。而我还是一个首席开发者。当我看到很多人热衷于“氛围编程”时，我不禁想：你究竟如何期望通过氛围编程成为资深开发者？当AI工具失效或变得过于昂贵时，你从哪里获得维护和扩展这些代码库的技能？
即使有更大的上下文窗口、更多的计算能力、推理模型或代理，AI仍然会有无法做到的事情。随着时间的推移，AI工具会变得越来越强大，这是肯定的。但当你收到一条Slack消息说“网站在生产环境中运行正常，但应用程序挂了；我在本地试过，那里没问题，Sentry里也没有任何记录”时，祝你好运让AI代理为你解决这个问题。也许它可以，也许不行。当AI代理无法解决时，你的回复会是“抱歉，Cursor没搞懂，明天再试试”吗？
没有这些工具，你也能行
有时候，你会觉得如果不使用AI，六个月后就会失业。我们已经听到“3-6个月后”的故事两年多了。我早就停止相信CEO们关于“3-6个月后”功能的承诺。2019年我买特斯拉时，花了6400欧元购买了一个“3-6个月后”就会推出的功能，而五年过去了，这个功能仍然没有如承诺的那样出现。
目前，让AI为你编写代码在比大学项目更大的项目中不太可能奏效。在处理遗留系统或企业中的大型项目时，或者当你需要处理并咨询大量依赖内部结构时（比如我在使用Unreal Engine时），AI工具通常无法解决问题。当你需要处理内部DSL、工具或框架时，祝你好运让LLM生成有用的输出。在某些行业，你甚至根本不能使用AI工具，原因多种多样。
有些事情你真的不应该依赖AI。比如在实现JWT2签名或RBAC3等认证系统时，在提示中添加“并且它应该是安全的”并不能保证安全性，如果它是在包含CVE4的GitHub代码上训练的。在安全方面，你应该成为那个负责并完全理解的人。关键系统应该由人类编写和审查，如果我们走向一个AI代理编写代码、另一个审查自动生成的PR、再由另一个AI代理部署代码的局面，我们很快会看到安全问题的激增。
我的底线
我仍然偶尔使用AI。我认为如果明智地使用，它可以成为一个很棒的工具。我的底线是集成。我将AI与我的代码编辑器完全分开。所有的上下文，我手动添加。我故意保持较高的操作成本，以降低我的使用频率。
我在工作中使用AI的例子包括“将这些Go测试从结构体转换为映射中的测试”、“将这个计算转换为SIMD”或“当内容类型为application/zlib时，解码主体”5。我设置了一些自定义指令，只给我更改后的代码，并给我添加它的说明。这样，我仍然是那个在代码库中做出更改的人。仅仅批准一个Git差异是不够的，我想手动添加代码，只有这样我才能有信心签署并对其负责。
AI的另一个很好的用例是学习。我经常有一些非常不常见的问题，因为我有一些非常小众的兴趣。事实证明，在使用ECS的自定义游戏引擎中添加网络代码并没有很多学习资源。对我来说，有效的方法是让AI解释代码片段，比如“解释这段汇编代码”、“解释这个着色器的作用”、“哪些书籍深入探讨了解决游戏引擎中客户端/服务器不同步的问题”。AI有时会在这方面遇到困难，我得到的结果参差不齐，但仍然比搜索引擎好得多。我甚至会在这篇文章中使用它，虽然不是用于写作内容，而是用于检查6。
这种使用AI的另一个好处是成本。没有不必要的API调用，手动管理上下文，并对LLM设置进行更多控制。我使用一个桌面应用程序，连接了多个不同的LLM。在过去的三个月里，我每天都使用它，总共消耗了大约4美元的信用额度。
我想补充的是，在某些事情上我更加严格。在我的个人网站上，我不希望有任何AI生成的内容，无论是文本还是图像。我个人不喜欢AI生成的图像或“艺术”，原因多
