摘要：十年前，Dan McKinley 的《选择无聊的技术》成为无数工程师的座右铭。十年后，Copilot 与大模型看似让任何新技术都触手可及，但这篇经典雄文的原则非但没有过时，反而变得更加致命。本文将深入探讨，在 AI 编程时代，我们为何要更加警惕那些“闪亮新工具”所带来的陷阱，以及如何将 AI 从“脆弱的拐杖”变为真正的“力量倍增器”。

一、凌晨三点的告警，与“无聊”技术的价值

让我们回到一个经典的工程师噩梦：凌晨三点，生产环境告警，系统核心服务崩溃。

在这一刻，你最不想要面对的，是一个你知之甚少的、时髦的新技术。你真正需要的，是一个拥有海量文档、Stack Overflow 上有无数“前人”踩过的坑、社区生态成熟稳定的“无聊”技术。

这正是 Dan McKinley 在其经典文章《选择无聊的技术》（Choose Boring Technology）中阐述的核心思想。他提出，每个团队的“创新代币”是有限的，应该用在最能创造业务价值的刀刃上，而不是在技术栈上随意“炫技”。像 Python、Postgres、Java Spring 这类“无聊”技术，最大的优点并非新潮，而是其 故障模式和能力边界是广为人知的。

这个原则，在过去十年，是无数架构师和资深工程师的技术选型“圣经”。然而，一个新变量的出现，正在动摇这个根基——那就是 AI 编程助手。

二、AI 编程的“潘多拉魔盒”：无限的能力与致命的幻觉

AI 编程助手（无论是 GitHub Copilot 还是通义灵码）带来了一个全新的、既诱人又极其危险的局面。

诱惑在于，现代 AI 几乎能为任何你能想到的技术栈，生成“看起来非常专业”的代码。

你可以让它用最新的 JavaScript 框架，结合 GraphQL Federation 和 Kubernetes，帮你实现一套复杂的微服务。它会迅速返回一堆代码——这些代码可能遵循了所有社区最佳实践，命名规范无可挑剔，错误处理看起来滴水不漏，甚至，它真的能 docker-compose up 跑起来。

这种“弹指一挥间，掌握任何新技术”的感觉，就是 AI 的诱惑。它让你觉得，技术栈的宽度不再是障碍。

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

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

我亲眼见过，有团队兴高采烈地接受了 AI 生成的代码，而这些代码里包含了：

1. 使用了早已废弃（deprecated）的 API：在短期内能工作，但随时会在未来的版本更新中引爆。

2. 实现了严重的安全反模式：比如错误的认证流程，留下了巨大的安全隐患。

3. 制造了极其隐蔽的性能“地雷”：比如一个在低负载下运行良好，但在高并发下会造成数据库连接池耗尽的查询。

为什么会这样？因为这些代码“看起来是对的”，它的错误，深植于技术的细枝末节之中，只有真正精通这门技术的人，才能一眼看穿其中的凶险。

三、风险的“乘法效应”：从“技术债”到“技术核爆”

过去，我们说选择一门新技术，是为项目增加了一个“未知数”。这个未知数可能会带来一些麻烦，但通常是可控的“技术债”。

而在 AI 时代，当你将“不熟悉的技术”与“AI 生成的代码”结合时，你不再是简单地增加未知数，而是在乘以未知数。

传统风险 = 项目复杂度 + 新技术的未知 AI时代风险 = 项目复杂度 × 新技术的未知 × AI幻觉的未知

你不知道这个框架是否是解决你问题的最佳选择；你不知道 AI 的实现是否遵循了行业最佳实践；你更不知道，这套“组合拳”将会在未来的哪个凌晨，以何种奇特的方式彻底崩溃。

这已经不是简单的“货物崇拜”（cargo-culting），而是 指数级的货物崇拜。当告警再次响起时，你面对的不再是一个有迹可循的 Bug，而是一个你完全不理解的、由 AI 构建的“黑盒”。你甚至不知道问题出在你的逻辑，还是 AI 的逻辑，还是那个你本就不熟的新技术上。

四、AI 时代的技术选型第一性原理：做“主人”，而非“拐杖”的奴隶

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

AI 是你所精通技术的“力量倍增器”，却是你不熟悉技术的“脆弱拐杖”。

• 当你是一个精通 Rails 的开发者，你可以让 AI 帮你生成冗长的 Controller 和 View 代码。当 AI 提出一个可疑的数据库查询建议时，你的经验会立刻让你警觉。在这里，AI 是你的副驾驶，为你处理了导航和换挡的琐事，但方向盘始终在你手中。

• 当你是一个 JavaScript 新手，你让 AI 帮你写一段复杂的异步并发控制代码。它可能会给你一段使用了 Promise.all 的代码，看起来简洁优雅。但你可能并不知道，其中一个 Promise 的 reject 会导致整个链路中断，而你真正的业务需求或许是使用 Promise.allSettled。你依赖着一根脆弱的拐杖，在悬崖边上行走。

五、给开发者和团队的三条黄金法则

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

1. 以“审查能力”为技术选型的试金石。 在引入一项新技术前，先扪心自问：“如果 AI 为这项技术生成了1000行代码，我有能力、有信心去逐行审查（Code Review）并批准合并吗？”如果答案是否定的，那么这项技术绝对不应该用于任何对你而言是任务关键型的项目。

2. 用“刻意练习”替代“复制粘贴”。 当你决定要用掉一个宝贵的“创新代币”去学习新技术时，请务必投入时间去深度理解它。将 AI 当作你的学习伙伴，而不是代码生成器。你可以让它生成代码，然后要求它解释每一行的作用，追问多种实现方式的优劣。你的目标，必须是达到能对 AI 的建议进行独立事实核查的程度。

3. 抵制“技术全家桶”的诱惑。 AI 可能会给你一种“我能搞定一切”的错觉，让你想同时拥抱一门新语言、一个新框架和一套新基础设施。请坚决抵制这种诱惑。真正可靠的系统，是通过一次只引入一个变量来逐步构建的。否则，你得到的将是一个无法维护的、由无数“黑盒”拼接而成的“缝合怪”。

总结：深刻的理解，是前所未有的宝贵资产

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

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

所以，我们的建议始终不变：当你要解决一个问题时，请使用你已经深刻理解的技术。当你想要学习新东西时，那就专心去学习。

在一个 AI 可以为你从未涉足的领域自信地生成数千行代码的世界里，你自己的、来之不易的深刻理解，比以往任何时候都更有价值。这，才是你在智能时代最坚不可摧的护城河。