过去一段时间里，软件开发正在经历一场底层的变化：过去工程师大部分代码靠手敲，如今越来越多代码由 AI 编程助手与智能体批量生成。但 AI 生成之后，仍需要人来把关——阅读、清理并验证这些代码是否真的符合要求。

当 AI 拥有对整体架构的有限视野时，界定系统边界、保障生产环境的安全与可靠，依然要靠人。换句话说，软件工程的关键环节，正从「写」悄悄转向「审、验、养」。

Go 生来为「软件工程」而非「编程」

有意思的是，正是这种团队协同的考量，促使 Rob Pike、Robert Griesemer 与 Ken Thompson 二十多年前在 Google 创造了 Go 语言。当其他语言不断堆砌特性、追求更多表达写法时，Go 选择了一条更大的路线：让语言设计服务于软件工程。

软件工程并不等于编程。编程是用代码解决问题并运行它；软件工程则是与人协作，设计一套能随时间演进、长期可维护的系统。编程只是其中一部分。

要让语言服务于工程，光有语法不够，还需要覆盖软件全生命周期的工具链，需要「有主见的简单」——让整个团队用同一种方式组织、格式化、测试代码；需要强兼容承诺——今天写的代码十年后不仅仍能运行，而且依旧是「好代码」；还需要健全的生态与贯穿始终的安全考量。

可读，意味着人和 AI 都更好审

Go 的另一大特征是「重可读、轻炫技」。三位设计者很清楚，开发者读旧代码的时间，远多于写新代码的时间。于是 Go 刻意拒绝其他语言热衷的语法魔法，形成了「以简单为美」的文化。

到了 AI 辅助开发时代，这种「先读后写」的哲学成了放大器。当个体开发者偏爱简短语法、隐式类型与聪明捷径时，智能体与人协作的验证回路，恰恰要求相反的东西：可预测、显式、结构刚性。

如果一门语言用十几种方式表达同一段逻辑，AI 生成的代码就会变成风格杂乱的大杂烩，人工审阅者要花很大力气去猜意图。Go 用内置的 gofmt 统一格式、用刻意克制的抽象，确保所有代码——无论出自资深工程师、初级贡献者还是大模型——看起来都一样。语法完全可以预测时，人能更快发现一处幻觉出来的接口调用、一个逻辑漏洞或一处安全隐患。

可靠，编译器替你拦住幻觉

可读性只是上半场。如果跑起来脆弱、不安全、负载下行为难测，再好读也进不了生产环境。

Go 的第一道防线是静态类型系统，它相当于给智能体生成的代码加了一张自动安全网。大模型常常在跨文件的类型与结构边界上犯迷糊，产生幻觉属性与潜伏的隐患。在 Python 这类动态类型语言里，这类幻觉往往能躲过基础语法检查，直到特定生产负载下才在运行时崩溃；而在 Go 里，编译器会立刻拒绝——智能体若调用了不存在的方法、传错类型或漏初始化变量，代码根本编不过。

配合 Go 标志性的编译速度（据 Google 方面介绍，比 Java、C#、Rust 等生产级编译语言快出数量级），智能体可以高效地自我纠错：在人工审阅之前，就把语法与类型错误迭代修好。

在编译器之外，Go「开箱即用」的哲学还化解了 AI 生成代码的一大风险——软件供应链。大模型写功能时常常依赖训练数据，于是倾向于建议陈旧、无人维护甚至恶意的第三方依赖。而 Go 体量完备的标准库，会自然地把模型引向官方维护、经过优化的包，而不是随意拉外部依赖，从而大幅压缩供应链攻击面。

再加上校验和数据库与模块镜像（记录每一次导入模块的副本，以防中间人篡改），以及官方漏洞库与集成扫描工具 govulncheck（只标记代码真正调用的漏洞函数，反馈精准、噪音低），Go 形成了一套低噪音的安全闭环。

可维护，才是 Day 2 的真正考验

能读、能跑，只是起点。代码库是活的系统，会自然腐化、累积技术债。当自主 AI 智能体可以一口气生成几十个拉取请求、随手重构整个服务时，架构漂移的速度被急剧放大。

Go 的答案是著名的兼容性承诺：在 Go 这里，兼容不是便利，而是安全与运维的硬要求。早在 Go 1.0 时代编写的代码，到今天的最新工具链依然能原样编译运行；Go 承诺永不破坏向后兼容，并且不会有 Go 2.0。编译器与运行时越变越好，代码无需改动就能跟着受益：升级、重编译，仅此而已。

这种长期耐久，配上 Go 的部署便携性更显价值。Go 直接编译成单一静态二进制、零系统依赖；当 AI 智能体越来越多地以「系统管理员」身份运行——拉起微服务、执行脚本、通过命令行操作环境——这种自包含的设计变得空前重要。而 Go 编译器支持跨操作系统、跨架构交叉编译，智能体可以按需为任意目标平台构建二进制，无需复杂构建系统。

为了对抗架构漂移，Go 还提供内置的、确定性的重构与现代化工具。官方语言服务器 gopls，以及重新打造的 go fix（引入了「modernizers」概念），能确定性地把旧代码模式更新到最新写法与语言特性。由于这些工具标准化、内建于平台，AI 智能体能借助它们安全地重组包、管理依赖、清理技术债，而不破坏代码库。

最后，Go 还把可维护性延伸到生产环境：运行时内置性能分析与执行追踪，编译器原生支持基于真实负载画像的画像引导优化（PGO），与 AI 编排的部署流水线结合，形成「生产数据回流编译器、再优化系统」的闭环。

当 AI 接管写代码，语言反而更重要

写代码越来越少，按说语言选择该变得无关紧要，事实却正相反。当代码生成被甩给 AI，软件工程的瓶颈从「写得快不快」彻底转移到「审得严不严、验得准不准、养得长久不长久」。那些曾以松散原型、聪明隐式捷径见长的语言，在碎片化的智能体输出重压下越来越难保持稳健；而把可读性、可靠性、可维护性刻进骨子里的 Go，反而在这个时代显得从容。

来源：Google Developers Blog（作者：Cameron Balahan、Richard Seroter，2026 年 8 月 11 日）

技术博主 Dan Luu 决定动手验证。他跑了两轮真实规模的评测，结论是：这个被广泛传播的判断，基本站不住脚。

被引用最多的那份数据，题目太简单了

流行说法的源头是一份对比实验，作者从 Rosetta Code 上取题，测量不同语言解同一道题需要多少 token。结果显示，最费 token 的 C 语言与最省的 Clojure 之间存在 2.6 倍的差距；后来又补测了数组语言 J，平均只需 70 个 token，几乎是 Clojure（109 个）的一半。作者由此推断，如果 token 效率真的成为关键驱动力，这可能会成为编程语言演化的一个有趣方向。

问题恰恰藏在这组数字里。Dan Luu 指出，一道能用 70 个 token 解决的题目，根本算不上题目。这类琐碎任务里，大部分工作只是把答案打印出来，性能表现无法推广到需要真正干活的场景。他此前在评测「穴居人模式」提示词时就见过同样的现象：在极简任务上宣称的巨大收益，一旦换成稍微需要动脑的问题就消失了。

另一份支持相同结论的对比实验，毛病更隐蔽。其中一项测试执行了一条并不存在的路径，导致失败；后面某个智能体把这条不存在的路径符号链接到了自己的可执行文件，测试通过了，但代价是此后所有测试都在跑那一个智能体的可执行文件。原作者据此分析 Rust 为何出现失败，实际上只是因为 Rust 的评分环节跑在 Go 智能体做符号链接之前。

两个真实项目：zstd 解码器与 Pandoc

Dan Luu 的做法是自己造评测，并且在看结果之前先公开写下预测。他给出的三条预注册判断是：95% 的把握认为动态与静态语言的整体差异说法不成立；60% 的较低把握认为在超高算力档位下静态语言会稍占上风；98% 的把握认为 J 这类「怪语言」的优势不会成立。

第一轮评测的任务是实现一个完整的 zstd 解码器。智能体拿到 zstd 的 RFC 文档和勘误，被关在没有网络的容器里，不提供测试用例。模型统一用 GPT-5.6 Sol，分 medium 与 ultra 两档算力投入。之所以不给测试，是因为像 zstd 这种覆盖面的项目，测试不可能穷尽所有分支——Dan Luu 本人就曾在这个久经考验的软件里找到过数据损坏的缺陷。

结果分成两层：只看 medium 档，动态语言的确聚集在成本更低、正确率更高的那一侧，看上去支持流行结论；但换到 ultra 档，格局就乱了，排在前列的反而以静态语言居多。真正稳定的规律不在动静态之分上，而在两个别的维度——汇编这类对人类也极其费劲的语言表现明显更差；冷门语言同样吃亏，合理的解释是各家 AI 实验室在小众语言上投入的合成训练数据极少甚至为零。把语言流行度和评测表现放在一起看，能观察到一个弱到中等的正相关：越主流的语言，写出来的代码往往既更正确又更便宜。这与第一份实验推崇 J 这类高密度语言的方向正好相反。

第二轮换了完全不同的任务与呈现方式。Dan Luu 把 ProgramBench 的 Pandoc 评测改造了一下：不做原本的逆向工程题，而是把 ProgramBench 的材料连同测试一并交给智能体，再用一组留出测试来打分，更接近测试驱动开发的节奏。结论依旧：成本与得分和语言的动静态属性没有明显关系，冷门语言仍然吃亏，汇编依旧垫底，而 Clojure 在这一轮比在 zstd 那轮好得多。

Clojure 在第一轮翻车有具体原因：40 次 medium 运行里有 36 次、40 次 ultra 运行里有 5 次出现测试失败，症结是字节转换在 128 到 255 区间抛出异常，或许应该改用 unchecked-byte。这也是一个真实存在的成本——如果没有测试兜住，这类错误会一路带到线上；即便有测试，修它同样要烧掉时间和 token。

哪些流行判断被证伪了

对照两轮数据，几条在社区里流传甚广的说法可以做初步清算：

• 「代码质量参差的语言（比如 PHP）在大模型手里表现更差」——在这两项任务上不成立
• 「既然重写成本变低了，就该用表达力强的语言（比如 Haskell）」——同样不成立
• 「应该选流行语言」——有弱支持
• 「动态语言在小项目上占优，项目变大后被静态语言反超」——这两项任务不支持这一判断，不过两个任务的形态和呈现方式差异太大，无法确定究竟是规模因素还是别的变量在起作用

回看他自己的三条预注册判断，第一条和第三条被证实，第二条（ultra 档静态语言稍好）信息不足，若必须二选一，他倾向于判定为错误。

值得留意的是这套方法本身的意义。Dan Luu 提到，2014 年他梳理过静态与动态类型的学术文献，除少数案例研究外收获寥寥。以一篇典型论文《静态类型系统能改善软件系统的可维护性吗？一项实证研究》为例：33 名受试者被分配修复既有代码中的错误或补全存根方法，静态组用 Java，动态组用 Groovy，采用被试内设计并随机化任务顺序。结论是类型错误场景下 Java 组更快，语义错误场景下没有差异。但该研究刻意回避了循环、递归等复杂控制结构以降低耗时方差，导致所有缺陷都是琐碎缺陷，中位解题时间只有几百秒——这恰恰是最不耗费职业程序员时间的那类问题。

大模型改变了这件事的可行性。让智能体实现一个 zstd 解码器大约花费 20 美元，乘上语言数量和每种条件下的重复次数确实不便宜，但相比雇一位能读懂 zstd 规范并动手实现的职业程序员，这个数量级的研究此前根本不可能做，Pandoc 那一轮更是如此。许多原本无从回答的问题——什么测试手法有效、什么软件架构适合、修缺陷的成本是否因语言而异——如今至少有了动手一试的可能。

至于最终答案，Dan Luu 的态度相当克制：绝大多数关于「某语言特别适合大模型」的流行断言看起来都是错的，但什么才是对的，目前还不清楚。

来源：danluu.com（Dan Luu）