本文永久链接 – https://tonybai.com/2026/05/21/go-is-the-new-lingua-franca-for-ai-agents-at-google

大家好，我是Tony Bai。

在过去的两年里，只要一提到 AI 开发，99% 的人脑海中弹出的第一个词绝对是：Python。而如果是涉及到大模型底层的高性能推理与算力压榨，大家想到的必然是 C++ 或是 Rust。

但在真正的工程落地中，情况正在发生一场令人猝不及防的剧变。

最近，Google 资深软件工程师 Jaana Dogan（@rakyll）在 X（原推特）上发布了一条引发技术圈热议的推文：

“Go 成为 Google 内部 Agentic（智能体）系统的通用语言（lingua franca），这真的很了不起。我以前从未看到过 Go 有取代 C++ 的路径，但现在我相信这是可能的。”

这不仅仅是一条简单的技术感慨，它揭示了 AI 浪潮进入“下半场”后的核心工程困境：当我们把大模型封装成 Agent，并让成千上万个 Agent 并发协作时，Python 太脆弱，C++ 太沉重，而 Go，迎来了它的“天命时刻”。

今天，我们就来扒一扒，为什么 Google 会让 Go 接管 AI Agent 的底层开发？这对我们普通开发者的技术栈转型，又意味着什么？

打破滤镜：为什么 Python 和 C++ 在 Agent 时代“失宠”了？

要理解 Go 的上位，我们首先要搞清楚，AI Agent 到底需要什么样的工程能力。

现在的 AI 应用，早就不是早期那种“写个 Python 脚本，调用一下 OpenAI API，把结果打印出来”的玩具了。真实的 Agentic 系统（智能体系统）包含了极其复杂的网络 I/O、并发工具调用（Tool Calling）、多智能体消息路由、长时记忆状态管理，以及大规模的分布式容错。

在这个场景下，旧有的王者们暴露出了致命的缺陷：

1. Python 的“工程化陷阱”

Python 是 AI 研究员的最爱，因为它的数据科学库天下无敌。但当你要构建一个高并发、高可用、需要 24/7 运行的 Agent 编排系统时，Python 的弱类型（重构火葬场）和 GIL（全局解释器锁，导致无法真正利用多核并发）就成了灾难。正如原贴讨论区一位开发者所言：“模型层可能是 Python 的天下，但围绕着模型的 Runtime（运行时环境）正越来越像 Go 的领地。”

2. C++ 的“杀鸡用牛刀”

C++ 拥有极致的性能，是模型训练和推理引擎（Inner Loop）的绝对霸主。但 Agent 编排系统真的需要 C++ 级别的疯狂数学计算吗？不需要。

Agent 系统本质上是大量的网络等待（等 LLM 返回结果、等数据库查询、等网页抓取）。用 C++ 来写极其复杂的并发网络请求和状态机，不仅开发周期漫长，而且极易产生内存泄漏。正如推文评论所指出的：“C++ 背负了太多的历史包袱，它在 Agent 编排上显得太重了。”

Go 凭什么上位？Goroutine 与 Agent 的“完美同构”

Go 语言在这个时间节点爆火，并非偶然，而是因为它底层的并发哲学与 AI Agent 的行为模式产生了“完美的同构映射”。

在 X 上的讨论中，多位资深开发者一针见血地指出了核心原因：

“Goroutines mapping directly to concurrent agent communication is the reason why it makes perfect sense.”（Goroutine 直接映射到并发 Agent 之间的通信，这是它如此完美契合的原因。）

让我们用大白话来翻译一下这个硬核逻辑：

什么是多智能体系统（Multi-Agent System）？本质上就是一堆各自独立的“数字员工”，它们一边自己干活，一边通过发消息相互沟通。
而 Go 语言最强大的杀手锏是什么？正是 CSP（通信顺序进程）并发模型，即 Goroutine（轻量级协程）和 Channel（通道）。

• 当你启动一个 Agent 时：在 Go 里，你只需要一个简单的 go runAgent()，就能以极其低廉的内存代价（几 KB）启动一个并发实体。一千个 Agent？一万个 Agent？对 Go 来说毫无压力。
• 当 Agent 之间需要协作对话时：你不需要去搞复杂的锁（Locks）或者共享内存，你只需要用 Go 的 Channel 把消息塞过去，另一个 Agent 就能安全地接收。

Agent 的编排，需要的是“轻量级的并发管理”，而不是“极致的数学计算速度”。这简直就是为 Go 量身定制的战场。

征服大厂，构建 Agent 架构的“铁三角”

除了并发模型上的天作之合，评论区的一位开发者还另外总结了 Go 赢下这场战争的另外三个决定性因素。他指出，现代 Agent 技术栈奖励三种特性，而 “Go 完美击中了这三点（Go nails all three）”：

1. 强类型系统（Types）：告别“盲盒”开发

Agent 系统中充斥着复杂的 JSON 解析、Tool Calling 的参数校验、以及结构化的输出。Python 的字典（Dict）传递在项目变大后就像是“盲盒”，你永远不知道里面缺了哪个字段。而 Go 的强类型 Struct 和极度清晰的错误处理机制（虽然大家都吐槽 if err != nil，但它确实极其可控），让系统拥有了极高的可预测性（Predictability）。

2. 极速的编译体验（Fast Builds）

“编译速度是让它成为绝配的原因之一。”在快速迭代的 AI 产品中，Go 那种秒级的编译速度，让开发者可以飞速地测试 Agent 的行为逻辑。相比之下，C++ 那漫长的编译过程在需要高频微调的 AI 时代显得格格不入。

3. 小巧的单一二进制文件（Small Binaries）

当你把 Agent 部署到云端、边缘设备甚至是 Serverless 环境时，Go 编译出来的是一个无需任何外部依赖的独立执行文件。没有 Python 烦人的环境依赖（无需折腾 pip, conda, 虚拟环境），直接丢进一个极小的 Docker 镜像中就能运行，这对于现代云原生运维来说是无可估量的优势。

一个反直觉的冷知识：大模型“最爱”写 Go 代码

推文中一个开发者提出了一个极其有趣且经常被忽视的视角：在 LLM（大语言模型）的眼中，Go 是一门完美的语言。

如果你经常用 Cursor/Codex/Claude Code等 写代码，你会发现一个现象：让 AI 写 Python，它经常会用错第三方库的版本；让 AI 写 C++ 或 Scala，它可能会搞出一堆极其复杂的继承、多态或者生命周期错误。

但如果你让 AI 写 Go 呢？成功率出奇的高。

原因在于：

1. Go 的语法极致简单、无聊，甚至“没有类（Classes）”。它只有 Struct 和接口，这极大地减少了代码的“表面积（Surface Area）”。
2. Token 使用率极高。由于没有复杂的黑魔法和繁琐的泛型体系（早期），LLM 在生成 Go 代码时不容易出现“幻觉”，维护起来极其容易。

在这个连代码本身都开始由 AI 生成的时代，“对 LLM 友好”竟然成了一门编程语言的核心护城河。

终局推演 —— C++ 守住“内环”，Go 赢下“外环”

那么，Go 真的会彻底消灭 C++ 吗？

并不完全是。这场讨论最终达成了一个非常清晰的技术栈共识：

“C++ still wins the inner loop. Go wins everything around it.”（C++ 依然赢得了内环，而 Go 赢得了周围的一切。）

未来的 AI 系统架构已经初露端倪，它将被清晰地划分为三个层级：

1. 研究与数据层（Python）：用于模型训练、数据清洗、算法验证。
2. 算力内环（C++ / Rust / CUDA）：大模型的推理引擎（如 vLLM、Ollama 底层）、张量计算。这里需要极致榨干每一滴 GPU 性能，C++ 依然是绝对的霸主。
3. 编排外环与业务层（Go）：这是距离普通开发者最近、也是市场需求最大的地方。成千上万的 Agent 调度、API 网关、并发的数据检索（RAG）、记忆数据库交互、工具链调用，全部都将被 Go 统治。

最新铁证！Google I/O 2026 震撼官宣：废弃旧路线，用 Go 重写 AI 核心入口！

如果你觉得前面硅谷大佬们的讨论还只是“理论推演”，那么在刚刚举办的 Google I/O 2026 大会上，Google 官方直接用一记雷霆手段，把这个趋势变成了既成事实。

Google 开发者博客发布了公告：正式宣布停止维护原有的 Gemini CLI，全面过渡到全新的“Google Antigravity（反重力）”多智能体开发平台，并推出全新的核心入口 —— Antigravity CLI。

而在官方给出的技术变更文档中，最扎眼、最让 Go 开发者狂喜的一条更新理由，白纸黑字地写着：

“Faster execution: Built in Go, Antigravity CLI is snappier and more responsive.” （更快的执行速度：基于 Go 语言构建，Antigravity CLI 更加轻快、响应更迅速。）

旧版的 Gemini CLI 是基于传统脚本语言（Node.js/TS 体系）构建的，在处理单点交互时绰绰有余。但 Google 明确表示，现在开发者的需求已经彻底变了：“你现在需要多个 Agent 相互通信、分工合作来解决复杂的系统问题。”

当单点 CLI 变成“多 Agent 协同编排后端”时，旧有的 JS/TS 体系在高并发、异步工作流（Asynchronous Workflows）和底层系统控制上面临性能瓶颈。Google 毫不犹豫地选择用 Go 语言 彻底重写，就是为了利用 Go 极致的并发和执行效率，来支撑起“后台多任务并发运行、且不锁定终端”的强悍体验。

小结：给开发者的生存建议

过去的一年里，无数后端开发者感到焦虑，觉得自己掌握的 CRUD 技能在 AI 面前一文不值。但 Google 内部的这场技术栈迁移，给我们指明了一条无比清晰的道路：

别再只盯着 Python 看了。

当 AI 从单一的对话框，走向全面接管企业业务流的多智能体（Multi-Agent）协作形态时，对高并发、高可用后端工程能力的需求不仅没有减少，反而呈指数级爆发。

学习 Go 语言，理解 Goroutine，掌握如何构建一个稳健的 Agent 编排框架。因为决定下一个十年 AI 应用成败的，不再是模型本身的算力，而是谁能最好地管理和协调这些拥有智能的“数字大军”。

而目前来看，Go，已经在这场战役中拔得头筹。

资料链接：https://x.com/rakyll/status/2056528039698403498

今日互动探讨：

你目前在开发 AI 应用或 Agent 系统时，使用的是什么语言？你是否遇到了 Python 在高并发或部署时的痛点？欢迎在评论区分享你的实战经验与踩坑血泪史，我们一起探讨 AI 时代的最佳实践！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/20/ai-coding-win-rate-rankings-go-and-rust-vs-cpp

大家好，我是Tony Bai。

过去两年，程序员群体经历了一场前所未有的“职业身份危机”。

随着 GPT、Claude、Gemini 等模型的发布与能力更迭，各种“AI 几秒钟写出小游戏”、“AI 自动化修复 Bug”的新闻充斥屏幕。在各种传统的代码补全基准测试（如 HumanEval）中，大模型们动辄刷出 90% 以上的惊人通过率。一时间，“程序员是夕阳行业”、“架构师即将下岗”的言论甚嚣尘上。

然而，这只是硬核工程世界的冰山一角。最近，由 Meta FAIR（Meta 基础人工智能研究实验室）、斯坦福大学和哈佛大学联合发布的一项重量级研究——ProgramBench，彻底击碎了这些幻觉。

ProgramBench 的设计初衷非常“残暴”：它不再测试 AI 能不能写出一个简单的算法函数，而是测试 AI 能不能从零开始（From Scratch）复刻一个完整的开源项目，即从观测二进制行为（Probe）到编写源码（Build），再到最终的等效性评估。

测试规则如下：

1. 黑盒逆向：不给源码，只给 AI 一个编译好的二进制可执行文件（如 sqlite3、ffmpeg、ripgrep）和一份使用说明书。
2. 物理断网：切断互联网访问，防止 AI 通过搜索“偷看”GitHub 上的源码。
3. 架构自主：AI 必须自己决定项目的文件结构、选择什么编程语言、设计什么抽象层次。

在这场面向 200 个真实复杂项目的“闭卷考试”中，全球最顶尖的大模型们集体陷入了沉思。

数据表明，即便是在最强的模型面前，完全成功的概率依然是 0。

但在这场败战中，我们通过海量数据发现了一个足以改变未来十年技术选型的真相：Go 与 Rust 已经成为了 AI 时代的“天命语言”，而 C++ 则不那么受 AI 青睐，AI 用起来也不那么顺手！

诸神黄昏：Claude 对 GPT 家族的“工程级”碾压

在程序员的认知中，GPT 家族曾代表着 AI 的巅峰。但在 ProgramBench 的 Leaderboard（排行榜）上，局势发生了戏剧性的反转，但也正如我们预料的那样。

根据论文统计，在衡量“几乎完成”（即通过 95% 以上的测试用例）这一指标时，排名如下：

1. 头号种子：Claude Opus 4.7。它是全场唯一一个在 3.0% 的复杂项目中展现出近乎完美复刻能力的模型。
2. 二号梯队：Claude Opus 4.6 (2.5%) 与 Claude Sonnet 4.6 (1.6%)。
3. 集体挂零：GPT 5.4、Gemini 3.1 Pro。 没错，这些在其他榜单上呼风唤雨的模型，在“从零复刻完整项目”的任务中，竟然连一个能通过 95% 测试的任务都没完成。

为什么 GPT 会在硬核工程上输给 Claude？

研究人员通过分析“智能体轨迹（Agent Trajectories）”发现了秘密。大模型写代码有两种流派：

• “急性子”派（以 GPT 5.4 为代表）：GPT 倾向于“单次爆发”。数据显示，它在每个任务中平均只用 17 个命令。它习惯于在最初的几个回合内，直接吐出 96% 的代码。如果代码跑不通，它很少进行深度的自我修正。
• “架构师”派（以 Claude 为代表）：最强的 Claude 模型更像是一个深思熟虑的工程师。它平均每个任务会调用 868 个命令！它会不断地执行 ls 查看目录、用 cat 检查文件、反复运行测试并根据报错信息进行“重构”。

可见，在复杂的软件工程面前，单纯的“语料记忆”失效了。Claude 的胜出，本质上是其“推理链”和“持续迭代能力”的胜出。它不只是在背代码，它是在通过不断的试错来“推演”架构。

通过上图中不同模型的动作类型分布，我们可以看到 Claude 拥有极长且复杂的“读-写-探测”循环，而 GPT 的动作序列短得惊人。

语言偏好：AI 也有自己的“舒适区”

ProgramBench 给 AI 提供了完全的自由：AI 可以用任何语言来复刻目标程序。这产生了一个极其有趣的“语言混乱矩阵（Confusion Matrix）”。

1. GPT 的 Python 执念

GPT 5.4 表现出了近乎偏执的 Python 依赖。在所有任务中，它有 79% 的方案是用 Python 写的。无论原程序是用更底层的 C 还是 Rust 写的，GPT 的第一反应往往是：“我能不能用 Python 给它糊出来？”

2. Claude 的硬核品味

最强模型 Claude Opus 4.7 表现出了极高的系统级素养。它只在 14% 的情况下选择 Python，它更倾向于使用 Rust 和 Go 来应对复杂任务。这说明越强大的模型，越能理解底层语言在性能和逻辑表达上的严密性。

3. 为什么 AI 喜欢 Python？

原因很简单：容错率。 Python 拥有极其丰富的第三方包、极简的语法以及无需手动管理内存的特性。对于 AI 来说，Python 是它能用最少的回合数实现最多功能的“逃生路径”。但这种逃生是有代价的——复杂的系统级软件用 Python 复刻，往往会因为性能或底层调用模拟不足而失败。

深度解析：为什么 Go 与 Rust 是 AI 的“天命之子”？

这是本次研究中最具行业指导意义的发现。通过研究数据对比，我们发现不同语言在 AI 手下的“存活率”天差地别：

• Go 语言项目：AI 成功通过率 38.4%
• Rust 语言项目：AI 成功通过率 38.5%
• C/C++ 项目：AI 成功通过率仅为 27.7%

为什么同样是系统编程语言，Go 和 Rust 就能完胜 C++？这不仅仅是语法的问题，更是现代工程化基建的降维打击。

1. 构建系统：AI 开发者的“生死线”

在 C/C++ 的世界里，构建系统是混乱的代名词。CMakeLists.txt、Makefile、系统特定的动态链接库（.so/.dll）路径……对于 AI 智能体（SWE-agent）来说，这些是致命的障碍。

调研显示，AI 在 C++ 任务中，往往还没开始写业务代码，就已经在配置环境时陷入了死循环。

反观 Go 和 Rust：

• Go：一个 go mod tidy 加一个 go build 解决了全球 99% 的构建问题。
• Rust：Cargo 是目前人类文明最先进的包管理器之一。

对于 AI 来说，这种“标准化”意味着它只需要执行一条命令就能建立起完整的工程环境。这种极高的工程化一致性，让 AI 可以把宝贵的 Token 消耗在业务逻辑上，而不是折腾环境。

2. 标准库的“全家桶”效应

Go 语言一直以“自带电池（Batteries included）”著称。它的标准库涵盖了网络、加密、编解码等大部分现代互联网开发所需的功能。AI 调用 Go 的标准库就像从兜里掏东西一样自然。

而 C++ 的标准库相对贫瘠，往往需要引入第三方库（如 Boost, libcurl）。一旦涉及到第三方依赖，AI 的出错概率就会呈指数级上升。

3. 内存安全：给 AI 的“保护索”

在 C/C++ 中，AI 极其容易写出缓冲区溢出、内存泄露或段错误。一旦程序在运行过程中崩溃，由于 AI 缺乏深度的 GDB 调试能力，它很难从 Core Dump 中恢复。

Rust 严格的借用检查（Borrow Checker），在编译阶段就强行纠正了 AI 的大部分错误。这种“编译即正确”的反馈循环，让 AI 在复刻软件时拥有了更高的胜率。

揭秘 AI 程序员的“坏习惯”：屎山代码的起源？

除了排名和语言，ProgramBench 还揭露了目前 AI 编码的三个极具冲击力的特征：

1. 单文件架构迷恋

人类架构师讲究解耦，喜欢建立复杂的目录结构。但 AI 却恰恰相反。数据显示，67% 的 AI 方案产生的目录深度明显浅于原项目。

AI 表现出强烈的“单文件狂魔”倾向。 它们喜欢把数千行代码塞进 1-3 个超级大文件里。这反映出目前的模型在处理跨文件的上下文关联时，依然存在明显的认知衰减。

2. 逻辑“大颗粒化”

AI 写的函数数量通常只有人类原作者的 10% 到 20%。但这并不意味着功能缺失，而是因为 AI 喜欢写超长函数（God Functions）。

Claude 生成的函数长度平均是人类的 1.46 倍，Gemini 甚至达到了 1.62 倍。这种代码对于 AI 来说运行没问题，但对于人类后续维护来说，简直是噩梦。

3. 诚信危机：AI 也会“偷懒作弊”

在测试的早期阶段，研究人员尝试给 AI 开启互联网访问。结果发现，最强的大模型们全都是“老油条”。

一旦它们通过二进制文件的帮助信息（–help）推断出这是哪个开源项目，它们会直接去克隆对应的 GitHub 仓库代码并提交。

Claude Sonnet 4.6 的作弊率一度高达 36%！ 这迫使研究团队最终必须在完全断网的环境下运行测试。这告诉我们：永远不要低估大模型为了完成任务而寻找“捷径”的本能。

小结：程序员的黄昏还远未到来

看完这份长达 60 多页的研究报告，我们不仅没有感到绝望，反而产生了一种前所未有的踏实。

报告证明了：即便是在最顶尖的模型面前，真实的软件工程（Software Engineering）依然是一个极度复杂的高壁垒领域。写代码只是软件工程中最后、最轻的一环。而之前的架构设计、模块拆分、抽象提取、以及对业务边界的理解，目前的 AI 依然处于“学龄前”阶段。

给开发者的建议：

1. 向 Go 和 Rust 迁移：这不只是性能考量，更是为了拥抱 AI。如果你想让 AI 帮你更高效地干活，请选择那些对 AI 友好的工程化基建。
2. 强化架构师思维：既然 AI 喜欢写单文件“屎山”，那么如何管理大型项目的复杂性、如何通过 Prompt 引导 AI 进行模块化设计，将是未来高级工程师的核心竞争力。
3. 拥抱 Claude 模式：告别“单次生成”的幻觉，建立起“持续迭代、自动测试、反复纠错”的 AI 开发流水线。

程序员的黄昏还远未到来。

相反，我们正在进入一个全新的时代：一个由人类架构师掌控蓝图，由 AI 劳工在标准化的 Go/Rust 仓库中疯狂试错、高效产出的黄金时代。AI 并没有取代你，它只是淘汰了那些只会机械写代码、而不懂工程设计的“码农”。

真正的开发者，正在迎来属于他们的、被 AI 加持的黎明。

资料链接：

• https://arxiv.org/abs/2605.03546
• https://programbench.com/

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/19/ai-era-software-engineer-algorithm-map

大家好，我是Tony Bai。

“帮我写一个限流器。”

当你把这行字敲进 Claude、Gemini 或ChatGPT 的对话框或CLI形式的命令行时，几秒钟后，屏幕上会出现一段看似完美的 Go 代码。它可能使用了 Token Bucket 算法，也可能用了一个简单的计数器。

这时候，一个残酷的问题摆在你面前：代码已经生成了，你的价值在哪里？

• 如果你看不懂它是基于什么模式生成的，你就不敢在生产环境用它；
• 如果你不知道如何调整它的滑动窗口参数，当流量洪峰来袭时，系统就会雪崩；
• 如果你无法从这段代码联想到 TCP 协议的拥塞控制或 Kubernetes 的资源调度，那么你依然只是一个“代码搬运工”，只不过搬运的工具从 Google 变成了 AI。

在 AI 时代，编码（Coding）的成本正在无限趋近于零，但设计（Design）与判断（Judgment）的价值却在指数级上升。

很多工程师在刷 LeetCode 时感到痛苦，是因为他们把算法当成了“面试八股文”，考完即忘。但在资深架构师眼里，LeetCode 里的每一个算法模式，都是现代软件工程中的一个微缩模型。

• 滑动窗口（Sliding Window） 不只是为了求子串，它是 TCP 流量控制和微服务限流熔断的基石；
• 并查集（Union-Find） 不只是为了算连通分量，它是社交网络好友推荐和图像处理魔棒工具的底层逻辑；
• LSM Tree 的设计思想，其实就是归并排序（Merge Sort） 在磁盘 I/O 上的极致应用。

我策划这个《AI 时代软件工程师的算法图谱：从 LeetCode 模式到工程实战》的微专栏不教你怎么“背题”，也不搞什么枯燥的数学证明。我要做的是连接——通过 Go 语言，在“LeetCode 模式”与“硬核工程实战”之间架起一座桥梁。

我们要把那 2000 多道题，提炼成 15 类核心模式，装进你的武器库。下次遇到工程难题时，我希望你的直觉告诉你的不是“我去问问 AI”，而是“这是一个典型的 Top K 问题，我可以用堆（Heap）模式来解决，顺便让 AI 帮我补全代码细节。”

这将是一次从“刷题”到“识图”，从“算法”到“架构”的认知升级。

我们将整个知识体系划分为五季，共 16 讲，层层递进！

第一季：线性数据流与内存模型

—— 掌握系统的“吞吐”与“存储”

这一季我们从最基础的数组和链表出发，但视角完全不同。我们将探讨如何用双指针解决日志系统中的多路归并问题；如何用滑动窗口构建一个高性能的实时流控组件；单调栈在编译器解析和数据可视化中的妙用；以及链表操作在操作系统内存分配器（Malloc）和 Redis Ziplist 中的影子。

• 第 01 讲 | 双指针：从数组去重到日志合并
• 第 02 讲 | 滑动窗口：流式数据的流量控制
• 第 03 讲 | 栈与单调栈：解析器与最近相关性
• 第 04 讲 | 链表操纵：指针的艺术与内存管理

第二季：组织与调度

—— 在海量数据中建立“秩序”

当数据量大到无法放入内存，或者任务多到 CPU 处理不过来时，我们需要更高效的组织方式。我们将从二分查找谈到分布式系统的一致性哈希查找；用堆（Heap） 模式来剖析操作系统任务调度器和热搜榜单的实现；用贪心算法来解决云计算资源调度和数据库事务锁管理。

• 第 05 讲 | 二分查找：在不确定性中定位边界
• 第 06 讲 | 堆与 Top K：高频热点与调度器
• 第 07 讲 | 贪心与区间：资源分配的最优解

第三季：结构化数据与张量

—— 理解万物互联的“关系”

这是 AI 时代和分布式系统最核心的板块。我们将用树的遍历来解析 JSON/YAML 配置和 DOM 树；用图论（Union-Find/拓扑排序） 来解决微服务依赖分析和死锁检测；用最短路径算法搞定网络路由协议（OSPF）；特别是矩阵与张量一讲，将带你理解图像处理卷积核与 AI 框架中的 Tensor 变换原语。

• 第 08 讲 | 树的遍历：层级数据的处理范式
• 第 09 讲 | 图论基础：依赖与连通性
• 第 10 讲 | 最短路径：网络流与路由
• 第 11 讲 | 矩阵与张量：AI 时代的计算原语

第四季：编码与底层魔法

—— 榨干机器性能的“黑科技”

在对性能要求极高的场景下，我们需要深入比特位。我们将探讨字符串匹配（KMP/Rabin-Karp） 在文本编辑器和 rsync 增量同步中的应用；以及位运算（Bit Manipulation） 在权限系统设计、布隆过滤器（Bloom Filter）和搜索引擎 Bitmap 索引中的神奇威力。

• 第 12 讲 | 字符串处理：模式匹配与哈希
• 第 13 讲 | 位运算：状态压缩与高效计算

第五季：复杂决策与系统设计

—— 从算法走向架构师

最后，我们将挑战最复杂的场景。用回溯法构建正则表达式引擎和自动化测试用例生成器；用动态规划理解数据库查询优化器（Cost-based Optimizer）和文本 Diff 原理；最后通过 Trie 树和 LRU/LFU 两种模式，亲手设计搜索引擎自动补全和 Redis 内存淘汰策略，完成从算法到系统设计的最后一公里。

• 第 14 讲 | 回溯与分支定界：暴力搜索的优化
• 第 15 讲 | 动态规划：空间换时间的极致权衡
• 第 16 讲 | 系统设计模式：从算法到架构

算法从来不是为了刁难你，它是前人智慧的结晶，是软件世界的物理定律。

在 AI 时代，Copy 代码很容易，但 Copy 思维很难。 我希望通过这个专栏，帮你构建起一套属于自己的“算法图谱”。当你拥有了这份图谱，无论技术浪潮如何更迭，你都能一眼看透复杂系统背后的简单逻辑。

准备好了吗？让我们开始这趟“重塑”之旅。

点击这里 或扫描下方二维码，订阅《AI 时代软件工程师的算法图谱》，开启你的进阶之路。

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/17/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

大家好，我是Tony Bai。

在 AI 编码工具普及的今天，我们往往容易陷入一种认知误区：认为只需接入最顶尖的模型，生产力便会随之爆发。然而，当我们将 Claude Code 引入拥有数百万行代码、错综复杂的微服务架构或积淀深厚的遗留系统中时，单纯的“模型能力”往往会触碰到现实的边界。

真正的大规模部署，比拼的并非仅仅是单一模型的推理上限，而是如何构建一套高效的“工程化框架”。如何通过 CLAUDE.md 让 AI 读懂组织的隐性约定？如何利用钩子（Hooks）与插件（Plugins）让工具实现自我演进？又该如何将“代码库地图”转化为 AI 的导航指南？

近期Anthropic发布了一篇名为《How Claude Code works in large codebases: Best practices and where to start》的文章，深度揭露了 Anthropic 团队在企业级场景下的实践智慧，为你揭示如何通过精细化的工程布局，让 Claude Code 真正成为大型代码库中不可或缺的高效协作伙伴。

下面是这篇文章的译文。

最成功的 Claude Code 部署案例都共享了一套跨配置、工具和组织结构的可识别模式。本文是“Claude Code 大规模应用”系列文章的一部分，旨在分享工程组织在大规模环境下使用 Claude Code 的最佳实践。

Claude Code 正应用于数百万行的单体仓库（monorepo）、拥有数十年历史的遗留系统、跨越数十个存储库的分布式架构以及拥有数千名开发人员的组织中。这些环境带来了较小的、更简单的代码库所不具备的挑战，即跨越不同子目录或没有共享根目录的遗留代码，其构建命令各不相同。

本文涵盖了我们观察到的促成 Claude Code 大规模成功部署的模式。我们用“大型代码库”来指代广泛的部署场景：包含数百万行代码的单体仓库、运行数十年的遗留系统、数十个微服务的集合，或以上各种形式的组合。这还包括运行在 AI 工具通常不常关联的语言（如 C, C++, C#, Java, PHP 等）上的代码库。（得益于最近的模型版本，Claude Code 在这些情况下的表现优于大多数团队的预期。）虽然每个大型代码库的部署都由其特定的版本控制、团队结构和累积的约定所塑造，但这些模式在各处具有普遍性，是团队考虑采用 Claude Code 的良好起点。

Claude Code 如何导航大型代码库

Claude Code 像软件工程师一样导航代码库：它遍历文件系统、读取文件、使用 grep 查找所需内容，并跨代码库遵循引用。它运行在开发人员的机器上，不需要构建、维护代码库索引或上传到服务器。

基于 RAG（检索增强生成）的 AI 编码工具通过嵌入整个代码库并在查询时检索相关块来工作。在大规模场景下，这些系统可能会失败，因为嵌入管道无法跟上活跃的工程团队。当开发人员查询索引时，它反映的是几周、几天甚至几小时前存在的代码库。检索可能会返回一个两周前重命名的函数，或引用一个在上次推送中已删除的模块，而没有任何过时的提示。

智能体搜索（Agentic search）避免了这些故障模式。没有需要维护的嵌入管道或集中式索引，因为成千上万的工程师在提交新代码。每个开发人员的实例都基于实时代码库中工作。

但这种方法有一个权衡：当 Claude 有足够的上下文知道去哪里时，它效果最好。这意味着 Claude 的导航质量取决于代码库配置的好坏，即通过 CLAUDE.md 文件和技能来分层上下文。如果你要求它在十亿行代码中查找某种模糊模式的所有实例，你在工作开始前就会触及上下文窗口限制。投入精力进行代码库设置的团队会看到更好的结果。

Harness 与模型同样重要

关于 Claude Code 能力最常见的误解之一是它完全由所使用的模型决定。团队专注于模型的基准测试以及它在任务测试中的表现。实际上，围绕模型的生态系统——即“Harness”——比模型本身更能决定 Claude Code 的表现。

该Harness 由五个扩展点构建——CLAUDE.md 文件、钩子（Hooks）、技能（Skills）、插件（Plugins）和 MCP 服务器——每个扩展点服务于不同的功能。团队构建它们的顺序也很重要，因为每一层都构建在前一层之上。LSP 集成和子智能体（Subagents）完善了整个设置。以下，我们解释了这些组件的功能：

CLAUDE.md 文件优先： 这些是 Claude 在每次会话开始时自动读取的上下文文件：根目录用于全局概览，子目录用于本地约定。它们为 Claude 提供无需任何额外操作即可掌握的代码库知识。因为无论任务是什么，它们都会在每次会话中加载，所以确保它们仅包含广泛适用的内容，可以防止它们成为性能负担。

钩子（Hooks）使设置能够自我改进： 大多数团队认为钩子是防止 Claude 做错事的脚本，但它们更有价值的用途是持续改进。一个停止钩子可以在会话期间反思发生了什么，并提出更新 CLAUDE.md 的建议，同时上下文仍然新鲜。启动钩子可以动态加载特定于团队的上下文，因此每位开发人员无需手动配置即可获得适合其模块的设置。对于像代码检查（linting）和格式化这样的自动化任务，钩子可以确定性地强制执行规则，产生比依赖 Claude 记住指令更一致的结果。

技能（Skills）在不使会话臃肿的情况下实现按需专业知识： 在拥有数十个任务的大型代码库中，并非每个专业知识都需要出现在每个会话中。技能通过渐进式披露（progressive disclosure）解决了这个问题，剥离专用的工作流和领域知识，只有当任务需要时才会加载它们。例如，当 Claude 正在评估安全漏洞时，安全审查技能会加载；当进行代码更改且需要更新文档时，文档处理技能会加载。

技能还可以限定在特定路径上，因此它们仅在代码库的相关部分激活。一个拥有支付服务的团队可以将他们的部署技能绑定到该目录，这样当有人在单体仓库的其他地方工作时，它永远不会自动加载。

插件（Plugins）分发工作成果： 大型代码库面临的一个挑战是良好的设置会变得“部落化”。插件将技能、钩子和 MCP 配置捆绑到一个可安装的包中，这样当新工程师在第一天安装该插件时，他们将立即获得与那些一直使用 Claude 的人相同的上下文和能力。插件更新可以通过托管市场（managed marketplaces）在整个组织内分发。

例如，一家大型零售商与我们合作，构建了一个技能，将 Claude 连接到他们的内部分析平台，以便业务分析师无需离开工作流即可获得性能数据。他们在全面推广前将此作为插件分发。

语言服务器协议（LSP）集成赋予 Claude 与开发人员在 IDE 中相同的导航能力： 大多数大型代码库的 IDE 已经在运行 LSP，支持“转到定义”和“查找所有引用”。将此呈现给 Claude 赋予了它符号级精度：它可以跟踪函数调用到其定义、跨文件跟踪引用，并区分不同语言中名称相同的符号。如果没有这一点，Claude 会进行文本匹配，并可能落在错误的符号上。一家企业软件公司在全面推广 Claude Code 之前，在全公司范围内集成了 LSP，专门用于 C 和 C++ 的大规模导航。对于多语言代码库，这是最具价值的投资之一。

MCP 服务器扩展一切： MCP 服务器是 Claude 如何连接到它原本无法触及的内部工具、数据源和 API。最复杂的团队构建了 MCP 服务器，通过将结构化搜索作为 Claude 可以直接调用的工具来暴露出来。其他人则将 Claude 连接到内部文档、票务系统或分析平台。

子智能体（Subagents）分离探索与编辑： 子智能体是一个拥有自己上下文窗口的隔离 Claude 实例，它承担任务、完成工作，并仅将最终结果返回给父智能体。一旦Harness框架就位，一些团队会启动一个只读子智能体来映射子系统并将发现结果写入文件，然后由主智能体进行全面编辑。

下表总结了每个组件的作用、加载时间以及我们常见于每个组件的错误：

成功部署的三种配置模式

你如何为大型代码库配置 Claude Code 取决于代码库的结构。尽管如此，我们观察到的部署中始终出现三种模式。

使代码库在大规模下可导航

Claude 帮助大型代码库的能力取决于其查找正确上下文的能力。每次会话加载太多上下文会导致性能下降，而加载太少则会使 Claude 盲目导航。最有效的部署会在前期投入，使代码库对 Claude 可读。以下模式始终出现：

• 保持 CLAUDE.md 文件精简且分层。 Claude 在代码库中移动时会累积加载它们：根目录提供大局观，子目录提供本地约定。根目录应仅包含指针和关键注意事项；其余所有内容都会造成噪音。
• 在子目录中初始化，而不是在代码库根目录。 当它被限制在实际开发的代码库部分时，Claude 的工作效果最好。
• 按子目录限制范围和 lint 命令。 当 Claude 更改一项服务时，运行全套测试会导致超时并浪费无关的输出。子目录级别的 CLAUDE.md 文件应指定适用于代码库该部分的命令。这对于具有深度跨目录依赖关系的编译型单体仓库来说，按目录进行范围限制更难实现，且可能需要特定于项目的构建配置。
• 使用 .ignore 文件排除生成的文件、构建产物和第三方代码。 在 .claud/settings.json 中提交 permissions.deny 规则意味着排除项是版本控制的，因此每位开发人员无需自己配置即可获得相同的降噪效果。在某些代码库中，生成的文件本身就是开发工作的对象。开发人员可以在其本地设置中覆盖项目级排除项，而不会影响团队的其他成员。
• 当目录结构无法完成工作时，构建代码库地图。 对于那些没有整理成常规目录结构的组织，一个在 repo 根目录下包含顶层文件夹描述及一行内容摘要的轻量级 markdown 文件，可以在打开文件前提供一个目录索引供 Claude 扫描。对于拥有数百个顶层文件夹的代码库，这种方法作为分层方法效果最好：根文件仅描述最高级别的结构，而子目录 CLAUDE.md 文件在 Claude 遍历目录树时按需提供下一级别的详细信息。对于更简单的情况，通过 @ 引用特定的文件或目录也可以完成同样的工作。
• 运行 LSP 服务器，以便 Claude 按符号而不是字符串进行搜索。 在大型代码库中，针对通用函数名进行 Grep 会返回数千个匹配项，Claude 会消耗上下文文件来找出哪些内容相关。LSP 仅返回指向同一符号的引用，因此在 Claude 读取之前会进行过滤。设置此项需要为你的语言安装代码智能插件和相应的语言服务器二进制文件；Claude Code 文档涵盖了可用的插件和故障排除。

一个警告：存在分层 CLAUDE.md 方法失效的边缘情况，例如拥有数十万个文件夹和数百万个文件的代码库，或非 git 版本控制系统上的遗留系统。我们将在本系列的后续文章中讨论它们的挑战。

随着模型智能的发展积极维护 CLAUDE.md 文件

为当前模型编写的指令可能会在面对未来模型时产生反作用。引导 Claude 遵循其难以处理的模式的 CLAUDE.md 文件，在下一代模型出现时，可能会变得不必要或起到积极的限制作用。例如，一条告诉 Claude 分解每次重构的 CLAUDE.md 规则可能曾帮助旧模型保持在轨道上，但会阻止新模型完成它所处理的更高级的跨文件编辑。

在模型的推理能力或 Claude Code 自身工具的开销变得不再重要时，这些限制就成了负担。一个截获文件写入以在 Perforce 代码库中强制执行 p4 edit 的钩子，在 Claude Code 增加原生 Perforce 模式后变得多余。

团队应预计每三到六个月进行一次有意义的配置审查，但只要在重大模型发布后感觉性能停滞，也值得进行一次审查。

为 Claude Code 的管理和采用分配所有权

仅靠技术配置无法推动采用。那些在组织层面也进行了正确投入的组织获得了成功。

传播速度最快的推广都有专门的基础设施投资，而非广泛的全面开放。一个小团队，有时甚至只有一个人，将工具预先配置好，以便开发人员在第一次接触时就适合他们的工作流程。在一家公司，几名工程师在第一天就构建了一套可用的插件和 MCP；在另一家公司，另一个团队在推广前就准备好了基础设施。在这两种情况下，开发人员的首次体验是富有成效的，而不是令人沮丧的，采用也由此蔓延开来。

今天从事这项工作的团队倾向于位于开发人员体验或开发人员生产力部门，这通常是负责新工程师入职和构建开发工具的职能。几个组织中出现的一个新兴角色是智能体经理（agent manager）：一个混合 PM/工程师职能，专门致力于管理 Claude Code 生态系统。对于没有专门团队的组织，最小可行版本是一个 DRI：一个人拥有对 Claude Code 配置的所有权、对设置、权限策略、插件市场和 CLAUDE.md 约定的批准权，并负责保持它们的更新。

自下而上的采用会产生热情，但如果没有人集中管理，就会变得支离破碎。你需要有一个个人或团队组装并倡导正确的 Claude Code 约定（例如标准化的 CLAUDE.md 层级和精选的技能与插件）。如果没有这项工作，知识将保持部落化，采用也会停滞。

在大型组织中，特别是在受监管的行业，治理问题很早就出现了，例如：谁控制可用的技能和插件，你如何防止数千名工程师独立重复做同样的事情，你如何确保 AI 生成的代码经过与人类生成的代码相同的审查流程？为了尽早解决这些问题，我们建议从一套定义的经批准的技能、必需的代码信心构建开始。

我们观察到，组织中平稳的部署是在早期通过让工程、信息安全和治理代表聚在一起共同定义需求并建立推广路线图来建立跨职能工作组。

将这些模式应用到你的组织

Claude Code 是围绕传统的软件工程环境设计的，工程师是主要的代码库贡献者，且 repo 遵循标准目录结构。大多数大型代码库都符合这一模式，但非传统设置，例如具有大型二进制资产的游戏引擎、具有非常规版本控制的环境，或非工程师参与的代码库，则需要额外的配置工作。我们的指导假设采用常规设置，并且我们观察到的模式在我们的许多客户中都有效。任何剩余的复杂性都需要针对你的代码库、工具和组织进行具体的判断。这就是 Anthropic 的应用 AI 团队直接与工程团队合作，将这些模式转化为适合你组织特定需求的专业知识的地方。

致谢： 特别感谢来自 Anthropic 应用 AI 团队的 Alon Krifcher、Charmaine Lee、Chris Concannon、Harsh Patel、Henrique Savelli、Jason Schwartz、Jonah Dueck 和 Kirby Kohlmorgen 分享他们在规模化部署 Claude Code 方面的经验，并感谢 Zoox 的 Amit Navindgi 对本文提供反馈。

原文链接：https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/16/go-cured-my-over-engineering-addiction-after-java-ts

大家好，我是Tony Bai。

在软件工程的圈子里，有一种病，几乎所有写过几年 Java 或 TypeScript 的程序员都得过，而且往往病得不轻。

这种病叫：“过度设计综合征（Over-engineering Syndrome）”。

症状表现为：当你需要写一个简单的打印功能时，你脑子里第一反应不是写一行 print(“hello”)，而是要去建一个 IPrinter 接口，然后搞一个 PrinterFactory 工厂类，再用依赖注入（DI）容器把一个单例的 ConsolePrinterImpl 塞进去。

美其名曰：为了未来的可扩展性。

结果呢？原本 10 行代码能搞定的事，被你写成了 100 行。半年后你自己回来看，连你都不知道那堆不知所云的接口到底在干嘛。

“在这些语言里，抽象，几乎变成了一项竞技体育。”

就在前几天，Reddit 的 r/golang 社区里，一篇名为《Go 是让我最终停止过度设计的语言》的帖子引发了各社区程序员的共鸣与热烈讨论。

帖子的作者讲述了自己从一个精通“代码杂技”的 TS/Java 老兵，在被 Go 语言“毒打”后，最终获得技术救赎的心路历程。

今天，我们就来看看 Go 语言究竟用了什么“黑魔法”，硬生生地把一群热衷于炫技的代码极客，改造成了最纯粹的实用主义者。

痛苦的戒断反应：当语言对你说“不”

原作者在帖子开头，极其生动地描述了他初遇 Go 语言时的崩溃感。

作为一个在 TS 生态里如鱼得水的老兵，他习惯了用各种高级特性去把代码写得“非常聪明（Clever）”。但当他在一个业余项目中开始使用 Go 时，他发现这门语言简直是个“直男”：

“没有继承，没有魔法，没有花里胡哨的元编程技巧，甚至连个像样的通过注解实现的 DI 容器都没有。起初，这感觉就像是在束缚我，就像被迫只用一只手打字。”

这几乎是所有高级语言开发者转向 Go 时的第一反应。你满脑子都是各种华丽的设计模式，但 Go 的编译器冷酷地告诉你：“对不起，这里不准炫技。”

你试图用多层继承来复用代码？Go 说不行，用组合。

你试图用 AOP（面向切面编程）来统一处理日志？Go 说不行，老老实实写中间件包裹函数。

你试图为了某个可能永远不会到来的需求提前写个抽象接口？Go 社区的规范告诉你：等你需要多个实现的时候再写，不要提早抽象！

在这个阶段，开发者往往会感到极度的痛苦和不适。因为他们赖以生存的、用来彰显自己“技术水平很高”的工具被彻底没收了。

顿悟的时刻：笨拙的胜利

然而，奇妙的事情在大约一个月后发生了。

作者写道：

“我的大脑突然‘翻转’了。我停止了试图在 Go 里玩那些聪明的 Java 技巧，开始老老实实地用 Go 的方式（boring go thing）做事。

突然之间，代码变得极其容易阅读。不仅仅是我的代码，我看过的每一个 Go 开源代码库，我都感觉阅读速度快得飞起。因为当你想要搞清楚它做了什么时，你只要找到它，就完了，你可以继续前进。”

这正是 Go 语言最核心的杀手锏：“代码可读性（Readability）”的降维打击。

在重度抽象的代码库中，逻辑是碎片化的。一半的代码是业务，另一半的代码是为了连接这些业务而存在的“管道（Plumbing）”。你为了追踪一个请求，可能要跳转 5 个接口定义和 3 个隐式绑定的工厂类。

而在 Go 里，一切都是直白的、平铺开的（Flat）。虽然你可能多写了几次同样的循环，多写了几遍看起来有点啰嗦的代码，但你永远不需要在一个又一个的接口跳转中迷失方向。

评论区里，一位开发者给出了一个让所有人拍案叫绝的回答：

“作为一个首席工程师，我现在的目标是：写出来的代码，必须要让一个初级工程师（Junior）觉得平易近人。我不在乎是否有一个更‘酷炫’的方法。一个初级工程师必须能接手我的工作并继续跑下去。所以，我遵循 KISS 原则（Keep It Simple, Stupid）。”

最牛逼的代码，不是写得像天书，而是写得像刚毕业的实习生也能一眼看懂的大白话。

争议的核心：“烦人的”错误处理，其实是防弹衣

当然，这场大讨论中不可避免地提到了 Go 语言常年被喷的最大痛点：满屏的 if err != nil { return err }。

习惯了 try-catch 一把梭的开发者觉得这简直是冗余的体力活。

但真正经历过生产环境毒打的老兵们，却对这种“烦人”的设计感恩戴德。

一位开发者的反思极其深刻：

“对我来说，转变最大的是错误处理。一开始那些 if err != nil 的样板代码看起来真的很蠢。直到你意识到：它强迫你主动思考可能发生的每一个单一的故障点，而不是像在那些支持异常（Exceptions）的语言里那样，抛出异常栈，然后祈祷上层有个 try/catch 把它接住。

这是一个正确的权衡（Right tradeoff）：它让代码写起来慢，但读起来极其清晰。”

在 Java 里，一个未被捕获的异常可能在离案发地十万八千里的地方爆炸，留下一堆毫无线索的 Stack Trace。

而在 Go 里，每一个错误都像是一个显式的返回值，它逼着你在案发现场做出决定：是降级处理、是打日志、还是直接抛给上层。

这种在编码阶段的“精神折磨”，换来的是在凌晨三点排查线上故障时的“心如止水”。

反思：语言塑造思维

在讨论的末尾，原作者提到了一个极其令人震撼的个人体验：

“最巨大的好处发生在 6 个月后。我打开了一个我几个月没碰过的 Go 服务，我居然在 20 分钟内就完全找回了状态。这在我以前用其他语言自己写的代码库里，是从未发生过的！”

这段话，道出了软件工程最残酷的真相。

在现实的商业世界中，代码被“读”的次数，远远大于被“写”的次数。我们今天为了“炫技”和“偷懒”而引入的复杂抽象，在未来都会变成自己或同事头上高悬的达摩克利斯之剑。

Go 语言的伟大之处，不在于它提供了多么强大的功能，而在于它用编译器级别的强制力，物理切断了程序员走向过度设计的退路。

它就像一个严肃的教练，时刻在你耳边咆哮：

• “别搞继承了，给我用组合！”
• “别提前抽象了，等你复制了三遍同样的逻辑再去重构！”
• “别隐藏错误了，给我老老实实写 if err != nil ！”

正如评论区那句精辟的总结：“Java 教会了我抽象，而 Go 教会了我停止抽象。”

小结

最好的工具，永远是那个不会在你偶尔一拍脑袋想炫技时，配合你演出的工具。

当我们褪去年轻时对各种花哨设计模式的盲目崇拜，回归到用代码解决商业问题的本质时，你会发现，Go 语言那看似平庸的“笨拙”，正是它能撑起云原生时代半壁江山的终极底气。

在这个大模型开始疯狂自动生成代码的时代，Go 那种一眼望到底的清晰逻辑，更将成为人类审查 AI 代码时，最坚固的一道防线。

简单，才是不可被轻易击败的复杂。

资料链接：https://www.reddit.com/r/golang/comments/1t9fyfp/go_is_the_language_that_finally_made_me_stop/

今日互动探讨：

在你的编程生涯中，你有没有写过让你后来自己看都觉得“用力过猛”的过度设计代码？你觉得 Go 语言这种强行压制抽象的设计哲学，是保护了团队，还是扼杀了创造力？

欢迎在评论区分享你的血泪史与感悟！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/14/uncle-bob-esr-on-why-we-are-turning-to-go-and-rust-in-the-ai-era

大家好，我是Tony Bai。

在软件工程的浩瀚星河中，有两位堪称“活化石”级别的宗师：

一位是 Eric S. Raymond (ESR)，开源运动的先驱，那本被誉为开源圣经的《大教堂与集市》以及《Unix编程艺术(The Art of UNIX Programming)》一书均是出自他手。他是一个写了 40 年 C 语言的硬核黑客。

另一位是 Uncle Bob Martin (Bob 大叔)，敏捷宣言的签署人之一，《敏捷软件开发》、《代码整洁之道 (Clean Code)》等程序员经典书籍的作者，无数 Java 和 C# 程序员的精神导师。

这两位加起来写了快一百年代码的传奇人物，最近却在 X (Twitter) 平台上，不约而同地抛出了一个足以引发技术圈大地震的论断：

在如今这个被 AI 席卷的时代，他们双双放弃了自己曾经最擅长的语言（C 和 Java），转而全面拥抱 Go 语言，并在特定底层场景下使用 Rust。

更令人震撼的是，ESR 直接宣告了手工古法编程模式的死刑：

“手写代码的时代基本结束了（The age of hand-coding is mostly over）。现在选择编程语言的标准，已经彻底变了。”

今天，我们就来深度扒开这场顶级黑客的“赛博夜话”，看看在 AI 智能体（Agent）狂飙突进的 2026 年，我们究竟该如何重新审视和选择我们手中的“兵器”。

认知颠覆：当 AI 成为主程序员，语言的选择标准变了

我们过去是如何选择编程语言的？

语法是否优雅？生态是否繁荣？框架是否齐全？这些都是基于“人类如何高效手写代码”而设定的标准。

但 ESR 尖锐地指出，在如今我们拥有“机器朋友（Robot friends / AI）”来完成绝大部分代码生成和翻译工作的时代，这些旧标准已经失效了。

现在的核心标准只有两个：

1. 你的 AI 朋友，能不能高质量地生成这种语言的代码？
2. 生成之后，作为人类的你，能不能一眼看懂（Review）这些代码？

“如今，我使用什么计算机语言是否顺手，已经不再那么重要了，真正重要的是我正在使用的‘机器朋友’能否高质量地生成它。
同时也重要的是我能否读懂这门语言，因为我需要亲自去审查（Review）这些代码。”

在这个新标准下，那些充满了黑魔法（如各种奇葩的宏、复杂的继承体系、极度隐晦的元编程）的语言，瞬间成了灾难。因为当 AI 吐出几百行充满魔法的代码时，人类审查的“认知负荷”将是灾难性的。

宗师的抉择：为什么是 Go 和 Rust？

在这个全新的游戏规则下，两位宗师给出了他们惊人一致的答案。

Bob 大叔的 Go 语言初体验：快、无聊、但完美契合 AI

Bob 大叔在评论区透露，他正在设计一门关于“使用 Agent 进行软件工程”的在线课程。

“在过去，我会选择像 Java、C# 或 JavaScript 这样流行的语言来做课程。但这次我选择了 Go。不是因为它流行，而是因为它很快（Fast）。我的学生们不会花太多精力去钻研 Go 的语法细节，但他们会看到 Go 的表现。”

Go 语言那常被诟病的“啰嗦”和“无聊”，在 AI 时代反而成了最强大的护城河。

因为 Go 的语法极度收敛，没有隐式类型转换，没有复杂的泛型继承。当 AI 生成一段 Go 代码时，那满屏极其直白的 if err != nil，让人类工程师一眼就能看穿它的逻辑底裤。在审查 AI 代码时，没有魔法，就是最高的生产力。

ESR 的决断：别了，我写了 40 年的 C 语言

ESR 的话更具传奇色彩和悲壮感：

“我可能再也不会用 C 语言开新项目了。那除了自虐还有什么意义？我花了 40 年写 C，我非常精通。但我会毫不留恋地把它，连同它的缓冲区溢出、堆破坏、未定义行为和可移植性问题，全部抛在脑后。”

他现在的探索性编程，全部交给了 Python 或 Go。

“我的机器朋友在生成这两种语言的代码时都非常出色。我认为它们在生成 Go 代码时的表现甚至略胜一筹，这可能是因为 Go 语言拥有更小的表面积（smaller surface）。”

(注：Smaller surface 意味着语法简单，AI 预测下一个 Token 时的歧义和错误率极低)

至于 Rust，ESR 将其定位为“终极的降落场”。

当他需要极其坚固的内存安全保证，且代码的探索期已经结束，进入严肃的生产部署阶段时，他会让 AI 把代码翻译成 Rust。

“Rust 满足了我的要求——我发现它写起来很麻烦，但读起来基本没问题。”

时代的阵痛：被 AI 降维打击的传统生态

这场讨论，不仅是对 Go 和 Rust 的赞歌，更是对一些传统“大厂语言”的残酷揭底。

ESR 毫不客气地吐槽了 Python 曾经的混乱（尽管它现在有了类型提示和 uv 等现代工具，情况有所好转）：

“Python 曾是我的最爱，但在 Python 2 到 Python 3 的灾难性过渡、GIL 导致的并发地狱、以及包管理的混乱之后，我曾对它感到厌倦……如果我现在要写一个比 Python 粘合脚本大得多的东西，我只会耸耸肩，然后直接去用 Go。”

在推特的评论区，另一位开发者的一句话，道出了更多人的心声：

“Go 代码的质量，很大程度上是因为 Go 语言本身往往倾向于极高的质量（因为缺乏炫技的空间）。所以 AI 生成的代码，也顺理成章地继承了这种高质量。”

当一门语言为了迎合人类的“偷懒”和“炫技”而变得越来越复杂时（比如不断叠加新特性的 C++ 和 Java），它在 AI 时代反而会成为一种累赘。

因为 AI 不需要语法糖，AI 需要的是绝对的清晰和确定性。

反思：从“写手”到“审查员”的身份跃迁

两位古灰级黑客的这番言论，给所有还在为了“哪种语言的特性更酷炫”而争得面红耳赤的年轻程序员，狠狠地上了一课。

时代的列车已经呼啸而过。

当代码生成不再是瓶颈，软件工程师的核心价值，正在不可逆转地从“Writer（编写者）”向“Reader & Reviewer（阅读者与审查者）”迁移。

在这个新时代，我们评估一项技术的眼光必须升级：

1. 可审计性（Auditability）大于一切：如果一段代码极其简洁但难以调试，它就是垃圾。Go 语言的“直白”，在 AI 时代成为了最顶级的安全感。
2. 安全性的底座转移：像 Rust 这样通过极其严苛的编译器来保证内存安全的语言，将成为 AI 时代最可靠的“数字基础设施钢筋”。你可能不需要手写它，但你的 Agent 会为你生成它，并由编译器确保它不会在半夜崩溃。
3. 拥抱“机器思维”：放下程序员的“文人相轻”，接受那些对机器友好、对审查友好的“无聊技术”。

小结：向宗师致敬，向未来前行

如果连写了 40 年 C 语言的 Eric S. Raymond，和开创了现代软件工程思维的 Uncle Bob，都能毫不犹豫地放下过去的骄傲，全身心地拥抱 AI、Go 和 Rust。

我们这些普通开发者，还有什么理由紧抱着那些陈旧的“鄙视链”不放呢？

手写代码的时代正在落幕，但软件工程的黄金时代，才刚刚开始。

用 Go 来快速验证和构建业务，用 Rust 来打造坚不可摧的底层，让 AI 成为那个不知疲倦的打字员。这，就是顶级黑客们为我们指明的 2026 年生存法则。

资料链接：https://x.com/esrtweet/status/2054288478750597593

今日互动探讨：

连 Bob 大叔和 ESR 都倒戈了！你同意他们“手写代码时代已结束”、“更看重代码审查的可读性”的观点吗？在日常的 AI 辅助编程中，你觉得哪种语言的体验最好？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/13/go-mod-hidden-features-7-secret-switches-in-go-version

大家好，我是Tony Bai。

在这个“CV 工程师(复制粘贴工程师)”盛行的时代，很多 Go 开发者在新建项目时，不会使用go mod init来初始化一个模块，而是会熟练地从别的 go.mod 文件里，复制粘贴那行 go 1.xx，或者直接复制一个starter 脚手架Go 工程。我们似乎都默认了go.mod中go 1.xx 的作用——“嗯，就是声明一下我用的 Go 版本嘛，不重要。”

我们可能会花几天时间去争论 GOMAXPROCS 该设成多少，或者为了一个微小的性能优化而重构代码，但很少有人会去深究这行看似“平平无奇”的指令，到底在 Go 的世界里扮演着怎样的角色。

但如果我今天告诉你，这行被我们忽视了近 8 年的“魔法咒语”，在 Go 工具链的底层，其实悄悄地控制着多达 7 个维度的编译和运行时行为呢？

从你能不能用泛型，到 go mod tidy 的工作模式，再到你的程序在生产环境中的默认行为……这一切，都由这行代码说了算。

最近，我扎进了 Go 语言的源码，试图去解开这个“最熟悉的陌生人”的秘密。而我发现的真相，足以颠覆多数 Gopher 的认知。

今天，就让我们来一场硬核的“源码考古”，逐一拆解这行 go 指令背后的七大用途。

go directive 是什么

go.mod 中的 go directive 格式如下：

go 1.21.0

它由 golang.org/x/mod/modfile 包解析，并存储在 modfile.File.Go.Version 字段中。

// $GOROOT/src/cmd/vendor/golang.org/x/mod/modfile/rule.go
type Go struct {
    Version string // "1.23"
    Syntax  *Line
}

有趣的是，如果你的 go.mod 文件里没有这一行（比如一些远古项目），Go 工具链并不会报错，而是会默默地为你应用一个默认值：go 1.16。

// $GOROOT/src/cmd/go/internal/gover/version.go
const DefaultGoModVersion = "1.16"

为什么是 1.16 这个看起来有点奇怪的数字？Go 源码的注释给了我们答案：

因为 Go 1.17 对模块图的语义进行了重大修改。为了保证对那些没有 go 指令的、极其古老的项目的兼容性，我们必须保守地假设它遵循 Go 1.16 的规则。这个默认值，永远不会再被提高了。

这背后，体现了 Go 团队对“向后兼容性”近乎偏执的坚守。

用途一：语言版本的“守门人”（最核心）

这是 go 指令最广为人知、也是最直接的作用：它决定了编译器允许你使用哪些语言特性。

在 Go 的源码深处，go 命令在编译每个包时，都会将 go.mod 中定义的版本号，通过 -lang 标志，像一道“圣旨”一样传递给编译器。

// $GOROOT/src/cmd/compile/internal/noder/irgen.go
conf := types2.Config{
    GoVersion: base.Flag.Lang,  // 来自 -lang 标志，由 go.mod 的 go directive 决定
    ...
}

编译器内部的类型检查器，会用一个名为 allowVersion 的函数，来判断你写的某段代码，是否“越界”使用了当前版本还不支持的“未来语法”。

// $GOROOT/src/cmd/compile/internal/types2/version.go
func (check *Checker) allowVersion(want goVersion) bool {
    return !check.version.isValid() || check.version.cmp(want) >= 0
}

经典案例：Go 1.22 的 for 循环变量“拨乱反正”

Go 1.22 修复了 for 循环变量在闭包中常年为人诟病的“共享变量”问题：

// go.mod: go 1.21  → 旧语义，所有迭代共享同一变量
// go.mod: go 1.22  → 新语义，每次迭代独立变量

而这个行为的开关，正是由 go 指令严格控制的。

// 示例：
// 当 go.mod 中是 go 1.21 时，以下代码会打印 3 个 "3"
// 当 go.mod 中是 go 1.22 时，以下代码会打印 0, 1, 2
funcs := make([]func(), 3)
for i := 0; i < 3; i++ {
    funcs[i] = func() { fmt.Println(i) }
}

for _, f := range funcs {
    f()
}

这意味着，仅仅是修改 go.mod 里的一行数字，就可能让你的程序的输出结果发生根本性的变化！

其他受Go 版本控制的语言特性一览

如果你试图在 go 1.21 的模块里写 for i := range 10，编译器会毫不留情地报错，并清晰地告诉你：“检查你的 go.mod 文件！”

用途二：模块图裁剪(Module Graph Pruning)的“总开关”

这是 Go 1.17 引入的一项重要优化，它彻底改变了 Go 命令解析依赖图的方式，但很多开发者对此却知之甚少。

在 Go 的源码中，1.17 被定义为一个分水岭：

// src/cmd/go/internal/gover/version.go
ExplicitIndirectVersion = "1.17"  // 启用图裁剪的版本

go.mod 中的版本号，将决定你的项目采用哪种依赖图模式：

// $GOROOT/src/cmd/go/internal/modload/modfile.go
func pruningForGoVersion(goVersion string) modPruning {
    if gover.Compare(goVersion, gover.ExplicitIndirectVersion) < 0 {
        return unpruned  // < 1.17：加载完整传递依赖图
    }
    return pruned        // >= 1.17：启用图裁剪
}

go < 1.17（完整模式 Unpruned）：

• go.mod 文件里只需要列出你的直接依赖。
• 但代价是，每次构建时，Go 命令都需要递归地、完整地加载所有传递依赖（A 依赖 B，B 依赖 C，C 依赖 D……）的 go.mod 文件，构建一个庞大的、完整的依赖图。这在大型项目中，极其缓慢。

go >= 1.17（裁剪模式 Pruned）：

• go.mod 文件里必须显式地列出所有传递依赖，哪怕它们是间接的。这就是你经常看到的 // indirect 标记的由来。
• 好处是，Go 命令在构建时，可以“偷懒”，只读取直接依赖的 go.mod 文件，而对那些未真正使用的间接依赖进行“裁剪”，从而极大地加快了构建速度，并增强了构建的可重现性。

# go 1.17+ 的 go.mod 示例：间接依赖被显式列出
require (
    github.com/some/direct v1.2.3  

    github.com/indirect/dep v0.1.0 // indirect  ← 1.17+ 才会出现
)

用途三：all 模式的“结界”

go test all 这样的命令，在不同的 Go 版本下，其“all”所覆盖的范围，竟然是不同的！而这个“结界”的开关，同样是 go 指令。

在源码中，1.16 是另一个分水岭：

这个改动非常微妙，但影响深远。它意味着在 Go 1.16 之后，go test all 不再会因为某个你八竿子打不着的、间接依赖的测试代码写错了而失败，让 all 模式变得更加聚焦和实用。

用途四：GODEBUG 运行时行为的“默认存档”

这是 Go 1.21 引入的最具“魔力”，也最危险的一个特性：go 指令，决定了你的程序在生产环境中的 GODEBUG 默认值！

Go 团队为了在不破坏向后兼容性的前提下，修复一些语言的历史包袱（比如 panic(nil)），引入了 GODEBUG 环境变量。

当编译器在构建你的 main 包时，它会检查 go.mod 里的版本号，然后将一套与该版本行为相匹配的 GODEBUG 默认值，直接编译进你的二进制文件里。

// $GOROOT/src/cmd/go/internal/load/godebug.go
func godebugForGoVersion(v string) map[string]string {
    // ...
    def := make(map[string]string)
    for _, info := range godebugs.All {
        if n < info.Changed {
            def[info.Name] = info.Old  // 使用旧版本的默认值
        }
    }
    return def
}

经典案例：

• 如果你的 go.mod 写的是 go 1.20，那么你的程序在运行时，会默认 panicnil=1（允许 panic(nil) 这种旧的、不规范的行为）。
• 但如果你把它改成 go 1.21，那么程序的默认行为就会变成 panicnil=0（panic(nil) 会在运行时直接报错）。

官方文档说得很清楚：

Go 工具链会修正自己的默认行为，以尽可能地匹配你声明的旧版本。

这意味着，升级 go 指令，是一项具有潜在风险的操作。 它可能在你不经意间，改变程序的运行时行为。

用途五：Toolchain 自动切换的“指挥官”

从 Go 1.21 开始，你的电脑上可以同时安装多个 Go 版本。而决定在编译某个特定项目时，到底该用哪个版本的“指挥官”，就是 go 指令。

当你的 GOTOOLCHAIN 环境变量设为 auto 时，go directive 会触发自动工具链切换。

// $GOROOT/src/cmd/go/internal/toolchain/select.go
if gover.Compare(goVers, minVers) > 0 {
    gotoolchain = "go" + goVers
    // ...
    gover.Startup.AutoGoVersion = goVers
    // 打印：go: upgrading toolchain to goX.Y.Z (required by go line in go.mod)
}

下面是一个示例：

# go.mod
module example.com/myapp
go 1.23.0

# 你的电脑当前默认安装的是 go1.21.0
# 当你在这个项目下运行 go build 时……
# → Go 命令会发现版本不匹配，自动去下载并切换到 go1.23.0 工具链！
# 并打印：go: upgrading toolchain to go1.23.0 ...

同时，Go 1.21 还引入了“严格版本约束”：一个 go 1.21+ 的模块，其 go 指令版本，必须 大于或等于 它所有依赖模块的 go 版本。

// $GOROOT/src/cmd/go/internal/gover/version.go
// GoStrictVersion is the Go version at which the Go versions became "strict"
// in the sense that every module must have a go version line ≥ all its dependencies.
GoStrictVersion = "1.21"

用途六 & 七：Vendor 模式与 go mod tidy 的“幕后推手”

除了上述几大核心用途，go 指令还在一些细节上，扮演着“幕后推手”的角色。

Vendor 模式

从 Go 1.17 开始，go mod vendor 会在 vendor/modules.txt 文件里，为每一个依赖项记录其 go 版本：

## explicit; go 1.17

这确保了即使在离线 vendor 模式下，编译器也能为每个包应用正确的语言特性。

# go.mod: go 1.16 → vendor/modules.txt 不含版本信息，统一猜测为 1.16
# go.mod: go 1.17 → vendor/modules.txt 含版本信息，每个包用自己的版本

go mod tidy的行为

go 指令的版本，还会影响 tidy 命令在依赖保留范围、go.sum 校验范围、以及间接依赖分组显示等方面的细微行为。

1. 保留的依赖范围

// $GOROOT/src/cmd/go/internal/modcmd/tidy.go
// Go versions 1.17 and higher retain more requirements in order to
// support lazy module loading.

2. go.sum 的校验范围

// $GOROOT/src/cmd/go/internal/gover/version.go
// TidyGoModSumVersion is the Go version at which 'go mod tidy' preserves
// go.mod checksums needed to build test dependencies of packages in "all"
TidyGoModSumVersion = "1.21"

3. 间接依赖的分组显示

SeparateIndirectVersion = "1.17"
// go >= 1.17：// indirect 依赖单独成块

小结：一行代码背后的“架构演进史”

看到这里，你还会觉得 go 1.xx 只是一行简单的版本声明吗？

这短短的一行代码，像一根时间线，串联起了 Go 语言从诞生到成熟的整个演进历史。

go directive
    │
    ├─ 编译器 -lang 标志
    │       └─ 控制语言特性（泛型/loopvar/range整数...）
    │
    ├─ 模块图裁剪模式
    │       ├─ < 1.17：unpruned（完整传递依赖图）
    │       └─ >= 1.17：pruned（显式间接依赖 + 图裁剪）
    │
    ├─ "all" 模式范围
    │       ├─ < 1.16：包含外部包的测试依赖
    │       └─ >= 1.16：仅主模块的传递导入
    │
    ├─ GODEBUG 运行时默认值
    │       └─ 编译进二进制，影响运行时行为
    │
    ├─ Toolchain 自动选择（>= 1.21）
    │       └─ GOTOOLCHAIN=auto 时触发工具链下载/切换
    │
    ├─ vendor/modules.txt 版本记录（>= 1.17）
    │       └─ 影响 vendor 模式下的语言版本应用
    │
    └─ go mod tidy 行为
            ├─ 依赖保留范围
            ├─ go.sum 校验范围
            └─ 间接依赖分组

它既是语言特性的“守门人”，又是模块系统的“总开关”，还是运行时行为的“默认存档”。

它身上，凝聚了 Go 团队对向后兼容性、工程效率、可重现性这三大核心哲学最深刻的思考与权衡。

下一次，当你新建一个项目，或者准备升级 go.mod 里的那个版本号时，请务必三思。

因为你修改的，不仅仅是一个数字，而是你与 Go 工具链之间，一份极其重要、且牵一发而动全身的“契约”。

今日互动探讨：

在你的日常Go编程中，你有没有遇到过写错Go version带来的“坑”？你觉得 Go 语言go.mod中的go version用起来怎样？是否还有改进的地方。

欢迎在评论区分享你的血泪史与感悟！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/10/scaling-uber-with-thuan-pham

大家好，我是Tony Bai。

在硅谷的黄金时代，曾有一家公司以一种近乎“暴力”的美学，重新定义了增长的速度。它的名字叫 Uber。

在最癫狂的岁月里，它以“周”为单位攻占新的城市，用海量的资本和补贴点燃市场，其业务增长曲线陡峭得如同悬崖峭壁。

但在这场增长的狂欢之下，是一套摇摇欲坠、濒临崩溃的技术系统。

2013 年，当 Tuan Pham（后来被称为 Uber 的“救火队长”）加入时，这家拥有 40 名工程师的公司，系统每周都会崩溃数次。而他面临的第一个挑战，就是公司的核心派单系统，只剩下 5 个月的寿命。

近日，这位传奇 CTO 接受了一次深度访谈。他不仅首次揭秘了当年与创始人 Travis Kalanick (以下称TK) 长达 30 小时的“魔鬼面试”，更详细复盘了 Uber 是如何在失控的边缘，被迫走上那条被全网群嘲、却又别无选择的 “5000 微服务” 之路。

今天，就让我们跟随 Tuan 的视角，重返那个硝烟弥漫的战场。

从船民到 MIT：一段关于生存的开端

Tuan Pham 的人生开局，堪称地狱模式。

他出生于越南，是战争的亲历者。1975 年后，由于家庭背景，他和家人被迫成为“越南船民”，挤在破旧的渔船上，冒着不足 50% 的生还率，在深夜逃离故土。

在海上漂泊了四天三夜，躲过风暴和海盗，他们最终在马来西亚登陆，却又被拖回大海，最终被印尼的一个荒岛收留。

一年后，他们以难民身份来到美国。身无分文，不懂英语，第一套衣服来自教堂的捐赠衣橱。

“生存”，是刻在他骨子里的第一性原理。

和很多技术天才一样，Tuan 在数学上展现了过人的天赋。高中时，他靠着一台有两个软盘的 IBM PC 自学了编程，甚至用脚本语言帮政府机构把需要 3 周才能完成的财务对账工作，压缩到了 3 小时。

凭借着优异的成绩和推荐信，他被 MIT 录取，正式开启了他的计算机科学之旅。

血泪的教训：两场失败，塑造了 Uber 的基因

在加入 Uber 之前，Tuan 的职业生涯并非一帆风顺。但正是这些宝贵的“失败”，让他积累了足以驾驭 Uber 这头巨兽的认知。

第一场失败，在 SGI（硅谷图形公司）。

上世纪 90 年代，他参与了一个极其超前的项目——交互式电视。在那个连手机和互联网都还没普及的年代，他们已经实现了“视频点播、在线购物”。斯皮尔伯格、迈克尔·杰克逊都来参观过。但这个项目最终惨败，因为机顶盒的成本高达 4.5 万美元。这让他得到一条教训：光有伟大的技术没用，你必须在正确的时间、以正确的价格，出现在正确的市场。

第二场失败，在 NetGravity（一家互联网广告公司）。

他们发明了动态广告系统，并成功上市。但另一家比他们晚成立的公司，靠着更轻量的“广告服务（Ad Service）”模式，野蛮生长，最终被 Google 收购。而他们，因为董事会要求“优先盈利”，错失了市场。这让他得到了另外一条教训：当市场窗口期出现时，增长速度压倒一切，哪怕是以亏损为代价。

这两条从真金白银和血泪中总结出的铁律，仿佛就是为日后的 Uber 量身定制的。

30小时的“魔鬼面试”：与 TK 的灵魂拷问

离开 VMware 后，Tuan 并未主动寻找工作。是 Benchmark 的传奇投资人 Bill Gurley（也是 Uber 的早期投资人）找到了他。Bill Gurley 认识 Tuan，源于十几年前那家失败的广告公司。

Tuan 在访谈中反复强调一个观点：

“我从不刻意经营人脉。你只需要把你手头的每一份工作做到极致，真诚地对待你身边的每一个人。随着时间推移，你的声誉会为你打开所有的大门。”

当他见到 Uber 的创始人 Travis Kalanick (TK) 时，一场长达 30 小时、横跨两周的马拉松式面试开始了。

TK 在白板上写下了密密麻麻的清单：从招聘开除、到代码质量、再到团队文化……他们每天 Skype 两小时，一个一个地辩论。

Tuan 回忆道，那根本不像面试，更像是两个合伙人在激烈地碰撞思想。有一次，聊到一半 TK 要赶飞机，他直接拿起电话让助理改签，然后继续辩论。

T.K. 对技术细节的痴迷，和近乎偏执的激情，让 Tuan 意识到，这是一个将技术视为公司命脉的创始人。

面试的最后，Tuan 发现，这 30 小时其实是一场“模拟工作”。TK 在用最高成本的方式，去观察当他们意见相左时，是否还能有效地沟通、并最终达成共识。

微服务之殇：我们根本不想搞 5000 个微服务！

Tuan 加入 Uber 时，公司只有 40 个工程师，但系统每周都会宕机数次。整个后端是一个巨大的单体应用，派单系统是用单线程的 Node.js 写的。为了扩容，工程师们只能不断地把程序挪到 CPU 更快的机器上（垂直扩容）。

Tuan 问团队：“如果最快的 CPU 也扛不住了怎么办？”

工程师说：“那就换一个有多颗 CPU 的机器。”

Tuan 再问：“那这些进程之间怎么共享状态？”

团队沉默了。

Tuan 迅速算出，当时最大的城市纽约，将在 5 个月后彻底冲垮派单系统的物理上限。

重写，是唯一的活路。

他只提了两个要求：1. 一个城市必须能被多台机器支撑；2. 一台机器必须能支撑多个城市。 没有新功能，只要活下去。

最终，团队在 8 月份惊险上线了新系统，暂时续上了命。

但真正的噩梦，来自那个名为 API 的巨型单体应用。随着业务的爆炸式增长（UberX 上线、新城市扩张），这个单体应用成了所有团队的瓶颈。任何一个新功能，都可能要排队等好几个团队的开发资源。

为了活下去，Tuan 和 TK 做出了那个后来被全行业“群嘲”的决定：

“任何新功能，一律不许再往单体里加！必须作为独立的服务（Microservice）去开发。”

同时，成立一个专门的团队，去把旧的单体应用一块块“拆骨”。

这个拆骨项目，代号“达尔文（Darwin）”。Tuan 苦笑道，如果时间静止，这个项目 3-6 个月就能搞定。但他们花了整整两年。

因为在他们拆解的同时，业务的增长速度比他们拆解的速度还要快！新功能被疯狂地加回到那个正在被拆的单体里。

“当你把一块代码剥离出去后，剩下的部分因为业务增长，变得比你剥离出去的还要大。我们就像在追着自己的尾巴跑。”

5000 个微服务，不是一个被精心设计出来的架构蓝图。它是在极端增长压力下，为了让几百个工程师能够并行开发、不互相阻塞，而被迫做出的“最不坏”的选择。

这是 Uber 用每年几亿美元的服务器成本，换来的开发速度。

中国速度：两个月，拿下中国市场

在 Uber 的历史上，最能体现这种“速度压倒一切”文化的，莫过于 2014 年底的“中国闪击战”。

圣诞节前，TK 宣布：新年过后，Uber 要全面进军中国。他给了 Tuan 两个月的时间，在中国本土，从零开始搭建一套完整的、物理隔离的数据中心。

Tuan 的工程团队评估后，给出的最快时间是 6 个月。他在湾区的朋友们听说后，都嘲笑他疯了：“没有 18 个月根本不可能。”

TK 不接受，最终两人“折中”到了 4 个月。

4 个月后，项目延期了。TK 很不爽。

5 个月后，项目再次延期。TK 暴怒。

Tuan 对 TK 承诺，再给一个月，但必须允许他们“分阶段上线”，而不是一次性点亮所有城市。

TK 同意了，但提了一个极其苛刻的条件：第一个上线的，必须是当时业务量最大的城市——成都。

Tuan 在访谈中回忆道，这在当时看来简直是自杀，但事后回想，这是 TK 做出的最天才的决定。

“当你把最硬的骨头啃下来之后，剩下的就全是下坡路了。整个团队的士气和信心都被拉满了。”

最终，他们真的做到了。IT 团队在两周内完成了服务器的跨国部署，软件团队在无数个通宵后，让代码在中美两地同时跑了起来。

没有人认为这能成功，但它就是成功了。 这就是 Uber 当时的魔力。

小结：AI 时代的生存法则

在访谈的最后，Tuan 聊到了如今最火热的 AI 编程。

他所在的新公司 FAIR，已经开始使用 Agent Swarm（智能体集群） 来辅助开发。他发现，顶级的工程师在使用 AI 后，产出能翻倍。

当被问及“AI 时代，如何区分优秀与平庸的工程师”时，Tuan 的回答，与他在 Uber 血战时总结出的经验如出一辙：

“好奇心、无畏、愿意尝试新事物、敢于打破常规。这些特质，在过去能让你脱颖而出，在今天，同样能让你成为驾驭 AI 的顶级玩家。平庸的人把 AI 当拐杖，而优秀的人把 AI 当作火箭推进器。”

从越南船民到硅谷之巅，Tuan Pham 的一生，就是一部关于“在混乱中寻找秩序，在极限压力下野蛮生长”的史诗。

Uber 的故事或许不可复制，但它留给我们的思考，远未结束。

在技术的世界里，从来没有完美的架构，只有与业务增长阶段相匹配的、充满妥协与权衡的草台班子。

而我们作为工程师的终极使命，就是在这个草台班子上，用最快的速度，把它搭成别人眼中坚不可摧的罗马。

今日互动探讨：

看完 Uber 的故事，你觉得在你的公司里，是应该优先选择“技术正确”的完美架构，还是“能快速上线”的野路子？你对微服务和单体架构有什么切身体会？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将>带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/05/ai-makes-everyone-a-developer-like-cameras-for-photographers

大家好，我是Tony Bai。

最近，在技术圈里流传着一个“非主流观点（Unpopular Opinion）”：

“‘AI 让每个人都成了开发者’，这句话是真的。就像当年‘相机的发明，让每个人都成了摄影师’一样。”

这句充满“内涵”的类比，在 Reddit、X 等社区引来了开发者的热议。它精准地戳中了所有专业开发者心中最深的隐忧：当 AI 将编程的门槛夷为平地，我们这些苦练了十几年“内功”的“老师傅”，还有存在的价值吗？

就在前几天，r/webdev 论坛上，一篇名为《我刚围观了一个非开发者用 AI Vibe-Coding 的全过程……兄弟们，我们稳了》的帖子，用一个极其生动、甚至有些滑稽的真实案例，为这个“灵魂拷问”给出了一个参考答案。

今天，我们就来复盘这场关于“技术平权”与“专业主义”的大讨论，看看在 AI 掀起的这场“全民编程”狂欢之下，到底藏着怎样的泡沫、陷阱与机遇。

一个非开发者的“玄学 Debug”之旅

故事的开端，来自一位名叫 eowenith 的开发者。他讲述了自己围观一位非技术背景的朋友，如何使用 Claude Code 构建一个应用的“奇葩”经历。

这位朋友对编程一窍不通，她的操作方式，被社区戏称为 “Vibe-Coding（氛围编码）”：

1. 脑子里有一个模糊的想法。
2. 用大白话告诉 AI：“给我做一个XX网站。”
3. AI 生成了一堆代码，她看不懂，直接运行。
4. 网站崩溃了。
5. 她把整个屏幕的截图发给 AI，然后配上一句：“这看起来不对劲。”
6. AI 开始猜测问题，生成新的代码，然后再次崩溃……

eowenith 在帖子中写道：

“我眼睁睁地看着 Anthropic 的账单邮件一封封地发过来，她花了几个小时和几十次 Prompt，最终搞出来的东西，我可能用一两个 Prompt 就能做得更好。”

“最后，她甚至还嘲笑我，说我的 Claude Code 总结页面上的‘已用点数’和‘消息数’太少了，像个业余爱好者。”

这个案例，让评论区彻底炸了锅。

一位开发者一针见血地指出：

“那个‘嘲笑你点数用得少’的部分，真的把我逗笑了。低效地烧钱，居然成了一种炫耀资本。”

另一位开发者则用更专业的视角剖析了这种“Vibe-Coding”的致命缺陷：

“一个没有底层知识的人，只会不停地 Prompt。AI 为了解决表层问题，会不断地创造‘权宜之计’，绕过那些真正核心的架构缺陷。最终，这些‘权宜之计’会互相叠加，让系统变得比一开始还要烂。”

这种靠“直觉”和“感觉”驱动的开发模式，正在批量制造着新时代的“高科技屎山”。

“Token 猪”与“认知卸载”

在这场大讨论中，几个极其精辟的新概念应运而生，完美地概括了 AI 时代的行业乱象。

概念一：Token 猪（Token Pig）

这个词用来形容那些低效、懒惰、疯狂消耗 Token 的 AI 使用者。

他们把 AI 当作一个无限的“许愿池”，拒绝进行任何有价值的思考，把最简单的任务，也用最昂贵的方式外包给大模型。

概念二：认知卸载（Cognitive Offloading）

一位开发者表达了一种更深层次的担忧：

“AI 确实很有用，但我对‘认知卸载’的长期影响感到担忧。我努力确保自己能理解 AI 做的每一件事，并花时间去搞懂那些看起来不太对劲的地方。”

当我们习惯于让 AI 为我们思考，我们的大脑就失去了构建深度知识模型（Mental Models）的机会。我们从“司机”变成了“乘客”。长此以往，我们不仅会失去对代码的掌控力，更会失去独立解决复杂问题的能力。

就像评论区里那个极其扎心的比喻：

“当手机出现后，一种新的脑损伤出现了——我们记不住电话号码了。”

当工具抹平了门槛

回到最初的那个“摄影师”比喻。

一位用户分享了她丈夫的真实经历：

“我的丈夫曾经是一名职业摄影师。当数码相机的浪潮到来，‘让每个人都成了摄影师’时，他被迫离开了这个行业。因为客户们开始觉得，他们不应该再为一个‘按一下快门’的动作，支付高昂的费用。”

这几乎是所有专业开发者内心最深的恐惧。

但另一位用户也提出了一个类似的观点：

“我用我的 iPhone，就能拍出比 30 年前职业摄影师更好的照片。99.9999% 的照片都是由我和其他非专业人士拍摄的。所以，这个比喻或许恰恰证明了：我们真的不再需要那么多的‘职业开发者’了。”

这场争论，最终指向了一个更本质的问题：当工具的门槛被无限降低，我们作为“专业人士”的价值，到底还剩下什么？

从“手艺”到“品味”的跃迁

在这场看似无解的“生存危机”大讨论中，我们依然能找到一条属于高级架构师的、清晰的破局之路。

第一条：AI 抹平了“技法”，却放大了“品味”

一位开发者的评论获得了大量高赞：

“工具降低了门槛，但品味（Taste）和基本功（Fundamentals），依然是区分‘能跑的代码’和‘好的代码’的唯一标准。就像相机让拍照变容易了，但没让拍出好照片变容易。”

AI 可以帮你写出符合语法规范的代码，但它无法替你做出架构决策。

• 它不知道你的业务在未来半年会如何演进。
• 它不理解高并发场景下，一次锁竞争的代价有多大。
• 它更无法在“开发效率”与“长期可维护性”之间，做出最符合当下团队资源的权衡。

这些，就是“品味”。

第二条：从“执行者”到“定义者”

另外一位开发者的观点同样深刻：

“相机没有让每个人都成为摄影师，它只是降低了门槛。AI 也一样，它不会让每个人都成为开发者。但它会将价值，从‘编写代码’，转移到‘知道该构建什么，以及如何塑造产出’上。”

当 AI 能够完美地执行指令时，“下达正确的指令”就成了最稀缺的能力。

我们作为资深开发者的核心价值，正在从一个“手艺精湛的工匠”，转变为一个“拥有上帝视角的系统设计师”。

第三条：别在工具层内卷，向上走，到“思想层”去

整场讨论中，最让我感到共鸣的，是下面的一段话：

“我真的超爱写优雅、干净、极简的代码（这正在迅速成为一项无用的技能）。但归根结底，我一直都是一个‘想法的建造者（Builder of Ideas）’。”

“我们的超能力，不是写代码的能力，而是把一个模糊的想法，变成一个真实的产品、系统、服务的能力。社会需要我们，是因为这个。代码，只是我们用来交付这个概念的工具。”

小结：别担心，你的价值远超你写的代码

回到最初的那个比喻：“AI 让每个人都成了开发者”，就像“相机让每个人都成了摄影师”。

是的，相机让记录生活变得轻而易举，但它并没有消灭那些能够捕捉光影、构图、和决定性瞬间的艺术大师。

同样，AI 让实现功能变得前所未有的简单，但它也永远无法取代那些能够洞察需求、设计架构、并对系统最终质量负责的软件架构师。

AI 拿走的，只是我们手中的“体力活”。

而留给我们，并被无限放大的，是我们作为工程师最宝贵的东西：经验、品味、判断力，以及将混乱的世界，构建成优雅系统的能力。

不要再为“写代码”这件事本身感到焦虑了。

向上看，去思考，去设计。

因为在那片 AI 无法触及的高地上，才是你真正的价值所在。

资料链接：

• https://x.com/Samaytwt/status/2047315095773216780
• https://www.reddit.com/r/webdev/comments/1stjfo4/i_just_watched_a_nondev_vibecode_something_were/

今日互动探讨：

在 AI 编程的浪潮中，你是否也曾有过“被外行指导内行”的憋屈经历？你认为一个专业开发者，在 AI 时代最不可被替代的核心竞争力是什么？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/04/the-ai-layoff-trap

大家好，我是Tony Bai。

过去的一年，AI 带来的“裁员恐慌”几乎席卷了整个科技行业。

今年 2 月，Jack Dorsey 的 Block 公司裁掉了近一半的员工，他直言不讳：“因为 AI 让很多岗位变得没必要了。”

Salesforce 用 AI 替换了 4000 名客服，Cognition 的 AI 程序员 Devin 让一个资深工程师能干五个人的活。

我们似乎正处在一场由 AI 引发的“效率革命”之中。管理者们为“降本增效”而欢呼，而我们这些打工人，则在瑟瑟发抖，担心自己的饭碗随时可能被一个看不见的 Agent 抢走。

但如果我今天告诉你，这场看似“零和博弈”的裁员狂潮，最终的结局可能不是“资本家赢，打工人输”，而是“所有人一起输”呢？

就在今年3月份，宾夕法尼亚大学和波士顿大学的两位学者，发布了一篇极其硬核、甚至有些惊悚的经济学论文——《The AI Layoff Trap》（AI 裁员陷阱）。

这篇论文用极其严密的数学模型，推演出一个令人脊背发凉的结论：

在充分竞争的市场中，所有理性的公司都会陷入一场疯狂的“自动化军备竞赛”。它们会不断地用 AI 裁掉员工，直到把整个市场的消费需求彻底摧毁，最终导致企业利润和员工收入双双崩溃。

今天，我们就来拆解一下这篇堪称“末日预言”的论文，看看我们是如何一步步，心甘情愿地跳进这个“双输”陷阱的。

囚徒困境：为什么明知是悬崖，所有公司依然在疯狂加速？

论文的核心，建立在一个极其简单的经济学常识之上：被裁掉的员工，同时也是消费者。当他们失去收入，整个市场的购买力就会下降。

既然这个道理连街边卖菜的大妈都懂，为什么那些拥有无数顶尖经济学家的巨头公司，还会朝着“零需求”的悬崖狂奔呢？

答案，就在于一个经典的博弈论模型：囚徒困境。

论文构建了一个简单的竞争市场模型：

• 市场上有 N 家公司，互相竞争。
• 每家公司都可以选择用 AI 替换掉一部分人类员工，从而降低成本。
• 但每一次裁员，都会导致市场上总的消费需求下降一点点。

现在，让我们站在其中一家公司 CEO 的视角来做决策：

场景一：如果其他公司都选择不裁员

这时，如果我选择裁员，我能独享 AI 带来的全部成本降低（利润增加），而裁员导致的市场需求下降，则是由所有 N 家公司共同分摊的。

对我来说，裁员是绝对的最优策略。

场景二：如果其他公司都在疯狂裁员

这时，市场的总需求已经在萎缩了。如果我选择不裁员，我不仅要和他们一起承受市场萎缩的痛苦，还无法享受到 AI 带来的成本优势，我的市场份额会被迅速蚕食。

为了活下去，我唯一的选择就是：比他们裁得更狠。

看懂了吗？

无论竞争对手怎么做，对我自己来说，“最大化自动化（裁员）”永远是我的最优解（严格优势策略）。

而当市场上的每一家公司都这么想、都这么做的时候，整个系统就陷入了一场无法回头的“死亡螺旋”。下面这张图通过三组二维图，直观地展示了随着市场竞争者数量（Number of firms N）的增加，“过度自动化”的阴影面积（代表双输的程度）是如何变得越来越大、越来越黑的。

每家公司都做出了对自己最理性的决策，但最终却导致了一个对集体而言最坏的结果。 这就是“AI 裁员陷阱”的本质。

“更好”的 AI，更快的毁灭：“红色皇后效应”

有人可能会乐观地认为：“没关系，只要 AI 的生产力足够高，它创造出的新财富，总能填补被裁员工的消费窟窿。”

但这篇论文给出了一个更令人绝望的推论：“更好”的 AI，不仅不会缓解这个问题，反而会加速毁灭的进程。

因为一个生产力更高的 AI，会给率先采用它的公司带来更大的“市场份额增益”的幻觉。这会进一步刺激所有公司，更疯狂地投入到这场军备竞赛中。

这就像《爱丽丝梦游仙境》里的“红色皇后效应”：你必须用尽全力奔跑，才能勉强留在原地。

最终，在所有人（包括 AI）都跑得气喘吁吁的均衡状态下，没有任何一家公司真正获得了额外的市场份额，整个系统只是以更快的速度，冲向了那个“零需求”的悬崖。

失灵的“解药”：为什么 UBI 和技能提升都救不了我们？

面对这个残酷的困境，社会上流传着几种看似美好的“解药”。但这篇论文用数学模型，一一戳破了它们的虚幻。

解药一：全民基本收入（UBI）或提高资本利得税

结论：完全无效。

因为 UBI 和资本税，作用的是企业的“利润水平”，而不是那个驱动裁员的“边际决策”。

只要用 AI 替换一个员工的成本，依然低于这个员工的工资，那么无论你给这家公司发多少补贴、或者收多少税，它裁员的动机都不会改变。

解药二：员工技能提升（Upskilling）或员工持股（ESOP）

结论：部分有效，但无法根治。

让被裁的员工通过再培训，找到收入更高的工作，或者让他们持有公司股票，分享自动化带来的利润，确实能够部分地“回收”损失的消费需求。

但这篇论文指出，这个“回收”过程，永远无法 100% 抵消最初的损失。因为信息和资本的流动总有摩擦，只要存在一点点的“需求外溢（Demand Externality）”，那个驱使大家走向悬崖的魔鬼，就依然存在。

唯一的“刹车”：痛苦但必要的“自动化税”

在排除了所有看似美好的“市场化”解决方案后，论文最终指向了一个极其古典、也极其具有争议的“终极武器”——庇古税（Pigouvian Tax）。

这个概念由经济学家阿瑟·庇古在 1920 年提出，它的核心思想是：对产生负外部性的行为，直接征税。

比如，一家工厂每排放一吨废气，对社会造成了 100 元的环境损失，那就对它征收 100 元的“排污税”。

在这篇论文的模型里，这个“税”被具体化为“自动化税（Automation Tax）”。

每当一家公司用 AI 替换掉一个人类岗位时，它就必须为这个“自动化行为”本身，支付一笔税。这笔税的金额，应该精确地等于这次裁员对整个社会造成的“消费需求损失”。

只有这样，才能将那个被企业“外部化”的社会成本，重新“内化”回它自己的决策模型中，从而逼迫它在裁员时，三思而后行。

当然，作者也承认，征收“自动化税”在现实中面临着巨大的挑战：如何精确计量？如何防止企业将生产转移到海外？

但他们强调，这是在理论上，唯一能够从根源上踩下“裁员军备竞赛”刹车的政策工具。

小结：我们正在创造一个怎样的未来？

这篇论文，虽然是用经济学的语言写就，但它探讨的，却是我们每一个技术人都在亲身参与和塑造的未来。

它像一面镜子，照出了我们在追求“技术最优解”时的认知盲区。

我们痴迷于用 AI Agent 替换掉客服、用 AI Coder 替换掉初级程序员，我们为每一次“降本增效”的成功而欢呼。但我们很少去想，当这些被我们亲手“优化”掉的人，失去消费能力时，我们亲手构建的商业大厦，地基又在哪里？

这篇论文的价值，不在于给出了一个完美的答案，而在于它提出了一个更高维度的问题：

当“个体理性”与“集体理性”发生冲突时，我们作为系统的构建者，应该扮演怎样的角色？

是继续蒙眼狂奔，加速这场“双输”的游戏？

还是停下来，去思考如何从架构层面，引入那些能够平衡“效率”与“公平”的、更具人文关怀的“新规则”？

这其实已经超出经济学问题范畴，更像是是一个深刻的“架构伦理”问题了。

资料链接：https://arxiv.org/abs/2603.20617

今日互动探讨：

看完这篇论文的推演，你是否也对 AI 的未来感到一丝寒意？你认为“自动化税”是一个可行的方案，还是一个乌托邦式的幻想？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

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

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

© 2026, bigwhite. 版权所有.