你以为AI写的是「正确代码」，其实它只是「貌似可信的代码」

快速导读：一篇技术博客通过一个惊人的案例揭示了LLM编程的陷阱：一个由AI生成的SQLite重写版本，代码能编译、能通过所有测试，但在最基础的主键查询上，比原版慢了整整20171倍。问题不在于语法，而在于AI只会生成“看起来对”的代码，却无法理解性能背后的核心设计。

一个LLM生成的Rust版SQLite重写项目，在最基础的主键查询任务上，比原版慢了20171倍。执行100行查询，官方SQLite用时0.09毫秒，而这个AI生成的版本，花了1815毫t秒。

最诡异的是，这坨代码能完美编译，通过所有单元测试，甚至文档都写得像模像样。它看起来、感觉起来都像一个正常的数据库。除了慢得像一场行为艺术。

你以为LLM写的是「正确代码」，其实它生成的是「貌似可信的代码」（Plausible Code）。这二者之间有一条致命的鸿沟。

作者深挖代码后发现，AI漏掉了一个极其关键的检查。这个检查能让主键查询直接通过B-tree实现O(log n)搜索。没有它，每一次查询都退化成了全表扫描，性能直接掉到O(n²)。这一个细节，就是26年工程经验和纯粹模式匹配的区别。

这个模式反复出现。同一个开发者用AI写的另一个项目——一个82000行代码、带智能预测的磁盘清理工具，只是为了解决一个一行cron定时任务就能搞定的问题。AI完美执行了“构建一个复杂的系统”这个指令，却完全没理解“解决问题”的真实需求。

这是一种被称为“谄媚”（Sycophancy）的AI行为模式：模型倾向于生成用户想听到的，而不是用户需要听到的。它不会反问“你确定要这么做吗”，它只会热情地把你描述的任何东西，无论多离谱，都给实现出来。

这正在改变工程师的价值评估标准。当代码的生成成本趋近于零，稀缺的就不再是写代码的能力，而是“知道什么是正确”的能力。是你能不能在57万行看似正常的代码里，找到那一个被遗忘的、决定系统生死的关键检查。

如果你无法解释AI生成的代码为何选择A算法而非B算法，那你不是在使用工具，你是在掷骰子。

真正拉开开发者差距的，不再是生成代码的速度，而是验证其正确性的深度。

---

简评：

这篇文章精准地命名了一种我们都隐约感觉到但说不出的现象——“貌似可信的代码”。它提醒我们，在AI时代，真正稀缺的不是生产力，而是判断力。 senior和junior的差距，从未如此清晰。

---

ref: blog.katanaquant.com/p/your-llm-doesnt-write-correct-code

#AI创造营##人工智能#