上个月我接了个小活——用 AI 给一个 Go 项目写几个微服务。本来以为半天搞定的事结果折腾了两天。不是 AI 不行。是 AI 太行了——行到让我开始怀疑之前对编程语言选型的理解全是错的。事情是这样的同样的需求我让 Claude 先生成了一遍 Go 版本又生成了 Python 版本FastAPI还顺手试了下 Node.js。三个结果拿过来一对比差距大到离谱。Go 版本几乎可以直接 deploy——代码风格统一、依赖就一个标准库、错误处理规范。Python 版本嘛……能用但 package 的选择五花八门同一件事有四五种写法。Node 版本更惨express、fastify、hono 三个框架混着用我甚至不知道它到底想干嘛。这就引出了一个有意思的问题AI 写代码的水平跟你用的语言有直接关系。一致性就是模型的舒适区Jacob Young 在四月份发了篇博客叫Use boring languages with LLMs讲的其实就是这个事。核心论点一句话就能说清楚大语言模型放大不一致的技术栈默默强化一致的那些。翻译成人话就是——你用的语言/框架越分裂AI 写出来的代码就越拉胯。为什么你想啊模型训练的时候看的是整个公开代码库。Python 有 pip、poetry、uv 三个主流包管理器还有 Django、FastAPI、Flask、Starlite……你让模型猜你的项目结构它猜中的概率有多大xz 漫画里有个经典梗——How Python projects handle dependencies一张图里画了十几条路箭头乱飞。对 AI 来说这不是梗是真实的训练数据分布。每条路在语料里都出现模型根本不知道该走哪条。Go 就不一样了。Go被低估的 AI 友好型语言说实话我早几年写 Go 的时候没少骂它。没有泛型当时、语法啰嗦、IDE 支持一般。当时我跟同事吐槽Go 就是 Google 造出来给写基础设施的苦力用的。但放到 AI 编程这个场景下Go 的优势就全出来了。1. 并发模型——goroutine 是真香AI 写异步代码经常翻车这是共识。回调地狱、async/await 颜色问题、事件循环阻塞——这些东西模型学得半生不熟。Go 的 goroutine 就简单了results:make(chanstring,len(urls))for_,u:rangeurls{gofunc(ustring){resp,err:http.Get(u)iferr!nil{results-err.Error()return}deferresp.Body.Close()results-resp.Status}(u)}forrangeurls{fmt.Println(-results)}goroutine 就是一个go关键字channel 就是一个带类型的管道。没有 async 函数和普通函数的颜色区分没有复杂的生命周期。模型学起来简单写出来也稳定。你敢信Go 的并发代码在我用过的所有语言里AI 生成的正确率是最高的。2. 标准库——够用就行net/http支撑了互联网上不知道多少微服务。crypto/tls是 Google 掏钱维护的安全性没得说。你不需要装第三方包就能搭一个生产级的 HTTP 服务。packagemainimport(fmtnet/http)funcmain(){http.HandleFunc(/healthz,func(whttp.ResponseWriter,r*http.Request){fmt.Fprintln(w,ok)})http.ListenAndServe(:8080,nil)}这段代码任何一个版本的 Go 都能跑语料里出现过无数次。模型闭着眼睛都能写对。3. 工具链——没有选择就是最好的选择Go 的工具链值得单独拿出来夸。gofmt强制统一格式不需要讨论大括号放哪行这种问题。go vet静态检查。go fix自动迁移。$govet./... ./user.go:22:2:resultoffmt.Errorfcallnotused ./user.go:38:9:declarationoferrshadowsdeclarationatline34对 AI 来说这种只有一种正确写法的生态简直是福音。模型不需要在 Go 的各种风格之间做选择因为它根本就没有选择。对比一下 Python# 你用的是哪个pipinstallflask poetryaddflask uvaddflask三个命令都能让 AI 写出能跑的代码但 AI 怎么知道你项目用的是哪个包管理器模型只能猜猜对了还好猜错了你就得手动改。那其他语言呢说到这儿可能有读者要问了你只说了 Go 和 Python那 Java、Rust、Ruby 呢我大概归纳了一下语言生态一致性AI 代码质量备注Go高高标准库工具链无敌Rails/Ruby高中高约定优于配置模型学得透Java/Spring中高中生态大但 Spring Boot 是事实标准Python低中低选择太多模型无所适从JavaScript极低低框架泛滥AI 写出来常是混搭Rust中中所有权/借用检查对 AI 是硬门槛这个表是我的个人经验不一定对。不过有一点可以确定——你用的技术栈越无趣、越标准化AI 产出就越稳定。Rails 是个好例子。虽然 Ruby 本身不如 Go 一致但 Rails 框架在 Ruby 生态里是绝对的主导。Jacob 的文章里提到过用 Rails 的 AI 代码质量明显高于用普通 JavaScript 后端的。原因很简单——模型训练时见过的 Rails 代码足够多怎么写都有模板可循。Rust 的情况比较特殊。它的所有权模型和借用检查器很强大但 AI 经常在这上面栽跟头。一个常见的场景AI 生成了一段 Rust 代码编译报 borrow checker 错误然后修了三次才通过。不是说 Rust 不好——它是一门优秀的语言——只是在 AI 编程的场景下学习曲线对模型来说和对人一样陡。这不是最佳语言的争论话说回来我写这篇文章不是想说Go 是最好语言——这种事情吵了十年也没吵出结果。我想说的是选技术栈的时候把你未来可能用 AI 编程这件事考虑进去。如果你在 2026 年还在写纯手撸代码那你大概率不是效率最优的那批人。AI 编程助手Claude Code、Cursor、GitHub Copilot已经成了标配。那问题就变成了哪些语言能让 AI 发挥出最大价值Go 的回答很明确一致性。没有选择的自由就没有选择困难。对模型来说这是一个高度可预测的环境。一个实操建议如果看完这篇文章你想试试建议从一个小项目入手装好 Go版本 1.22打开 Claude Code 或 Cursor让它用 Go 写一个简单的 CLI 工具——比如从 API 拉数据并格式化成表格输出观察它是不是一次就写出能编译的代码然后换 Python 做同样的事。你大概率会发现Python 版本可能需要你手动修一两处 import 或异步调用的问题Go 版本基本一把过。这里有个小技巧——gopls是 Go 语言服务器装好后能实时给 AI 提供语义反馈。加上golangci-lint做静态检查AI 生成的代码质量会上一个台阶。所以……要不要换 Go不一定。如果你的团队已经在用 Python 或 JavaScript并且积累了大量基础设施和业务代码为了AI 友好全盘重写显然不现实。但有几个方向可以考虑新项目选型时多一个维度除了性能、生态、招人之外加上AI 生成代码质量这个指标核心微服务可以试试 Go特别是 CLI 工具、API 网关、中间件这类场景Go 本身就是强项Python 项目做好约束用 ruff 做格式化、用 pyproject.toml 统一配置、选一个包管理器就别换了说个坑——我之前有个项目用 Python 做数据处理让 AI 帮忙写 ETL 脚本。结果它每次生成的 import 方式都不一样有时候用pandas.read_csv有时候用csv.DictReader还有一次直接用了open() split()手撸解析。代码都能跑但风格完全不统一。后来我把它重写成了 GoAI 每次输出都稳如老狗。结尾这个话题其实挺有意思的——当 AI 成为主力编码工具后好语言的定义可能完全变了。以前我们追求表达能力、生态丰富度、开发效率。以后可能要看模型在你这门语言上训练得有多深、写出来的代码有多稳定。你平时用哪个语言配 AI 编程有没有遇到过AI 写 Go 一把过写 Python 反复修的情况评论区说说我整理到后续文章里。
用Go写代码的AI更靠谱？聊聊「无趣语言」的LLM优势
上个月我接了个小活——用 AI 给一个 Go 项目写几个微服务。本来以为半天搞定的事结果折腾了两天。不是 AI 不行。是 AI 太行了——行到让我开始怀疑之前对编程语言选型的理解全是错的。事情是这样的同样的需求我让 Claude 先生成了一遍 Go 版本又生成了 Python 版本FastAPI还顺手试了下 Node.js。三个结果拿过来一对比差距大到离谱。Go 版本几乎可以直接 deploy——代码风格统一、依赖就一个标准库、错误处理规范。Python 版本嘛……能用但 package 的选择五花八门同一件事有四五种写法。Node 版本更惨express、fastify、hono 三个框架混着用我甚至不知道它到底想干嘛。这就引出了一个有意思的问题AI 写代码的水平跟你用的语言有直接关系。一致性就是模型的舒适区Jacob Young 在四月份发了篇博客叫Use boring languages with LLMs讲的其实就是这个事。核心论点一句话就能说清楚大语言模型放大不一致的技术栈默默强化一致的那些。翻译成人话就是——你用的语言/框架越分裂AI 写出来的代码就越拉胯。为什么你想啊模型训练的时候看的是整个公开代码库。Python 有 pip、poetry、uv 三个主流包管理器还有 Django、FastAPI、Flask、Starlite……你让模型猜你的项目结构它猜中的概率有多大xz 漫画里有个经典梗——How Python projects handle dependencies一张图里画了十几条路箭头乱飞。对 AI 来说这不是梗是真实的训练数据分布。每条路在语料里都出现模型根本不知道该走哪条。Go 就不一样了。Go被低估的 AI 友好型语言说实话我早几年写 Go 的时候没少骂它。没有泛型当时、语法啰嗦、IDE 支持一般。当时我跟同事吐槽Go 就是 Google 造出来给写基础设施的苦力用的。但放到 AI 编程这个场景下Go 的优势就全出来了。1. 并发模型——goroutine 是真香AI 写异步代码经常翻车这是共识。回调地狱、async/await 颜色问题、事件循环阻塞——这些东西模型学得半生不熟。Go 的 goroutine 就简单了results:make(chanstring,len(urls))for_,u:rangeurls{gofunc(ustring){resp,err:http.Get(u)iferr!nil{results-err.Error()return}deferresp.Body.Close()results-resp.Status}(u)}forrangeurls{fmt.Println(-results)}goroutine 就是一个go关键字channel 就是一个带类型的管道。没有 async 函数和普通函数的颜色区分没有复杂的生命周期。模型学起来简单写出来也稳定。你敢信Go 的并发代码在我用过的所有语言里AI 生成的正确率是最高的。2. 标准库——够用就行net/http支撑了互联网上不知道多少微服务。crypto/tls是 Google 掏钱维护的安全性没得说。你不需要装第三方包就能搭一个生产级的 HTTP 服务。packagemainimport(fmtnet/http)funcmain(){http.HandleFunc(/healthz,func(whttp.ResponseWriter,r*http.Request){fmt.Fprintln(w,ok)})http.ListenAndServe(:8080,nil)}这段代码任何一个版本的 Go 都能跑语料里出现过无数次。模型闭着眼睛都能写对。3. 工具链——没有选择就是最好的选择Go 的工具链值得单独拿出来夸。gofmt强制统一格式不需要讨论大括号放哪行这种问题。go vet静态检查。go fix自动迁移。$govet./... ./user.go:22:2:resultoffmt.Errorfcallnotused ./user.go:38:9:declarationoferrshadowsdeclarationatline34对 AI 来说这种只有一种正确写法的生态简直是福音。模型不需要在 Go 的各种风格之间做选择因为它根本就没有选择。对比一下 Python# 你用的是哪个pipinstallflask poetryaddflask uvaddflask三个命令都能让 AI 写出能跑的代码但 AI 怎么知道你项目用的是哪个包管理器模型只能猜猜对了还好猜错了你就得手动改。那其他语言呢说到这儿可能有读者要问了你只说了 Go 和 Python那 Java、Rust、Ruby 呢我大概归纳了一下语言生态一致性AI 代码质量备注Go高高标准库工具链无敌Rails/Ruby高中高约定优于配置模型学得透Java/Spring中高中生态大但 Spring Boot 是事实标准Python低中低选择太多模型无所适从JavaScript极低低框架泛滥AI 写出来常是混搭Rust中中所有权/借用检查对 AI 是硬门槛这个表是我的个人经验不一定对。不过有一点可以确定——你用的技术栈越无趣、越标准化AI 产出就越稳定。Rails 是个好例子。虽然 Ruby 本身不如 Go 一致但 Rails 框架在 Ruby 生态里是绝对的主导。Jacob 的文章里提到过用 Rails 的 AI 代码质量明显高于用普通 JavaScript 后端的。原因很简单——模型训练时见过的 Rails 代码足够多怎么写都有模板可循。Rust 的情况比较特殊。它的所有权模型和借用检查器很强大但 AI 经常在这上面栽跟头。一个常见的场景AI 生成了一段 Rust 代码编译报 borrow checker 错误然后修了三次才通过。不是说 Rust 不好——它是一门优秀的语言——只是在 AI 编程的场景下学习曲线对模型来说和对人一样陡。这不是最佳语言的争论话说回来我写这篇文章不是想说Go 是最好语言——这种事情吵了十年也没吵出结果。我想说的是选技术栈的时候把你未来可能用 AI 编程这件事考虑进去。如果你在 2026 年还在写纯手撸代码那你大概率不是效率最优的那批人。AI 编程助手Claude Code、Cursor、GitHub Copilot已经成了标配。那问题就变成了哪些语言能让 AI 发挥出最大价值Go 的回答很明确一致性。没有选择的自由就没有选择困难。对模型来说这是一个高度可预测的环境。一个实操建议如果看完这篇文章你想试试建议从一个小项目入手装好 Go版本 1.22打开 Claude Code 或 Cursor让它用 Go 写一个简单的 CLI 工具——比如从 API 拉数据并格式化成表格输出观察它是不是一次就写出能编译的代码然后换 Python 做同样的事。你大概率会发现Python 版本可能需要你手动修一两处 import 或异步调用的问题Go 版本基本一把过。这里有个小技巧——gopls是 Go 语言服务器装好后能实时给 AI 提供语义反馈。加上golangci-lint做静态检查AI 生成的代码质量会上一个台阶。所以……要不要换 Go不一定。如果你的团队已经在用 Python 或 JavaScript并且积累了大量基础设施和业务代码为了AI 友好全盘重写显然不现实。但有几个方向可以考虑新项目选型时多一个维度除了性能、生态、招人之外加上AI 生成代码质量这个指标核心微服务可以试试 Go特别是 CLI 工具、API 网关、中间件这类场景Go 本身就是强项Python 项目做好约束用 ruff 做格式化、用 pyproject.toml 统一配置、选一个包管理器就别换了说个坑——我之前有个项目用 Python 做数据处理让 AI 帮忙写 ETL 脚本。结果它每次生成的 import 方式都不一样有时候用pandas.read_csv有时候用csv.DictReader还有一次直接用了open() split()手撸解析。代码都能跑但风格完全不统一。后来我把它重写成了 GoAI 每次输出都稳如老狗。结尾这个话题其实挺有意思的——当 AI 成为主力编码工具后好语言的定义可能完全变了。以前我们追求表达能力、生态丰富度、开发效率。以后可能要看模型在你这门语言上训练得有多深、写出来的代码有多稳定。你平时用哪个语言配 AI 编程有没有遇到过AI 写 Go 一把过写 Python 反复修的情况评论区说说我整理到后续文章里。
