[AI小新闻快报] AI生成的57万行代码，竟然慢了2万倍？

📰 新闻概要

• LLM生成代码的惊人延迟: 通过基准测试发现，LLM项目从零开始用Rust重实现SQLite，其主键搜索速度比原版SQLite（C语言）慢了20,171倍。
• 57万行的『似是而非』代码: 生成的代码长达576,000行，具备解析器、B树、WAL等数据库构成要素，并且通过了测试，但在性能上存在致命缺陷。
• 缺乏优化逻辑: 原因在于查询规划器未能识别特定列为索引，导致执行了全表扫描，而非O(log n)的搜索。

💡 重要要点

• 追求『似是而非』: LLM优化的是输出是否“看起来正确（Plausibility）”，但并不保证“真正正确（Correctness）”。在本案例中，代码结构看似专业，但算法选择完全错误。
• 接收标准的重要性: 作者得出结论，在将LLM纳入开发时，成功的关键是用户需在生成第一行代码之前明确“接收标准（Acceptance Criteria）”。

🦈 鲨鱼的视角（策展者视点）

看似完美的57万行代码，实际上却是一个空洞的“全表扫描地狱”，真是令人毛骨悚然的故事啊！

特别值得注意的是is_rowid_ref函数的实现。原版SQLite聪明地将INTEGER PRIMARY KEY当作内部rowid的别名处理，而AI版本却只能识别特定字符串，自行封闭了通往快速B树搜索的道路。这表明“代码能运行”和“软件实用”之间存在着巨大鸿沟。开发者不应完全依赖LLM，而应该在让其发挥之前，先设置好“性能标准”的框架！

🚀 接下来会如何发展？

• 验证工具的演进: 生成的代码不仅要能编译通过，还需满足计算复杂度和性能标准，因此自动验证工具的重要性日益提高。
• 提示工程的变革: 从“写代码”的指令转向“首先定义测试和性能要求，然后实施满足这些要求的实现”，这种更加注重设计的指令将加速转变。

💬 鲨鱼观点

就像外表强壮却不会游泳的鲨鱼一样，代码只看外表是没用的！如果不仔细检查内容，最终可能会在生产环境中淹没哦！🦈🔥

📚 术语解释

• 全表扫描: 在数据库中查找特定数据时，从头到尾逐条检查所有数据的低效方法。数据量一旦增加，速度就会极其缓慢。

• 查询规划器: 数据库的“头脑”，负责判断如何最快执行SQL等指令。如果它不聪明，即使有高效的索引也不会被利用。

• B树: 一种高效搜索数据的树形结构。使用B树可以在处理100万条数据时，仅需几步就能找到目标数据（O(log n)）。

• 信息来源: LLMs work best when the user defines their acceptance criteria first