本文永久链接 – 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

本文永久链接 – 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技能再上一个新台阶！

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