为什么 AI 代码生成无法取代工程严谨性

“甩手掌柜”式开发的谬误

近期利用 AI 智能体对现有应用程序进行全规模语言重写的趋势——例如将 Campfire 从 Ruby on Rails 转换为 Rust 和 Elixir——表明 AI 生成的代码并不能替代工程判断。当开发者放弃阅读和理解代码的责任时，他们实际上是在默认接受大语言模型（LLM）在性能、内存使用和故障模式方面所做的一系列随机决策。核心结论是：编程始终是一门权衡的学科，而 AI 智能体在没有特定专家级指导的情况下无法处理这些权衡。

隐式决策的隐藏成本

当 LLM 进行重写时，它必须做出成千上万个微小的决策，而这些决策在提示词中很少被明确定义。其中包括：

• 向后兼容性： 决定是维护现有的 API 契约，还是为了架构便利性而破坏它们（例如丢弃 CSRF 令牌）。
• 资源管理： 在进程内队列和 Redis 等外部服务之间进行选择。
• 并发模型： 确定如何在特定语言运行时的约束下处理数据库操作和锁定机制。

在 Campfire 重写的案例中，Rust 版本选择了与 Elixir 版本不同的兼容性约束，这使得对语言本身的直接比较变得具有误导性。这些差异并非语言固有的，而是 AI 在缺乏引导的情况下所做实现选择的产物。

为什么基准测试往往会误导人

性能基准测试经常被用来证明一种语言或实现优于另一种，但它们往往无法捕捉到完整的运营现实。大多数“粗制滥造”的基准测试测量的是闭环系统中的吞吐量，这忽略了以下关键因素：

• 背压处理： 系统在达到极限时的表现。
• 事件传递延迟： 断开连接（快速失败）与无限期排队事件（导致巨大的延迟峰值）之间的区别。
• 内存占用： 在持续负载下发生 OOM（内存溢出）崩溃的风险。

例如，Rust 实现的事件广播器最初受到较小通道容量的限制，导致其在高负载下丢失消息。虽然增加容量提高了传递率，但同时也导致延迟激增至超过 130 秒。这凸显了“修复”一个性能指标往往会引入新的、更严重的运营风险。

批判性思维的必要性

工程学就是管理故障模式的行为。一个通过断开滞后客户端来优雅失败的系统，通常优于一个试图以极高延迟处理事件的系统。这些决策需要人类来定义什么是“正确的”失败。

正如社区讨论中所指出的，危险在于将 AI 视为“魔法按钮”而非工具。虽然 AI 可以加速代码生产，但它无法取代以下需求：

• 对抗性测试： 使用 AI 生成挑战系统假设的测试套件。
• 代码审查： 手动审计生成的代码，以识别反模式和性能瓶颈。
• 约束设定： 明确定义 AI 必须遵守的非功能性需求。

归根结底，软件系统的质量始终与投入的关注度成正比。无论代码是由人类编写还是由 AI 编写，其可靠性、性能和可维护性的责任始终由部署它的工程师承担。