2026-04-15 08:27:57
本文永久链接 – https://tonybai.com/2026/04/15/cpp-community-debate-productivity-revolution-vs-complexity
大家好，我是Tony Bai。
如果你把编程语言比作工具，Go 是一把极简的手术刀，精准且克制；Rust 是一套带智能传感器的外骨骼装甲，严苛且安全。
而 C++ 呢？它更像是一把在过去四十年里不断被加挂零件的、超重型复合瑞士军刀。
最开始，它只有刀片和叉子；后来，它加了锯子、剪刀和钳子；再后来，它甚至被塞进了一套显微镜和一支激光笔。在开发者眼里，它是能解决世间一切难题的万能神兵，但也是一个重到让你拿不稳、甚至随时可能切到自己手指的“庞然大物”。
但就在前几天，r/cpp 这个拥有近 10 万 C++开发者的顶级社区里，一篇名为《现代 C++ 是让我们更高效了… 还是更复杂了？》的帖子，引发了一场深度大讨论。
发帖人发出了灵魂拷问：
“C++20/23 给我们带来了 Ranges、协程（Coroutines）、Concepts、Modules……这些新特性真的很酷，我也在用。但我总在想，我们是不是在用这些东西吓跑新人的同时，眼睁睁地看着老代码库永远冻结在 C++98？现代 C++ 对生产力来说，到底是一场革命，还是在原本已经足够复杂的巨兽身上，又叠加了一层复杂性？”
这篇帖子，精准地戳中了每一个 C++ 开发者心中最深的困惑。短短一天，就吸引了上百条充满血泪与思考的评论。
今天，我们就来复盘这场顶级的社区大讨论，看看这柄“瑞士军刀”在疯狂“堆料”的背后，到底藏着怎样的挣扎、分裂与反思。
在这场大讨论中，我仿佛看到了 C++ 社区三个泾渭分明的平行宇宙。
宇宙一：永远的 C++98/11 ——“能跑就行，别动！”
评论区里，点赞最高的一派观点，充满了对“存量代码”的敬畏与无奈。
一位开发者吐槽道：
“我在太多项目里因为各种原因被迫使用旧标准，以至于我已经懒得去关心最新的特性了。我感觉很多专业场景就是这样：我们用着‘穴居人 C++’，因为那玩意儿安全（指熟悉）、方便。”
另一位开发者更是直接引用了 Matt Godbolt 的名言：“向后兼容性才是 C++ 的超能力。”
“别想着重构了，那只会破坏一切。跑了 20 年没 Bug 的生产代码是无价之宝，别碰它！”
更有甚者，因为芯片厂商的编译器只支持 C++89，或者因为“法律原因”，一个项目被迫在一个 3 年前的工具链上锁死 7 年。
在这个宇宙里，C++20 的新特性，对他们来说都像火星科技一样遥远。
宇宙二：拥抱 C++20/23 ——“旦用难回，太香了！”
与“遗老派”形成鲜明对比的，是那些已经吃上新标准红利的“先锋派”。
有开发者激动地表示：
“自从我开始用协程（Coroutines）写网络 IO 代码，我再也回不去以前那种回调地狱了！”
另一位则对 C++23 的 std::println 赞不绝口：
“我离不开 C++23，完全是因为 println。我不知道我还在用 23 的什么其他特性，但光这一个就太棒了。”
对于这部分开发者来说，现代 C++ 的每一个新特性，都是一次生产力的解放。他们就像一群拿到了新玩具的孩子，兴奋地探索着 Ranges 的组合魔法和 Concepts 带来的清爽报错。
宇宙三：爱恨交织的“中间派”——“一半是天堂，一半是地狱”
这或许是最大多数 C++ 开发者的真实写照。
正如帖子作者所言，新特性确实很酷，但它们也带来了巨大的认知负荷和决策成本。
一个开发者的评论获得了 82 个高赞：
“我们大多数人只用了 C++ 语言特性的一小部分。这就像一个‘鸡生蛋、蛋生鸡’的问题：这里有个新特性，但我不知道该怎么用、为什么要用；或者，我代码里有个痛点，可能能用新特性解决，但我不知道该用哪个。”
这种“选择的困境”，正是 C++ “自由”的代价。
为什么 C++ 会演变成今天这样？
评论区里的一位开发者给出了一个极其精妙的比喻：“集市（Bazaar）”。
“我绝对热爱 C++ 的一点是：它有一个特性集市，你可以挑选你认为适合你项目的工具。如果你看其他语言，比如 Java 要求万物皆对象，Haskell 要求万物皆函数。C++ 给了你面向对象，你讨厌它？没问题，不用就行。你喜欢函数式？C++ 也支持。”
这种“万物皆可选”的自由，是 C++ 最大的魅力，当然也是它最大的诅咒。
因为在一个团队里，当每个人都从“集市”上拿回了自己最喜欢的锤子时，整个项目就会变成一个风格迥异的“建筑工地”。
原帖作者自己也承认：
“自由是真实的，但这也意味着两个 C++ 代码库可能看起来像两种完全不同的语言。”
当一个文件里还在用裸指针和手动内存管理，而另一个文件里已经用上了 std::unique_ptr 和 std::span；当一部分团队在用 boost::asio 写回调，而另一部分团队在用 C++20 的协程……
Code Review 就变成了一场噩梦。
这场大讨论的背后，其实隐藏着两个更深层次的软件工程哲学问题。
问题一：新特性是“锦上添花”，还是“非用不可”？
很多 C++ 老兵认为，现代 C++ 增加的很多特性，比如 Ranges 和 Coroutines，其实早在几十年前的 LISP 语言里就已经被证明是伟大的思想。C++ 只是在用一种极其缓慢、极其复杂的方式，在“偿还”几十年前欠下的“技术债”。
但另一些人认为，C++ 的伟大恰恰在于，它能用“零成本抽象（Zero-cost Abstraction）”的硬核方式，将这些高级思想，落地到对性能要求极致的生产环境中。
问题二：复杂性是“敌人”，还是“朋友”？
一位开发者的评论极具辩证思维：
“这（新特性）既是好事，也是坏事。学习的门槛确实在不断提高。但这些工具是实实在在有用的，它们让你能用更干净、更安全、更高效的方式表达代码。”
当 Go在极力做“减法”，试图降低开发者的心智负担时，C++ 却似乎在坚定地走着另一条路：它信任开发者是专家，它把所有的选择权和复杂性都交给你，让你自己去构建属于你的“最佳子集”。
这就像驾驶一架拥有几百个仪表盘的航天飞机。对于新手来说是灾难，但对于顶尖的飞行员来说，每一个按钮都意味着更精准的控制力。
在这场看似无解的“内部大讨论”中，我们依然能找到一条充满智慧的中间路线。
有人分享了一个极具参考价值的真实案例：
他成功地在一个庞大的 C++98 代码库中，引入了一个用 C++17 编写的新功能模块。他没有去重构任何老代码，只是简单地升级了编译器和构建脚本。结果：新特性带来了性能的提升和开发效率的飞跃，而老代码依然稳定运行。
这或许就是现代 C++ 正确的打开方式：不要试图用新标准去“革命”旧代码，而是在写新代码时，大胆地、有选择地拥抱新特性。
让 C++98 的归 C++98，让 C++23 的归 C++23。在一个代码库中，允许不同时代的“方言”共存，用新增的模块去逐步“稀释”历史的包袱。
C++ 的这场大讨论，没有赢家。
它只是再次向我们证明了这门语言的“独一无二”：它是一门民主的语言。它给了你选择一切的自由，也要求你为自己的选择承担一切后果。
用一位开发者的话来说：
“Rust 强加给你它的观点；而 C++ 要求你有你自己的观点。这就像专制与民主的区别。大多数时候，民主只是一个被猴子笼子管理的、组织混乱的马戏团。但我更喜欢民主。”
或许，对于我们这些已经习惯了 Go 和 Rust 那种“带你走”模式的开发者来说，偶尔回头看看 C++ 这个充满“混沌与活力”的古老集市，会让我们对“软件工程”这门手艺，有更深刻的理解。
资料链接：https://www.reddit.com/r/cpp/comments/1sihs1w/is_modern_c_actually_making_us_more_productive_or
今日互动探讨：
在你的技术生涯中，你是否也曾被困在某个古老的“技术版本”里动弹不得？对于 C++ 这种“万物皆可选”的自由哲学，你是向往，还是恐惧？
欢迎在评论区分享你的看法！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-13 06:29:12
本文永久链接 – https://tonybai.com/2026/04/13/dave-cheney-goroutine-management-philosophy
大家好，我是Tony Bai。
在 Go 语言的江湖里，go func() 就像一把绝世好剑。它轻灵、锋利，只需几个字符，就能让你瞬间拥有“分身术”，并发地处理海量任务。Go 团队曾自豪地告诉我们：Goroutine 很廉价，你可以随手启动成千上万个。
于是，我们习惯了在代码里肆意挥洒：
我们以为自己掌握了并发的捷径。
但就在去年的 GopherCon Singapore 技术大会上，Go 社区的资深布道师 Dave Cheney，却用一场充满哲学思考的演说，给所有 Gopher 敲响了警钟。
他的核心论点很明确：Goroutine 绝非免费的午餐，它是一种需要付出代价的“有限资源”。如果你只管启动（Start）而不懂如何停止（Stop），你并没有在写高效的并发程序，你只是在为系统埋下慢性自杀的伏笔。
今天，我们就来深度拆解 Dave Cheney 的这场重要演讲，梳理出他在 AI 大模型和微服务时代，为我们总结的 “Goroutine 声明周期管理四大哲学”以及他最终给出的Goroutine管理方案。
Dave Cheney 在演讲开头提出了一个极其硬核的观点：内存不是无限的，它是和数据库连接、文件句柄一样的有限资源。
在 Java 或 C++ 中，我们要时刻担心内存泄漏。但在 Go 里，我们觉得有 GC（垃圾回收器）在，一切无忧。
然而，Dave 指出了一个被 99% 的人忽略的真相：在 Go 的世界里，每一个正在运行的 Goroutine，都是一个“GC 根节点（GC Root）”。
什么意思？
只要一个 Goroutine 还在运行，它所引用的所有内存、它栈上的所有变量、它指向的所有堆对象，GC 都绝对不敢回收。
“你可以关闭一个文件，可以解锁一个互斥锁。但你如何‘回收’一个失控的 Goroutine？”
如果你启动了一个 Goroutine 后失去了对它的追踪，它就变成了一个永远无法回收的“内存僵尸”。它不仅自己霸占着 2KB 以上的栈空间，更可能死死拽着几个 GB 的业务对象不撒手。
这是 Dave Cheney 演讲中最核心的一句军规：Never start a goroutine without knowing how it will stop.
为了证明“野 Goroutine”的破坏力，Dave 在现场演示了一个极其经典的血泪 Demo。
他写了一个 HTTP 服务器，为了让请求秒回，他把日志记录放到了后台：go logRequest(r)。
接着，他通过重定向标准输出模拟了下游日志系统网络拥堵、写入被阻塞的场景。
恐怖的一幕发生了：
服务器内存开始疯狂飙升，每秒钟都有成百上千个新的 Goroutine 被创建，但因为输出被阻塞，它们全都卡在写入的那一行，一个都死不掉。
不到一分钟，整个程序因为 OOM（内存溢出）当场暴毙。
Dave 的结论非常冷酷：
启动一个 Goroutine 只需要 1 微秒，但如果不考虑它的“死法”，这个 Goroutine 最终会成为杀掉你整个集群的凶手。
在 Java 中，曾经有一个 thread.stop() 方法，后来被禁用了，因为它会引发不可控的资源损坏。Go 语言聪明地避开了这个坑：Go 没有任何一种方式，能让一个 Goroutine 强行停止另一个。
你只能通过 “协同（Cooperation）”。
Dave 强调，defer 是 Goroutine 的“临终遗言”。所有的资源释放（文件关闭、锁解除）都必须放在 defer 里。
而管理这一切的唯一“生死符”，就是 Context。
在 Dave 的哲学里，一个合格的后台服务函数，必须长成这样：
func (s *Service) Run(ctx context.Context) error {
// 1. 临终遗言：无论如何，最后一定要清理战场
defer s.cleanup()
for {
select {
case <-ctx.Done():
// 2. 收到“生死符”，优雅退出
return ctx.Err()
case task := <-s.taskChan:
s.process(task)
}
}
}
你必须给 Goroutine 一个“想得开”的机会，让它在收到 ctx.Done() 时，带着所有的 defer 体面地离开。
这是 Dave Cheney 给库开发者（Library Authors）提出的最高阶要求。
他引用了另一位大神 Peter Bourgon 的话：“Leave concurrency to the caller.”
一个设计糟糕的库： 在你调用 NewProvider() 的时候，悄悄在后台启动了一个 Goroutine 去跑心跳，却没给你返回任何停止它的句柄。这种库是不可靠的。
一个具有“管理哲学”的库： 即使它需要后台运行，它也应该把那个 Run 函数暴露给用户，让用户自己决定：
只有这样，作为顶层架构师的你，才能真正实现所有子系统的 “同生共死”。
事实上，Go 社区与“Goroutine 管理”这个恶魔的斗争，从 2012 年就开始了。Dave带着我们一起回顾了一下社区的方案，虽然每个方案都不完美！
第一代武器：Tomb (坟墓)
来自 Canonical（Ubuntu 母公司）的 Juju 项目，发明了 tomb 包。它通过一个 t.Go() 方法来启动 Goroutine，并用一个 t.Wait() 来等待它们全部结束。但它的缺点是，如何通知这些 Goroutine“你们该停了”，依然需要开发者手动传来传去。
第二代武器：Errgroup
由 Go 社区大神 Brad Fitzpatrick 编写的 errgroup，极大地简化了“并发执行一组任务，并收集第一个错误”的场景。但它同样没有解决“如何优雅地通知所有任务提前中止”的问题。
第三代武器：OK Log 的 group 包
由 Peter Bourgon 设计的 group 包，首次引入了一个极其优雅的范式。它要求你在添加一个任务时，必须同时提供两个函数：一个 execute 函数（如何启动），和一个 interrupt 函数（如何打断）。
这是一种“契约式”的设计，强制开发者在启动一个 Goroutine 的时候，就必须想好如何杀死它。
在吸收了上述哲学以及社区尝试后，Dave 给出了一个现代 Go 微服务的“标准起手式”，当然也是他自己的Goroutine管理方案：pkg/group。
在吸收了社区十几年来的所有经验和教训之后，Dave Cheney 在演讲的最后，亮出了他自己多年来在无数个项目中沉淀下来的“终极武器”——一个同样名为 group 的、集大成的 Goroutine 管理库：pkg/group，也可以认为是一个现代 Go 微服务的“标准起手式”：
在 Dave Cheney 的 group 里，你添加的每一个任务，都必须是一个接受 context.Context 作为参数的函数。
g.Add(func(ctx context.Context) error {
// ...
})
Context 成了所有 Goroutine 唯一的“生死符”。无论是超时、是上游请求被取消、还是整个服务收到了 SIGTERM 信号准备关闭，都会通过 ctx.Done() 这个唯一的通道，通知到每一个角落。
在 Dave Cheney 的 group 中，任何一个子 Goroutine 发生的 panic，都不会导致整个进程崩溃。它会被 recover 住，转化为一个 error，然后触发整个 group 的优雅关闭流程。
pkg/group的使用典型示例如下：
在这段代码里，所有的后台服务被捆绑成了一个“命运共同体”。任何一个服务失败，或者 k8s 发来关闭 Pod 的信号，都会导致所有服务一起进入优雅关闭流程，确保数据不丢失、连接被妥善断开。
从“启动”到“坟墓”，Dave Cheney 为我们揭示了并发编程的下半场：Goroutine管理
go func() 赋予了我们随手创造并发的权力，但真正体现架构师功力的，是你管理这些并发生命周期的责任感。
下一次，当你在键盘上敲下那几个字符时，请停顿一秒。
想一想：这把剑挥出去，你还能收回来吗？
资料链接：https://www.youtube.com/watch?v=eJLVT157BSs
今日互动探讨：
在你的项目中，是否曾遇到过 Goroutine 泄漏导致的内存灾难？你是如何定位出那个“失踪”的 Goroutine 的？
欢迎在评论区分享你的避坑经验!
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-12 06:56:06
本文永久链接 – https://tonybai.com/2026/04/12/agile-manifesto-dead-in-ai-era-martin-fowler-kent-beck
大家好，我是Tony Bai。
25 年前，在美国犹他州的一间滑雪小屋里，17 位当时最顶尖的软件开发者聚集一堂，共同签署了一份将彻底改变未来二十年软件工程形态的纲领——《敏捷软件开发宣言》。
在这 17 位“上古大神”中，有两个名字，如同北极星一般，指引了一代又一代程序员的成长：一位是《重构》的作者 Martin Fowler，另一位则是“极限编程（XP）”之父、敏捷宣言的发起人 Kent Beck。
25 年后的今天，当生成式 AI 的海啸席卷全球，当“敏捷迭代”被 AI 的“瞬间生成”无情碾压时，我们不禁要问：敏捷已死吗？我们曾经信奉的那些工程哲学，还剩下什么？
就在前几天，在一个汇聚了硅谷最火热 AI 创业者的闭门活动上，这两位白发苍苍的“活化石”出人意料地并肩坐到了一起，进行了一场关于 AI 时代的世纪对话。
他们没有去鼓吹 AI 带来了多高的效率，反而用一种极其深刻、甚至有些悲观的视角，对当下这场“AI 狂欢”提出了终极拷问。这场对话，值得我们每一个身处其中的技术人，暂停手中飞速生成的代码，静下心来，一字一句地读完。
面对台下年轻开发者对 AI 的狂热与恐慌，Kent Beck 的开场异常平静。他把时间拉回到了自己还是个孩子的时候。
“在微处理器（Microprocessor）诞生之前，电脑是一个你根本搬不动的庞然大物。当英特尔 4004 芯片问世时，我们突然意识到，‘等等，这也是一台电脑！’ 突然之间，你能做的事情的想象空间被无限放大了。”
Kent Beck 认为，今天的 AI，在本质上与当年的微处理器、后来的面向对象、再后来的互联网浪潮并无不同。它们都是“想象力的放大器”。
他坦言自己现在正在用 AI 去做一些“极其离谱的、野心勃勃的项目”，比如用 Rust 写库级别的高质量代码。“很多都会失败，但这没关系，这就是探索的一部分。”
而 Martin Fowler 则补充了他对技术浪潮的“二阶思考”：
“你必须在‘怀疑主义’和‘好奇心’之间找到完美的平衡。我对区块链就极其怀疑。但我的怀疑主义必须是绝对的——这意味着，我必须连我自己的怀疑本身，都保持怀疑。”
他坦言，自己一开始对 Copilot 这种东西也极度不屑，觉得它生成的都是垃圾。直到他读了 Simon Willison 的博客，才意识到：要用好一个工具，你必须先学会如何用好它。这和当年很多人嘲笑“面向对象”没用，但其实只是他们自己没有用对，是同一个道理。
当被问及“AI 承诺的‘更快、更好、更便宜’，与 25 年前敏捷宣言的初衷是否一致”时，Kent Beck 抛出了一个极其扎心的观点：
“事实证明，企业根本不想要更快、更好、更便宜。在一个公司内部，各种激励机制的错位，导致他们会惩罚那些真正追求效率的人。”
Martin Fowler 对此深有同感。他认为，AI 与敏捷最大的不同在于，当年他们需要费尽口舌去说服企业“敏捷有多重要”，而今天，没有任何一家公司敢对 AI 的重要性视而不见。
但这恰恰是最大的陷阱。
当年的“敏捷转型”，在无数企业中最终都演变成了一场“形式主义的灾难”，催生了庞大的“敏捷工业复合体”。
而今天，同样的剧本正在 AI 身上重演。无数根本不懂技术的咨询公司，正在兜售着各种“AI 转型”的灵丹妙药。
AI 正在成为新的“蛇油（Snake Oil）”。
注：“蛇油”是19 世纪的美国民间骗局，有人贩卖一种据说能治百病的“蛇油”之类的神药。其核心特征是用夸张的疗效宣传、用故事/神秘疗法包装、同时缺乏科学依据，最后你花钱买到的往往是没用甚至有害的东西。
如果说对“蛇油”的警惕还只是宏观层面的担忧，那么 Kent Beck 接下来提出的观点，则直接刺向了每一个正在享受 AI 编码便利的开发者。
他认为，AI 正在让软件开发“重新孤岛化（Re-soloing of programming）”。
“极限编程（XP）很大一部分工作，是为那些天生不善社交的程序员，创造一个安全的社交环境。在一个 XP 团队里，人们每天花几个小时进行结对编程、激烈讨论，并乐在其中。”
“但我现在看到的是什么？‘我是一个程序员，我手下有 6 个 Agent，所以我是一个小团队的管理者。’ 不，你不是。你只是在同时使用 6 个工具。”
在过去，我们把程序员从一个个封闭的办公室里解放出来，让他们围坐在一起，通过“混乱、复杂、充满人味儿”的社交过程，去创造伟大的软件。
而现在，我们似乎又在主动退回那个“把程序员关进小黑屋，从门缝底下塞披萨”的时代。只不过，这次陪伴你的，是几个冰冷的 AI 机器人。
Martin Fowler 也表达了同样的担忧：
“未来的团队，到底是‘一个披萨的团队’（因为 Agent 不吃披萨），还是一个‘两个披萨的团队，但效率翻倍’？我赌后者。”
他认为，“两个人类 + N 个 AI” 的结对编程模式，可能是未来的答案。因为两个人类可以更好地控制 AI 的方向，同时保留了宝贵的人类交互。
有趣的是，Kent Beck 甚至觉得现在的 AI 有点“太快了”。
“当 AI 需要 3 分钟才能返回结果时，我们正好可以利用这段时间，去讨论一下变量命名的哲学，或者下一步的架构方向。但如果它 15 秒就返回了，我们就失去了交流的时间。”
在对话的最后，当被问及“AI 时代，程序员该如何自处”时，Kent Beck 的一段独白，充满了“手艺人”的失落与悲情，足以让每一个热爱编码的资深开发者瞬间破防。
“我过去在编程中获得的一种‘强迫症’般的享受，正在消失。那种把一个文件从一坨屎山，通过无数个微小、安全的步骤，最终重构成一件艺术品的快感，再也没有了。”
“我依然可以从宏观上理解我正在做什么。但我需要把我的关注点，从享受‘雕琢程序本身’，转移到享受‘理解业务领域’上。因为在‘雕琢程序’这件事上，我们已经失去了杠杆。”
Martin Fowler 则给出了更具操作性的建议：
“一个有趣的现象是：开发者体验（Developer Experience）和智能体体验（Agent Experience）的维恩图，是一个完美的圆。对 Agent 友好的代码，对人类也友好。”
他认为，拥有良好模块化、清晰接口和完备测试的代码，AI 处理起来会更得心应手。我们过去几十年积累的那些“手艺”，并没有过时，它们只是从“指导人类”变成了“指导 AI”。
这场持续了一个多小时的对话，没有给出任何关于“如何写 Prompt”、“用哪个模型”的答案。
但这两位穿越了数个技术周期的智者，用他们的人生经验，为我们指明了在 AI 这场史无前例的巨浪中，唯一能抓住的几块礁石：
最后，Kent Beck 给出了一个极其悲壮的建议：或许，我们是时候放弃享受“雕琢代码”的乐趣，而去享受“理解世界”的乐趣了。
这或许是对 AI 时代，我们这些“数字手艺人”最深刻、也最无奈的宿命注解。
资料链接：https://www.youtube.com/watch?v=CZs8J1ZD0CE
今日互动探讨：
在使用 AI 编程后，你是否也像 Kent Beck 一样，感觉失去了那种“重构屎山”的快感？在 AI 时代，你认为“结对编程”是会消亡，还是会变得更加重要？
欢迎在评论区分享你的看法！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-11 08:14:44
本文永久链接 – https://tonybai.com/2026/04/11/go-command-working-group-formed-legacy-commands-deprecated
大家好，我是Tony Bai。
在这个技术浪潮汹涌的时代，Go 语言以其惊人的稳定性和向后兼容性著称。但稳定，并不代表停滞。
就在最近，Go 核心团队内部悄然发生了一件大事：他们正式成立了一个全新的 “Go Command 工作组（Go Command Working Group）”。
这个工作组汇聚了 Go 工具链领域最核心的大神们（如 Cherry Mui、Matloob、ThePudds 等）。他们的使命非常明确：对 go 命令集中那些最古老、最含糊、最容易引发开发者困惑的“历史遗留问题”，进行一次彻底的“清理门户”。
就在前几天，这个“指挥部”的前两次闭门会议纪要，以及随之而来的两份重磅提案（Issue #78350 和 #78387被公之于众。
当我读完这些提案和讨论后，我意识到，一场关于 Go 语言未来的“静默革命”已经打响。今天，就让我们来拆解这场顶级大佬的闭门会议，看看我们用了十年的几个“祖传命令”，为什么即将面临被废除的命运。
如果你写过稍微复杂一点的 Go 项目，甚至只是写过一些 Makefile，你大概率见过 go list …。
在早期，go list …中的这三个点的省略号 … 意味着“匹配所有（Everything）”。
但在 Go Modules 时代，这条命令成了一个彻头彻尾的“陷阱”。
在最新的 Issue #78387 提案中，工作组负责人 Matloob 毫不客气地指出：
“在Go 模块模式下，go list … 几乎永远做不出用户期望它做的事！”
大佬辩论现场还原：
为什么必须砍掉它？
在旧的 GOPATH 时代，go list … 能简单粗暴地列出 $GOPATH/src 下的所有包。但在 Modules 时代，你想要的其实是当前项目的所有包，也就是 go list ./…（注意前面的 ./）。
直接用 … 会引发漫长且无意义的全局依赖解析，甚至导致构建失败。
更有意思的是，核心成员 Sean Liao (seankhliao) 用 GitHub 搜索了一下，发现有将近 6700 个 Makefile 或脚本里还写着 …。但经过抽查发现，这些代码大多是从几年前的旧教程里复制粘贴过来的，实际上在现在的模块模式下，它们本来就已经跑不通了。
经过讨论，工作组达成初步共识：在模块模式下，直接使用 go list … 将会报错并被禁用。系统会提示你改用 ./… 或者 work 模式。如果你公司的古老 CI 脚本里还有这个写法，赶紧改！
GO111MODULE 这个环境变量，是无数 Gopher 从 GOPATH 时代痛苦过渡到 Modules 时代的“阵痛记忆”。
它有三个值：on（强制开启模块）、off（强制关闭）、以及 auto（自动检测）。
在 Issue #78350 提案中，工作组决定对 auto 下达最终的“死亡通知书”。
大佬辩论现场还原：
为什么必须砍掉 auto？
auto 的逻辑是：如果当前或上层目录有 go.mod，就用模块模式；否则就回退到 GOPATH 模式。
这种“左右摇摆”的行为在十年前是伟大的过渡方案，但在今天却成了巨大的累赘。
Go 的工具链在启动时，每次都要去猜自己到底在什么模式下运行。如果彻底砍掉 auto（即默认全局 on），编译器可以做大量的架构简化。
更有趣的是，在提案的评论区，有开发者表示他们为了在旧 GOPATH 项目和新 Modules 项目间切换，在全局环境变量里写死了 GO111MODULE=auto。
但 Go 团队的决心是坚定的：到了 2026 年，如果你真的还在维护古老的 GOPATH 项目，你应该显式地在那个目录下设置 GO111MODULE=off。默认情况下，大门已经向 GOPATH 彻底关闭。
除了上述两个直接废弃的命令，会议纪要中还透露了一个极具前瞻性、也最能体现 Go 团队“工程哲学”的重磅提议：关于 go.mod 文件中 Go 版本号的简化。
如果你现在运行 go mod init my-module，生成的 go.mod 文件里会包含一个精确到补丁号（Patch version）的版本，比如 go 1.26.2。
这引发了一个极其无聊，却又在开源界反复上演的“内卷”：
每次 Go 发布一个新的小补丁版本，Github Dependabot 这种自动化机器人就会疯狂地给全世界的开源项目提 PR，要求把 go.mod 里的版本号也跟着升上去。
大佬辩论现场还原：
go.mod 里的 go 指令，核心作用是“启用语言的语法特性”。只要你的代码没用新语法，写 1.26 就足够了。至于构建时到底用 1.26.3 还是 1.26.8 的编译器来保证安全，那是执行构建动作的人（或者 CI 系统）该操心的事，而不是由成千上万个基础库的 go.mod 文件来反向绑架。
这项提议一旦落地，将彻底终结无意义的 PR 轰炸，让开源维护者重新获得清净。
Go Command 工作组的这两次会议，没有像泛型那样引入任何惊天动地的新语法。
但它对 Go 语言生态的影响，可能比任何一个新特性都要深远。
它像一个经验丰富的老园丁，正在小心翼翼但又果断地修剪 Go 这棵大树上那些已经枯萎、或者长歪了的枝桠。
在这场“静默的革命”背后，我们看到的，是 Go 团队对“简单性、确定性、工程效率”这三大工程哲学一以贯之的坚守。
Go 语言的伟大，不在于它有多么强大的功能，而在于它在过去十几年里，拒绝了多少看似“合理”的坏品味。而这场“清理门户”，才刚刚开始。
资料链接：https://github.com/golang/go/issues/78474
今日互动探讨：
在日常开发中，你被 Go 命令行的哪些“反直觉”行为坑过？对于废弃 go list … 和 GO111MODULE=auto，你是拍手叫好还是觉得会影响你的老项目？
欢迎在评论区分享你的看法！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-10 07:36:06
本文永久链接 – https://tonybai.com/2026/04/10/rails-father-dhh-on-ai-and-programmer-value
大家好，我是Tony Bai。
在这个由 AI 主导的、充满不确定性的 2026 年，整个软件行业似乎都被一种集体性的焦虑所笼罩。我们每天都在讨论：当 AI 能在一分钟内写完我们一周的代码时，我们这些“人类程序员”的价值还剩下多少？
就在所有人都在悲观地预测“程序员即将贬值”时，一位以“毒舌”和“极简主义”著称的硅谷大神，却逆着人潮，抛出了一个极其震撼的“反共识”暴论：
“我们可能已经见证了‘普通程序员’薪资的顶峰。但对于那些顶尖的、真正懂行的开发者来说，AI 正在让他们变得比以往任何时候都更值钱、更有价值。”
说出这句话的，正是 David Heinemeier Hansson (DHH)——Ruby on Rails 框架之父、37signals (Basecamp & HEY) 的联合创始人兼 CTO。
就在几个月前，DHH 还是 AI 编程最坚定的“喷子”之一。他曾公开嘲讽 Copilot 像个烦人的实习生，打断他的思路，生成的代码全是垃圾。
但在一场最新的深度访谈中，他却上演了一场惊天动地的“自我推翻”。他不仅承认自己已经“彻底投降”，更是将他现在的工作流形容为 “Agent First on Everything”（万物皆以智能体为先）。
这场 180 度的惊天逆转背后，到底发生了什么？在这场信息量爆炸的对话中，DHH 不仅详细复盘了让他“觉醒”的那个“aha moment”，更对 AI 时代的程序员价值、团队协作、以及“软件匠艺”的未来，给出了极其深刻、甚至有些残酷的终极洞见。
DHH 坦言，在 Copilot 和早期 Cursor 的“代码补全（Autocomplete）”时代，他对此类工具的厌恶达到了顶峰。
“我感到无比愤怒。它总是在我还没想清楚的时候就试图猜我想写什么。‘你是想写这个吗？’‘你是想写那个吗？’ 闭嘴！让我自己把话说完！”
他甚至一度悲观地认为，整个行业将走向一个由“Tab 键”驱动的、毫无思想的愚蠢未来，并开玩笑说自己可能要去丹麦种土豆了。
转折点发生在 2025 年的冬天。两个关键变量，彻底改变了游戏规则：
DHH 形容，当这两个变量结合在一起时，他迎来了职业生涯的“第二次启蒙”——上一次，是 2000 年初他第一次发现 Ruby 语言的优雅。
“我不再是那个在键盘上打字的人，我感觉自己像是穿上了一套超级机甲。我突然长出了 12 只手，可以同时操作 7 个屏幕。我作为程序员的能力，被极度放大了。”
当被问及 AI 是否会取代程序员时，DHH 毫不避讳地抛出了一个极其冷酷的观点：
我们很可能已经见证了“程序员（作为一种普通职业）”的黄金时代顶峰。
他认为，在过去，程序员之所以能获得极高的薪资，是因为他们是生产软件的“瓶颈资源”。产品经理想出一个绝妙的点子，必须排队等待昂贵的程序员花几周时间才能实现。
但现在，瓶颈正在快速转移。
“当产品经理自己就能用 AI 生成可用的代码时，事情就要变天了。在任何一个软件开发被视为‘成本中心’（而这恰恰是世界上绝大多数的软件开发场景）的公司，降薪和裁员的压力将是不可避免的。”
但这是否意味着所有程序员都会被淘汰？
恰恰相反。DHH 认为，AI 正在引发一场剧烈的“价值两极分化”。
因为他们是那个能够判断“AI 生成的东西是对是错、是美是丑”的最终把关人。他们从“体力劳动者”，进化为了“艺术总监”。
在这场对话中，DHH 反复强调一个词：Aesthetics is truth（美学就是真理）。
他认为，无论是在数学、物理学还是软件工程中，一个优美的解决方案，往往也正是那个正确的方案。
“乔布斯之所以关心 Mac 电脑机箱内部的走线，是因为他凭直觉知道，只有那些在乎印刷电路板布局的人，才会去死磕用户界面的每一个像素。”
在 AI 时代，这种对“美”的追求，不仅没有过时，反而变得空前重要。
因为当你拥有了无限的“算力（AI）”时，唯一稀缺的，就是“品味（Taste）”。
DHH 认为，未来顶尖的软件工程师，其核心竞争力将不再是“知道多少种排序算法”，而是：
代码的实现，正在变得廉价；而代码的“品味”，正在变得无价。
DHH 详细分享了他现在的“Agent-First”工作流，堪称教科书级：
他使用 tmux 在终端里创建了一个三分屏布局：
“我几乎所有的工作都从其中一个 Agent 开始。我给它一个模糊的指令，然后看着它生成初稿。然后我把初稿扔给另一个 Agent，让它去批判和重构。我让它们俩来回‘吵架’。最后，我再跳到 Neovim 里，做那个最终的‘裁判’。”
他分享了一个让他自己都感到震惊的案例：
37signals 的 Linux 发行版 Omarchy 积压了 250 个无人处理的 PR。他花了 90 分钟，让 Claude 帮他审完了其中 100 个。
“这在以前至少是一周的工作量。更重要的是，其中一半的 PR 涉及我不懂的领域，Claude 在那些领域，是比我更聪明、更优秀的审查者。”
DHH 在访谈中提到了一个极具启发性的概念：AI 正在让“雄心（Ambition）”变得廉价。
他举例，他让 Agent 在几天内，为一个搁置已久的需求（为 Omarchy 实现 Windows 双系统启动）制定了一套完整的、可执行的方案。而在过去，他连花 4 个小时去调研的意愿都没有。因为这件事“重要但不紧急”，而且“非常麻烦”。
“探索一个直觉的成本，已经被降低了一千倍。我们现在可以去挑战那些过去连想都不敢想的项目。”
他分享了 37signals 内部的一个真实案例：一位名叫 Jeremy 的工程师，利用 AI 发起了一个名为“P1 优化”的疯狂项目。他要去优化系统中那最快的 1% 的请求，让它们变得更快。
这在传统性能优化的世界里，简直是“吃饱了撑的”。
但 Jeremy 仅用了几天时间，通过让 Agent 疯狂分析和重构，提交了 12 个 PR，硬生生把这 1% 请求的延迟从 4ms 压缩到了 0.5ms 以下，实现了 10 倍的性能提升。
当探索的成本趋近于零时，过去那些被视为“无用功”的边缘优化，将共同汇聚成压倒性的产品优势。
在访谈的结尾，DHH 表达了他对未来的极度乐观。
他认为，AI 并没有让编程变得无趣，反而让他找回了自 2000 年初发现 Ruby 以来最大的快感。
DHH 的这场“觉醒”，不仅仅是一个技术大佬对新工具的拥抱。它更像一个宣言：
在 AI 时代，软件工程的“手艺（Craft）”并没有消亡，它只是从“雕琢代码”的微观层面，升维到了“塑造品味”与“驾驭系统”的宏观层面。
AI 正在无情地淘汰那些只会“拧螺丝”的码农，但同时，它也为那些真正热爱创造、拥有极高审美和品味的“工匠”，递上了一把前所未有的神兵利器。
你，准备好拿起它了吗？
资料链接：https://www.youtube.com/watch?v=JiWgKRgdgpI
今日互动探讨：
在使用 AI 编程后，你是否也像 DHH 一样，感觉自己的“野心”被放大了，敢于去挑战更复杂的项目？在你的工作中，AI 是更多地扮演“体力外包”，还是“创意伙伴”的角色？
欢迎在评论区分享你的真实感受！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
