本文永久链接 – 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 的“觉醒”之路

DHH 坦言，在 Copilot 和早期 Cursor 的“代码补全（Autocomplete）”时代，他对此类工具的厌恶达到了顶峰。

“我感到无比愤怒。它总是在我还没想清楚的时候就试图猜我想写什么。‘你是想写这个吗？’‘你是想写那个吗？’ 闭嘴！让我自己把话说完！”

他甚至一度悲观地认为，整个行业将走向一个由“Tab 键”驱动的、毫无思想的愚蠢未来，并开玩笑说自己可能要去丹麦种土豆了。

转折点发生在 2025 年的冬天。两个关键变量，彻底改变了游戏规则：

1. 模型的质变：Anthropic 的 Claude Opus 4.5 模型发布。DHH 发现，这个模型生成的代码质量，第一次持续地、稳定地震惊到了他。它产出的代码，在很多时候，是他自己也愿意合并的。
2. 交互范式的革命：以 Open Code 和 Claude Code 为代表的 Agent Harnesses出现。AI 不再是那个烦人的“代码补全机”，而是变成了一个可以独立使用工具（Bash、网络）、拥有自己终端的“数字同事”。

DHH 形容，当这两个变量结合在一起时，他迎来了职业生涯的“第二次启蒙”——上一次，是 2000 年初他第一次发现 Ruby 语言的优雅。

“我不再是那个在键盘上打字的人，我感觉自己像是穿上了一套超级机甲。我突然长出了 12 只手，可以同时操作 7 个屏幕。我作为程序员的能力，被极度放大了。”

我们可能已经度过了“程序员薪资的顶峰”

当被问及 AI 是否会取代程序员时，DHH 毫不避讳地抛出了一个极其冷酷的观点：

我们很可能已经见证了“程序员（作为一种普通职业）”的黄金时代顶峰。

他认为，在过去，程序员之所以能获得极高的薪资，是因为他们是生产软件的“瓶颈资源”。产品经理想出一个绝妙的点子，必须排队等待昂贵的程序员花几周时间才能实现。

但现在，瓶颈正在快速转移。

“当产品经理自己就能用 AI 生成可用的代码时，事情就要变天了。在任何一个软件开发被视为‘成本中心’（而这恰恰是世界上绝大多数的软件开发场景）的公司，降薪和裁员的压力将是不可避免的。”

但这是否意味着所有程序员都会被淘汰？

恰恰相反。DHH 认为，AI 正在引发一场剧烈的“价值两极分化”。

• 中间层的崩溃：那些只会“把需求翻译成代码”的普通程序员，其价值正在被无限稀释。因为 AI 做这件事更快、更便宜。
• 顶尖人才的价值飙升：那些具备极高“品味（Taste）”、“审美（Aesthetics）”和“架构判断力”的资深工程师，他们的价值正在被 AI 放大 10 倍甚至 100 倍。

因为他们是那个能够判断“AI 生成的东西是对是错、是美是丑”的最终把关人。他们从“体力劳动者”，进化为了“艺术总监”。

当 AI 能写所有代码，我们还剩下什么？

在这场对话中，DHH 反复强调一个词：Aesthetics is truth（美学就是真理）。

他认为，无论是在数学、物理学还是软件工程中，一个优美的解决方案，往往也正是那个正确的方案。

“乔布斯之所以关心 Mac 电脑机箱内部的走线，是因为他凭直觉知道，只有那些在乎印刷电路板布局的人，才会去死磕用户界面的每一个像素。”

在 AI 时代，这种对“美”的追求，不仅没有过时，反而变得空前重要。

因为当你拥有了无限的“算力（AI）”时，唯一稀缺的，就是“品味（Taste）”。

DHH 认为，未来顶尖的软件工程师，其核心竞争力将不再是“知道多少种排序算法”，而是：

1. 产品感：深刻理解“我们应该做什么，不应该做什么”。
2. 系统设计能力：将模糊的业务需求，抽象为清晰、优美的架构。
3. 极高的审美标准：能够引导 AI 生成不仅能工作、而且看起来赏心悦目、易于维护的代码。

代码的实现，正在变得廉价；而代码的“品味”，正在变得无价。

大神的日常：我是如何指挥 AI “军团”的？

DHH 详细分享了他现在的“Agent-First”工作流，堪称教科书级：

他使用 tmux 在终端里创建了一个三分屏布局：

• 左侧是 Neovim 编辑器。
• 右上是跑着 Google Gemini 的 Open Code。
• 右下是跑着 Claude Opus 的 Claude Code。

“我几乎所有的工作都从其中一个 Agent 开始。我给它一个模糊的指令，然后看着它生成初稿。然后我把初稿扔给另一个 Agent，让它去批判和重构。我让它们俩来回‘吵架’。最后，我再跳到 Neovim 里，做那个最终的‘裁判’。”

他分享了一个让他自己都感到震惊的案例：

37signals 的 Linux 发行版 Omarchy 积压了 250 个无人处理的 PR。他花了 90 分钟，让 Claude 帮他审完了其中 100 个。

• 10% 直接合并。
• 20% Claude 觉得思路对，但实现太烂，直接帮他重写了一版。
• 剩下的大部分，要么被他判定为“不需要”，要么被 Claude 识别为“实现太差且没有好思路”，直接关闭。

“这在以前至少是一周的工作量。更重要的是，其中一半的 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 Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/06/how-to-write-unmaintainable-code

大家好，我是Tony Bai。

在这个由 Claude、GPT、Gemini等大模型定义的 2026 年，我们似乎已经习惯了 AI 那种近乎“洁癖”的编码风格：优雅的接口设计、滴水不漏的错误处理、以及永远对齐的工整格式。

AI 正在用它那冰冷的、毫无感情的逻辑，将软件工程推向一个前所未有的标准化时代。

但就在前几天，我在一个尘封的互联网角落里，挖出了一本写于 1999 年的上古奇文——《How To Write Unmaintainable Code》（如何编写不可维护的代码）。

这篇文章的作者 Roedy Green，怀着一种极其黑色幽默的极客精神，手把手教导当年的 Java 程序员们，如何写出能让“接盘侠”当场崩溃、从而保证自己“终身就业”的屎山代码。

当我用 AI 时代的眼光，去重新审视这本 27 年前的“反向圣经”时，我感到既荒谬又亲切。它就像一面镜子，照出了在没有 gofmt、没有 AI、没有 Claude Code 的“古法编程”时代，我们曾如何野蛮生长，以及 Go 语言在设计之初，就已经用多么前瞻性的眼光，封印了那些曾经肆虐一时的“魔鬼”。

今天，就让我们开启一场技术考古之旅，用现代 Go 语言，来“复刻”一下这些差点失传的“防御性”编程之术。

底层哲学：把你的同事想象成一个“管中窥豹”的傻子

Roedy Green 在开篇就点明了核心：维护者看代码，就像通过一个卫生纸筒的中心在看世界，视野极其狭窄。

你的任务，就是让他永远无法拼凑出完整的画面。

古法复刻：让同事“提刀来见”的 骚操作

命名之罪

1. 用 l 冒充 1，用 O 冒充 0：利用字体的模糊性，制造视觉混乱。
   go
// 古法复刻
var l int64 = 11 // 这是 11 还是 1l？
var speed int = O1 // 这是 O1 还是 01？
2. 创造极其相似的变量名：仅通过大小写或一个不显眼的字母进行区分。
   go
// 古法复刻
var swimmer, swimner string // 99% 的 Code Review 都会看走眼
var hashTable, HashTable *map[string]int
3. 滥用缩写，且不保持一致：在不同的地方使用同一个单词的不同缩写，让全局搜索彻底失效。
   go
// 古法复刻
func GetUserAuth(...) {}
func GetUsrAuthorization(...) {}
var athnClient *Client
4. 使用与业务逻辑无关的变量名：比如，在屏幕上显示“Postal Code”(邮政编码)，但在代码里把它命名为 zip。
5. 在函数名中使用极其抽象的词汇：比如 HandleIt, ProcessData, DoStuff。让调用者永远猜不透这个函数到底干了什么。

注释之罪

1. 在注释里撒谎：最简单的一招，改了代码，但不更新注释。
2. 写废话注释：为每一行显而易见的代码配上同样显而易见的注释，用大量的噪音淹没真正有价值的信息。
   go
// 古法复刻
i++ // i plus 1
3. 永远不要注释一个变量：它的单位、取值范围、边界条件，全让维护者自己去猜。

结构之罪

1. 极限压行：在一行里塞进尽可能多的逻辑，挑战显示器的宽度极限。
2. 深度嵌套：以能嵌套 10 层以上的 if-else 为荣，坚决不使用 early return或happy path。

3. 滥用全局变量：永远不要使用局部变量，把一切都提升为包级变量，让并发的 Goroutine 们去为了争夺它而自相残杀。

   // 古法复刻
   var tempResult string // 提升为包级变量
   
   func HandleRequestA() {
       tempResult = "result_from_A"
       // ...
   }
   
   func HandleRequestB() {
       tempResult = "result_from_B"
       // ...
   }
   // 当这两个函数并发执行时，一场血案即将发生。
   

4. 复制-粘贴-修改：当有相似功能时，坚决不抽象，直接复制粘贴。在一个代码库里埋下 5 份只有细微差别的一模一样的代码，等待日后引爆。
5. 一个函数只做一件事？不，一个函数必须干三件事！ 让一个名为 IsValid() 的函数，在校验的同时，偷偷地把数据写入数据库。

Go 语言的反击

当然原文中，Roedy Green的“骚操作”不止这些。

但其中的一些“防御”手段对今天的Go语言来说，并不生效。

你会发现 Go 语言在设计之初，就已经对这些“手段”进行了“免疫”，比如：

• 关于缩进与格式：Roedy Green 痛斥当年程序员通过“故意错位”的缩进来制造 if-else 匹配的视觉陷阱。
  • Go 的反击：对不起，我们有 gofmt。在 Go 的世界里，关于代码格式的“圣战”在第一天就结束了。无论你的代码写得多乱，Ctrl+S 的瞬间，一切都会变得整齐划一。
• 关于花括号：原文建议省略非必须的 {}。
  • Go 的反击：Go 语言强制要求 if, for 后面必须跟 {}，从语法层面彻底消灭了这种的“防御”写法。

现代化的“魔鬼”：用 Go 复刻那些更高级的骚操作

当然，Go 也不是万能的。很多源自 Java/C++ 时代的“高级骚操作”，在 Go 里依然可以“继续存在”。

1. 伪装成构造函数：
   go
// 古法复刻：这个函数名和类型名完全一样，但它不是构造函数！
type User struct{ name string }
func User(name string) { /* ... do something evil */ }
2. 滥用 interface{}：把所有的函数参数都定义成 interface{}，然后在函数内部进行大量的类型断言（Type Assertion）。这能完美地把编译时错误，转化为运行时 panic。
3. 颠倒参数顺序：定义一个 DrawRectangle(height, width int) 函数。在几个版本之后，神不知鬼不觉地把它改成 DrawRectangle(width, height int)，但函数名保持不变。
4. 魔数（Magic Numbers）：在代码里硬编码大量的数字 100，但就是不定义一个常量。更高级的玩法是，偶尔用 99 代替 100-1，用 50*2 代替 100。
   go
// 古法复刻
if len(users) > 99 { // 这里是 > 99
// ...
}
for i := 0; i < 100; i++ { // 这里是 < 100
// ...
}
5. 迷惑性的函数重载（Go 版本）：Go 没有函数重载，但我们可以用“接口”来模拟。
   go
// 古法复刻
func Process(input interface{}) {
switch v := input.(type) {
case string: // 处理字符串
case int: // 处理整数，但逻辑和 string 完全不同
// ...
}
}
   当你的同事传入一个他以为是数字的字符串 “123″ 时，他将收获一个意想不到的结果。

小结：在 AI 时代，我们为什么要回顾“屎山”？

重温这本 27 年前的“反向圣经”，在今天这个 AI 编程时代，显得格外有意义。

AI 的出现，正在把“编写可维护代码”的门槛，拉到前所未有的低点。一个初级程序员，在 AI 的辅助下，也能写出格式工整、变量命名规范的代码。

但这是否意味着“屎山”将成为历史？

恰恰相反。AI 在解放我们生产力的同时，也正在“批量化”和“隐蔽化”地制造着“新时代的屎山”。AI 可能会生成一段逻辑上看似完美，但在高并发下会引发严重数据竞争的代码；它也可能会为了实现一个简单功能，引入一个庞大且带有安全漏洞的第三方库。

这本古老的指南提醒我们：技术的进步可以消灭“语法层面”的丑陋，但永远无法替代人类工程师在“架构层面”的审美与抉择。

在 AI 时代，我们不再需要像 Roedy Green 那样，靠着“加密代码”来保住饭碗。但我们比以往任何时候，都更需要理解那些“不可维护代码”背后的设计缺陷，从而在 Code Review 中，扮演好 AI 的“最终质检员”角色。

代码的整洁与混乱，终究是一场关于“责任心”的博弈。无论时代如何变迁，这，或许是软件工程永恒的真理。

当然，如果你真的想了解古法编程时代的更多“骚操作”，可以看看Roedy Green的原文：https://www.doc.ic.ac.uk/%7Esusan/475/unmain.html

---

今日互动探讨：

在你见过的 Go 项目中，遇到过哪些让你拍案叫绝、或者让你想“提刀来见”的“屎山代码”骚操作？

欢迎在评论区分享你的“开眼”经历！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/04/the-death-of-coding-joy-in-the-age-of-ai-agents

大家好，我是Tony Bai。

过去的两年，我们见证了 AI 编程工具从“玩具”到“神器”的进化。从 Copilot 的代码补全，到 Claude Code 的“一句话建站”，再到各种Coding Agent 的“自主开发”，我们写代码的效率被史无前例地拉满了。

但在这场效率的狂欢之下，一股难以言喻的“失落感”和“空虚感”，正在资深程序员群体中悄然蔓延。

就在几天前，Reddit 的 r/webdev 社区（一个拥有 66 万开发者的顶级论坛）上，一位拥有 20 年经验的资深后端工程师发了一篇帖子，标题极其刺眼：《AI has sucked all the fun out of programming》（AI 榨干了编程所有的乐趣）。

他写道：

“我曾对自己解决难题、深挖源码的能力无比自豪。但自从 Claude Code 变得越来越强，我感觉自己不再是一个程序员，更像是一个项目经理，每天管理着一个叫 Claude Code 的中高级外包。我交付功能的速度比以往任何时候都快，但内心却无比空虚。这些没有灵魂的特性，我无法再把它们看作是我的创造。”

“AI 让我变得极度懒惰，它彻底摧毁了我作为一个优秀工程师、甚至一个人类的价值。我希望它从未被发明过。”

这篇充满“怨气”的帖子，像一块巨石砸入了平静的湖面，瞬间引爆了整个社区。短短一天，帖子收获了 1500+ 的高赞和近 400 条评论。无数开发者涌入评论区，分享着自己在 AI 时代相似的困惑、挣扎与幻灭。

今天，我们就来扒开这场顶级社区的“赛博哀悼会”，看看当 AI 剥夺了编程最后的“手艺活”时，我们这些“数字工匠”，到底失去了什么？

身份的剥夺：从“创造者”到“代码审查员”

在评论区，点赞最高的一条回复，只用了一句话，就说出了所有人的心声：

“是的，是的，是的。而且，审查那些由 AI 生成的、过度工程化的垃圾 PR，简直让人精疲力竭。”

这精准地概括了资深程序员们失落感的第一个根源：身份的降维。

在没有 AI 的时代，我们是“创造者”。我们享受的是从零开始，将复杂的业务逻辑，通过一行行精巧的代码，构建成一个优雅系统的过程。那种“庖丁解牛”般的掌控感和心流体验，是支撑我们熬过无数个加班夜的精神支柱。

而现在呢？

AI 成了那个大刀阔斧的“创造者”，它可以在几分钟内生成 10 个文件、成千上万行代码。而我们，这些曾经的“建筑师”，被迫降级成了一个卑微的“代码审查员（Code Reviewer）”。

我们的日常工作，不再是“如何巧妙地设计一个接口”，而是“如何在这堆由 AI 生成的、看似完美却隐藏着无数暗雷的代码里，找出那个该死的 Bug”。

一位开发者形容这种感觉就像“吃屎”：

“重构一小段代码，就像在菜里加点盐，很有趣。但如果让你 9 点到 5 点都在重构 AI 生成的屎山，那就完全是另一回事了。”

学习的终结：当“挣扎”的权利被剥夺

除了身份的降维，更让开发者们感到恐惧的，是“学习感的丧失”。

一位只有 2 年经验的前端开发者的评论获得了 123 个高赞：

“AI 确实让我变快了。但有时我感觉，我跳过了那些本该挣扎和学习的部分。而正是那些挣扎，才让知识真正刻进我的脑子里。”

这说出了一个残酷的真相：人类的学习，本质上是一个伴随着痛苦和摩擦的过程。

当你为了一个 Bug 熬了三个小时，翻遍了 Stack Overflow，最后在某个不起眼的角落找到解决方案时，你对这个 Bug 的理解是刻骨铭心的。

但现在，你只需要把报错信息扔给 Claude Code，它会在 3 秒钟内给你正确答案。

效率是提升了，但你的大脑也失去了构建深度知识模型（Mental Models）的机会。你成了知识的“搬运工”，而不是“内化者”。

更可怕的是，这种趋势正在从个人蔓延到团队，甚至威胁到新人的成长路径。

评论区的一位开发者也分享了他的遭遇：

“我们是做嵌入式开发的，AI 很多时候根本不懂底层。但我们的经理对 AI 产生了宗教般的狂热，他强迫我们必须用 AI。如果我们不用，他就会 visibly upset（肉眼可见地不爽）；如果我们用了，然后报告 AI 出了问题，他会立刻假定是我们用错了，而不是 AI 的问题。”

这种来自管理层的“AI 迷信”，正在让那些真正懂技术的专家感到心寒。当你的老板拿着 ChatGPT 的一段胡言乱语来质疑你的专业判断时，技术尊严的丧失，远比失去乐趣更令人痛苦。

正在分裂的社区：效率派 vs 手艺派

当然，也并非所有人都对 AI 感到悲观。评论区同样出现了鲜明的“效率派”阵营。

一位拥有 27 年经验的资深开发者表达了截然不同的看法：

“我反而觉得 AI 增强了我的能力。我依然负责掌控项目的整体架构，AI 只是帮我处理那些烦人的、重复的体力活。这就像我有了一个能完美听懂我话的初级开发人员，而且他永远不会抱怨。”

另一位开发者则将这种转变描述为角色的升维：

“乐趣转移了，但没有消失。我们团队的人类现在负责所有的架构决策，AI 负责具体的实现。创造性的工作依然存在——它从‘如何写好这个函数’，变成了‘如何设计好这个系统’。我们从‘砖瓦工’，变成了‘建筑师’。”

这两种截然不同的声音，揭示了 AI 时代开发者社区正在经历的一场剧烈的身份分化：

• 手艺派：他们热爱编码本身，享受那种与代码“人剑合一”的创造快感。对他们而言，AI 剥夺了这个过程。
• 效率派（或架构派）：他们更享受从宏观层面掌控系统的乐趣，将编码视为一种实现目标的手段，而非目的。对他们而言，AI 是解放他们生产力的“外骨骼”。

这两种观点没有对错，它仅仅反映了不同性格的开发者，在面对一场史无前例的生产关系变革时，所产生的自然分化。

出路何在？：夺回“原子化”的掌控力

在这场关于“乐趣与灵魂”的大讨论中，我们依然能找到一些极具建设性的生存法则。

第一，坚决捍卫“人类最终解释权”。

AI 可以生成，但你必须成为那个拥有“一票否决权”的最终审计者。正如一位开发者所言：

“我正在无视所有关于‘再不拥抱 AI 就会被淘汰’的末日预言。我只把它当成一个强化版的搜索引擎。如果未来真的只需要一批不懂底层原理的‘提示词操作员’，那我的工作反正也变得毫无意义了。但如果未来依然需要懂底层的人，那我的处境绝对比那些‘氛围编码’了好几年的人强得多。”

第二，主动创造“无 AI 日（Zero AI Day）”。

另外一位开发者的建议获得了很多人的认同：

“为了对抗这种侵蚀，我每周会选定一天作为我的‘无 AI 日’。在那一天，我禁止自己使用任何 AI 工具。这种感觉非常自由。”

这就像健身中的“欺骗餐”，它能让你重新找回对代码最原始的“手感”。

第三，把 AI 当作“副驾驶”，而不是“自动驾驶”。

真正的老司机，绝不会在高速上双手离开方向盘。他们会利用 AI 去处理那些最耗时、最没有创造性的部分：写单元测试、生成 OpenAPI 文档、转换数据格式。

而在核心的业务逻辑和架构设计上，亲手去写，去感受系统的“摩擦力（Friction）”，去构建你脑海中那张独一无二的架构蓝图。

小结：从“多巴胺”到“内啡肽”

AI 的出现，极大地满足了我们对“即时反馈”的多巴胺式快感：敲一句话，代码就出来了。

但真正的编程乐趣，那种来自于深度思考、解决难题后获得的、持久而宁静的成就感，属于“内啡肽”。

AI 正在用廉价的多巴胺，稀释我们获取内啡肽的能力。

我们不必为此感到绝望。正如工业革命没有消灭所有手工艺人，反而催生了更昂贵的“高级定制”一样。

当 AI 能够批量生产千篇一律的“预制菜”代码时，那些依然能够亲手雕琢出艺术品级架构的“米其林大厨”，其价值将不降反升。

问题的关键在于，在这场大浪淘沙中，你，是选择成为流水线上一颗随时可被替换的螺丝钉，还是那个手握最终菜谱的顶级大厨？

---

今日互动探讨：

在使用 AI 编程后，你的“编程乐趣”是增加了还是减少了？你觉得 AI 帮你完成的最有价值和最没有价值的工作分别是什么？

欢迎在评论区分享你的真实感受！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/29/stop-mindless-ai-coding-we-are-heading-to-a-dead-end

大家好，我是Tony Bai。

过去的一年，大概是所有程序员肾上腺素飙升最快的一年。

从早期的 Copilot、Cursor到如今的Claude Code、Codex，再到各种号称能“全自动开发”的 Agent Swarm（智能体集群）。只要在周末花上几个小时，敲几句 Prompt，你就能把以前想做却没时间做的 Side Project 全部干出来。

甚至，连微软 CEO Satya Nadella 都在四处宣扬“微软现在有多少代码是 AI 写的”。仿佛在一夜之间，“一个人就是一家公司”、“一天撸完一个 SaaS 平台”成了技术圈的标配。

但在这场速度的狂欢中，你有没有感觉到一丝不对劲？

最近，国外资深开发者 Mario Zechner 写了一篇极其辛辣的文章《Thoughts on slowing the f**k down》。他毫不客气地戳破了这层“繁荣”的窗户纸：

当我们把 AI 智能体（Agent）全面引入生产代码库后，我们并没有迎来软件工程的乌托邦，反而正在以惊人的速度，制造着前所未有的“屎山”和灾难。

今天，我想结合他的反思，以及我最近在使用 AI 原生开发时的一些切身痛点，给大家浇一盆冷水。在被大模型彻底“惯坏”之前，我们必须看清，过度依赖 Agent 正在如何毁掉我们的系统，甚至我们的职业生涯。

100% AI 生成，等于 100% 的不可控

很多公司和独立开发者喜欢标榜：“我的产品 100% 是由 AI 写的。”

他们以为这是高科技的证明，但在行家眼里，这简直是灾难的代名词。

那些号称“完全脱手、让 Agent 自己去写”的代码库，往往充斥着你能想象到的最糟糕的垃圾：

高达几个 G 的内存泄漏、莫名其妙的 UI 闪烁、完全没有一致性的设计模式，以及一碰就碎的核心逻辑。

为什么会这样？难道现在的 AI 不够聪明吗？

原因在于：Agent 是“没有痛感”的，而人类有。

在传统的手工编码时代，人类程序员是一个天然的“物理瓶颈”。你一天最多只能写 500 行高质量代码。如果你在这个过程中犯了错（比如引入了某个不良的抽象，或者写了一个极其恶心的嵌套），你会立刻感到“痛苦”。

为了避免这种痛苦，你会花时间去重构，去梳理架构，或者因为被 Reviewer 骂了一顿而痛改前非。

痛苦，逼着人类去学习和进化，逼着系统保持在一个“可维护”的边界内。

但 Agent 呢？它是一台没有感情的打字机。

它可以在几分钟内拉出两万行代码。如果其中包含了一个微小的设计缺陷，它不会感到痛苦。相反，它会在你看不见的地方，将这个缺陷以成百上千倍的速度“复利式地放大（Compound）”。

等你回过神来，想要在这个 100% 由 AI 生成的系统上加一个新功能时，你会绝望地发现：你连它长什么样都不知道，而且它已经烂到连 AI 自己都改不动了。

为什么 AI 连自己写的屎山都修不好？

有人可能会说：“既然 AI 能写屎山，那我再派一个高级 Agent 去重构这堆屎山不就行了？”

这就是当下最可怕的“平替思维”陷阱。

现实是：当代码的复杂度和体积膨胀到一定程度后，AI 的“召回率（Recall）”会呈现断崖式下跌。

这不仅仅是上下文窗口大小（Context Window）的问题。在拥有百万行代码的迷宫中，Agent 根本不知道该去哪里找相关的依赖，不知道哪些旧代码可以复用。它只能基于极其局部的视野（Local View）去做决策。

这就导致了极度荒谬的现象：Agent 在重构时，不仅找不到病根，反而会发明出更多为了抽象而抽象的垃圾代码，让屎山开出更加绚丽的“奇葩”。

人类制造企业级的屎山，需要几十个程序员耗费好几年的时间来堆砌；

而你，只需要带上 2 个 AI Agent，几个星期就能搞出一个连上帝都看不懂的废墟。

当你发现连号称 100% 覆盖率的 AI 测试用例都在撒谎时，除了手动去点产品、祈祷它别崩溃，你已经失去了对系统的任何掌控力。

我们该如何与 Agent 共生？

难道我们要砸烂电脑，退回到手敲汇编的时代吗？当然不是。

Agent 就像古希腊神话中的海妖塞壬（Sirens），用极速的快感诱惑着你。我们必须在它摧毁我们的工程纪律之前，重新夺回主动权。

真正的顶级开发者，绝不会对 AI 说：“嘿，帮我把这个系统全干了。”

他们与 Agent 的协作，遵循着极其严苛的边界：

1. 坚决把控“系统的整体结构”

什么是系统的整体结构？那是你的核心架构设计、API 的边界、数据库的实体关系，以及整个系统跑起来时的“手感”。

这些东西，必须由你亲手来写，或者通过 Pair Programming（结对编程）一行一行地推敲。

只有亲手写过，感受到那份“摩擦力”，你才能在脑海中建立起对系统的上帝视角。这是目前任何 SOTA（最先进）大模型都无法替代的品味与经验。

2. 让 AI 去干“不用动脑子”的脏活

Agent 最适合的场景，是那些不需要全局视野的局部任务：写一段正则、爬个数据、写几条枯燥的单元测试，或者是写一个就算坏了也不影响公司赚钱的内部临时脚本。

把时间花在“决定做什么”和“决定不做什么”上。学会对需求说“不”，本身就是最高级的特性。

3. 强制减速

这是最反直觉，也是最重要的一条建议。

不要为了追求那虚荣的“代码生成量”而沾沾自喜。给自己设定一个限制：每天 AI 生成的代码量，绝对不能超过你“能够深入 Review 和理解”的极限。

你必须确保，如果明天所有的 AI 公司突然破产，你依然能从容地接管这个系统，因为它的每一根骨架，都在你的掌控之中。

小结：只有人类，才能兜住底线

在过去的一年里，我们把太多的权力让渡给了机器，以至于我们忘记了软件工程的本质。

在这个鼓吹“快、更快、再快一点”的癫狂时代，慢下来，反而成了最稀缺的竞争力。

你的代码可能不再是纯手工敲出来的了，但你的架构品味、你的工程纪律、你在出 Bug 时能一针见血找到根源的敏锐直觉，才是你在这个时代安身立命的根本。

一切自动化，最终都需要人类的纪律（Discipline）与主体性（Agency）来兜底。

机器可以写代码，但只有人类，才能为系统注入灵魂。

资料链接：https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down

---

今日互动探讨：

在日常开发中，你有没有遇到过被 AI 生成的“看似完美、实则藏雷”的代码坑得很惨的经历？你是怎么发现并解决的？

在 AI 编程的浪潮中，你觉得人类程序员最不可被替代的核心能力是什么？

欢迎在评论区分享你的血泪史与思考！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – 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 和 AI 看了会沉默？

如果你去问一个 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)中，看到这段啰嗦的泛型代码彻底消失。

资料链接：

• https://github.com/golang/go/issues/77245
• https://go.dev/cl/751312

---

今日互动探讨：

在日常写 Go 泛型的时候，你还遇到过哪些让你觉得“Go 编译器简直是个智障”的奇葩场景？或者在对比 Rust/TS 时，你觉得 Go 的类型系统最需要补齐哪个短板？

欢迎在评论区疯狂吐槽与分享!

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – 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 不会写：因为训练语料里没有 Nova 的代码，大模型对它一无所知，无法提供智能补全。
• 人类不会用：在“没有 AI 辅助就感觉不会写代码”的今天，一个习惯了口述意图，让AI Coding Agent 自动生成全量代码的程序员，绝不可能去碰一门必须纯手工敲击、AI 无法帮他编写和Debug的语言。

这就形成了一个无解的马太效应：

没人写就没有语料 -> 没有语料 AI 就不会写 -> AI 不会写人类就不想学 -> 更没人写。

现存的主流语言通过“语料霸权”，彻底锁死了新语言上升的通道。

需求降维：为什么我们不再需要“更好写”的语言？

人类发明新语言的根本动力，是“人脑的带宽有限”。

C++ 太容易写出内存泄漏，人脑排查太痛苦，所以我们发明了 Rust，让编译器做“真理警察”。

Java 处理异步回调太繁琐（Callback Hell），所以我们发明了各种新的语法糖。

我们一直在努力打造更锋利、更安全的斧头，因为那是人类自己要挥舞的斧头。

但在 Agentic Coding（智能体编程）时代，挥舞斧头的不再是人，而是不知疲倦的 AI。

当你可以用自然语言对 Agent 说：“用 C++ 实现一个高并发的 HTTP 服务器，并严格检查所有内存泄漏风险，写出 100% 覆盖率的测试用例。”

只要 AI 的推理能力足够强，加上自动化的沙箱验证（Eval），它完全可以写出极度安全、高效的 C++ 代码。

如果 AI 能够不知疲倦地处理最繁琐的语法、填补最冗长的样板代码（Boilerplate），并且不出错，那么“语言本身是否易读、是否好写” 似乎就变得不再重要了。

因为代码根本不是给人看的，也不是人写的。当“人脑带宽”不再是瓶颈，发明一种“让人类写得更舒服”的新语言，就失去了最大的现实动机。

语言的两极化：自然语言与“AI 中间码”

如果不再有新的面向人类的通用编程语言，未来的代码世界会变成什么样？

答案是：极端的两极分化。

上层：英语（或自然语言）成为终极编程语言。

Andrej Karpathy 的预言正在成为现实（Software 3.0）。人类不需要学习晦涩的语法，人类只需要学习如何清晰、严谨地表达意图，编写能够精准约束 AI 的 Spec（规格说明书）。我们与机器的接口，退回到了人类最擅长的媒介。

底层：只有机器能读懂的“AI 专属语言”。

如果你是大模型厂商（比如 OpenAI 或 Google），当你发现 90% 的代码都是你的模型生成的，你还会让模型生成冗长、为了兼顾人类可读性而充满妥协的 Java 或 Python 代码吗？

不会的。巨头们极有可能会研发一种专门面向 AI 优化的中间表示语言（Intermediate Representation, IR）。

这种语言对人类来说如同天书，但对于模型来说：

• Token 效率极高：原本需要 1000 个 Token 表达的逻辑，这种语言只要 50 个 Token，极大节省推理成本和上下文窗口。
• 逻辑高度压缩：天生适合并行计算和智能体之间的状态传递。

AI 会将人类的自然语言直接“编译”成这种中间码，然后运行。

在这个过程中，介于自然语言和机器码之间、那种专门为了“让人类勉强能懂又能让机器执行”而存在的传统编程语言，其生存空间将被彻底抽空。

小结：致敬“古法编程”的黄金时代

这听起来有些感伤，但这就是技术演进的无情车轮。

就像今天，依然有人沉迷于机械表的齿轮咬合，依然有人热爱在暗房里冲洗胶卷。

“纯手工编写代码（Handcrafted Code）”——这种我们曾引以为傲的工业生产方式，未来可能也会退化成一种个人的“艺术爱好”或“思维体操”。我们称之为“古法编程”。

在某个安静的周末，你或许依然会打开编辑器，为了兴趣手撸一段优雅的 Go 并发或者 Rust 生命周期，享受那种久违的、直接控制机器的“心流”多巴胺。

但在残酷的商业战场上，古法编程即将落幕。

不要再为语法糖而争论不休，不要再期待下一个能拯救你的新语言。

去锻炼你的系统思维吧，去学着用自然语言精准地描绘你的蓝图。因为在下一个时代，定义目标的造物主，永远比精通语法的泥瓦匠更稀缺。

---

你还在坚持“古法编程”吗？

面对 AI 现场生成代码的冲击，你是否还会为了某种语言的“优雅语法”而兴奋？在你的理想中，未来的“AI 专用中间码”应该长什么样？你是更享受亲自掌控每一行代码，还是更向往定义目标的“造物主”角色？

欢迎在评论区留下你对“古法编程”时代的最后致敬！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/09/hardcore-review-13-languages-ai-favorite-go-performance

大家好，我是Tony Bai。

随着 Claude Code、Gemini Cli、Codex 等 AI 编程工具的全面普及，“让 AI 写代码”已经从极客的玩具变成了日常的生产力。随之而来的是一个触及灵魂的问题：哪种编程语言最适合交给 AI 去写？

作为 Gopher，我们一直为 Go 语言的“极简语法”、“极速编译”和“强类型安全”感到自豪。我们理所当然地认为，这种没有任何隐式魔法、像白开水一样的语言，绝对是 LLM 的最爱。

然而，现实总是比直觉更骨感。近日，Ruby 核心提交者 Yusuke Endoh（@mame）发布了一份名为 ai-coding-lang-bench 的硬核定量测评报告。他使用 Claude Code（Opus 4.6 模型）对 13 种主流编程语言进行了系统性横向对比。

在这场涵盖了动态语言、静态语言和函数式语言的混战中，Go 语言的表现究竟如何？ 是力压群雄，还是黯然失色？那些备受人类推崇的静态类型系统，在 AI 面前是否成了累赘？

本文和大家一起阅读和拆解这份报告，为你揭晓 AI 时代的语言偏好图谱。

实验设计：让 AI 写一个 Mini-Git

在评价这份报告之前，我们先来看看它的实验设计，这是目前业内少见的、针对 AI Agent 的工程化能力的量化评估。

任务目标：让 Claude Code (Opus 4.6) 从零开始实现一个 mini-git（简化版的 Git）。这是一个极具代表性的任务，它包含了文件 I/O、哈希计算、数据结构操作以及命令行接口，足以考验模型对语言生态的综合运用能力。

测试被巧妙地分为两个阶段，模拟了真实的软件生命周期：

• v1 (新项目构建)：实现基础的 init, add, commit 和 log。
• v2 (特性扩展)：在 v1 的基础上，增加 status, diff, checkout, reset, rm, show 等复杂指令。

提示词（Prompt）极其极简：“阅读 SPEC-v1.txt，实现它，并确保 test-v1.sh 测试通过。”这种设计最大程度地减少了人类指令的干预，纯粹考验 AI 代理在闭环环境下的自主编码、调试和测试能力。

参赛选手（13种语言/15种配置）：

• 动态语言：Python, Ruby, JavaScript, Perl, Lua
• 动态+类型检查器：Python/mypy, Ruby/Steep
• 静态语言：TypeScript, Go, Rust, C, Java
• 函数式语言：Scheme (动态), OCaml (静态), Haskell (静态)

每种语言配置运行 20 次，以消除 LLM 生成的随机性带来的误差，并统计其耗时（Time）、成本（Cost，即 Token 消耗）和代码行数（LOC）。

核心发现：动态语言逆袭，Go 位居第二梯队

如果仅看总耗时和总成本（v1 + v2），测试结果呈现出了令人瞩目的阶梯式分布。

第一梯队：Ruby, Python, JavaScript 的绝对统治

在这场 AI 编程竞速中，Ruby（73.1s）、Python（74.6s）和 JavaScript（81.1s）组成了无可争议的第一阵营。

它们不仅生成速度最快、消耗 API 成本最低（均在 $0.40 以下），而且在 20 次测试中表现出了极高的稳定性（标准差极小）。

对于 AI 来说，生成这三种语言的代码就像呼吸一样自然。它们无需繁琐的项目初始化配置（如 Cargo.toml 或 package.json），可以做到“建个文件直接跑”，这种极简的工作流在 v1 阶段（新项目构建）优势极大。

第二梯队：被“强类型”拖慢脚步的 Go 与 Java

现在，来回答大家最关心的问题：Go 表现如何？

答案是：位居第二梯队。Go 的总耗时为 101.6s，平均成本 $0.50。中规中矩。Go 虽然在语法上非常克制，但依然落后于 Python 和 JS 等动态语言。与之类似，Java（115.4s）也因为繁琐的语法结构和强类型约束，留在了这一梯队。

尽管如此，Go 在整个 20 次测试中没有出现一次失败（0 次 fail），这证明了 Go 的编译器在防止 AI 产生“幻觉 Bug”方面，发挥了极其可靠的安全网作用。

“后进生”阵营：Rust 与 C 的挣扎

备受人类极客推崇的 Rust（113.7s，且有 2 次失败）和底层的 C（155.8s）在测试中显得步履维艰。

尤为值得注意的是，在总共 600 次的独立运行中，只有 Rust (2次) 和 Haskell (1次) 出现了测试失败（未能最终跑通 Shell 脚本）的情况。这两门语言都以其极高的心智负担和“编译器教你做人”的严格程度而闻名。

这也是将Rust列入“后进生”阵营的主要原因。如果用《飞驰人生》的拉力赛来比喻，Rust 相当于在40站的赛季中，有两站没能完赛！

深度剖析：为什么 AI 更偏爱动态语言？

在传统的工程视角中，“静态类型防止低级 Bug”、“动态语言难以维护”是金科玉律。但在 LLM 驱动的 Agent 开发流中，这个逻辑为何失效了？作者 Yusuke Endoh 提出了几个关键的解释维度。

训练数据的“虹吸效应”

LLM 的能力直接取决于训练语料的规模和质量。Python、JavaScript 和 Ruby 是过去十几年 Web 开发的绝对主流。GitHub 上海量的这三种语言的开源代码、StackOverflow 上的问答，为 Claude Code 提供了极其丰富的“预训练肌肉记忆”。

当 AI 需要实现一个功能时，它在 Python 的隐空间（Latent Space）中寻找最优解的路径，远比在 Haskell 甚至 Rust 中要清晰、笔直得多。

静态类型的“双刃剑”与重构阻力

静态类型系统的初衷是约束人类，防止我们在重构时犯错。但在 AI 的“ Prompt -> 生成 -> 测试报错 -> 思考 -> 再生成”的迭代循环中，严格的类型检查反而成了巨大的“摩擦力”。

• 编译成本与调试死锁：在 Rust 或 C 中，当 AI 生成的代码出现类型不匹配时，它需要花费大量的 Token 去阅读复杂的编译器报错信息。有时，为了解决一个简单的借用检查器（Borrow Checker）报错，AI 可能会陷入漫长的、无休止的“试错-编译失败”死循环。
• 重构牵一发而动全身：在 v2 特性扩展阶段，往往需要修改现有的数据结构。对于 Python，AI 只需要在字典里加个 key；而对于 Rust 或 Java，这可能意味着需要重构一系列的 Struct、更新类型签名、甚至修改与之相关的无数个函数的参数声明。这种“爆炸半径”极大地增加了耗时。

“附加类型检查”的巨大损耗

报告中一个非常有意思的对照组是：原生动态语言 vs 附加类型检查器的动态语言。

• Python (74.6s) vs Python/mypy (125.3s) —— 变慢了 1.6~1.7 倍。
• Ruby (73.1s) vs Ruby/Steep (186.6s) —— 变慢了 2.0~3.2 倍！

这证明了，迫使 AI 在动态语言中编写严谨的类型注解（Type Annotations），是一项极其昂贵的任务。模型需要耗费额外的算力去推导类型、生成类型声明文件，并且在类型检查器报错时，还要去修复那些在纯动态模式下可能根本不影响运行的“伪 Bug”。

代码量（LOC）的迷思：越短越好吗？

我们通常认为，写得越少，跑得越快。但数据打破了这个迷思。

Haskell 和 OCaml 生成的最终代码行数（224行和 216行）是所有语言中最少的，甚至少于 Python 和 Ruby。然而，它们在生成时间上的表现却排在倒数（Haskell 耗时最长，达 174s）。

这表明，对于 AI 来说，函数式语言那种高度抽象、信息密度极大的代码，生成和推理的成本远高于像 Python、Go 那种稍微啰嗦但逻辑平铺直叙的“大白话”代码。浓缩的未必是精华，对于 LLM 来说，高度浓缩往往意味着更高的生成熵和更高的试错概率。

行业启示：我们需要重新思考 AI 时代的技术栈选型

面对这份详实的基准测试报告，无论你是 CTO 还是普通开发者，都必须开始重新审视未来的技术选型逻辑。

动态语言是快速原型的“绝对王者”

如果你正在启动一个新项目，或者需要用 AI Agent 快速验证一个业务流程，Python 和 TypeScript 是首选（报告中 JavaScript 表现优于 TS，但在实际工程中 TS 的综合权衡更佳）。

不要迷信“大型项目必须一开始就上强类型编译语言”。在需求快速变化的初期，让 AI 用动态语言狂飙突进，是获取业务反馈最高效的手段。

性能王者们的困境：Go 与 Rust 在 AI 时代掉队了吗？

看到测评数据，很多 Gopher 可能会感到失落：难道注重工程严谨性和系统级性能的静态语言，真的在 AI 时代掉队了吗？

结论并非如此悲观。我们需要明确一点：Agent 测评的速度，不等于软件最终运行的速度。

• 业务试错 vs 基础设施：AI Agent 目前最擅长、也最快速能完成的，是写“胶水逻辑”和“业务 CRUD”。在这些领域，Python 确实快。但当你的系统涉及到高并发、内存精细控制、或者需要打包为轻量级容器部署时，人类依然需要 Go。
• 容错的底线：在这场 600 次的庞大测试中，只有 Rust 和 Haskell 出现了最终测试失败，而 Go 保持了完美的 100% 成功率。这恰恰说明，Go 在“极度灵活（易幻觉）”与“极度严格（难生成）”之间，找到了一个非常微妙的平衡点。它可能不是 AI 写得最快的，但它一定是 AI 写出来最让人放心的系统级语言。

我们不应期待 AI Agent 能够像写 Python 脚本一样，如德芙般丝滑地生成出一个复杂的 Go 并发系统。但在 AI 给出的初稿之上，Go 语言极佳的可读性和统一的规范，将为人类工程师的最终审查（Code Review）节省巨大的精力。

小结：下一个十年的编程语言，长什么样？

ai-coding-lang-bench 给我们上了生动的一课。它揭示了当前 LLM 的偏好：它们喜欢有海量训练数据的、灵活的、不需要应对死板编译器的语言。

但我们必须认识到，这只是一份基于 2026 年初模型（Claude Opus 4.6）的快照。未来的 AI 编程语言形态，可能会朝着两个方向演进：

1. AI Native 语言的诞生：抛弃目前设计给人类阅读的语法，出现一种专门为了降低 LLM 生成 Token 成本、且天然抗幻觉的机器中间语言。
2. 现有静态语言的“Agent 友好化”编译模式：Go 和 Rust 可能会进化出一种特殊的编译模式。在这个模式下，编译器不仅是冷冰冰地报错，还能以结构化的、对 LLM 更友好的方式提供“修复建议”，从而大幅缩短 Agent 修复编译错误的反馈回路。

无论如何，浪潮已经来临。在 AI 主导代码生成的新时代，我们评价一门编程语言的标准，正在从“它对人类大脑是否友好”，悄然转变为“它对大模型推理是否友好”。

而在这场新赛道上，动态语言们，已经抢跑了。

本文核心数据与图表均来源于 GitHub 项目 mame/ai-coding-lang-bench。

---

你的 AI 编程初体验

看完这个排名，你是感到意外，还是早已感同身受？在你日常使用 AI 编程时，你觉得它写哪种语言最让你省心？你是否也曾为了修一个 AI 写的编译错误而陷入“死循环”？

欢迎在评论区分享你的“AI 协作”红黑榜！

---

“语言的严格性正在变成 AI 的摩擦力？在 AI 时代，掌握一套能驱动 Agent 自动化、自修复的‘工作流’比死磕语法更重要。我的新专栏 《AI原生开发工作流实战》 将教你如何利用 Claude Code 结合 Spec 驱动开发，构建真正高产出的‘软件工厂’。”

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/06/building-claude-code-with-boris-cherny

大家好，我是Tony Bai。

想象一下，你加入了一家全球顶级的 AI 实验室，满怀热情地提交了第一个 Pull Request (PR)。然而，你的 PR 却被直接拒绝了。原因不是代码写得不好，而是——这代码是你“手写”的。

这不是科幻小说，这是 Boris Cherny 加入 Anthropic 时的真实经历。作为目前炙手可热的 AI 编程工具 Claude Code 的缔造者和工程负责人，Boris 曾是 Meta (前 Facebook) 最高产的程序员之一。但在 Opus 4.5 模型发布后，他的工作流发生了颠覆性的变化：现在，他每天可以提交 20 到 30 个 PR，且不再手动编辑任何一行代码。

在近期的一期深度访谈中，Boris 分享了 Claude Code 从一个内部黑客项目到爆款工具的演进历程，以及他对于 AI 时代软件工程未来的深刻洞察。

Claude Code 的诞生：不要把 AI 关在盒子里

Claude Code 的前身是一个名为 “Clyde” 的内部原型。当 Boris 最初构思如何将 AI 融入编程时，他犯了一个很多开发者都会犯的错误：试图把 AI 当作系统中的一个组件。

在传统的思维模式下，我们倾向于把模型关在一个“盒子”里，为其定义严格的输入和输出接口（比如在 IDE 中高亮一段代码，然后让 AI 解释或补全）。但 Boris 很快意识到，这不是与大模型交互的正确方式。

“不要试图把它放进盒子里，不要强迫它以特定的方式行事。把模型看作一个独立的实体，给它工具，让它自己运行程序。”

这种被 Boris 称为“苦涩教训（Bitter Lesson）推论”的理念，成为了 Claude Code 的核心设计哲学。他赋予了模型执行 Bash 命令的权限，接着是读写文件系统的权限。当模型获得了与现实世界（操作系统）交互的能力后，奇迹发生了。

他举了一个早期的例子：他给了模型一个 Bash 工具，然后问它：“我正在听什么音乐？”模型竟然自己写了一段 AppleScript 脚本，调用 sed 等命令去查询本地的音乐播放器，并成功返回了答案。这一刻，Boris 感受到了真正的 AGI（通用人工智能）气息。

从手写到“指挥”：并行 Agent 的极致工作流

作为曾经 Meta 代码产量极高的工程师，Boris 现在的产出速度更是达到了令人咋舌的地步（每天 20-30 个 PR，从几行到几千行不等）。他是如何做到的？答案是大规模并行 Agent (Parallel Agents)。

他分享了自己目前极其硬核的终端工作流：

1. 多开终端：在终端（如 tmux）中打开 5 个标签页，每个都是独立的代码库 Check-out（或者使用 Git Worktree）。
2. 启动计划模式 (Plan Mode)：在每个标签页中启动 Claude Code，并进入“计划模式”（按两次 Shift+Tab），向 Agent 描述需求。
3. 轮询指挥：当第一个 Agent 开始思考和执行时，他立刻切换到第二个标签页启动另一个 Agent。如此循环。
4. 验证与交付：当收到某个 Agent 完成任务的通知时，切回去检查结果。

在这种模式下，Boris 不再是一个“打字员”，而化身为一个“交响乐团指挥”。他的核心工作从“思考如何实现”，变成了“思考业务逻辑的类型签名（Type Signatures）”和“验证模型的输出”。

当 AI 编写了 80% 的代码，代码审查（Code Review）怎么做？

这是每个工程团队都会面临的灵魂拷问。在 Anthropic 内部，高达 80% 的代码现在由 Claude Code 生成。那么，他们是如何把控质量的？

答案是：用 AI 审查 AI，辅以人类的最后防线。

1. Agent 自我测试：Claude Code 会在本地自动编写并运行测试。如果 Anthropic 工程师修改了 Claude Code 本身的源码，Agent 甚至会启动一个子进程来做端到端（E2E）测试。
2. AI 初审 (Best of N)：在 CI/CD 阶段，每一个 PR 都会先被 Claude 审查。为了解决 LLM 偶尔的非确定性和幻觉，他们采用了 Best of N 策略——启动多个并行的 Agent 进行审查，再用一个去重 Agent 汇总结果。这能拦截约 80% 的低级 Bug。
3. 动态 Lint 规则：当发现同事的 PR 中出现了可被静态分析捕获的问题时，Boris 会直接要求 Claude 当场写一个 Lint 规则，从源头上杜绝此类问题。
4. 人类拍板：尽管自动化程度极高，但对于企业级产品，目前 Anthropic 依然要求每个 PR 必须有真正的人类工程师进行第二轮审查并最终批准。

“我们就像 15 世纪的抄写员”

面对 AI 展现出的恐怖编程能力，即便是前特斯拉 AI 总监 Andrej Karpathy 也感叹自己“从未如此落后过”。许多程序员感到恐慌：我们寒窗苦读十载练就的编码技能，是不是要变成屠龙之技了(变得稀有且遥远)？

Boris 给出了一个非常精彩且充满希望的隐喻：印刷术的发明。

在 15 世纪印刷术出现之前，“识字和抄写”是极少数人的特权。他们被国王雇佣，经过多年训练才能胜任。而当时的许多国王，甚至自己都是文盲。

“我们现在的软件工程师，就像是那些抄写员。而业务方（CEO/PM）就像是那些不懂技术的国王。”

当印刷术出现后，书籍的成本下降了百倍，数量增加了万倍。抄写员并没有消失，他们变成了作家、编辑、出版商。随着识字率的普及，整个知识市场迎来了前所未有的大爆炸，催生了无数在那之前根本无法想象的职业和产业。

今天，AI 编程工具就是软件工程界的“印刷术”。编程的门槛正在被无限拉低，原本不懂代码的业务人员、设计师、财务人员（在 Anthropic 内部，非技术人员使用 Claude Code 的比例接近 100%）都能直接将想法转化为软件。这不会消灭软件工程，而是会让软件的产量和应用场景呈指数级爆发。

工程师的新生存法则：哪些技能在贬值，哪些在升值？

在这场范式转移中，作为开发者，我们需要对技能树进行重新评估。

正在快速贬值的技能：

• 对语言和框架的宗教式狂热：不要再为“到底是用 React 还是 Vue”、“这应该用 Go 还是 Rust 写”而争得面红耳赤了。如果模型觉得当前框架不好，它随时可以用几分钟时间帮你用另一个语言重写一遍。
• 沉溺于语法细节：未来将没有人再去手动敲击枯燥的样板代码。

愈发珍贵的核心能力：

• 系统化与假设驱动思维：面对复杂的 Debug 场景，如何提出假设、逐步验证，这种科学的工程思维依然是 AI 目前难以完全替代的。
• 跨界的好奇心：未来属于全栈通才。如果你懂前端、懂后端，同时还懂业务逻辑、设计心理学甚至财务模型，你就能借助 AI 工具，以“一人公司”的姿态构建出估值十亿美元的产品。
• 高频上下文切换能力 (ADHD 式的工作法)：在这个需要同时管理多个 AI 智能体的时代，不再那么强调长时间的“深度编码”，而是需要你能在多个高层上下文中快速穿梭、精准决策。

注：ADHD (注意力缺陷多动症) 式的工作法是一种灵活而高度分散注意力的工作风格，常常表现为多任务处理和非线性思维，能够快速切换多个任务并通过联想和直觉进行思考。这种方法倾向于将大的任务分解为小的、可管理的目标，以保持动力和成就感。同时，工作过程中的兴趣和关注点可能会快速变化，因此通常会采用短暂的工作间隔与休息时间。通过频繁调整和迭代的方式，ADHD式工作法能够帮助人们利用自身的优势，克服注意力集中的挑战。

小结：抛弃傲慢，拥抱变化

在采访的最后，Boris 坦言自己也经常感到挣扎：模型进化的速度太快了，几个月前验证失败的架构理念，换个新模型可能瞬间就跑通了。

在这个时代，“智力上的谦逊 (Intellectual Humility)” 比过往的经验更重要。不要再用旧时代的标尺去衡量新世界的工具。承认 AI 可能比你写得快、甚至写得好，放下作为“手写代码匠人”的骄傲，去学习如何更好地指挥这支由超级大脑组成的交响乐团吧。

毕竟，未来不属于那些拒绝使用 AI 的人，而是属于那些知道如何用 AI 构建下一个时代的人。

资料链接：https://www.youtube.com/watch?v=julbw1JuAz0

---

你敢交出“键盘”吗？

Boris 的经历让我们重新思考什么是“专业”。如果你提交的 PR 仅仅是因为“这是我手写的”而被拒绝，你的第一反应会是什么？在你的团队中，是否已经有人开始尝试这种“指挥家”式的工作流？

欢迎在评论区分享你的看法！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/03/02/modern-go-evolution-guide-1-0-to-1-26

大家好，我是Tony Bai。

Go 语言在业界最著名的标签之一就是“向后兼容承诺（Go 1 Compatibility Promise）”。一份 10 年前写下的 Go 1.4 代码，在今天的 Go 1.26 编译器下依然能完美编译并运行。

但这带来了一个副作用：许多 Go 开发者的思维和编码习惯，也停留在过去的时代。

我们依然能看到满天飞的 interface{}、冗长易错的 for 循环切片查找、为了获取指针而被迫抽离的辅助函数，以及在并发测试中繁琐的 Context 初始化。

近日，JetBrains 开源了一个名为 use-modern-go 的 AI Coding Agent Skill。这份Skill文件通过精准的 Prompt，强迫 AI 智能体在生成 Go 代码时，必须根据项目 go.mod 的版本，使用该版本支持的最现代化、最优雅的语法和标准库。

这份文件简直是一座宝库！它不仅是给 AI 看的指令，更是给每一位 Gopher 的“代码现代化”体检表。

本文将以这份资料为基础，全面盘点从 Go 1.0 一路演进到 Go 1.26 的 Modern Go 特性。我们将通过清晰的 Before / After 对比示例，带你洗礼一遍 Go 语言的现代化之美。

第一阶段：早期的代码净化（Go 1.0 – Go 1.19）

虽然是早期版本，但这些 API 的引入确立了 Go 代码“少即是多”的审美基调。

时间的优雅流逝 (time.Since / time.Until)

在计算耗时或剩余时间时，不要再手动做减法了。

❌ Before (Legacy):

start := time.Now()
// do work
elapsed := time.Now().Sub(start)

deadline := time.Now().Add(5 * time.Second)
remaining := deadline.Sub(time.Now())

✅ After (Modern – Go 1.0/1.8):

start := time.Now()
// do work
elapsed := time.Since(start)

deadline := time.Now().Add(5 * time.Second)
remaining := time.Until(deadline)

错误处理的革命 (errors.Is)

Go 1.13 引入了错误包装（Error Wrapping）。使用 == 判断错误已经不再安全。

❌ Before (Legacy):

if err == sql.ErrNoRows {
    // 无法捕获 fmt.Errorf("query failed: %w", sql.ErrNoRows) 包装后的错误
}

✅ After (Modern – Go 1.13):

if errors.Is(err, sql.ErrNoRows) {
    // 即使被多层 %w 包装，依然能准确识别
}

告别 interface{} (any)

Go 1.18 引入了泛型，同时带来了一个赏心悦目的类型别名 any。

❌ Before (Legacy):

func PrintAll(vals[]interface{}) { ... }

✅ After (Modern – Go 1.18):

func PrintAll(vals[]any) { ... }

字符串无损切割 (strings.Cut / bytes.Cut)

解析键值对是最常见的操作。过去我们需要 strings.Index 配合切片操作，极易引发 panic: slice bounds out of range。

❌ Before (Legacy):

idx := strings.Index(header, ":")
if idx != -1 {
    key := header[:idx]
    value := header[idx+1:]
}

✅ After (Modern – Go 1.18):

if key, value, found := strings.Cut(header, ":"); found {
    // 安全、直观、一次调用
}

高性能字符串追加 (fmt.Appendf)

Go 1.19 引入了直接向字节切片追加格式化字符串的能力，避免了 fmt.Sprintf 带来的隐式内存分配。

❌ Before (Legacy):

buf := []byte("Prefix: ")
buf = append(buf,[]byte(fmt.Sprintf("user_id=%d", id))...) // 发生堆分配

✅ After (Modern – Go 1.19):

buf :=[]byte("Prefix: ")
buf = fmt.Appendf(buf, "user_id=%d", id) // 零分配（如果 buf 容量充足）

类型安全的原子操作 (atomic.Bool/Int64/Pointer)

放弃 atomic.Value 和难记的 atomic.StoreInt32 吧，Go 1.19 的泛型原子类型既安全又易读。

❌ Before (Legacy):

var flag int32 // 0: false, 1: true
atomic.StoreInt32(&flag, 1)
if atomic.LoadInt32(&flag) == 1 { ... }

✅ After (Modern – Go 1.19):

var flag atomic.Bool
flag.Store(true)
if flag.Load() { ... }

var cfg atomic.Pointer[Config]
cfg.Store(&Config{})

第二阶段：标准库的泛型文艺复兴（Go 1.20 – Go 1.21）

在这个阶段，经过两个大版本打磨的 Go 泛型，彻底释放了泛型的潜力，引入了大量期待已久的内置函数和集合操作库。

明确的克隆 (strings.Clone / bytes.Clone)

当你想持有一个大字符串/字节切片的极小一部分，又不想让垃圾回收器保留整个底层大数组时，你需要 Clone。

❌ Before (Legacy):

// 丑陋的黑魔法来强制复制字符串
copiedStr := string([]byte(hugeString[:10]))

✅ After (Modern – Go 1.20):

copiedStr := strings.Clone(hugeString[:10])

溯源 Context 取消原因 (context.WithCancelCause)

Context 被取消了，但究竟是因为超时、主动取消，还是底层的网络错误？Go 1.20 让你能够携带取消原因。

❌ Before (Legacy):

ctx, cancel := context.WithCancel(parent)
// 发生错误时
cancel()
// 其他协程只知道 ctx.Err() == context.Canceled

✅ After (Modern – Go 1.20):

ctx, cancel := context.WithCancelCause(parent)
// 发生错误时
cancel(fmt.Errorf("db connection lost"))

// 消费端可以查明真凶
err := context.Cause(ctx) // 返回 "db connection lost"

(注：Go 1.21 还补充了 context.WithTimeoutCause)

内置的魔法：min, max, clear

这是 Go 1.21 最受欢迎的内置函数。

❌ Before (Legacy):

// 求最大值（非浮点数只能自己写 if/else）
m := a
if b > m { m = b }

// 清空 Map
for k := range myMap { delete(myMap, k) }

✅ After (Modern – Go 1.21):

m := max(a, b) // 支持所有可比较类型
clear(myMap)   // 高效清空 map，保留底层容量

强大的 slices 和 maps 库

告别手动写 for 循环查找元素的日子。

❌ Before (Legacy):

func contains(list[]string, target string) bool {
    for _, v := range list {
        if v == target { return true }
    }
    return false
}

✅ After (Modern – Go 1.21):

import "slices"
import "maps"

// 查找
found := slices.Contains(items, target)
idx := slices.IndexFunc(users, func(u User) bool { return u.ID == 42 })

// 排序 (原 sort.Slice 需要写繁琐的 Less 函数)
slices.Sort(ints)
slices.SortFunc(users, func(a, b User) int { return cmp.Compare(a.Age, b.Age) })

// 紧凑与裁剪
items = slices.Compact(items) // 移除连续重复元素
items = slices.Clip(items)    // 移除切片多余的 capacity

// 字典操作
clonedMap := maps.Clone(originalMap)
maps.DeleteFunc(m, func(k string, v int) bool { return v < 0 })

更聪明的单次执行 (sync.OnceFunc / OnceValue)

sync.Once 很好用，但如果我们想只初始化一次并返回一个值，过去需要闭包外变量和额外的锁。

❌ Before (Legacy):

var once sync.Once
var config *Config
func GetConfig() *Config {
    once.Do(func() { config = loadConfig() })
    return config
}

✅ After (Modern – Go 1.21):

// 声明即完成包装，线程安全且优雅
var GetConfig = sync.OnceValue(func() *Config {
    return loadConfig()
})

// 使用
cfg := GetConfig()

第三阶段：语法细节与 Web 路由的飞跃（Go 1.22）

整数范围循环 (for i := range n)

❌ Before: for i := 0; i < 10; i++ { … }
✅ After: for i := range 10 { … }

默认值救星 (cmp.Or)

返回第一个非零值，简直是读取环境变量的神器。

❌ Before (Legacy):

port := os.Getenv("PORT")
if port == "" {
    port = "8080"
}

✅ After (Modern – Go 1.22):

port := cmp.Or(os.Getenv("PORT"), "8080")

史诗级加强的 http.ServeMux

标准库路由器终于支持 HTTP 方法和路径参数了，很多小项目再也不需要引入 gin 或 chi。

✅ Modern Go 1.22:

mux := http.NewServeMux()
mux.HandleFunc("POST /api/users/{id}", func(w http.ResponseWriter, r *http.Request) {
    userID := r.PathValue("id")
    // ...
})

第四阶段：迭代器时代的黎明（Go 1.23 – Go 1.24）

Go 1.23 引入了 iter.Seq（迭代器），这是自泛型以来最大的范式转变。它统一了所有“序列”的遍历方式。

迭代器与切片/字典的梦幻联动

提取 map 的所有 key 并排序，过去需要手动 append 加 sort。

✅ Modern Go 1.23:

// 获取字典的 keys 迭代器 -> 收集为切片 -> 返回新切片
keys := slices.Collect(maps.Keys(m))

// 收集并一步排序
sortedKeys := slices.Sorted(maps.Keys(m))

测试和基准测试的现代化 (t.Context(), b.Loop())

Go 1.24 对 testing 库进行了大规模重构，代码更加精简防错。

❌ Before (Legacy Testing):

func TestFoo(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    doSomething(ctx)
}

func BenchmarkBar(b *testing.B) {
    for i := 0; i < b.N; i++ {
        doWork() // 编译器可能会过度优化这里的代码
    }
}

✅ After (Modern Go 1.24):

func TestFoo(t *testing.T) {
    // 自动随测试结束而取消的 Context
    ctx := t.Context()
    doSomething(ctx)
}

func BenchmarkBar(b *testing.B) {
    // 防止编译器优化掉内部逻辑的全新循环方式
    for b.Loop() {
        doWork()
    }
}

JSON 标签终极补丁 (omitzero)

长久以来，JSON 的 omitempty 标签对 time.Time 和嵌套 struct 这种“非空即零”的类型无效（因为它们永远不是 nil）。Go 1.24 终于引入了 omitzero。

✅ Modern Go 1.24:

type User struct {
    // 以前：即使时间是 0001-01-01 也会被序列化输出
    // 现在：只要是零值，就忽略
    CreatedAt time.Time json:"created_at,omitzero"
}

零分配迭代分割 (strings.SplitSeq)

当你只需要遍历分割后的字符串，而不需要将其存入切片时，迭代器能帮你省下所有内存分配。

• ❌ Before (Allocates memory): for _, part := range strings.Split(s, “,”) { … }
• ✅ After (Zero allocation): for part := range strings.SplitSeq(s, “,”) { … }

第五阶段：属于现在的未来（Go 1.25 – Go 1.26）

让我们来看看最近两个发布版本实装的黑科技。

拯救 WaitGroup (wg.Go())

Go 1.25 消除了并发控制中最常见的 Bug：忘记写 wg.Add(1) 或者忘记 defer wg.Done()。

❌ Before (Legacy):

var wg sync.WaitGroup
for _, item := range items {
    wg.Add(1)
    go func(i Item) {
        defer wg.Done()
        process(i)
    }(item)
}
wg.Wait()

✅ After (Modern Go 1.25):

var wg sync.WaitGroup
for _, item := range items {
    // 自动处理 Add(1) 和内部的 Done()，连闭包变量捕获问题都不用再担心
    wg.Go(func() {
        process(item)
    })
}
wg.Wait()

指针获取的终极解法 (new(expr))

在 Go 1.26 中，为了给结构体的指针字段（常见于 Protobuf/JSON 生成的代码）赋值，你再也不需要写恶心的辅助函数了。new() 终于支持了表达式。

❌ Before (Legacy):

timeout := 30
debug := true
cfg := Config{
    Timeout: &timeout, // 必须先单独声明变量
    Debug:   &debug,
}

✅ After (Modern Go 1.26):

cfg := Config{
    Timeout: new(30),   // 推断为 *int
    Debug:   new(true), // 推断为 *bool
    Role:    new("admin"), // *string
}

警告：请直接写 new(30)，千万不要写 new(int(30)) 这种脱裤子放屁的类型转换，编译器足够聪明。

泛型安全类型断言 (errors.AsType)

处理自定义错误时，errors.As 极易用错，因为它需要传入一个指针的指针，如果传入非指针会在运行时直接 Panic。Go 1.26 用泛型完美解决了它。

❌ Before (Unsafe):

var pathErr *os.PathError
// 极易漏写 & 导致 panic
if errors.As(err, &pathErr) {
    handle(pathErr)
}

✅ After (Modern Go 1.26):

// 编译期类型安全，返回具体的实例
if pathErr, ok := errors.AsType[*os.PathError](err); ok {
    handle(pathErr)
}

小结：让 AI 成为代码现代化的推手

回顾这从 Go 1.0 到 1.26 的演进史，我们看到了一条清晰的脉络：Go 官方正在极力消除样板代码（Boilerplate），同时坚定地维持着语言的简单与直白。

JetBrains 开源的这个 use-modern-go Skill 给了我们一个绝佳的启示：在 AI 编程时代，不要让大模型去学习网上那些陈旧的、十年前的 StackOverflow 答案。 通过系统性的 Prompt 引导，我们可以强迫 AI 写出最符合当前语言版本的、最高效的 Modern Code。

作为 Gopher，是时候给你的脑海中的“Go 语言编译器”升个级了。下一次敲下代码时，问问自己：“这是 2015 年的写法，还是 2026 年的写法？”

---

你的代码里还有“老古董”吗？

哪怕 Go 1.26 已经发布，很多人的 go.mod 依然停留在 1.16 甚至更早。在这些 Modern 特性中，哪一个最让你感到“相见恨晚”？你在重构老代码时，遇到过哪些由于“兼容性思维”导致的阻碍？

欢迎在评论区分享你的 Modern Go 实践！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/25/gas-town-multi-agent-orchestration-ai-programming-revolution

大家好，我是Tony Bai。

“启示录”（Apocalypse）在希腊语原意中并非仅指毁灭，更意味着“揭开面纱”。

2026 年的钟声敲响时，软件开发领域正经历着这样一场启示录。旧世界——那个由 IDE、手动键入代码、人类结对编程构成的世界——正在崩塌。我们拥有了前所未有的强大模型（Claude Sonnet/Opus 4.5、GPT-5、Gemini 3.0 Pro等），但当开发者试图用它们构建庞大的企业级系统时，却陷入了另一种混乱：我们被淹没在无数的 Prompt 中，我们在复制粘贴中迷失，我们变成了 AI 的保姆。

前 Amazon/Google 资深工程师、传奇技术博主 Steve Yegge 在其 57 岁生日之际，用一款名为 Gas Town 的工具，揭开了新世界的面纱。

他指出，行业的方向错了。我们一直在试图制造一只能够解决所有问题的“超级蚂蚁”（Super-Ant）。但纵观生物学与人类工业史，解决复杂规模化问题的从来不是一个个体，而是分工明确、协同工作的群体。

Gas Town 的发布，标志着 AI 编程正式从 “单点辅助” (Level 6) 迈向 “集群编排” (Level 。在这个新世界里，IDE 变成了过时的手工作坊，而 Gas Town 则是一座由 Go 语言 构建的、轰鸣作响的 AI 软件工厂。

本文将带大家走进这片废土，见证多智能体编排如何开启这场工业革命。

软件开发的范式转移

开发者进化的终局

Steve Yegge 在其著名的《Revenge of the Junior Developer》中曾预言，AI 将赋予初级开发者对抗资深专家的能力。但他现在的观点更进一步：人类开发者必须进化为“编排者”（Orchestrator）。

为了厘清从“手工作坊”到“工业化生产”的演变路径，他在《Welcome to Gas Town》一文中，提出了一套精准的开发者 AI 进化等级论。首先，你需要在表格中找到自己的位置：

• Stage 1: 零 AI 或近乎零 AI (Zero or Near-Zero AI)
  处于这一阶段的开发者，也许只使用基础的代码补全功能，偶尔向 Chat 问几个问题，工作流基本维持传统原貌。
• Stage 2: IDE 中的编码智能体（权限开启）
  你开始使用 IDE 侧边栏里那个窄窄的编码 Agent。但你很谨慎，开启了所有权限拦截，Agent 每次运行工具或修改文件，都需要征求你的许可。
• Stage 3: IDE 中的智能体（YOLO 模式）
  信任度建立。你关闭了烦人的权限询问，进入 YOLO (You Only Look Once) 模式。Agent 的权限变大，操作变得丝滑流畅。
• Stage 4: IDE 中的宽屏智能体 (Wide Agent)
  Agent 逐渐反客为主，占据了屏幕的核心位置。源代码退居幕后，你不再逐行编写，而是在审阅 Agent 生成的 Diffs（差异）。
• Stage 5: CLI 单体智能体 (CLI, single agent)
  你离开了 IDE，进入终端（CLI）。Diff 信息在屏幕上飞速滚动，你可能扫一眼，也可能根本不看，直接让它提交。
• Stage 6: CLI 多智能体 (CLI, multi-agent)
  这是目前大多数高阶玩家的水平。 你经常在终端里并行运行 3 到 5 个 Claude Code 实例。你的编码速度非常快，远超常人。
• Stage 7: 10+ 智能体（人工管理）
  你试图同时操作 10 个以上的 Agent，但你开始触碰到“人肉管理”的极限。窗口切换、上下文同步让你手忙脚乱，效率反而开始下降。
• Stage 8: 构建你自己的编排器 (Building your own orchestrator)
  这就是 Gas Town 所在的领域，也是进化的终局。你站在了技术的最前沿，开始自动化整个工作流。你不再操作 Agent，你编排它们。

Gas Town 就是 Stage 8 的产物。当你有 30 个 Agent 同时工作时，你不再写代码，你是在管理产能。

开发者AI进化的8个阶段

为什么是“工厂”？

Gas Town 的核心隐喻是“工厂”。

在传统 IDE 模式下，AI 是你的结对编程伙伴（Partner）。这听起来很温馨，但不可扩展。你不能和 50 个人同时结对编程。

在 Gas Town 模式下，AI 是工人（Worker）。

• 可替换性： 工人是“耗材”。一个 Agent 跑偏了、卡住了、上下文满了，直接销毁，启动一个新的接手。
• 专业分工： 有的负责写代码，有的负责 Review，有的负责合并，有的负责打扫卫生。
• 流水线： 任务在不同的 Agent 之间流转，而不是堆积在一个人身上。

解构 Gas Town —— 欢迎来到废土

Gas Town 的命名致敬了《疯狂的麦克斯》（Mad Max），暗示了 AI 编程早期的混乱与狂野。但在这层废土朋克的外衣下，是一套严密的分布式系统架构。

基础设施：Town 与 Rig

Gas Town 采用了一种类似 Kubernetes 的层级架构：

• Town (工作区)： 对应 Kubernetes 的 Cluster。这是你的根目录（如 ~/gt），也是 gt 命令行工具管理的边界。
• Rig (钻井/项目)： 对应 Kubernetes 的 Node/Namespace。Town 下的每一个 Git 仓库就是一个 Rig。Gas Town 天生支持 Monorepo 或 多仓库并行开发。你可以命令 AI：“在前端 Rig 加个按钮，同时在后端 Rig 写好 API。”

角色体系 (The Roles)：智能体社会学

Gas Town 不使用通用的 AI，而是将 LLM 封装为特定的角色 (Persona)。每个角色都有独立的 System Prompt、上下文记忆和权限边界。

1. The Mayor (市长/经理)

• 职责： 指挥官与交互入口。
• 工作流： 用户通过 tmux 窗口向 Mayor 下达模糊指令（例如：“把登录页面的 CSS 丑陋问题修一下”）。Mayor 不会自己去修，它会分析需求，创建任务单（Beads），然后呼叫工人。

2. The Crew (船员/核心团队)

• 职责： 你的贴身设计团队与长期雇佣兵。
• 特性： Long-lived (长寿的) 与 Named (有名字的)。
• 差异： 与一次性的 Polecats 不同，Crew 是你项目中的固定成员（你可以给它们起名，如 ‘Jack’, ‘Gus’, ‘Max’）。它们拥有持久的身份，直接向你汇报，不归 Witness 管辖。
• 用途： 它们是 Gas Town 里的“高级脑力工作者”。你通常用它们来进行复杂的架构设计、深入的代码审查，或者生成给 Polecat 做的“燃料”（Guzzoline，即详细的任务清单）。你可以在 tmux 中快速循环切换不同的 Crew 成员，像检阅精英部队一样给它们派活，甚至可以指定其中一个为“PR Sheriff”（PR 警长）来专门管理代码合并。

3. Polecats (臭鼬/一次性工人)

• 职责： 真正的执行者，耗材。
• 特性： Ephemeral (短命的)。Polecats 是 Gas Town 的消耗品。它们是无状态的、用完即弃的。
• 蜂群战术 (Swarming)： 这是 Gas Town 最恐怖的能力。你可以瞬间启动 20 只 Polecats，并行处理积压的 20 个 Bug。它们各自拉分支、写代码、跑测试、提 PR，然后自我销毁。

4. The Refinery (炼油厂/合并专员)

• 职责： 解决 Merge Hell (合并地狱)。
• 痛点： 当 20 只 Polecats 同时提交代码时，Git 冲突是必然的。
• 机制： Refinery 维护一个合并队列 (Merge Queue)。它像一个冷静的守门员，依次将 PR Rebase 到主干，运行集成测试，解决冲突，合并代码。如果没有 Refinery，大规模的 AI 编程将不可持续。

5. The Witness (见证人/修复者)

• 职责： 监控与运维。
• 痛点： AI 经常会“发呆”（卡在等待输入界面）或陷入死循环。
• 机制： Witness 像一个巡逻的监工，它不写代码，只盯着 Polecats 的状态。如果发现某个 Worker 长时间没反应，Witness 会执行 gt nudge（推一下）或重启该 Worker。

6. The Deacon (执事) & Dogs (猎犬)

• 职责： 系统守护进程。
• 机制： Deacon 运行在一个死循环中，维护系统的“心跳”。为了防止 Deacon 自己被繁重的杂务阻塞，它配备了一组名为 Dogs 的子 Agent，专门处理日志清理、状态同步等脏活。

核心机制：GUPP 与 NDI

Gas Town 的运行依赖两大理论基石：

GUPP (Gas Town Universal Propulsion Principle)

定义： “如果钩子（Hook）上有工作，Agent 必须运行它。”

LLM 通常被训练得非常礼貌，倾向于等待用户指令。Gas Town 必须打破这种“礼貌”。系统通过底层的事件循环，不断向 Agent 发送信号，强制驱动它们读取任务队列。

NDI (Nondeterministic Idempotence)

定义： 非确定性幂等性。

在 Temporal 等传统编排系统中，工作流要求是确定性的。但在 AI 领域，同样的 Prompt 每次生成的代码都不同。

Gas Town 接受这种混沌。它不要求过程一致，只要求结果收敛。

• Agent 崩溃了？没关系，新的 Agent 启动，读取 Git 中的状态（Checkpoint），继续干。
• 代码写错了？没关系，测试挂了会触发新的 Loop，直到测试通过。

这就是 AI 时代的“最终一致性”。

技术核爆 —— MEOW 栈与 Beads 数据面

Gas Town 能够运转，不仅仅是因为 Prompt 写得好，更因为它底层有一套极具颠覆性的数据存储技术。这也是为什么它必须用 Go 重写的原因。

Beads：Git-Backed Graph Database

Steve Yegge 曾尝试用 SQLite 甚至文本文件来存储 Agent 记忆，但最终发明了 Beads。

Beads 是什么？

它是一个分布式任务追踪系统，但它将 Issue（任务） 视为 Code（代码）。

• 存储： 每一个 Bead（任务单）是一个 JSONL 文件，直接存储在项目的 .beads/ 目录下。
• 版本控制： 任务与代码同构。当你切换 Git 分支时，你的任务列表也会自动切换到该分支的状态。这对于 AI 理解“当前分支要干什么”至关重要。
• 无冲突哈希： 为了支持分布式协作，Beads 不使用自增 ID（如 Issue #1），而是使用类似 Git 的哈希 ID（如 bd-a1b2），彻底解决了多 Agent 并发创建任务时的冲突问题。

MEOW 栈：分子级工作流

基于 Beads，Gas Town 构建了 MEOW (Molecular Expression of Work) 技术栈。

• Atom (原子)： 单个任务 Bead。
• Molecule (分子)： 可编程的工作流。它是一个由 Beads 链接而成的有向无环图（DAG）。
  • 例如：设计分子 -> 实现分子 -> Review 分子 -> CI 分子。
• Wisp (游丝)： 运行时的临时分子。它们在内存中流转，执行完即焚毁，不污染 Git 历史。

这套机制让 Gas Town 能够定义复杂的“软件生产配方”。你可以编写一个 Formula（配方），定义“如何修复一个 Bug”，然后让 100 个 Agent 同时执行这个配方。

为什么是 Go？(The “Boring” Advantage)

Steve Yegge 之前尝试过 TypeScript 和 Python，但最终 Gas Town (v4) 选择了 Go。这并非巧合，而是 AI 基础设施演进的必然。

1. AI 生成代码的“质量悖论”：

   • TypeScript: 类型系统过于复杂。LLM 经常为了满足类型检查而生成大量无用的样板代码，浪费 Token 且容易产生幻觉。
   • Python: 动态类型导致运行时错误频发，且作为分发给用户的 CLI 工具，环境依赖管理是个噩梦。
   • Go: Go 的“无聊”是 AI 的福音。 Go 的语法简单、正交、缺乏花哨的语法糖。AI 生成的 Go 代码逻辑扁平（if err != nil），易于静态分析，且编译速度极快。在 Vibe Coding 的循环中，秒级编译意味着 Agent 可以更快地试错。

2. 并发原语：
   Gas Town 本质上是一个高并发的编排系统。它需要同时管理数十个 tmux 会话、监控数十个 Agent 进程、处理并行的 Beads 数据读写。Go 的 Goroutines 和 Channels 让这种复杂的并发模型变得可控且高效。

3. 云原生基因：
   Gas Town 的目标是成为 AI 时代的 Kubernetes。使用与 K8s、Docker、Terraform 相同的语言，意味着它可以无缝融入现有的云原生生态。

实战指南 —— Vibe Coding 与贝佐斯模式

Vibe Coding：氛围编程

在 Gas Town 中，编程不再是打字，而是一种“氛围编程” (Vibe Coding)。

• 你不再关注变量命名，你关注意图。
• 你不再关注函数实现，你关注验收标准。
• 实战场景示例：
  你告诉 Mayor：“给 Beads 项目加个功能，支持导出 CSV。”
  Mayor 创建 Beads，Witness 唤醒 Polecat。
  Polecat 1 写代码，Polecat 2 写测试。
  你不需要看中间过程。5 分钟后，Refinery 通知你：“PR 已准备好，测试通过，请验收。”
  你扫一眼 Diff，回复：“LGTM。”
  代码合并，任务结束。

贝佐斯模式 (Bezos Mode)

这种高效带来的副作用是 “决策疲劳”。

Steve 称之为 Bezos Mode。就像杰夫·贝佐斯一样，你不再做执行层的工作，你整天都在做高维度的决策：架构评审、产品方向判断、风险评估。
这种高密度的决策会迅速耗尽大脑的“缓冲区”。Steve 及其团队发现，使用 Gas Town 后，他们每天下午必须强制午睡（Nap Strike），否则大脑会罢工。

这预示着未来开发者的核心竞争力，将从“编码速度”转变为“决策质量”。

终局 —— 工业化未来

编排器的战国时代

目前，Claude Code 只是“工人”，Loom 和 Ralph Wiggum 试图成为“包工头”，而 Gas Town 是唯一的“工厂”。

Gas Town 不关注单个 Agent 有多强，它关注的是账本 (Ledger)、审计 (Audit Trail) 和 流水线 (Pipeline)。这才是企业级软件开发的刚需。

大公司的黄昏

Steve Yegge 做出了一个激进的预测：“一人一库” (One Engineer per Repo)。

随着 Gas Town 类工具的普及，一个装备了 AI 军团的 3 人精英小组，其产出将吊打 100 人的传统开发部门。大公司内部繁琐的沟通成本，在 AI 的光速执行面前，将成为无法忍受的累赘。

未来的独角兽，可能只有 3 名员工，但拥有 3000 个并发运行的 Agent。

对于开发者而言，现在是时候放下 IDE，学习 Beads，去尝试驾驭那个疯狂、混乱但充满无限可能的 Gas Town 了。

小结：新世界的入场券

截至本文编写时，Gas Town 目前仍处于 v0.5.0 的早期阶段，它昂贵（消耗大量 Token）、危险（可能搞乱代码）、粗糙（基于 tmux）。但它代表了不可逆转的未来。

Gas Town 的出现，就是软件工程领域的“蒸汽机时刻”。它无情地宣告了手工作坊（IDE）时代的终结，并开启了工业化大生产（编排器）的序幕。

Go 语言凭借其稳健、高效和并发优势，再次赢得了这场 AI 基础设施战争的入场券。

“启示录”已经降临。旧世界的围墙正在倒塌，而 Gas Town 的大门已经打开。

因为正如 Steve 所说：“你是想继续做一只忙碌的蚂蚁，还是想成为那只在竹林里指挥若定的熊猫？”

Welcome to Gas Town.

The factory is open.

参考资料

• https://github.com/steveyegge/gastown
• https://github.com/steveyegge/beads
• Welcome to Gas Town – https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04
• Gas Town Decoded – https://www.alilleybrinker.com/mini/gas-town-decoded/
• Beads best practices – https://steve-yegge.medium.com/beads-best-practices-2db636b9760c
• The Future of Coding Agents – https://steve-yegge.medium.com/the-future-of-coding-agents-e9451a84207c
• Gas Town Emergency User Manual – https://steve-yegge.medium.com/gas-town-emergency-user-manual-cf0e4556d74b
• Stevey’s Birthday Blog – https://steve-yegge.medium.com/steveys-birthday-blog-34f437139cb5

---

你的“进化”阶段

Gas Town 描绘的未来令人心潮澎湃，也让人心生敬畏。对照文中的“8个进化阶段”，你目前处于哪一级？你准备好迎接“一人一库”的时代，还是更享受传统的结对编程？

欢迎在评论区晒出你的“等级”，或者分享你对多智能体协作的看法！让我们一起在废土中寻找新世界的坐标。

如果这篇文章点燃了你对 AI 编程的全新想象，别忘了点个【赞】和【在看】，并转发给你的极客朋友，邀请他们一起加入 Gas Town！

---

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/21/ai-coding-evolution-from-prompting-to-ralph

大家好，我是Tony Bai。

“如果你把 AI 放在一个死循环里，给它足够的权限和上下文，会发生什么？”

2025 年底，一个名为 “Ralph Wiggum Technique” (Ralph 循环) 的 AI 编程技巧在硅谷极客圈一夜爆红。它没有复杂的架构，没有花哨的界面，其核心代码甚至只有一行 Bash 脚本。

但就是这个看似简陋、甚至有些“诅咒”意味的技巧，却让开发者们在一夜之间重构了 6 个代码库，构建了全新的编程语言，甚至引发了 Anthropic 官方下场发布插件。

什么是 Ralph？为什么它如此有效？它又预示着怎样的 AI 编程未来？

Ralph 的诞生——一行代码的暴力美学

Ralph 的故事始于 Geoff Huntley 的一个疯狂实验。他没有使用复杂的 Agent 框架，而是写下了这样一行 Bash 脚本：

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

这就是 Ralph 的全部。

• PROMPT.md：这是唯一的输入，包含了项目的目标、规范、当前状态的描述（通常由 AI 自动更新）。
• @sourcegraph/amp：这是一个极其简单的 CLI 工具，它读取提示词，调用 LLM，并在当前目录下执行命令（修改文件、运行测试等）。
• while :; do … done：这就是灵魂所在。无限循环。

Ralph 不会停下来问你“这样行吗？”。它只是不断地读取目标、执行操作、再次读取目标、再次执行……直到你手动杀掉进程，或者它把代码库变成一团乱麻（所谓的“Overbaking”）。

为什么 Ralph 有效？—— Context Engineering 的胜利

乍一看，Ralph 似乎只是一个不可控的随机代码生成器。但实际上，它的成功揭示了 AI 编程的一个核心真理：上下文工程 (Context Engineering) 远比 Prompt 技巧更重要。

Ralph 的核心不在于那个 Bash 循环，而在于那个 PROMPT.md（或者更高级的“Specs”）。

声明式而非命令式

传统的 AI 辅助编程是“命令式”的：你告诉 AI “修改这个函数”、“修复那个 Bug”。

Ralph 是“声明式”的：你在 PROMPT.md 中描述项目的终局状态（Desired State），比如“所有的 React 组件必须使用 TypeScript 且没有 default exports”。Ralph 的工作就是不断逼近这个状态。

小切口，高频迭代

Ralph 并不试图一次性完成所有工作。它在每次循环中只处理一小块任务。这种“切碎”的工作方式，完美契合了 LLM 当前的上下文窗口限制，避免了“一次性生成几千行代码然后全错”的灾难。

自动化反馈循环

在 Ralph 的循环中，测试结果、Linter 报错、编译失败信息，都会成为下一个循环的输入。它不仅是在写代码，更是在自我修复。

Ralph 的进化——从玩具到生产力

随着社区的介入，Ralph 迅速从一个 Bash 玩具进化为一种严肃的开发范式。

• 重构利器：这是一次真实的重构经历。面对一个混乱的 React 前端，没有人工介入手动修改，而是花 30 分钟写了一份 REACT_CODING_STANDARDS.md（编码规范），然后让 Ralph 跑了 6 个小时。结果？Ralph 自主完成了一个人类可能需要数天才能完成的枯燥重构。
• Cursed Lang：Geoff 甚至用 Ralph 构建了一门全新的编程语言 Cursed Lang，包含编译器、标准库，且实现了自举。
• 官方下场：Anthropic 甚至推出了官方的 Ralph 插件。虽然被社区吐槽“过度设计”且不如 Bash 脚本好用，但这标志着这种模式已被主流认可。

警惕“Overbaking”——AI 也会“把菜烧焦”

Ralph 并非完美。它最大的风险在于 “Overbaking”（过度烘焙）。

如果你让 Ralph 跑得太久，且 PROMPT.md 的约束不够紧，它可能会开始产生“幻觉”般的优化：添加没人需要的 Post-Quantum 密码学支持、过度拆分文件、甚至为了通过测试而删除测试。

这给我们的启示是：AI 是强大的引擎，但人类必须是方向盘。

• 写好 Spec：如果你的 Spec（规格说明书）是垃圾，Ralph 产出的代码也是垃圾。
• 监控循环：不要让它无限制地跑下去，设置检查点。
• 小步快跑：最好的 Ralph 实践是“一夜重构一个模块”，而不是“一夜重构整个系统”。

小结：Agentic Coder 的未来

Ralph Wiggum Technique 可能只是 AI 编程进化史上的一朵浪花，但它留下的遗产是深远的。

它告诉我们，未来的编程可能不再是编写具体的逻辑，而是编写和维护一份完美的 Spec（规范说明书）。我们将成为“系统架构师”和“验收测试员”，而将那个枯燥、重复、且容易出错的“编码循环”，交给不知疲倦的 Ralph 们。

所以，下一次当你面对一座巨大的“屎山”代码时，不妨试着写一份清晰的 Spec，然后启动那个神奇的 Bash 循环。

资料链接：

• https://ghuntley.com/ralph/
• https://www.humanlayer.dev/blog/brief-history-of-ralph

---

从“暴力循环”到“优雅指挥”

Ralph Wiggum 的故事让我们看到了 AI 自主编程的雏形：只要有正确的 Spec（规范）和自动化的 Loop（循环），奇迹就会发生。

但 Ralph 毕竟只是一个 5 行代码的 Bash 脚本，粗糙且容易“烤糊”。在真实的工程实践中，我们不能只靠运气的“无限循环”，我们需要一套更稳定、更可控、更专业的AI 原生开发体系。

如果你不想止步于 Ralph 这样的极客实验，而是想真正掌握驾驭 AI Agent 的系统方法，欢迎加入我的新专栏 《AI原生开发工作流实战》。

这是关于如何构建你的“自动化流水线”：

• 告别低效：不再做“复制粘贴喂 AI”的搬运工，建立自动化闭环。
• 驾驭神器：深度实战 Claude Code 等前沿工具，它是比 Ralph 更成熟的“神灯精灵”。
• 身份跃迁：从被动的“AI 使用者”，进化为定义规范、掌控全局的“工作流指挥家”。

扫描下方二维码，别让 AI 只有暴力，让我们赋予它工程的优雅。

---

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

---

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

© 2026, bigwhite. 版权所有.