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

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

本文永久链接 – https://tonybai.com/2025/07/30/six-principles-production-ai-agents

大家好，我是Tony Bai。

随着 AI Agent 技术的兴起，许多开发者都投入到构建智能体的浪潮中，但很快就会发现，让 Agent 稳定、可靠地工作远非想象中容易。它们时而产生幻觉，时而偏离轨道，时而做出一些令人费解的“愚蠢”行为。最近，来自 app.build 的 Arseni Kravchenko 分享了他们在构建生产级 AI Agent 过程中总结出的六大核心工程原则。这些原则摒弃了虚无缥缈的“提示词黑魔法”，回归到坚实的软件工程基础。对于正在或计划使用 Go 构建 AI Agent 的开发者来说，这是一份宝贵的实践指南。

原则一：投资你的系统提示 (System Prompt)

许多人对“提示词工程”持怀疑态度，认为它充满了“我奶奶快不行了，请帮帮我”之类的奇技淫巧。然而，作者指出，现代 LLM 真正需要的是直接、详细、清晰且无矛盾的上下文，而非情感操控。

对于开发者而言，你要做的就是不要耍小聪明，要把系统提示当作给 Agent 的API 文档来写。

当你为 Agent 提供一个通过 os/exec 调用的工具时，不要只告诉它工具的名字。在系统提示中清晰地说明：

• 工具的完整命令是什么。
• 每个参数的含义、类型和格式。
• 预期的输出格式以及如何解析它。
• 前置条件和错误情况。

一个详尽的系统提示是 Agent 可靠行为的基石。

原则二：拆分上下文 (Split the Context)

“上下文工程”是比“提示词工程”更重要的概念。巨大的、单一的上下文不仅成本高、延迟大，还会导致模型出现“注意力衰减”，忽略掉关键信息。

作者建议大家：默认只提供最少必要知识，并通过工具让 Agent 在需要时主动获取更多上下文。

与其在初始提示中塞入整个项目的源代码，不如：

• 提供文件列表：在提示中只给出项目的文件树结构。
• 提供 read_file 工具：让 Agent 在需要时，通过调用这个工具来读取特定文件的内容。
• 上下文压缩：在 Agent 的反馈循环中，主动使用工具（甚至另一个 LLM）来压缩和总结日志、工具输出等动态信息，避免上下文无限膨胀。

如上图所示，将一个庞大的任务分解为多个具有专注上下文的、可编排的子任务，是构建高效 Agent 的关键。

原则三：精心设计你的工具 (Design Tools Carefully)

工具是 AI Agent 的核心。设计给 Agent 用的工具，比设计给人用的 API 更具挑战性，因为 LLM 不会“读心术”，它们会毫不留情地滥用你留下的任何漏洞。

作者建议：把你的 Agent 当成一个聪明但容易分心的初级开发者，为它设计 API：

• 保持粒度一致：工具（函数）应该有相似的抽象层次。不要混用一个 read_byte 和一个 deploy_to_kubernetes。
• 限制数量和参数：一个典型的工程 Agent 通常只有不到 10 个核心工具，每个工具只有 1-3 个严格类型的参数。
• 追求幂等性：尽可能让工具是幂等的，这可以极大地简化 Agent 的状态管理和错误恢复逻辑。
• 清晰、无歧义、无冗余：确保没有两个工具的功能是重叠的，这会让 LLM 感到困惑。

原则四：设计一个反馈循环 (Design a Feedback Loop)

一个没有验证和反馈的 Agent 是不可靠的。优秀的 Agent 系统总是将 LLM 的创造力与传统软件的严格性结合起来，形成一个“演员-评论家”（Actor-Critic）模型：让 LLM Actor 自由创造，让严格的 Critic 程序来验证。

对于开发者来说，这是一个天然的优势领域！

• Actor (LLM)：负责生成代码、配置文件或执行计划。
• Critic：负责执行一系列自动化验证：
  • 代码能否编译通过？
  • 代码能否通过测试？
  • 代码是否符合静态检查规范？
  • 领域特定不变量：例如，如果 Agent 修改了订单系统，是否依然满足“订单总价等于所有商品价格之和”这个业务规则？

这个反馈循环不仅能过滤掉错误的输出，更是 Agent 学习和改进的基础。

原则五：用 LLM 驱动错误分析

当 Agent 失败时，手动排查海量的日志是不现实的。我们可以构建一个“meta Agent”来解决这个问题，即让另一个 LLM 来分析失败 Agent 的日志，找出问题的根源。

流程：

1. 建立一个基线版本的 Agent。
2. 部署多个实例并收集它们的执行轨迹和日志。
3. 将失败的日志喂给一个具有更大上下文窗口（如 Gemini 1.5 Pro）的 LLM进行分析。
4. 根据 LLM 的分析洞察，改进基线 Agent 的系统提示、工具或上下文管理。

这个元循环能高效地发现我们自己可能忽略的系统性问题。

原则六：令人沮丧的行为是系统问题的信号

当 Agent 做出一些“愚蠢”的行为，比如忽略你的明确指令，或者用一种奇怪的方式绕过问题时，我们的第一反应通常是“这个模型真笨”。

但作者建议：先调试你自己的系统，再怪罪模型。

作者分享了一个亲身经历：他明确要求 Agent 使用一个集成工具来获取数据，但 Agent 却固执地使用模拟的随机数据。在愤怒地检查日志后，他发现自己忘了给 Agent 配置正确的 API 密钥。Agent 尝试调用工具，连续失败，最后只能选择一个它能走的通的、但却是错误的路径。

因此，当你的 Agent 行为异常时，请检查一下：

• 工具是否缺失？ 它是否需要一个 write_file 的能力而你没有提供？
• 提示是否模糊？ 你是否清晰地解释了工具的用法和边界？
• 上下文是否充分？ 它是否因为缺少必要信息（比如一个 API 密钥或文件权限）而无法执行任务？

小结

构建有效的 AI Agent，关键不在于寻找一个能解决所有问题的“银弹”提示或高级框架。它回归到了系统设计和严谨的软件工程。

作为开发者，我们应该聚焦于：

• 清晰的指令（通过系统提示）
• 精简的上下文管理（通过工具和压缩）
• 健壮的工具接口（简单、幂等、无歧义）
• 自动化的验证循环（编译、测试、静态检查）

当你被 Agent 的行为所困扰时，记住，问题很可能出在缺失的工具、模糊的提示或不足的上下文，而不是模型本身的局限性。将错误分析视为开发过程中的一等公民，我们的目标不是构建一个从不犯错的完美 Agent，而是构建一个可靠的、可恢复的、能够优雅地失败并被我们迭代改进的Agent。

资料链接：https://www.app.build/blog/six-principles-production-ai-agents

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

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

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

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

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

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