本文永久链接 – https://tonybai.com/2025/08/06/blitzkrieg-vs-attrition-in-ai-age

大家好，我是Tony Bai。

最近，我们的社交媒体时间线上，充斥着各种令人惊叹的 AI 效率神话。一些出海独立开发者，凭借 AI 的强大能力，在极短时间内“闪电般”地产出数个产品，上演着“一人成军”的传奇。

这景象，在令人惊叹之余，也难免给我们这些在大型项目和复杂系统中深耕的工程师，带来一丝焦虑：世界变化这么快，我们传统的开发模式和节奏，是否已经落伍了？

今天，我想和你深入探讨这背后的本质。我们需要清醒地认识到，这其实是两种目标、路径、评价体系都截然不同的开发模式。我称之为：“闪电战”与“持久战”。

“闪电战”模式：速度优先的“代码喷射器”

首先，我们必须理解那些“效率神话”主角们的战场。这是一种典型的“闪电战”模式。

• 核心目标： 快速验证想法，通过大量的产品“赛马”，在广阔的市场中捕捉稍纵即逝的流量和商机。
• 产品生命周期： 极短，甚至可以说是“阅后即焚”。一个产品可能只有一周的生命周期。若数据不佳，便会毫不犹豫地被下线，开发者则迅速转向下一个想法。
• AI 的角色： 在这个模式下，AI 是一个速度优先的“代码喷射器”。它的核心任务是在最短时间内生成能运行的代码。至于代码质量、设计一致性、可维护性、乃至长期的技术债，通通不在首要考虑之列。因为代码本身，就是一种“快速消费品”。

我们工程师的“持久战”模式：严谨可靠的“副驾驶”

现在，让我们回到自己的战场。我们绝大多数人从事的，是截然不同的“持久战”。

• 核心目标： 构建稳定、可靠、可长期演进的系统。我们写的代码，很可能需要在金融、医疗、基础设施等关键领域，7×24 小时不间断地运行数年。
• 产品生命周期： 长期，以年为单位。每一次代码提交，都是在为一座摩天大楼添砖加瓦。
• AI 的角色： 在这里，AI 必须是一个严谨可靠的“副驾驶”。它生成的每一行代码，都必须经受我们最严格的审视。因为我们，作为工程师，需要对 AI 产出的质量、安全性、性能、可维护性负全部责任。在这里，代码不再是消费品，而是需要长期持有和维护的核心资产——或者，沉重的技术负债。

看清这一点，我们就能明白：用“闪电战”的效率标准来衡量“持久战”的工作，是毫无意义的。 我们的战场不同，评价标准也完全不同。因此，我们完全没有必要为那种“一人一天N个产品”的神话而感到焦虑。

我们“持久战”工程师的 AI 打法与“护栏”

那么，在我们的“持久战”中，应该如何正确地使用 AI，既享受其带来的效率提升，又保证工程质量呢？关键在于建立清晰的“护栏”。

1. 代码审查是最后防线： AI 生成的代码，必须经过比人类编写的代码更严格的审查。审查的重点，不应仅仅停留在功能实现，更要深入到安全漏洞、性能陷阱、设计模式是否恰当等深层问题。

2. 建立团队级“Prompt 知识库”： 鼓励团队沉淀高质量、包含完整上下文和明确规范要求的 Prompt 模板。这能保证 AI 输出的“起点”质量更高，更符合团队的架构和规范，而不是每次都从零开始“随机”生成。

3. AI 专攻其擅长领域： 我们可以放心地让 AI 生成单元测试、API 文档、数据结构模板，或是在明确的模式下进行代码重构。但在核心架构设计、复杂业务逻辑实现等“高风险”领域，AI 只应作为提供思路参考的“顾问”，绝不能成为决策者。

4. 引入“AI 生成”标识： 在代码提交或 Code Review 流程中，可以引入规范，要求开发者明确标识出哪些部分是由 AI 主要生成的。这就像在施工图纸上标注出“预制件”，提醒审查者需要重点检查其接口和集成质量。

小结：认清你的战场，定义你的价值

首先，我们需要明确一点：“闪电战”与“持久战”之间，没有高下对错之分，只有战场类型和战略目标的不同。 如果你是一位寻求市场机会的出海独立开发者，那么“闪电战”无疑是极佳的策略。它能让你以最低成本快速试错，抓住机会，并在数据不佳时果断放弃，及时止损。这是一种聪明且务实的生存之道。

而对于我们绝大多数在企业中构建关键系统的工程师来说，认清我们身处“持久战”的现实，并重新定义我们在 AI 时代的价值，则至关重要。我们的核心竞争力，正在加速地从“编写代码”，转向“定义问题、设计系统、制定标准、审查质量、保障稳定”。

AI 越是能高效地“写”，我们就越需要成为那个能提出正确问题、设计出健壮蓝图、并能精准鉴别优劣的“架构师”和“质检员”。我们的工作变得更“上游”，我们的思考变得更具决定性，我们的价值也因此而更高。

所以，朋友们，请放下焦虑。清晰地认识到自己的战场，然后拥抱 AI 这个强大的“副驾驶”，在我们的“持久战”中，更高质量、更有效率地去构建那些真正能够改变世界、并经受住时间考验的系统。这，才是属于我们的战场，和我们的荣耀。

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

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

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

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

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

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

本文永久链接 – 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 编程助手的世界里，我们该如何应用“选择无聊的技术”这一原则呢？这里有三条黄金法则：

1. 评估新技术时先自问：“如果 AI 为它生成了代码，我有能力审查吗？” 如果答案是否定的，那么这项技术或许不应该用于任何对你而言是任务关键型（mission-critical）的项目。

2. 学习新技术时（当你决定用掉一个“创新代币”时）： 请务必花时间深入理解它，达到能对 AI 的建议进行独立事实核查的程度。不要只是复制、粘贴，然后祈祷好运。

3. 抵制诱惑： 不要把 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技能再上一个新台阶！

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