2026-03-27 07:09:11
本文永久链接 – https://tonybai.com/2026/03/27/function-type-inference-should-work-in-all-assignment-contexts
大家好，我是Tony Bai。
在这个大模型（AI）写代码如喝水一般简单的时代，你有没有遇到过一种极其憋屈的场景：
你让 Claude Code 或者 Codex 帮你写了一段 Go 语言代码，逻辑清晰，结构优雅，连它自己都觉得这波操作满分。但当你满怀期待地按下 go run 时，Go 编译器却无情地丢给你一个红色报错：
cannot use generic function g without instantiation
（不能在未实例化的情况下使用泛型函数 g）
AI 沉默了，它不明白自己错在哪；如果你是个习惯了 Rust 那种“地表最强类型推断”的开发者，你可能会当场流下心酸的眼泪—— 在 Rust 里闭着眼睛都能推断出来的泛型参数，怎么到了 Go 里，它就突然变成了“残疾”？
如果你曾经被这个“诡异”的泛型报错折磨过，甚至因此怀疑过自己的智商，不要怪 AI 不懂 Go 语言。
因为就在最近，连“Go 语言之父之一” 的 Robert Griesemer 都亲自在官方 GitHub 上提了一个 Issue，承认这个语法限制不仅反直觉，甚至一度被认为是一个编译器 Bug！Griesemer 本人随即在 Issue 中自我更正，明确这需要语言规范(spec)层面的修改，而不只是修编译器。
今天，我们就来扒开这个在 Go 官方仓库引发热议的 Issue #77245，看看这个即将改变Go工程师日常编码的“底层规范级修补”，到底是怎么回事。
自从 Go 1.18 引入泛型以来，“不够聪明”的类型推断（Type Inference）就一直被开发者诟病。直到 Go 1.21 发布，官方宣称大幅增强了这部分能力：只要在赋值上下文中，目标类型是明确的，Go 就可以帮你自动推断出泛型函数的参数类型，不需要你手动写 g[int] 了。
这听起来很美好，对吧？
但现实是极其骨感的。我们来看看 Robert Griesemer 亲自给出的这个“薛定谔式的推断”的例子：
type S struct{ f func(int) }
func g[T any](T) {} // 这是一个简单的泛型函数
func _(s S) {
s.f = g // ✅ 没问题！Go 编译器智商在线，完美推断出 T 是 int
s = S{f: g} // ❌ 报错：不能在没有实例化的情况下使用泛型函数 g
s = S{f: g[int]} // ✅ 没问题！必须手动写死 g[int]
}
看懂这个坑在哪里了吗？
当你写 s.f = g 的时候，编译器智商在线，它知道 s.f 需要一个 func(int)，所以它机智地把泛型函数 g 实例化成了 g[int]。
但是（最气人的但是）！
当你使用结构体字面量 S{f: g} 进行初始化时，编译器却突然“智力下线”了。它死活推断不出 g 需要被实例化为 int，非逼着你极其啰嗦地写上 g[int]！
这种“一半聪明，一半智障”的表现，不仅存在于结构体里。在切片（Slice）、数组、Map，甚至是 Channel 的发送操作中：
type F func(int)
type A [10]F
type S []F
type M map[string]F
type C chan F
func g[T any](T) {}
func _() {
var a A
a[0] = g // ok
a = A{g} // error: cannot use generic function g without instantiation
a = A{g[int]} // ok
var s S
s[0] = g // ok
s = S{g} // error: cannot use generic function g without instantiation
s = S{g[int]} // ok
var m M
m["foo"] = g // ok
m = M{"foo": g} // error: cannot use generic function g without instantiation
m = M{"foo": g[int]} // ok
var c C
c <- g // error: cannot use generic function g without instantiation
c <- g[int] // ok
}
只要你使用了复合字面量（Composite Literals），这套“残疾”的类型推断就会集体失效。
如果你去问一个 Rust 开发者：“目标结构体的字段类型 f func(int) 明明就摆在那里，Go 编译器为什么会看不见？”
Rust 开发者可能会拍着你的肩膀叹气。在 Rust 强大的类型推断系统面前，这种上下文推导简直是基本操作，根本不需要开发者操心。
而在如今 AI 辅助编程大行其道的时代，这个问题更加被无限放大。
大模型在学习了海量代码后，它的“直觉（Next-token prediction）”告诉它，这里上下文极其明确，根本不需要写死类型参数。于是 AI 开心地生成了 S{f: g}，结果却被 Go 编译器无情打脸。你不得不停止思考，手动去把 AI 生成的代码一行行加上 [int]、[string]……
这根本不是 AI 的幻觉，而是 Go 语言规范（Spec）在当年设计时，由于过于严谨，给自己留下的思维盲区。
在最初的 Go Spec 中，关于泛型函数实例化生效的上下文规定得极其死板（只在某些直接赋值的场景生效）。当时的 Go 团队并没有抽象出一个统一的 “赋值上下文（Assignment Context）” 概念。这导致散落在各个角落的复合字面量操作，全都成了漏网之鱼。
起初，Robert Griesemer 以为这只是个单纯的编译器 Bug，只要改改代码就行了。
但随着讨论的深入，核心成员们（如 Austin Clements）发现，这事儿没那么简单。要从根本上解决这个问题，必须对 Go 语言规范（Spec）动刀子！
在随后的内部评审中，Go 团队做出了一个决策：
他们没有选择“头痛医头，脚痛医脚”地去给结构体、Map、切片分别打补丁。而是选择在 Go 语言最底层的定义——“可赋值性（Assignability）” 上做文章。
他们提出了一个新的 CL ，只要一个表达式符合“可赋值性”的校验（无论是等号赋值、结构体初始化、还是 Channel 发送），Go 编译器就必须启动泛型函数的自动类型推断。
这就好比给整个 Go 语言的类型推断系统，彻底打通了奇经八脉。
到这里，可能有开发者会问：“不就是少写几个 [int] 吗？至于这么大惊小怪吗？”
在几行代码的 Demo 里，这确实不是事。
但在大厂动辄十几万或几十万行的微服务源码中，当我们使用泛型去实现高阶的“工厂模式”、“回调注册”、“依赖注入”时，代码中会充斥着大量的结构体初始化和泛型函数传递。
如果没有统一的类型推断，原本极其优雅的代码，就会变成被各种中括号 [T, K, V] 塞满的“乱码”。
更少的手动类型标记，意味着更低的人类认知负荷（Cognitive Load），以及对 AI 代码生成工具更友好的兼容性。
Go 语言之所以能在一众花里胡哨的新语言中稳坐云原生霸主的交椅，靠的绝不仅是并发，更是这种对“代码清爽度”和“心智负担”极其克制、甚至有些偏执的追求。
好消息是，这个被开发者诟病已久的痛点，已经被 Go 官方提案评审委员会 “正式接受（Accepted）”。
我们极有可能在即将到来的后续版本(比如Go 1.27)中，看到这段啰嗦的泛型代码彻底消失。
资料链接：
今日互动探讨：
在日常写 Go 泛型的时候，你还遇到过哪些让你觉得“Go 编译器简直是个智障”的奇葩场景？或者在对比 Rust/TS 时，你觉得 Go 的类型系统最需要补齐哪个短板？
欢迎在评论区疯狂吐槽与分享!
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-26 07:20:24
本文永久链接 – https://tonybai.com/2026/03/26/rust-project-perspectives-on-ai
大家好，我是Tony Bai。
在这个大模型狂飙突进的时代，只要在推特或者掘金上刷一刷，你几乎每天都能看到这样的“成功学”分享：
“我是如何用 Claude Code + 4.6 Sonnet 在一天内向知名开源项目提交了 10 个 PR 的！”
“用 Cursor 混 GitHub 绿点，原来这么简单！”
这些利用 AI 工具轻松突破“开源门槛”的开发者们，正在享受着前所未有的技术平权红利。
但你有没有想过，站在这些开源项目背后的核心维护者（Maintainers）们，正在经历着怎样的地狱？
继Go核心团队拒绝 AI 署名，为AIGC 时代的Go项目划下的“工程红线”后，前不久，Rust 项目的核心开发者、语言设计团队负责人 Niko Matsakis 在内部发起了一场长达数周的“大摸底”，旨在收集 Rust 核心贡献者和维护者们对于 AI 辅助编程的真实看法。
目前阶段性地汇总出的这份长达 20 多页的内部讨论纪要，犹如一枚深水炸弹，撕开了“AI 编程繁荣”背后的残酷真相：毫无节制的 AI 生成代码，正在不可逆转地榨干 Rust 核心团队的精力，甚至将开源社区推向崩溃的边缘。
今天，我们就来扒开这份极其硬核的内部讨论，看看在这个世界上一贯严谨、对代码质量要求极高的社区里，顶级的Rust工程师们是如何看待、抵制、甚至反制 AI 编程的。
在很多人的幻想中，AI 是小白进阶的导师，是帮你看懂复杂底层源码的引路人。
但在 Rust 维护者们的眼里，绝大多数情况恰恰相反：AI 正在沦为某些开发者盲目自信的催化剂。
一位Rust贡献者一针见血地指出了问题所在：
“AI 给那些原本心怀愧疚、不敢随便提交低质量代码的人，盖上了一个‘官方批准’的假印章。对于那些处于‘达克效应（指能力欠缺的人产生虚幻的优越感）’状态的开发者来说，AI 简直就是一剂催化剂。它极大地膨胀了他们的自信，却严重削弱了他们真正的能力。”
在传统的开源世界里，“提交 PR”是一项极其庄重的工作。你需要阅读庞大的代码库，理解设计哲学，甚至要为了改一行代码而去推演上下文的几百个变数。这种“艰难的门槛”本身就是一种过滤机制。
但现在呢？
你只需要把报错信息扔给大模型或专门的编码智能体，比如Claude Code，它会生成一段看起来“极度合理”、语法看似“完美无瑕”的 Rust 代码。你连这行代码底层的生命周期（Lifetime）都没看懂，就欢天喜地地点了 git commit。
你以为你是在为开源做贡献，其实你只是把“寻找代码中细微致命毒药”的工作，无情地转嫁给了那些用爱发电的 Rust 维护者。
如果说 AI 生成的代码只是质量差，那维护者大不了直接关闭 PR 就可以了。真正让 Rust 核心团队感到绝望甚至想要“退网”的，是那些把 AI 当作“传声筒”的贡献者。
让我们来看另一个让核心成员愤怒到使用加粗字体的真实案例：
“一些贡献者甚至充当起了审查者（Reviewer）和大模型之间的‘传声筒’！他们复制我提问的 Review 意见，扔给大模型，然后把大模型生成的胡言乱语直接复制回来回复我。看在上帝的份上，求求你们停下吧！我想强调，这极其令人抓狂。这是导致我极度倦怠（Burn out）的头号因素！”
开源项目不仅仅是一堆冷冰冰的代码，它更是一个“人与人交流、碰撞、建立信任”的社区（正如 Peter Naur 在经典文章《Programming as Theory Building》中所言）。
当维护者满怀期待地与你讨论某个特性的底层设计时，你却用极其冗长、没有营养、甚至充满幻觉的 AI 废话来敷衍他们。这不仅是在浪费时间，更是在无情地践踏开源社区最宝贵的“信任契约”。
另一位Rust贡献者的控诉则充满了无奈：
“我完全不知道该怎么解决这个问题：‘没错，你很快就生成了一段看起来很合理的代码，但它在微妙的细节上完全是错的，而现在你正在浪费所有人的时间去排查它’。”
在没有 AI 的时代，分辨垃圾代码很容易；但在 AI 时代，大模型最擅长的，就是把垃圾包装成米其林三星的模样端给你。
面对这群不知疲倦的“AI 水军”，Rust 核心团队该怎么办？
在这份内部文档中，关于“如何对待 AI”的讨论，呈现出了极其撕裂的两种极端：
一些拥有极客精神的老兵认为，目前所有的 LLM 都是建立在“盗窃版权数据”的基础上的。不仅如此，大模型的训练正在消耗极度恐怖的能源，甚至让那些本该关闭的煤炭发电厂死灰复燃，加剧气候危机。
对于这些开发者而言，在 Rust 中拥抱 AI，就是对开源精神的背叛，是“令人作呕的”。他们主张全面封杀 AI 提交，并要求所有贡献者必须证明其代码完全由人类编写。
但现实是残酷的。Niko Matsakis 等负责人非常清楚：“潘多拉的魔盒已经打开，堵是堵不住的。”
既然无法阻止人们用 AI 写 PR，那就想办法用规则甚至用 AI 自身来防御 AI。
在这场激烈的讨论中，Rust 团队提出了几项极具参考价值的“防御性架构与策略”，值得每一个饱受 AI 代码折磨的团队学习：
在整份纪要中，最让我感到扎心的一段话，是关于“开源维护者生存现状”的拷问。
目前，像 OpenAI、Anthropic 这样的 AI 巨头，估值动辄千亿美元。它们的模型能写出越来越好的 Rust 代码，很大程度上是因为它们疯狂吸收了 Rust 社区十几年积累的心血。
然而，当这些估值千亿的公司推出“编程 Agent”，导致开源社区的维护工作量呈指数级爆发时，那些没日没夜帮这些“AI 垃圾代码”擦屁股的 Rust 核心维护者们，却拿不到一分钱的报酬！
一位核心成员悲愤地提议：
“也许我们应该直接去找那些 AI 公司（他们内部也在大量使用 Rust），要求他们出资赞助我们的维护者。虽然很多人在道德上抵制这些公司，但我依然希望拿他们的钱来养活我们的兄弟们。”
这就好比一家巨无霸外卖平台，每天把几十万份外卖倾倒在你的社区门口，然后让社区里那些没有工资的清洁工志愿者去疯狂打扫。
在 AI 巨头狂欢的盛宴下，开源世界的基石正在被悄无声息地榨干。
这份长达 20多 页的讨论，给所有沉浸在“AI 改变命运”幻觉中的开发者敲响了一记震耳欲聋的警钟。
不可否认，AI 确实是极其强大的工具。文档中也有不少成员承认，使用 AI 让他们感到了“赋能（Empowered）”，让他们能轻松搞定平时不愿意碰的繁琐文档和构建脚本。
但工具的强大，永远无法掩盖使用者的平庸。
当你可以用 Claude Code 在 10 秒内生成一段精妙的多线程 Rust 代码时，请记住：
只有当你真正懂所有权（Ownership）、懂借用检查（Borrow Checker）、懂底层内存布局，并且能在发生诡异 Panic 时独立完成 Debug 的那一刻，这段代码才真正属于你。
否则，你不过是 AI 巨头商业版图上，一个毫无感情的、廉价的“代码搬运工”。
不要用战术上的（生成代码）勤奋，去掩盖战略上的（底层认知）懒惰。
在代码生成的迷雾中，保持清醒的头脑，去深钻那些 AI 无法替代的系统级设计思维和底层工程哲学，才是我们在大模型时代唯一的生路。
资料链接：https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html
今日互动探讨：
在你的日常开发或开源贡献中，有没有被同事或陌生人提交的“AI 垃圾代码”狠狠坑过？你觉得开源社区应该全面封杀 AI 代码，还是张开双臂拥抱它？
欢迎在评论区疯狂吐槽与分享！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-25 07:11:34
本文永久链接 – https://tonybai.com/2026/03/25/go-spec-contradiction-in-types-section
大家好，我是Tony Bai。
在 Go 语言的世界里，type 是我们每天都在打交道的关键字。但如果我今天问你一个极其基础的问题：
Go 语言内置的 bool 类型，到底是不是一个“Defined Type（已定义类型）”？
你可能会愣一下，然后不假思索地回答：“那必须是啊，bool 是语言自带的，当然是已定义的。”
但如果我再追问一句：“既然它是 Defined Type，为什么我们不能给它绑定方法，像 func (b bool) IsTrue() {} 这样写？”
你可能就彻底懵了。
别慌，如果你对这个问题感到困惑，说明你已经触及到了 Go 语言类型系统设计中最深、也最容易被忽视的一个“历史遗留问题”。
就在最近，Go 官方 GitHub 仓库中，一个看似在“抠字眼”的 Issue #78208（spec: contradiction in Types section） 引来了社区里多位Go开发者下场激烈辩论，最终甚至连 Go 语言三巨头之一、被誉为“Go 语言之父之一”的 Robert Griesemer 都亲自现身，发表了一段长文来“认错”，并用拉丁语写下了那句沉重的 “Mea culpa”（我的锅）。
今天，我们就来当一次“技术侦探”，顺着这个 Issue 的蛛丝马迹，硬核扒开 Go 语言规范（Spec）的底层，看看这个小小的 bool 类型背后，到底藏着 Go 团队一段怎样的设计“原罪”，以及它对我们日常编码产生了多大的深远影响。
故事的起因非常简单。一位开发者在精读 Go 语言官方规范（Spec，被誉为 Go 语言的“圣经”）时，发现了一个极其明显的逻辑矛盾。
在 Types 章节，规范明确地将“具名类型（Named types）”分为了三类：
“Predeclared types, defined types, and type parameters are called named types.”
（预声明类型、已定义类型和类型参数，统称为具名类型。）
这里的措辞，清晰地将这三者并列。
但当你翻到 Boolean types 章节时，却赫然写着：
“The predeclared boolean type is bool; it is a defined type.”
（预声明的布尔类型是 bool；它是一个已定义类型。）
矛盾爆发了！
如果“预声明类型”和“已定义类型”是平级的、不同的两个分类，那 bool 怎么可能既是前者，又是后者？这就像生物分类学里说“哺乳动物和爬行动物是不同的两个纲”，然后又说“老虎是一种爬行动物”一样荒谬。
这个问题瞬间在社区里炸开了锅。
Issue 下方的评论区，堪称一场神仙打架。
一部分开发者认为这是明显的 Spec 笔误。他们旗帜鲜明地指出：
“bool 不是一个已定义类型。因为它不能拥有方法。对于一个已定义类型 T，它必须出现在 type T … 的定义中。”
这话说得掷地有声。我们都知道，type MyInt int 之后，MyInt 才是一个真正的 Defined Type，我们可以给它绑定方法。而 bool 显然不符合这个特征。
但另一派开发者，也开始了精彩的“诡辩”。他们认为：
“Spec 并没有说这三个分类是互斥的。‘预声明’只是意味着这个类型是编译器内置的，但它本质上依然是一个‘已定义’的类型。只不过它的定义对我们不可见罢了。”
双方你来我往，从类型的方法集，辩论到 Go 1.9 引入类型别名（Type Alias）时的历史背景，再到 Go 1.18 引入泛型后对“具名类型”的重新定义。
就在大家争得面红耳赤之时，Go 语言之父之一 Robert Griesemer 悄然现身，一锤定音。
Robert Griesemer 的长篇回复，像一本尘封已久的历史档案，为我们揭开了 Go 语言在类型设计上的一段“黑历史”。
他首先承认：“没错，你们都被搞糊涂了。这个 Spec 写得确实有歧义，我们马上就改。”
然后，他开始讲述这个“小小的”用词不当背后，隐藏的 Go 团队在设计类型系统时的“原罪”。
原罪的根源：Go 团队混淆了“拥有名字”和“拥有唯一身份”这两个概念。
那时只有“具名类型”和“匿名类型”。为了让 int、bool 这些内置类型拥有独一无二的身份（Type Identity），Go 团队很自然地把它们也归入了“具名类型”，毕竟它们确实有名字。这在当时看起来很完美。
type NewString = string 这样的类型别名出现了。NewString 也有名字，但它的身份和 string 是完全一样的。这就和原来的“具名=唯一身份”的假设冲突了。
为了解决这个问题，Go 团队做了一个现在看来极其糟糕的决定：他们把原来表示“唯一身份”的“具名类型”，改名为了 “已定义类型（Defined Type）”。而 bool、int 这些内置类型，为了保留它们的唯一身份，也就跟着一起被“定义”成了 Defined Type。
类型参数 T 出现了。T 也有名字，而且不同的类型参数（比如 T 和 P）必须拥有不同的身份。于是，Go 团队不得不又把“具名类型（Named Type）”这个概念重新捡了回来，这次用它来统称所有“拥有唯一身份”的类型。
看懂了吗？
bool 之所以被错误地描述为 defined type，完全是一次历史的意外。它是 Go 团队在不断给语言打补丁、修补旧概念的过程中，留下的一块“历史伤疤”。
Robert Griesemer 最后感慨道：“Mea culpa（我的锅）。”
这个小小的用词问题，背后是 Go 语言设计者在面对一个不断演进的复杂系统时，所做出的艰难权衡与无奈妥协。
他甚至自嘲般地补了一刀：
“为了让你们更受伤一点，我再告诉你们一个秘密：预声明的 any 类型，其实根本不是一个具名类型，它只是匿名接口 interface{} 的一个别名。”
最后，我们看到了Robert Griesemer 提交了一个cl，给出了修改方案：在spec中明确”predeclared types are named, not defined types”，即预声明类型是具名类型，但不是已定义类型。同时加上了对 any 这个预声明类型不是具名类型的澄清。
看到这里，你可能会觉得：“搞了半天，不就是改几个英文单词吗？关我写业务代码什么事？”
关系太大了。理解了这段“黑历史”，你才能真正打通 Go 类型系统的任督二脉，尤其是在处理泛型和接口时。
1. 你才能真正理解“类型约束”的本质。
在泛型函数中，~string 这个约束，匹配的是所有底层类型为 string 的类型。它包含了 string 本身，也包含了 type MyString string 这种 Defined Type。
但如果你只写 string，那么 MyString 类型的变量是传不进去的。
因为 string 是“预声明类型”，而 MyString 是“已定义类型”，尽管底层结构一样，但它们的“身份”在 Go 的世界里是完全不同的。
2. 你才能彻底搞懂“方法集”的规则。
为什么 bool 不能有方法？因为它不是通过 type 关键字在你的代码里定义的。方法只能绑定在你明确定义的类型上。这个规则，是 Go 语言不允许你“污染”内置类型的安全护栏。
3. 你才能在写库时，做出更高级的 API 设计。
当你设计一个库的 API 时，到底是应该接受 string，还是应该接受 interface{ String() string }？
如果你只接受 string，那么所有基于 string 定义的新类型都必须强制转换，非常不便。
但如果你接受接口，就意味着你放弃了对底层数据结构的强约束。
理解了“预声明类型”与“已定义类型”在身份上的本质区别，你才能在这两者之间做出最合理的架构权衡。
一个看似吹毛求疵的 Issue，最终牵扯出了 Go 语言长达十几年的演进历史和设计哲学。
它告诉我们： 一门伟大的编程语言，并不是一蹴而就的天才设计，而是在无数次的妥协、修补和自我反思中，不断螺旋上升的有机生命体。
而我们作为开发者，对这门语言最好的尊重，就是不仅要知其然，更要知其所以然。
下次当你在面试中被问到 Go 的类型系统时，不妨把这个关于 bool 的故事讲给面试官听。相信我，这远比你背诵一百遍枯燥的语法规则，更能证明你对这门语言的深刻理解。
资料链接：
今日互动探讨
在你的 Go 开发生涯中，遇到过哪些让你对 Go 的类型系统感到极其困惑，甚至怀疑人生的场景？比如类型断言的 panic、空接口的转换、还是泛型的约束？
欢迎在评论区分享你的踩坑经历！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-24 07:45:43
本文永久链接 – https://tonybai.com/2026/03/24/no-soil-for-new-programming-languages-in-ai-era
大家好，我是Tony Bai。
如果你回望过去十五年的软件工程史，那无疑是编程语言百花齐放的黄金时代。
为了对抗日益膨胀的系统复杂度，人类绞尽脑汁地发明新的“咒语”：
Google 推出了 Go 语言，用极简的 Goroutine 拯救了深陷并发地狱的后端工程师；
Mozilla 孕育了 Rust，用严苛的所有权机制向内存泄漏和数据竞争宣战；
苹果用 Swift 埋葬了晦涩的 Objective-C；
JetBrains 用 Kotlin 为笨重的 Java的使用者提供了一个更优雅的选择；
微软用 TypeScript 彻底规范了狂野的 JavaScript 生态。
每一次新语言的诞生，都伴随着开发者们的狂欢。我们热衷于讨论语法糖、对比编译速度、争论哪种范式更优雅。我们在各大论坛上为自己喜爱的语言摇旗呐喊。
但这已经是最后的余晖了。
站在 2026 年的节点上，当你看着 Claude Code、Cursor 或各类 Coding Agent 在几秒钟内倾泻出数千行逻辑严密的代码时，一个残酷的真相正在浮出水面：
大模型（LLM）的爆发，彻底抽干了孕育下一代通用编程语言的土壤。属于人类的“造语言”游戏，结束了。
这不是危言耸听，而是基于技术演进第一性原理的必然推演。
在 AI 时代，一门编程语言的生命力不再取决于它的语法有多么优雅，而取决于它在 AI 模型中的“语料权重”。
现存的主流语言（Python, Java, JavaScript, Go, C/C++等）在 GitHub 上积累了数年甚至十余年的海量开源代码。这些代码构成了大模型训练的底座，赋予了 AI 极高的“代码智商”。
当你用 Python 或 Go 提问时，AI 能够瞬间理解你的意图，补全复杂的逻辑，甚至自动发现隐藏的 Bug，因为它的“脑子”里装着上千万个成熟的 Python/Go 示例。
但对于一门新语言来说，这是绝对的死局。
假设明天某个天才发布了一门名为 Nova 的新语言，号称性能超越 C，安全性超越 Rust，语法如 Python 般简洁。
结果会怎样？
这就形成了一个无解的马太效应：
没人写就没有语料 -> 没有语料 AI 就不会写 -> AI 不会写人类就不想学 -> 更没人写。
现存的主流语言通过“语料霸权”，彻底锁死了新语言上升的通道。
人类发明新语言的根本动力，是“人脑的带宽有限”。
C++ 太容易写出内存泄漏，人脑排查太痛苦，所以我们发明了 Rust，让编译器做“真理警察”。
Java 处理异步回调太繁琐（Callback Hell），所以我们发明了各种新的语法糖。
我们一直在努力打造更锋利、更安全的斧头，因为那是人类自己要挥舞的斧头。
但在 Agentic Coding（智能体编程）时代，挥舞斧头的不再是人，而是不知疲倦的 AI。
当你可以用自然语言对 Agent 说：“用 C++ 实现一个高并发的 HTTP 服务器，并严格检查所有内存泄漏风险，写出 100% 覆盖率的测试用例。”
只要 AI 的推理能力足够强，加上自动化的沙箱验证（Eval），它完全可以写出极度安全、高效的 C++ 代码。
如果 AI 能够不知疲倦地处理最繁琐的语法、填补最冗长的样板代码（Boilerplate），并且不出错，那么“语言本身是否易读、是否好写” 似乎就变得不再重要了。
因为代码根本不是给人看的，也不是人写的。当“人脑带宽”不再是瓶颈，发明一种“让人类写得更舒服”的新语言，就失去了最大的现实动机。
如果不再有新的面向人类的通用编程语言，未来的代码世界会变成什么样？
答案是：极端的两极分化。
上层：英语（或自然语言）成为终极编程语言。
Andrej Karpathy 的预言正在成为现实（Software 3.0）。人类不需要学习晦涩的语法，人类只需要学习如何清晰、严谨地表达意图，编写能够精准约束 AI 的 Spec（规格说明书）。我们与机器的接口，退回到了人类最擅长的媒介。
底层：只有机器能读懂的“AI 专属语言”。
如果你是大模型厂商（比如 OpenAI 或 Google），当你发现 90% 的代码都是你的模型生成的，你还会让模型生成冗长、为了兼顾人类可读性而充满妥协的 Java 或 Python 代码吗？
不会的。巨头们极有可能会研发一种专门面向 AI 优化的中间表示语言（Intermediate Representation, IR）。
这种语言对人类来说如同天书，但对于模型来说：
AI 会将人类的自然语言直接“编译”成这种中间码，然后运行。
在这个过程中，介于自然语言和机器码之间、那种专门为了“让人类勉强能懂又能让机器执行”而存在的传统编程语言，其生存空间将被彻底抽空。
这听起来有些感伤，但这就是技术演进的无情车轮。
就像今天，依然有人沉迷于机械表的齿轮咬合，依然有人热爱在暗房里冲洗胶卷。
“纯手工编写代码（Handcrafted Code）”——这种我们曾引以为傲的工业生产方式，未来可能也会退化成一种个人的“艺术爱好”或“思维体操”。我们称之为“古法编程”。
在某个安静的周末，你或许依然会打开编辑器，为了兴趣手撸一段优雅的 Go 并发或者 Rust 生命周期，享受那种久违的、直接控制机器的“心流”多巴胺。
但在残酷的商业战场上，古法编程即将落幕。
不要再为语法糖而争论不休，不要再期待下一个能拯救你的新语言。
去锻炼你的系统思维吧，去学着用自然语言精准地描绘你的蓝图。因为在下一个时代，定义目标的造物主，永远比精通语法的泥瓦匠更稀缺。
你还在坚持“古法编程”吗？
面对 AI 现场生成代码的冲击，你是否还会为了某种语言的“优雅语法”而兴奋？在你的理想中，未来的“AI 专用中间码”应该长什么样？你是更享受亲自掌控每一行代码，还是更向往定义目标的“造物主”角色？
欢迎在评论区留下你对“古法编程”时代的最后致敬！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-03-23 07:18:11
本文永久链接 – https://tonybai.com/2026/03/23/go-is-the-best-programming-language-for-llm
大家好，我是Tony Bai。
在这个大模型重塑编程范式的当下，如果你想开发一个自主运行的智能体（Agent），或者想让大模型（LLM）帮你生成上万行的核心业务代码，你会选择哪门编程语言？
如果你去问 OpenAI 的总裁兼联合创始人 Greg Brockman，他的答案非常直接：
“Rust is a perfect language for agents, given that if it compiles it’s ~correct.”
（Rust 是开发 Agent 的完美语言，因为只要它能编译通过，它就基本是正确的。）
这句话听起来极其硬核且有道理。Rust 引以为傲的所有权模型和严苛的编译器，就像一个极度刻薄的审查员。既然大模型经常“胡言乱语”，那不如交给 Rust 编译器来兜底。
但有趣的是，Greg 的这番高论，最近在推特（X）上遭到了不少一线资深开发者的强烈反驳。其中，一条阅读量近 7 万的推文直指核心痛点，甚至抛出了一个让无数 Gopher（Go 开发者）极度舒适的反直觉结论：
“别吹 Rust 了，在大模型眼里，语法简单、风格统一的 Go 才是真正的‘香饽饽’！”
今天，我们就来扒一扒这场顶级“语言战争”背后的神仙打架，看看为什么 Go 语言身上那些曾经被全网群嘲的“缺点”，如今却成了大模型时代最无敌的护城河。
发起反驳的开发者 Emil Privér 一针见血地指出了用大模型写 Rust 的最大陷阱：“逃课”心理。
Greg Brockman 认为 Rust 编译器能阻止大模型犯错。但这有一个前提：大模型必须老老实实地去解生命周期（Lifetime）和所有权（Ownership）的方程。
然而现实是，大模型也是会“偷懒”的。
Emil 敏锐地指出，当现代 LLM 在生成复杂的 Rust 业务逻辑，且实在绕不过编译器的各种借用检查报错时，它们会极其鸡贼地使出大招：直接套上一层 unsafe {} 块，或者无脑使用 .unwrap() 来强行绕过编译器的安全审查！
你在指望编译器兜底，大模型却在底下悄悄开了“后门”。
就像评论区一位开发者吐槽的那样：“当你看到大模型为了图省事，把一段关键操作包在 unsafe 里，并且依然能顺利编译通过时，你还敢说它‘只要编译通过就基本正确’吗？”
虽然有开发者反驳说，可以通过配置强制禁止 unsafe。但大模型的“逃课手段”防不胜防，比如疯狂滥用 RefCell 导致运行时 Panic，这在编译器眼里是合法的，但在生产环境下却是灾难。
既然 Rust 太“聪明”导致大模型容易弄巧成拙，那大模型到底喜欢什么样的语言？
Emil 给出的答案是：Go。
他的底层逻辑非常硬核。
他认为，大模型（LLMs）的本质是基于大量预训练语料进行下一个 Token 的概率预测。对于这种预测机制来说，一段代码的上下文看起来越“同质化（Looks the same）”，大模型生成的准确率就越高。
这就牵扯到了 Go 语言一个常年被群嘲的“缺点”：啰嗦、缺乏表现力、没有花里胡哨的语法糖。
在 Go 里，如果你想写一个循环，你只有一种办法：for 循环。
没有 while，没有 do-while，没有 foreach，更没有各种炫技的函数式流处理。
而在 Rust 或者 JavaScript 等语言里，你想遍历一个数组，至少有 5 种写法。甚至在不同的开源库里，大家的编码风格都千奇百怪。
在人类看来，Go 语言简直“无趣”到了极点。但在大模型这种无情的“概率预测机器”眼里，Go 简直就是天堂！
因为 Go 语言有着近乎暴君般的强制格式化工具 gofmt，以及全宇宙最少、最没有歧义的语法关键字。无论你是 Google 的顶级工程师，还是刚入门三个月的新手，写出来的 Go 代码结构几乎是一模一样的。
这种极度“收敛”和“无聊”的代码风格，恰恰完美契合了大模型的预测机制。
当所有的 Go 项目看起来都像是一个模子里刻出来的，大模型在生成上下文时就不需要去猜测“这个项目的主人喜欢用哪种流派”。它闭着眼睛往下预测，准确率就能轻易碾压其他语言。
Go，这种“一眼望到底”的特性，让它成为了大模型眼里的头号“香饽饽”。
推特评论区里，争论依然在继续。
但透过这场口水战，我们作为一线的软件工程师，应该看透一个更深层次的时代演进：
在过去十年，程序员们热衷于发明各种奇技淫巧，比拼谁的代码写得更短、更具“魔法”；但在未来，当 80%以上 的代码都将由 AI Agent 自动生成时，“可读性”与“无歧义”将成为一门编程语言最核心的生产力。
Go 语言的联合缔造者 Rob Pike 当年顶着巨大的压力，坚持不给 Go 加各种复杂的特性。很多人觉得他固执、老派。但在十多年后的今天，当大模型海啸席卷而来时，我们才突然惊觉：
Go 语言那种“强迫你用最笨、最直白的方式写代码”的设计哲学，不仅让它在微服务时代大杀四方，更让它在 AGI 时代，成为了大模型最忠实、最可靠的合作伙伴。
当大模型吐出一段复杂的 Rust 代码，你可能还要花十分钟去审查它有没有隐藏的逻辑陷阱；
但当大模型吐出一段 Go 代码，那满屏极其直白的 if err != nil，让人类工程师一眼就能看穿它的核心逻辑。
没有魔法，才是大模型时代最强的防御。
资料链接：https://x.com/emil_priver/status/2034971247348535399
今日互动探讨：
在日常开发中，你让 ChatGPT/Claude 帮你写过哪种语言的代码？你觉得它写 Go、Python 还是 Rust 时的准确率最高？
欢迎在评论区分享你的实战感受！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
