Python - Tony Bai

本文永久链接 – https://tonybai.com/2025/08/03/choose-boring-technology

大家好，我是Tony Bai。

大约十年前，Dan McKinley 的一篇经典雄文《选择无聊的技术》（Choose Boring Technology）在工程师圈子里广为流传。它的核心观点简单而深刻：一家公司的“创新代币”（innovation tokens）是有限的，应该用在刀刃上，而不是随意挥霍在那些闪亮但未经证实的新技术上。

“无聊”的技术，比如 Postgres、Python、PHP，它们的优势不在于新潮，而在于其故障模式和能力边界是众所周知的。当系统在凌晨三点崩溃时，你需要的是一个有大量 Stack Overflow 答案可以求助的领域，而不是一片你必须独自开拓的未知“无人区”。

这个原则，在过去十年里，成为了无数资深工程师的技术选型座右铭。然而，十年后的今天，随着 LLMs 和 Agentic AI 编程工具的崛起，业界仍然认为：这个原则不仅没有过时，反而比以往任何时候都更加重要，甚至更加致命。

AI 时代的“诱惑”与“危险”

AI 编程助手带来了一个全新的变数。这个变数既有趣，又极其危险。

这里的“有趣”在于，现代 AI 工具（无论是 Claude 还是 Copilot）已经非常擅长为几乎任何你能想到的技术栈，生成“看起来非常专业”的代码。你给它一个 prompt，让它用最新的 JavaScript 框架、GraphQL federation 和 Kubernetes 来实现一套微服务，它会迅速给你返回一堆代码——这些代码可能遵循了所有社区惯例，命名规范无可挑剔，错误处理看起来也像模像样，甚至，它可能真的能运行。

这就是 AI 的“诱惑”。它让你感觉，掌握任何新技术都不过是弹指一挥间的事。

而“危险”也恰恰源于此。当你在一个你不熟悉的技术领域里使用 AI 时，一个致命的问题出现了：

你根本无法验证，AI 是不是在“一本正经地胡说八道”（bullshitting you）。

我亲眼见过，有工程师接受了 AI 生成的代码，而这些代码里：

使用了早已废弃的 API。
实现了严重的安全反模式。
制造了只有在生产负载下才会暴露的、极其隐蔽的性能问题。

为什么会这样？因为这些代码“看起来是对的”。但它的错误，是深植于技术细节中的，只有真正熟悉这门技术的人才能一眼看穿。

风险的“乘法效应”

过去，我们说选择一门新技术是增加了一个“未知数”。而在 AI 时代，当你将不熟悉的技术与 AI 生成的代码结合时，你不再是简单地增加未知数，而是在乘以未知数。

你不知道这个框架是否是解决你问题的最佳选择；你不知道 AI 的实现是否遵循了最佳实践；你不知道生成的代码中，哪些是无伤大雅的模板，哪些是核心业务逻辑；你更不知道，这套组合拳将会以何种奇特的方式在未来失效。

这已经不是简单的“货物崇拜”（cargo-culting）了，这是指数级的货物崇拜。

注：“货物崇拜”（cargo culting）是一个源自太平洋岛屿的概念，最早用于描述一些岛屿居民对西方物资和技术的崇拜现象。在二战期间，许多西方士兵在这些岛屿上驻扎，带来了大量的物资和现代技术。当地人对这些物品产生了强烈的向往，认为这些物品是神灵的恩赐。

AI 时代的“技术选型第一性原理”

那么，我们该怎么办？答案出奇地简单，它让我们回归到了那个最朴素的原则：

AI 是你所理解技术的“力量倍增器”，却是你不理解技术的“脆弱拐杖”。

当你选择“无聊”的技术，也就是你真正精通的技术时，AI 会变得无比强大。你可以让 Claude 帮你生成 Rails 代码，因为你对 Rails 了如指掌，能轻易发现它何时提出了可疑的建议。你可以让 Copilot 辅助你写 JavaScript，因为你理解这门语言的怪癖，能对它的产出进行事实核查。

在这种模式下，AI 是你的副驾驶，为你处理繁琐的路线，而你始终掌握着方向盘。

给 AI 时代开发者的实践指南

那么，在一个充满 AI 编程助手的世界里，我们该如何应用“选择无聊的技术”这一原则呢？这里有三条黄金法则：

评估新技术时先自问：“如果 AI 为它生成了代码，我有能力审查吗？” 如果答案是否定的，那么这项技术或许不应该用于任何对你而言是任务关键型（mission-critical）的项目。
学习新技术时（当你决定用掉一个“创新代币”时）： 请务必花时间深入理解它，达到能对 AI 的建议进行独立事实核查的程度。不要只是复制、粘贴，然后祈祷好运。
抵制诱惑： 不要把 AI 工具当作一个借口，让你能同时拥抱一门新语言、一个新框架和一套新基础设施。AI 可能会给你一种“我能搞定一切”的错觉，但你无法真正验证其中任何一环。

小结：理解，是前所未有的宝贵资产

“选择无聊的技术”这个论点的初衷，是为了降低系统的运维复杂性和团队的认知开销。在 AI 时代，这些理由依然成立，但我们又增加了一个更重大的风险：对抗由 AI 带来的、致命的虚假自信。

如今的风险更高了，因为 AI 生成的代码质量越来越好，使得发现问题变得更加困难。过去，坏代码通常看起来就很糟糕。现在，有问题的代码可能看起来相当不错，直到你对该领域足够了解，才能注意到那些微妙的致命伤。

所以，我的建议始终不变：当你要解决一个问题时，请使用你已经了解的技术。当你想要学习新东西时，那就专心去学习。不要将 AI 生成的代码，误认为是真正的理解。

在一个 AI 可以自信地为你从未用过的技术生成数千行代码的世界里，你自己的、深刻的理解，比以往任何时候都更有价值。

资料链接：

https://mcfunley.com/choose-boring-technology
https://www.brethorsting.com/blog/2025/07/choose-boring-technology,-revisited

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/07/19/go-understand-the-zen-of-python-better-than-python

大家好，我是Tony Bai。

最近，在国外的 Go 语言社区（Reddit r/golang）上，一个帖子引发了热烈的讨论。标题颇具“引战”意味：“Go似乎比Python更好地实现了Python之禅”。

这听起来像个悖论，甚至有点冒犯。用一个语言的哲学去评判另一个语言，就像用“太极”的理念去评价“咏春”，似乎风马牛不相及。但仔细看完社区的讨论，你会发现这并非无稽之谈，反而是一个极其刁钻又深刻的视角，能帮助我们重新审视 Go 语言设计的底层逻辑。

作为一名在 Go 的世界里摸爬滚打了多年的老 Gopher，我也不止一次有过类似的感觉。今天，我们就借着这场社区热议，一起聊聊这个有趣的话题。

重温“Python之禅”

首先，让我们重温一下那首著名的“Python之禅”（The Zen of Python）。在任何一个 Python 解释器里输入 import this，你都能看到它：

The Zen of Python, by Tim Peters
Python之禅，作者：蒂姆·彼得斯

Beautiful is better than ugly.
优美优于丑陋。

Explicit is better than implicit.
显式优于隐式。

Simple is better than complex.
简单优于复杂。

Complex is better than complicated.
复杂优于繁杂。

Flat is better than nested.
扁平优于嵌套。

Sparse is better than dense.
稀疏优于密集。

Readability counts.
可读性至关重要。

Special cases aren't special enough to break the rules.
特例不足以特殊到足以打破规则。

Although practicality beats purity.
虽然实用性胜过纯粹性。

Errors should never pass silently.
错误绝不能悄无声息地被忽略。

Unless explicitly silenced.
除非显式地使其沉默。

In the face of ambiguity, refuse the temptation to guess.
面对歧义，拒绝猜测的诱惑。

There should be one-- and preferably only one --obvious way to do it.
应该有且最好只有一种显而易见的实现方式。

Although that way may not be obvious at first unless you're Dutch.
虽然这种方式一开始可能并不那么明显，除非你是荷兰人。

Now is better than never.
现在优于永不。

Although never is often better than right now.
虽然，永不去做常常比“马上”动手要好。

If the implementation is hard to explain, it's a bad idea.
如果实现很难解释，那么它是个坏主意。

If the implementation is easy to explain, it may be a good idea.
如果实现很容易解释，那么它可能是个好主意。

Namespaces are one honking great idea -- let's do more of those!
命名空间是个绝妙的主意——让我们多多地使用它吧！

这不仅仅是代码风格指南，更是一种编程哲学的宣言。而奇妙的是，当我们手握 Go 这把锤子时，会发现很多钉子恰好就是按照这份宣言的图纸来设计的。

“显式优于隐式”：Go 的灵魂，Python 的妥协

这是“Python之禅”中最核心的信条之一，也是 Go 语言最引以为傲（或被吐槽）的特征所在。

想想 Go 语言里最经典的 if err != nil。新手可能会觉得它繁琐、重复，破坏了代码的流畅性。但在经验丰富的工程师眼中，这正是“显式”的极致体现。每一次函数调用，你都被迫直面其可能失败的现实，错误处理的路径清晰得如同一条直线，没有任何隐藏的控制流跳跃。

相比之下，Python 的 try…except 机制虽然优雅，却在某种程度上是“隐式”的。一个 try 代码块里可能有多行代码，任何一行都可能抛出异常，然后被远处的某个 except 捕获。这使得控制流变得不再那么一目了然。一位 Reddit 用户评论说：“自从我见过那些数据科学代码后，‘显式优于隐式’这条让我笑出了声。” 这虽然是句玩笑，却精准地指出了在复杂项目中，隐式处理可能带来的维护难题。

Go 通过把错误（error）设计成普通的值，而不是一个特殊的控制流机制，完美践行了“显式优于隐式”的原则。它是你必须亲手处理的返回值，而不是可以被忽略的“天外来客”。

“简单优于复杂”：Go 的克制与执拗

Go 语言的设计者们（Rob Pike, Ken Thompson 等）深受 Unix 哲学的影响，对“简单”有着近乎偏执的追求。

语法克制：Go 只有一个循环关键字 for，没有 while 或 do-while。它没有类和继承，取而代之的是更纯粹的组合与接口。并发模型也异常简单——go 关键字启动一个 goroutine，chan 进行通信，大道至简。
工具统一：gofmt 的存在，终结了所有关于代码格式的“圣战”。它体现了“Python之禅”中的另一条原则：“应该有且最好只有一种显而易见的实现方式”。在 Go 的世界里，代码风格不是一个需要讨论的问题，这极大地降低了团队协作的认知负荷。

反观 Python，随着其生态的繁荣和应用领域的扩张，语言本身不可避免地变得越来越复杂。从最初与 Perl、PHP 竞争的简洁脚本语言，到如今涵盖 Web 开发、数据科学、AI 的庞然大物，它引入了 async/await、复杂的元编程能力等。这并非坏事，而是语言成熟和演化的必然结果。但与诞生之初就目标明确（解决 Google 内部大规模工程问题）的 Go 相比，Python 在“保持简单”这条路上，显然背负了更沉重的历史包袱。

客观看待：Go 的“禅意”并非没有代价

当然，我们不能一边倒地吹捧。Reddit 的讨论中也充满了理性的声音。Go 为了实现这种“禅意”，也付出了相应的代价。

“优美优于丑陋”（Beautiful is better than ugly）：美是主观的。很多人认为 Go 的语法过于朴素，if err != nil 更是“丑陋”的代名词。但正如一位评论者所言：“我喜欢它，正是因为它在美学上很中庸（aesthetically mid）。” Go 的美，更多是一种“工程之美”，是结构清晰、易于维护、性能可靠的美，而非语法糖堆砌出的“华丽之美”。
“模板代码”（Boilerplate）：Go 的“显式”和“简单”，直接导致了更多的模板代码。这是为了可读性和可维护性做出的权衡。社区也意识到了这一点，因此 Go 在泛型等方面的引入，以及强大的代码生成工具生态，都是在弥补这一“短板”。