AI 编码时代的语言选择：Go 的定位与策略
最近，一个名为 mame/ai-coding-lang-bench 的基准测试在开发者社区引起了不小的讨论。这个测试的设定很有意思：让 Claude Code 用 13 种不同的编程语言，分别实现一个简化版的 Git 系统。每种语言测试 20 次，总共跑了 600 次。结果揭示了一些反直觉的规律，也让我重新思考了 Go 在 AI 辅助开发时代的定位。
动态语言的"降维打击"
数据很清晰：Ruby、Python 和 JavaScript 在 AI 辅助编码中表现出了压倒性的效率优势。它们最快、最便宜（消耗的 API token 最少）、结果也最稳定。
相比之下，TypeScript 的表现令人意外。作为 JavaScript 的超集，它的生成耗时几乎是纯 JavaScript 的两倍，成本高出 60%。同样的逻辑，只是加上了类型系统，AI 的生成效率就出现了明显的下滑。
这背后的原因并不复杂：静态类型系统要求 AI 在生成代码时同时满足多个约束条件------类型正确性、业务逻辑、API 兼容性、编译器通过。每多一层约束，AI 就需要多一步推理，相应地就会消耗更多 token，花费更多时间。
有趣的是，静态类型并没有带来更高的可靠性。在 600 次运行中，仅有的 3 次失败全部发生在静态类型语言中（Rust 2 次，Haskell 1 次）。这说明，类型系统对 AI 的保护作用，与对人类开发者的保护作用并不完全等同。
代码的"认知密度"悖论
另一个反直觉的发现是：OCaml 和 Haskell 生成了最紧凑的代码（约 216--224 行），但它们的生成速度却排在中等偏下的位置。
为什么？因为生成紧凑的、符合惯用法的代码，需要模型进行更复杂的推理。以 Haskell 为例，生成一行代码可能涉及对类型类、单子组合、惰性求值等多重概念的同步权衡。模型"思考"得更久，才能产出更少的代码。
这意味着，我们过去认为"更高级、更简洁"的语言，在 AI 生成场景下可能反而更"昂贵"。代码的体积不是衡量标准，生成过程中所需的心智负担才是。
那 Go 在哪里？
虽然这个基准测试没有单独强调 Go，但从它的设计特征和测试结果来看，我们可以推断它的位置。
Go 是一门静态类型语言，但它避免了 Java 的继承体系、Rust 的所有权模型、Haskell 的高级类型类。这种"刻意的简单"反而成了一个相对优势：
- 类型系统简单：没有泛型的高级用法（即使在 Go 1.18 之后，社区也倾向于保守使用），AI 需要满足的约束条件较少。
- 显式的错误处理 ：
if err != nil虽然啰嗦，但它将错误路径清晰地写在了代码中，对 AI 来说，这是一种"引导"而非"阻碍"。 - 标准库的稳定性：AI 模型在生成 Go 代码时，不需要像处理 Python 那样在数十个流行库之间权衡选择。
综合来看，Go 可能处于中游位置：比 Ruby/Python 慢，但比 TypeScript 或 Rust 快。这不算是一个能让你"赢"在起跑线上的位置，但也绝非劣势。
在人工智能开始主导代码生成的今天，我认同一个更实用的策略："原型用 Python，生产用 Go"。
这个策略反映了两种语言在设计哲学和最佳应用场景上的根本差异：
- 在原型阶段，使用动态语言（Python/Ruby）。AI 可以快速迭代、探索边界，而类型系统不会成为探索的障碍。你得到一个可工作的原型，成本最低，速度最快。
- 在生产阶段，迁移到 Go。这时，你已经明确了数据结构、API 契约和边界条件。Go 的类型系统（虽然简单）可以提供足够的编译时保障，而其并发模型、部署简洁性和内存效率，正是生产服务所需要的。
我过去的一个项目就是这个策略的受益者。我们先用 Python 配合 AI 生成了一个支付网关对接的完整原型，用来验证 API 设计和异常处理流程。整个验证过程只花了一个下午。然后，我们花了三天时间，将核心逻辑翻译成 Go，并利用 goroutine 实现了并发的重试和熔断机制。这个项目至今已经稳定运行了1年，期间没有出现过严重的内存泄漏或性能事故。
结语：语言选择的新维度
这个基准测试向我们揭示了一个新的现实：AI 编码性能，已经与运行时性能、开发者生态系统一样，成为了一个值得考量的语言属性。
在选择一门语言时，我们不仅要问："它跑得快吗？"、"它的生态成熟吗？"，还要考虑："AI 用这门语言完成任务，是高效还是费力？"
Go 可能不是 AI 生成效率的冠军，但它在自己的细分领域（生产级服务）中依然是出色的。理解它在这个新维度上的位置，能帮助我们做出更明智的架构决策：哪个阶段用哪种语言，如何利用各自的优势来降低时间和资金成本。 这已经超越了单纯的语法争论，成为了工程策略的一部分。