AI让简单的更简单，困难的更困难

晚风吹人冷

【AI让简单的更简单，困难的更困难】

AI并不总是让我们更快。

过去开发者用谷歌搜索，读StackOverflow的回答，做研究，结合自己的情况得出结论。没人会说“是谷歌帮我写的”。但现在我开始听到“是AI帮我做的”。这要么是在夸大其词，要么意味着开发者没有形成自己的判断。两者都很糟糕。

在一个个人项目中，我让AI代理往一个文件里添加测试。文件原本500行，执行后变成100行。我问它为什么删了其他内容，它说没删。然后说文件之前不存在。我给它看git历史，它道歉说应该先检查文件是否存在。

想象一下这发生在医疗系统的代码库里。

我花在和代理争论、恢复文件上的时间，比自己写测试还长。AI辅助有时候比不用还费时间，这听起来反直觉，但确实发生了。

大多数人忽略了AI辅助开发的一个关键问题：写代码一直是工作中最简单的部分。真正困难的是调查、理解上下文、验证假设、知道为什么某个方案在当前情况下是正确的。当你把简单的部分交给AI，剩下的不是更少的工作，而是只剩下困难的工作。如果你因为AI已经给了答案就跳过了调查，你就没有评估它输出的上下文。

阅读和理解别人的代码比写代码难得多。AI生成的代码就是别人的代码。我们把开发者擅长的部分（写）外包给了机器，留给自己更难的部分（读和审查），却没有通过亲自编写建立起来的上下文。

有人说AI让他们效率提升10倍，也许只是把0.1倍的工程师变成了1倍的工程师。技术上确实是10倍，但问题是这到底是生产力提升，还是暴露了他们之前做了多少调查工作。

倦怠和低质量交付会吞噬AI带来的任何生产力收益。你无法通过优化来解决人们太累而无法清晰思考的问题。

我用“AI是高级技能，初级信任”来解释AI编码代理的实际工作方式。它们写代码的技能很高，但我们必须像对待初级工程师一样审查它们的输出。代码看起来不错，可能也能运行，但我们应该更仔细地检查，因为它们没有经验。

换个角度看：AI编码代理就像一个读书很快的聪明人刚从街上走进来。他们可以帮忙调查，也能写一些代码，但他们没参加上周讨论重要背景的会议。

开发者需要对每一行代码负责，不只是自己写的，AI生成的也一样。如果你因为有人设定了不切实际的速度目标而复制粘贴AI输出，六个月后当新团队成员试图理解那段代码时，你就有麻烦了。凌晨两点代码崩溃时也一样。“AI写的”在这两种情况下都帮不了你。

那AI如何让困难的部分变简单？前几天有个生产环境的bug，用户在一次大发布后几小时发来了问题。做改动的开发者30分钟后要去上课，而我已经在家了。我用AI帮忙调查，告诉它bug一定和最近的改动有关，解释如何复现。结果发现一些废弃的方法优先于当前的时区感知方法，导致时区转换一直不正确。15分钟内我就有了根本原因、解决方案思路和GitHub issue里的调查笔记。开发者确认了修复，其他人测试部署，我下楼取外卖。

没有紧急救火，没有加班。AI做了调查的苦力活，我提供上下文并验证，开发者确认方案。这才是AI帮助解决困难部分的正确方式。

有评论者分享了一个精辟的观察：他尝试用AI写一个复古模拟器，效果很好；但尝试写一个高度专业领域的应用时，大量提示也没能接近目标。原因很简单：GitHub上有成千上万的模拟器，这是“令人尴尬的已解决问题”，存在于大语言模型的潜在空间里。而他尝试做的事情在GitHub上没有任何例子。

AI是巨大的力量倍增器。如果你的代码库基础差、方向错、到处是补丁，它只会写出同样风格的代码。但如果你的代码基础好、高度一致、从不允许补丁，AI就会保持那种干净的风格，效果惊人。代码基础决定一切。

这让我想到一个更深层的问题：我们这些年作为程序员，在让已解决的问题易于访问方面做得很差，总是不断重新发明轮子。AI也许还没有真正创造出什么新东西，但它确实是一个不错的已解决问题数据库。

只是希望我们不要过度依赖当前的AI，以至于失去自己解决新问题的能力。

www.blundergoat.com/articles/ai- ... he-hard-part-harder