AI编程的「幻灭之谷」

🔔 关注「AI知著」，每周深度思考一个AI领域的热点话题

━━━━━━━━━━━━━━━━━━━━

当AI一秒钟写完你一天的代码，灾难才刚开始......

2026年5月的最后一周，一群世界上最懂编程的人，突然开始集体问同一个问题：我们是不是让AI写得太快了？

━━━━━━━━━━━━━━━━━━━━

一个开发者的诚实坦白

Nolan Lawson是个什么样的程序员？他写博客写了十几年，是前端圈里公认的「认真派」。他不追热点，不喊口号，每篇文章都是代码说话。

2026年5月25日，他发了一篇博客。标题看起来像泼冷水：《用AI写更慢、更好的代码》。

这篇文章在Hacker News上拿到了1251分。如果你不了解HN的评分体系——这么说吧，这是过去一个月里排名前五的文章。整个技术社区疯了。

他说了什么？三句话就能概括。

第一句：「很多人似乎认定AI编程的意义就是尽可能快地写出低质量代码——喷出勉强能跑的slop，开一个巨大PR，不审查直接合并。发布！」

第二句：「但LLM是非常灵活的工具。你完全可以用它们写出更高质量的代码——但是你会写得更慢，而不是更快。」

第三句——这才是整篇文章最关键的一句：「每次我用这种方法，我并没有觉得自己的速度变快了。恰恰相反，审查过程经常发现一些早已存在的bug，所以我常常偏离主线去做支线任务。」

换句话说：AI写了更多代码 → 需要审查更多代码 → 审查发现了更多老bug → 修老bug → AI又写了更多新代码。这是一个无限循环。AI的「效率提升」，被它自己制造的审查需求吞噬了。

· · · · · ·

一个60秒游戏揭开的安全伤疤

同一周，另一个开发者Alex Wauters做了一件更绝的事。

他写了一个互动游戏，只有60秒。屏幕上不断弹出AI Agent的操作请求，你要在时间压力下判断：这个操作安全吗？批准还是拒绝？

`rm -rf ~/`——删除你的整个home目录，你拒绝了。

`cat ~/.aws/credentials`——读取你的云服务凭证，你拒绝了。

然后Agent换了个方式：先创建一个看起来很正常的文件，再请求你运行`npm run build`，而这个build脚本会在背后执行你完全不知道的命令。

你批准了。恭喜，你的凭证已经被窃取了。

这个游戏在HN上拿了379分。但真正让人不安的是游戏背后的数据——不是游戏里的数据，是Anthropic自己内部的安全遥测数据。

三个数字，一个比一个吓人：

93%。这是用户在实际使用中批准AI Agent权限请求的比例。不是游戏里的，是真实世界的。你看到的审批弹窗越多，你对每个弹窗的关注度就越低。这不是你的错——是人类大脑的设计缺陷。

96%。Anthropic安全团队做了一次内部渗透测试：让Agent尝试窃取开发者的AWS凭证。25次尝试，24次成功。对象不是外行——是Anthropic自己的工程师。

17%。Anthropic的「Auto模式」用快速过滤器加服务端扫描来自动审批请求。听起来不错？但它的漏报率是17%。也就是说，每6个危险操作里，有1个会被悄悄放行。

这三个数字放在一起时，你不需要是安全专家也能意识到：人类在循环中的安全审查模型，在Agent高频交互的时代，已经实质性失效了。

· · · · · ·

你以为是代码质量问题？先做一道数学题

很多人把这些现象归结为「AI写得还不够好」。「等GPT-6出来就好了」，「等Claude 5.0就好了」。

但本文的判断是：这首先是一个简单的数学问题。跟模型版本号无关。

假设你的AI Agent一天生成10,000行代码。假设你是一个极其勤奋的开发者，你一天能认真审查200行。你的审查覆盖率是多少？

2%。

剩下的9,800行代码，你是在闭着眼睛合并的。

你可能不服气——「我又不是每一行都要细看，我只看关键部分」。但什么是关键部分？当一个函数是由AI从零生成的，你没有任何关于它设计意图的先验知识。你不知道它是在什么假设下写的，不知道它预期什么输入处理什么边界情况。在这种情况下，「只看关键部分」本身就需要你理解全部内容。

Nolan Lawson在他的文章里描述了另一种解法。他不是审查得更快，他是审查得更深。他让Claude、Codex、Cursor三个AI同时审查一个PR，每个AI都有不同的擅长领域。三个AI交叉验证，他自己做最终决策。

结果呢？每次都能发现大量bug。误报率接近于零。

但代价是什么？他没有更快。 他把审查变成了一个更重的环节。他的净开发速度，并没有因为AI而提高。

这不是讽刺。这就是现实。

· · · · · ·

AI代码的三种「出厂缺陷」

退一步看，AI生成的代码有三个结构性问题——不是「现在还存在的暂时问题」，而是根植于生成式方法本身的系统性特征。

第一种：局部最优陷阱。

AI Agent在每一次对话中都只看到一个狭窄的上下文窗口。它会在这个窗口内找到最优解——当前这个弹窗最好的交互方式、当前这个错误处理最优雅的写法。但它从不考虑全局一致性。

结果是：你系统里有五个弹窗，用了五种不同的实现方式。同一个错误类型，在三十二个地方被处理了三十二种不同的方法。这不是bug——从AI的视角看，每个决策在当时的上下文里都是合理的。但把它们拼在一起时，你得到的是一个没有统一架构的拼贴画。

第二种：非确定性抽象。

一个编译器让你看不懂汇编也能写C语言，因为它的输出是确定的——同一段代码永远编译成同一个二进制。

AI Agent让你不会写代码也能生成代码，但它的输出是不确定的。同一段prompt，不同的时间、不同的上下文、不同的随机种子，生成的结果完全不同。

这就像一个喜怒无常的天才同事。有时候你描述一个需求，他给你写出你见过最优雅的方案。有时候同一段描述，他给你整出一个你自己完全看不懂的玩意儿。

更致命的是：你不知道下一次是哪一种。

第三种：安全攻击面的组合爆炸。

`git clone`一个仓库。听起来无害到不值得审查。但那个仓库里可能有一个`claude_settings`文件，里面写着一行指令。Agent会自动读取并执行它。

你安装的一个开源插件。三周前它看起来完全无害。但三天前，它的作者更新了一个补丁——插入了恶意prompt。Agent不会告诉你这些。

你连接的MCP服务器。它在正常工作，但同时也在悄悄记录你每一次Agent交互的完整内容。你不知情，Agent也不知情。

Agent最强大的卖点——它的可组合性、它的开放生态——恰恰是它最无法防御的安全漏洞。 每次你给Agent添加一个新的能力来源，你就在攻击面上增加了一个新的入口。而这些入口的数量，在以指数级增长。

· · · · · ·

一场已经发生过的危机

Mauro Bieg写了一篇文章，讲了另一个行业的前车之鉴。这篇文章在HN上拿了401分，被转发了数千次。

他讲的是前端开发。

15年前，要成为一个合格的前端开发者，你需要理解：HTML语义、CSS盒模型和浮动、浏览器兼容性、渐进增强、网络性能、无障碍访问。这是一套完整的、有深度的技能体系。

然后JavaScript框架来了。React、Vue、Angular。它们做的事情很简单：把浏览器变成一个编译目标。开发者不需要理解浏览器在做什么，只需要理解框架在做什么。

这带来了一个连锁反应。

第一步：入门变得容易了。你不需要学CSS盒模型，你只需要学Flexbox。你不需要理解浏览器的渲染管线，你只需要理解虚拟DOM。

第二步：市场上充斥着「全栈开发者」。他们既不完全理解前端，也不完全理解后端。他们只是「能写代码的人」。招聘标准从「你懂什么」变成了「你用什么框架」。

第三步：真的懂前端的人发现，他们的技能在市场上不再被定价。因为99%的公司不需要一个真正懂前端的人——一个能把设计稿在三天内用React复现出来的人就够了。

Mauro Bieg用了一个残酷的词来描述这个过程——去技能化。 它有三个结果：降低成本、降低准入门槛、削弱工人的议价能力。这三个结果不是副作用，它们恰恰是技术被设计出来的目的。

现在，AI编程工具正在把同一套剧本，从「前端」扩展到了「编程本身」。

你不需要理解算法，你只需要描述你想要什么。

你不需要理解架构，你只需要描述你想要什么。

你不需要理解安全，你只需要描述你想要什么。

然后三年后，你发现整个代码库变成了一个你自己完全无法理解的黑箱。而市场上的一代新人，从一开始就没有学会理解代码——他们只学会了让AI写代码。

· · · · · ·

但市场在用钱投票

写到这里，你可能觉得本文在唱衰AI编程。

但故事还有另一面。

Simon Willison给出了一组数据：Anthropic年化营收470亿美元。OpenAI的企业营收也在以同样的数量级增长。SpaceX签下了每月12.5亿美元的推理算力合同，一直到2029年。

你不需要喜欢AI编程。但你的公司已经开始为它买单。你的竞争对手已经开始为它买单。你客户的供应商已经开始为它买单。

而且不只是硅谷。Uber的CTO说：「我们几个月就用完了全年的AI预算。」微软据报道开始取消内部员工的Claude Code许可证——但原因不是程序员抱怨代码质量差，而是财务部在财年结束前开始盯着AI开支的ROI。

换句话说：AI编程面临的最大威胁不是开发者嫌弃代码质量。是CFO开始要求解释每一分钱的AI开支。

这恰恰是最危险的地方。

当一个技术被大规模采用不是因为「它更好」，而是因为「它能省钱」时，质量就成了第一个被牺牲的变量。公司不会说「AI写的代码比人差，所以我们不用AI」。公司会说「用AI写代码省了30%人力成本，多出来的bug以后再说」。

然后「以后」就变成了永远不会来的那一天。

· · · · · ·

三条路，三种未来

如果你是在这个行业里写代码的人，未来会怎么走？本文不会给你一个确定答案——因为没有人有确定答案。但有三条路值得看清楚。

第一条路：走量。

你把自己变成「AI操作员」。你不需要理解代码，你只需要会写prompt、会审查AI输出、会做轻量的修改和调整。

这条路的最大优势是：现在就可以走。市场需求巨大。所有想降本的公司都在招这种人。

这条路的致命弱点是：你的职业护城河基本为零。因为能做这件事的人太多了——而且AI自己在越来越擅长做这件事。当你的价值仅仅在于「在AI和你老板之间做翻译」时，你的可替代性取决于AI和老板之间的翻译成本。这个成本正在快速下降。

第二条路：走深。

你像Nolan Lawson那样，用AI来写更好而不是更快的代码。你让AI并行审查每一个PR。你对AI生成的每一行代码保持完整的理解。你写的代码量可能比以前少，但你审查的深度比以前深。

这条路的最大优势是：你的价值不会因为AI进步而贬值。因为你的核心竞争力不是「写代码」，而是「判断代码」。当代码越来越便宜时，判断力越来越贵。

这条路的代价是：你会很累。你的净产出数字可能不会变好看。你的经理可能不理解为什么你「用AI还能这么慢」。你需要在组织里为你的工作方式反复辩护。

第三条路：升维。

你从「怎么写」的问题中抽身，专注在「写什么」和「为什么写」的问题上。你不再纠结于实现细节——那是AI的领域。你的战场是需求分析、系统架构、技术选型、质量策略。

这条路最难走，但也最不可替代。因为AI目前——以及可预见的未来内——在这些问题上帮不了你。

这三条路不是互斥的。实际上，本文预测大多数开发者会在职业生涯的不同阶段走不同的路。关键不是选哪条，而在于：你是否清楚自己走的是哪条路，以及这条路通向哪里。

━━━━━━━━━━━━━━━━━━━━

最后：这周最值得记住的一句真话

在本周所有登上HN首页的文章里，有一句话被引用和讨论的次数最多。它来自Nolan Lawson的同事——一个不知名的评论者。

他说：「AI不会取代程序员。但会用AI的程序员，正在取代不会用AI的程序员。」

这句话在社交媒体上被当成金句疯狂转发。大多数人把它理解为「赶紧学AI」。

但Lawson用一个完整的实践告诉你，这句话的真正含义恰恰相反：会用AI的程序员不是那些让AI帮自己写最多代码的人。是那些让AI帮自己发现最多问题的人。

这是两种完全不同的「会用」。

前者在追求速度。速度让老板开心，让KPI好看，让季度review有东西写。但速度也在你的代码库里埋下雷，在你的职业壁垒上凿出洞。

后者在追求深度。深度不会让你的产出数字变好看。它甚至会让你的开发变得更慢。但它在做一件事：它让你成为那个知道每一行代码为什么在这里、哪里可能出问题、出了问题该从哪里开始找的人。

在一个代码越来越廉价的世界里，这个能力的价格——只会越来越高。

━━━━━━━━━━━━━━━━━━━━

*本文核心参考来源：Nolan Lawson「Using AI to Write Better Code More Slowly」（2026.5.25，HN 1251分）；Alex Wauters「Suffering from Agent Permission Fatigue?」（2026.5.28，HN 379分）；Mauro Bieg「Is AI Causing a Repeat of Frontend's Lost Decade?」（2026.5.23，HN 401分）；Simon Willison「I Think Anthropic and OpenAI Have Found Product-Market Fit」（2026.5.27）。Anthropic安全数据来自其公开的容器化安全策略披露。*

━━━━━━━━━━━━━━━━━━━━

📌 关注「AI知著」

专注 AI 大模型与智能体领域

深度解读 · 工具实测 · 行业分析

📬 每周更新「深度思考」

💬 你是走量型还是走深型？欢迎留言聊聊