本文永久链接 – https://tonybai.com/2026/06/12/zig-father-refuses-funding-bans-ai-why-no-1-0-in-a-decade

大家好，我是Tony Bai。

在技术圈，有一门名为 Zig 的系统级编程语言，它没有铺天盖地的营销，没有背后财大气粗的金主干爹，甚至它的代码仓库在 2025 年末从 GitHub 直接“硬核跑路”到了 Codeberg。

然而，在 JetBrains 发布的“最受敬仰编程语言”榜单中，它赫然位列 Top 5；Uber 用它的编译器解决 Go 的交叉编译难题；大热的 JavaScript 运行时 Bun 用它作为底层的胶水语言（注：近期Bun已经从Zig迁移为Rust实现）；金融级数据库 TigerBeetle 更是基于它实现了比传统方案快上千倍的性能。

为什么在拥有了 C++、Rust 和 Go 之后，世界依然需要 Zig？

最近，JetBrains 团队对 Zig 之父 Andrew Kelley 进行了一次深度专访。在长达一个多小时的访谈中，Andrew 展现出了极度“反主流”的极客态度：坚决抵制 AI 生成的代码（No-AI Policy）、宁可拿 67 万美元的非营利基金也不要上亿美元的投资、10 年不发布 1.0 版本。

今天，我们就来深度扒一扒，这位被称为“最硬核系统语言创造者”背后的狂人哲学。

缘起：“我能比 C++ 做得更好，我也能比 Rust 做得更好”

故事要从一个开发“数字音频工作站（DAW）”的失败尝试说起。

在 2015 年之前，Andrew 试图用各种现有的语言去开发一个专业的 DAW 软件。

• JavaScript？ “太高层了，根本接触不到计算机底层能力来做低延迟处理。”
• Go？ “和 C 库的交互极其痛苦（CGo），而且垃圾回收（GC）在实时音频处理中是致命的。哪怕卡顿一毫秒，在现场演出中都是灾难。”
• Rust（1.0 之前）？ “我为了让字体渲染工作花了一个月，被 Borrow Checker（借用检查器）折磨得生不如死。稍微改动一点代码，就会引发一连串的编译错误，让我彻底卡壳。”
• C++？ “刚开始感觉很高效，但很快，一个小拼写错误就导致了内存损坏（Memory Corruption），花了我几个星期去 Debug。这太慢了！”

即使退回到只用极简 C++（搭配 C 链接器），他依然在不断地“搬起石头砸自己的脚”。

那一刻，年轻的 Andrew 迸发出了极大的傲慢与决心：“我可以做得更好！我可以比 C++ 做得更好，比 Rust 做得更好，比 Go 做得更好！”

于是，Zig 诞生了。

为什么世界还需要 Zig？它凭什么挑战 C 和 Rust？

很多人会问：C 语言统治了底层 50 年，Rust 现在红得发紫，Zig 凭什么挤上牌桌？

Andrew 给出了一个极其精准的定位：“在 Zig 中，你不需要像在 Rust 中那样为了迎合编译器的‘类型理论’而去扭曲你的代码结构；在 Zig 中，你思考的是‘我希望 CPU 做什么’，然后你写出让它这么做的代码。”

1. 为什么它是更好的 C？

“想要替代 C，你不能放弃任何 C 拥有的能力。”Andrew 说道。

Go 放弃了底层的绝对控制权换取了并发的便利，所以 Go 永远无法替代 C 写操作系统内核。

但 Zig 做到了。在 Zig 中，一切都可以像 C 一样高效，但消除了 C 语言海量的“坑（Footguns）”。甚至在细节上，Zig 比 C 更像 C：C 语言只有溢出（Wraparound）的无符号整数，而 Zig 允许你精细控制整数的溢出行为和符号约束。

2. 为什么它不同于 Rust？

Rust 的核心是其宏大的类型系统和基于生命周期/借用的内存管理模型（类似 RAII）。

而 Zig 走的是“显式分配器（Explicit Allocators）”的路线。

在 Zig 中，没有隐式的内存分配，开发者经常针对特定应用使用 Arena Allocator（一次性分配，一次性销毁），以获得极低的延迟和极高的吞吐量。TigerBeetle 数据库就是利用这一点，在启动时预先分配好所有内存，此后运行时零动态分配（Zero Dynamic Allocation），从而实现了恐怖的高频交易性能。

3. 杀手锏：全宇宙最强的 Toolchain

如果你问一个开发者，在 C/C++ 项目里最痛苦的是什么？99% 的人会回答：配置构建环境（CMake、Makefile、装依赖）。

Zig 的杀手锏在于它的工具链：它没有任何外部依赖。 无论你在什么操作系统上，想要编译一个项目，永远只需要一句 zig build。不仅如此，Zig 甚至可以作为一个超级强大的 C/C++ 交叉编译器。Uber 就是用 zig cc 来解决 Go 语言中混合 C 代码在 ARM 架构上的交叉编译难题的。

“AI 代码全是垃圾”：为什么 Zig 坚决封杀 LLM 提交？

在这个“万物皆可 AI 编程（Vibe Coding）”的狂热时代，Andrew 和 Zig 社区制定了一项极其强硬的规则：严禁任何由大模型（LLM/AI）生成的 Issue 和 Pull Request。

为什么这么刚？Andrew 的回答充满了工程师的辛辣与无奈：

“因为那些贡献无一例外，全是垃圾（Invariably garbage）。”

Zig 的核心团队只有 5 个人，却要面对海量的社区贡献。开源项目接受 PR 的核心目的不仅仅是为了拿代码，更是为了“导师制（Mentorship）”——通过 Review 代码，培养出下一代的核心维护者。

但在 Andrew 看来，那些用 AI 批量生成代码然后扔过来的贡献者，不仅没有任何价值，还在疯狂消耗核心团队极其宝贵的 Review 时间。

“这就像是‘贡献者扑克（Contributor Poker）’。用 AI 的人永远只是路过，他们学不到任何东西，也永远不可能成为核心团队的一员。更可笑的是，他们往往只是把报错信息贴回 ChatGPT，然后假装自己修复了问题。这纯粹是在浪费所有人的时间。”

面对满天飞的“AI 编程神器”，Andrew 有着自己极其古典的软件信仰：

“我想要软件拥有‘绝不妥协的完美（Uncompromising perfection）’。我不想看到一个软件仅仅是因为‘出乎意料地没有 Bug’而沾沾自喜，那是一个糟糕透顶的质量标准。”

$670K 的独立基金与 $100M 的诱惑：为什么拒绝做大？

在科技圈，一个流行的开源项目很快就会被大厂收编，或者拿到顶级 VC 的上亿美元融资，然后迅速扩张。

但 Zig Software Foundation (ZSF) 走了一条截然不同的路。它是一个注册在美国的 501(c)(3) 非营利组织。2024 年，整个基金会的总收入只有区区 67 万美元（约合人民币 480 万）。

在这 67 万美元中，Andrew 为自己定下了 15.4 万美元的年薪（相当于纽约一个普通的资深程序员薪水），而剩下的资金的9成以上，全部用来支付另外几位兼职和全职的外包核心开发者。

当主持人犀利地问道：“如果一家大公司给你 1 亿美元的无条件赞助，你会要吗？”

Andrew 的回答展现出了极度的清醒：

“我会拿，但我会把它存进银行，确保我们未来 100 年都不需要再到处筹款。但我绝不会用这笔钱去扩张。我不想管理 100 个人的团队。”

他的逻辑极其自洽：保持一个极度精简、高效的微型组织，能够最大程度地抵御资本的腐蚀（Oxidation）。

“我们不是初创公司，我们没有投资人在背后催着我们变现。如果我们拿了大厂的钱，他们就会有控制权；现在，我们靠着多元化的小额赞助和少数企业的资助活着。如果哪天某个赞助商说‘你必须按我说的做’，我们可以硬气地回答：‘对不起，如果你撤资，我们依然能活下去。’”

这就是他宁可手写报税单，也要死守非营利基金的底层原因——他要为 Zig 争取“对世界说‘不’”的自由。

硬核的代价：离开 GitHub，以及那遥遥无期的 1.0

为了这份独立和自由，Andrew 付出了很多代价。

2022 年，他退出了 Reddit 和 Twitter。2025 年底，当发现 GitHub 的持续集成（CI）服务器对 Zig 极度不稳定时，他更是做出了一个惊世骇俗的决定：将 Zig 的主仓库从 GitHub 彻底搬迁到了一家德国非营利组织运营的平台 Codeberg。

这意味着他主动放弃了 GitHub 带来的巨大流量和打赏（Sponsors）收入。但他毫不在意：“我们是来写软件的。如果 CI 跑不通，我们就换一个能跑通的。Codeberg 是非营利组织，比那些为了下一个财报季奔波的创业公司靠谱多了。”

那么，被粉丝催了 10 年的 Zig 1.0 究竟什么时候出？

Andrew 坦言，1.0 本质上是一个“向后兼容的承诺”。像 Go 这种语言，1.0 之后很久没动过语法；而 Rust 虽早早发布 1.0，却靠着 Editions（版次）机制继续大改特改。

“我们不需要为了迎合风投的胃口，或者为了所谓的‘商业落地指标’去急匆匆地发布 1.0。当 Zig 1.0 发布的那一天，它必须是一份‘毫不妥协的热爱之作’。我们不需要为任何仓促的糟糕决定买单。”

不过，Andrew 也在采访中透露了一个彩蛋：他将全力冲刺即将到来的 0.16 版本 (注：截至发稿时，Zig官网已经发布了0.16.0版本)。在这个版本中，完全摆脱对 LLVM 依赖的自研 x86 后端将迎来爆发——百万级代码库的增量编译将低至恐怖的 50 毫秒！

小结：程序员的乌托邦

在访谈的最后，当被问及“未来 20 年人类还会写代码吗”，Andrew 的眼中闪烁着光芒：

“人们永远不会停止写代码，因为写代码真的太好玩了。”

在他看来，当今世界最好的软件，往往是开发者们在业余时间出于热爱而写的。而那些为了商业目的强加给用户的软件，总是充满了广告、诱导和恶意的参与度指标。

Zig 不仅仅是一门编程语言，它是 Andrew Kelley 献给世界的一份“无条件的礼物”。它在向所有热爱底层、渴望掌控计算机的极客们宣告：

在这个被大厂垄断、被 AI 噪音填满的世界里，我们依然可以凭借几百 K 的预算、五六个人的小团队，用对技术的极致纯粹，造出一把劈开混沌的利剑。

如果你也曾在这个庞大的系统工程世界里感到过疲惫与迷茫，不妨去试一试 Zig 吧。那是一片没有资本催促、没有 AI 噪音的，属于纯粹程序员的乌托邦。

资料链接：https://www.youtube.com/watch?v=iqddnwKF8HQ

✍️ 今日开放讨论

在这个几乎所有人都疯狂拥抱 AI 编程（Claude Code/ Codex /Antigravity Cli等）的时代，Zig 官方明确拒绝 AI 生成的 PR。你认为是 Andrew Kelley 过于“迂腐”，还是他在守护开源软件最核心的“导师制与高质量传承”？

欢迎在评论区留言，分享你对“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/06/10/the-story-of-cpp

大家好，我是Tony Bai。

如果将人类现代软件工业比作一部庞大的机器，那么支撑其运转的最核心骨架中，无疑很大一部分由C++支撑。从你手中的智能手机操作系统、每天刷的短视频推荐引擎、华尔街每秒百万次的高频交易系统，到驱动大语言模型（LLM）的底层算力矩阵，C++ 几乎无处不在。

在过去的 40 年里，这门语言一次次被宣布“濒临死亡”，却又一次次浴火重生。它被称为“弗兰肯斯坦的怪物”，被无数程序员诅咒过其令人发指的复杂性。但即便在如今 Rust 和 Go 等现代语言强势围剿的今天，C++ 依然稳坐系统级编程的王座。

近日，一部名为《The Story of C++: The World’s Most Consequential Programming Language》（C++ 官方纪录片）在 YouTube 上引起了巨大轰动。这部长达近两小时的纪录片，首次召集了包括 Bjarne Stroustrup（C++ 之父）、Alexander Stepanov（STL 之父）在内的一众 C++ 核心缔造者，向世人揭开了这门语言背后那些鲜为人知的妥协、背叛与权力斗争。

更精彩的是，在海外技术社区 Reddit 的 r/cpp 板块中，这部纪录片引发了无数大厂老炮和编译器极客的热烈讨论，通过将纪录片的官方叙事与社区的“野史”拼凑在一起，我们看到了一部远比代码本身更惊心动魄的技术史诗。

序章：从贝尔实验室逃出的“异类”

时间倒回 1979 年。彼时的贝尔实验室（Bell Labs）是全球计算机科学的“麦加圣地”，Ken Thompson和Dennis Ritchie 在这里创造了 C 语言和 Unix 系统。整个世界都沉浸在 C 语言那种贴近硬件、极致简洁的暴力美学中。

就在此时，一个名叫 Bjarne Stroustrup 的丹麦年轻人来到了贝尔实验室。他需要编写复杂的分布式系统模拟器，很快便发现，C 语言那套基于“函数与指针”的过程式编程，在面对巨大且复杂的系统时，就像是在用石器时代的工具建造摩天大楼——代码极易失控，且难以复用。

于是，他做了一个极具叛逆性的决定：他要在 C 语言的基础上，引入“类（Classes）”的概念。 这就是最初的“C with Classes”。

Bjarne 的初衷极其务实：他不想重新发明轮子，他只想让现有的 C 程序员能够稍微优雅一点地写代码。 因此，他定下了一条死命令：C++ 必须 100% 兼容 C 语言。

在 Reddit 的讨论中，一位资深 C++ 工程师指出：“C++ 之所以能在早期存活下来，唯一的理由就是它能够与海量的 C 语言头文件无缝对接。” 这条与 C 的“血脉绑定”，成为了 C++ 能够迅速占领企业级市场的最强杀手锏，但也为它日后的无底洞复杂性和编译期灾难埋下了最深远的隐患。

第一幕：STL 的救赎——从被群嘲到绝地反击

如果说 Bjarne 给了 C++ 骨架，那么真正赋予 C++ 灵魂的，是另一个极具争议的天才：Alexander Stepanov。

在 90 年代初，面向对象编程（OOP）如日中天。所有人都在沉迷于画继承树、搞多态。但 Stepanov 对此嗤之以鼻。他认为，将数据结构和算法强行绑定在对象里，是一种“极度低效且愚蠢的数学谬误”。

他提出了一种名为“泛型编程（Generic Programming）”的思想：算法应该独立于数据结构之外，通过一种叫“迭代器（Iterator）”的桥梁连接。

这就是后来名震天下的 STL（标准模板库）。

在纪录片中，最戏剧性的一幕发生在 1993 年的 C++ 标准委员会上。当 Stepanov 第一次将庞大且极其复杂的 STL 提案摆在委员会面前时，遭到了全场的群嘲与抵制。

“这太庞大了！这太疯狂了！这简直是在强奸编译器！”大佬们纷纷摇头。

此时的 C++ 委员会，正沉浸在由微软、IBM 等科技巨头把持的“门派斗争”中，没有人愿意为这种学术界的“屠龙术”买单。

在生死存亡之际，是 Bjarne 站了出来。为了让 STL 能够活下来，Bjarne 甚至不惜“扭断了自己亲生孩子的手臂”。

一位Reddit 用户分享了一段极其硬核的野史：“听到 Bjarne 承认为了让 STL 能在早期的 Cfront（C++ 编译器前置工具）上编译通过，他强行修改了 C++ 的语言规则，甚至导致了著名的 Cfront 2.0 bug，这简直太搞笑了！”

最终，在 Bjarne 的权力背书下，STL 以极其微弱的优势通过了委员会的投票。这一决定，彻底改变了现代软件工业的走向。没有 STL 提供的 Vector、Map 和极度优化的泛型算法，后来的谷歌、亚马逊和高频交易公司根本无法在 C++ 上构建起支撑亿万级流量的系统。

第二幕：巨头的绞杀——微软的野心与 Java 的入侵

正当 C++ 在系统底层攻城略地时，外部的绞杀战开始了。

2000 年前后，C++ 迎来了它生命中最黑暗的“冰河期”。在 Reddit 上，大厂老炮们对这段历史记忆犹新：

1. Java 的降维打击：Sun 公司推出的 Java 带着“Write Once, Run Anywhere（一次编写，到处运行）”和自带垃圾回收（GC）的承诺，瞬间摧毁了 C++ 在企业级开发层的统治地位。IBM 等巨头一夜之间倒戈。
2. 微软的背刺：为了对抗 Java，微软推出了自己的 .NET 战略和 C# 语言，并在很大程度上“冻结”了对原生 C++ 工具链的投入。

当时的 C++，就像是一个垂暮的老人：没有包管理器、跨平台编译像一场噩梦、ABI（应用程序二进制接口）地狱让人抓狂。甚至有人提到了一篇著名的早期新闻标题：“The Decline of C++?（C++ 的衰落？）”

更致命的是，C++ 标准委员会（WG21）在这个时期陷入了长达十年的“难产”。各大编译器厂商（尤其是微软的 MSVC）为了各自的商业利益互相扯皮。

在 Reddit 的帖子中，现任 MSVC STL 开发者的 STL 本尊亲自下场“辟谣”与爆料：

当时有很多开发者抱怨微软试图“破坏”STL（因为微软在 STL 里加入了极度拖慢性能的迭代器调试代码 _SECURE_SCL）。STL 大神解释道：“*微软并没有试图破坏 STL，这纯粹是出于对安全性的妥协，而在 2000 年代，由于编译器团队对 C++ 底层模板的理解不足，导致了糟糕的实现。*”

无论如何，在这漫长的十年里（C++98 到 C++11 之前），C++ 停滞不前。这段历史在官方纪录片中被轻描淡写地带过，但在社区看来，这是 C++ 被巨头资本裹挟、险些丧命的耻辱时代。

第三幕：现代 C++ 的绝地反击（C++11 至今）

就在所有人都以为 C++ 将退化为一门“只配用来写驱动”的边缘语言时，C++11 横空出世。

这绝对是编程语言史上最伟大的一次“续命”。C++11 引入了 auto、智能指针（Smart Pointers）、Lambda 表达式以及多线程支持。它仿佛将一辆生锈的老爷车，直接改装成了核动力飞船。

Reddit 上的一位开发者感叹道：“如果你没有经历过在 C++11 之前，仅仅是想要实现一个跨平台的多线程逻辑，就能触发各种未定义行为（UB）的时代，你就无法理解我们现在拥有的现代 C++ 有多么幸福。”

此时，硅谷的巨头们也终于醒悟。随着摩尔定律的逐渐放缓（单核 CPU 的免费午餐结束了），亚马逊、谷歌、Meta 以及高频交易巨头 Hudson River Trading（HRT）发现：要想在服务器账单上省下数千万美元，要想让延迟降低到微秒级，只有一条路可走——回归 C++。

从 C++11 开始，标准委员会终于恢复了活力，确立了每三年发布一个新标准（C++14, C++17, C++20…）的铁律。

纪录片中展示了今天 C++ 标准委员会的盛况：从最初的几十人，变成了现在动辄数百人的庞大机构。但这同时也带来了新的诅咒：过度设计与特征膨胀（Feature Bloat）。

终章：C++ 无法摆脱的诅咒与未来

纪录片以一种充满希望的基调收尾，特别提到了即将到来的 C++26 及其杀手级特性：静态反射（Static Reflection）。

但在 Hacker News 和 Reddit 上，那些每天深陷在 C++ 屎山代码中的一线架构师们，却显得远没有那么乐观。

1. 缺失的拼图：为什么官方不敢提 Boost？

眼尖的社区极客指出，这部宣称是“官方历史”的纪录片，竟然对 Boost 库 只字未提！要知道，在 C++ 停滞的十年里，是 Boost 库（包含大量实验性的元编程和现代特性）几乎凭借一己之力撑起了 C++ 的生态，并孵化了 C++11 的大部分新特性。社区猜测，这背后可能涉及到 Boost 基金会与 C++ 标准委员会之间复杂的权力斗争与未解恩怨。

2. 基础设施的荒漠：构建工具与包管理器之殇

在 Reddit 上，超过一半的火力集中在一个最朴素的痛点上：C++ 至今没有一个像样的官方包管理器。

当你用 Go 或 Rust 开发时，go get/install 或 cargo install 就能优雅地解决一切。但在 C++ 中，为了集成一个第三方库，你需要聘请一个拥有“博士学位”的 CMake 工程师，在 vcpkg、Conan、Bazel 之间痛苦挣扎，还要处理无穷无尽的 ABI（应用程序二进制接口）冲突。

一位大厂架构师绝望地写道：“标准化不应该强迫企业妥协，但现有的三大包管理器，导致了生态的极端割裂。C++ 真正的问题不在于语言层面，而在于其糟糕透顶的工程工具链体验。”

3. 碳（Carbon）与锈（Rust）的围剿

如今，谷歌推出了试图平替 C++ 的 Carbon 语言，而白宫甚至在安全报告中公开呼吁开发者放弃 C/C++，转向内存安全的 Rust。

面对如此巨大的压力，C++ 能够挺过下一轮大洗牌吗？

答案或许依然是肯定的。因为 C++ 早就超越了一门编程语言的范畴，它已经成为了人类数字文明的基础物理法则之一。 那些数以百亿计的遗留代码，那些经历了三十年实战检验的高频交易系统，那些与硬件深度绑定的 GPU 调度矩阵，是不可能在十年内被 Rust 或 Go 完全重写的。

《The Story of C++》不仅是一部纪录片，它是一面镜子。它照出了人类在构建庞大数字帝国时，那种充满妥协、混乱却又无比顽强的工程精神。

C++ 的世界里没有完美的乌托邦。正如 Bjarne Stroustrup 那句最著名的名言：

“世界上只有两种编程语言：一种是人们天天在抱怨的语言，另一种是根本没人用的语言。”

而 C++，无疑是被抱怨得最狠，却又永远无法被抛弃的那一个。

资料链接：

• https://www.youtube.com/watch?v=lI7tMxzSJ7w
• https://www.reddit.com/r/cpp/comments/1txhe5n/the_story_of_c_the_worlds_most_consequential/

今日开放讨论：

作为开发者，你认为 C++ 目前最大的痛点是由于它必须保持与 C 的后向兼容（Backwards Compatibility），还是因为它糟糕的构建和包管理工具？在 AI 和 Rust 崛起的时代，你会建议新人继续深入学习 C++ 吗？

欢迎在评论区留下你的观点，我们一起探讨系统级编程的未来！

还在为写 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/06/07/gaokao-in-the-age-of-ai-is-the-top-tier-degree-worthless

大家好，我是Tony Bai。

今天，2026年6月7日，千万名考生再次走向战场。

考场外，红色的横幅依然高悬，旗袍与鲜花依然簇拥。但在喧嚣之下，空气中却弥漫着一种前所未有的复杂情绪。

数据已经给出了最直观的反馈：在经历了2024年1342万人的历史峰值后，2025年和2026年的高考报名人数连续两年出现下滑。2026年全国高考报名人数仅为1290万人，比2025年的1335万人还减少45万人

生源的两连降，折射出的是无数家庭最深层的理性觉醒。在这个2026年的夏天，生成式AI、智能Agent和全自动工作流已经深度嵌入社会的每一个齿轮。

前阵子，一位本科毕业于某顶尖985高校、刚刚工作两年的程序员在社交平台上发帖：

“当年高考，我是全省前0.5%的做题家。辛辛苦苦在985卷了四年，以为拿到了中产阶级的入场券。结果工作不到两年，公司引入了AI 研发工作流。我现在每天90%的工作——写基础代码、debug、甚至写技术文档，AI两秒钟就能做得比我更好、更无懈可击。我开始怀疑，我那十二年的寒窗苦读，到底算什么？”

这条帖子瞬间引爆了全网的共鸣与焦虑。

今天的高考，我们还在为什么而战？如果连最顶尖的985、211学历，在AI面前都显得如此脆弱，我们付出的巨大代价，究竟在交换什么？

斯坦福的残酷研究：为什么我们的大学无法对抗AI的清算？

要回答“今天的高考还在为什么而战”，我们必须先看清一个长期被我们忽视的真相：我们的高等教育，正在让最聪明的年轻人“停止成长”。

斯坦福大学联合北京大学、清华大学、俄罗斯高等经济学院等全球顶尖机构，在《Nature Human Behaviour》（自然-人类行为）上发表了一篇具有里程碑意义的长期追踪研究。

研究团队对中国、美国、印度、俄罗斯数万名计算机和电子工程专业的学生进行了长达四年的标准化测试，得出了两个极具颠覆性的结论：

入学时，中国高考生是无可争议的“世界霸主”

在18岁踏入大学校门的那一天，中国大一新生的学术能力和数理基础处于全球同龄人的金字塔尖，其批判性思维（Critical Thinking）能力也与美国同龄人完全持平。

这证明，我们高强度的高考选拔，确实筛选出了这个星球上最聪明、最能吃苦、逻辑最严密的一批年轻人。

毕业时，我们的学生经历了残酷的“技能退化”

然而，追踪到大四毕业时，情况发生了戏剧性的逆转。

在大学四年里，美国学生的批判性思维能力实现了大幅度增长（约0.5个标准差）。而中国、印度和俄罗斯的学生，在四年里批判性思维几乎“零增长”，甚至在后两年出现了绝对值上的显著下降。

在数学和物理等专业学术能力上，中国学生在大一结束后，也出现了明显的、绝对的技能损失（下降约0.3标准差）。

这篇《Nature》论文揭示了一个近乎残酷的事实：中国的高考生在18岁那年达到了认知和技能的巅峰，然后，在大学四年里，他们被“严进宽出”的淘汰机制、陈旧的专业划分、以及重灌输轻思辨的教学模式，温水煮青蛙般地削弱了。

当这群大四毕业生拿着“高起点、低增值”的认知系统，一头撞上2026年已经进化到能够自我迭代的AI系统时，悲剧就发生了。

那些在大学里靠死记硬背应付考试拿下的GPA，在AI面前，连一秒钟的抵抗力都没有。

AI时代的清算：被替代的90%，到底是什么？

为什么那位985毕业生会感叹“AI替代了我90%的工作”？

因为在2026年的今天，AI首先消灭的，恰恰是那些“有明确标准、有套路可循、依赖信息检索和加工”的白领工作。

而这些工作，正是过去的大学教育最擅长培养、也是中产家庭最向往的就业方向：

• 初级程序员：AI自动编程工具已经能完成大部分基础代码的编写与测试。
• 翻译与文案策划：多模态大模型能够瞬间生成符合各种文化语境的译文和营销方案。
• 基础数据分析师：复杂的报表统计、趋势预测，AI可以在极短时间内完成可视化输出。
• … …

反思一下：这些被替代的工作，其核心特征不就是“做题”吗？

给出一个明确的需求（题目），寻找最优的算法或方案（标准答案）。

高考，是一场关于“寻找标准答案”的终极训练；而我们的大学，在过去很长一段时间里，只是这场训练的延续。

当“做题”的能力被AI彻底平替，我们十二年寒窗苦读积累的优势，在这一瞬间被抹平了。

2026年的质问：今天的高考，我们还在为什么而战？

既然如此，我们为什么还要支持孩子去考场？高考在今天，究竟还有什么意义？

如果我们依然把高考当成“通往高薪工作的自动售票机”，那我们一定会失望。因为那台售票机，已经坏了。

但如果我们换一个视角，高考在2026年，依然是一场不可替代的“成人礼”。我们今天在高考中战斗，是为了拿回三样AI永远无法夺走的东西：

1. 战的是“深度专注与抗挫折的底层神经元”

高考不仅考查知识，更是一场对意志力、抗压能力、多任务管理和长期深度专注力的极限训练。

在碎片化信息和即时反馈（如短视频、快餐娱乐）毁掉一代人脑前额叶的时代，能够为了一个长远目标，日复一日地进行深度学习、克服枯燥和焦虑——这种“深度专注的神经机制”，是你未来驾驭AI、不被AI深度娱乐化奴役的唯一底层硬件。

2. 战的是“在无标准答案世界里，寻找最优解的勇气”

很多人抱怨高考僵化，但高考恰恰教给普通人一件事：在规则极其明确的系统里，如何通过自我迭代，把自己的能力逼出极限。

这种“在给定约束条件下，调动一切资源求得最优解”的肌肉记忆，在走出考场后，可以无缝迁移到任何一个充满未知、没有标准答案的领域。

3. 战的是“改写自身命运的入场券”

尽管学历在贬值，但不可否认，高考依然是这个社会最公平、杂质最少的一次阶层跃迁和朋友圈重组的机会。

你考上的名校，它所能给你的最大价值，已经不再是课堂上的专业知识（那些网上都有），而是和你并肩站在一起的、同样经历过极限训练的同龄人群体，以及这个平台带给你的眼界和高维认知。

自救路径：考完之后，如何重塑你的“免裁系统”？

明天之后，高考生们将迎来人生中最长的一个暑假。但请记住，真正的分水岭，从交卷的那一刻才刚刚开始。

如果你不想在四年后成为那个被AI替代90%的“失业做题家”，你必须在大学第一天起，按照以下三步路径，重新设计自己的成长曲线：

步骤一：从“答题者”转变为“提问者”

未来的价值，不取决于你脑子里记了多少标准答案，而取决于你能否向AI、向世界提出最具洞察力的问题。在大学里，多去问“为什么（Why）”和“如果……会怎样（What if）”，而不是仅仅去背诵“是什么（What）”。

步骤二：建立你的“AI-Native”个人工作流

不要把AI当成作弊工具，而要把自己当成一个“AI团队的PM（项目经理）”。去学习如何编写结构化的Prompt，如何用多款AI工具协同完成一个研究报告、一个独立网站或一个创意视频。未来的竞争，不是人与AI的竞争，而是“掌握了AI的人”与“没掌握AI的人”的竞争。

步骤三：死守“人性的护城河”

去体验真实的生活，去和不同背景的人深度交流，去大自然中感受风、光与温度。去阅读那些不考的经典著作，去思考没有标准答案的伦理与道德。

人类特有的同理心、直觉、审美、物理世界的交互能力，以及在迷茫中坚守信仰的感性，是AI在很长一段时间里无法跨越的终极护城河。

小结

后天，当千万名考生走出考场，迎接他们的将是一个与他们父母辈完全不同的世界。

这个世界充满了不确定性，甚至有些冰冷。

但请不要害怕。高考从未保证过我们一生的无忧，它只是给了我们一次证明自己可以“为了梦想竭尽全力”的机会。

今天的高考，我们不为那张逐渐贬值的文凭而战，我们为那个在重压下历经淬炼、拥有无限自驱力、随时准备重塑自我的自己而战。

祝所有2026届考生，考场得意，金榜题名；更祝你们，在人生的下一场AI风暴中，乘风破浪。

资料链接：https://www.researchgate.net/publication/349707487_Skill_levels_and_gains_in_university_STEM_education_in_China_India_Russia_and_the_United_States

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「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/06/06/geohot-slams-ai-agents-as-the-most-expensive-software-disaster

大家好，我是Tony Bai。

在 AI 辅助编程疯狂席卷全球的今天，几乎每个开发者的双眼都被“效率翻倍”、“一键生成应用”的狂热口号晃得睁不开眼。大厂管理层在积极推进“全员 AI 编码”，创业者在吹嘘“氛围编码（Vibe Coding）”。

然而，就在这个全民狂欢的时刻，科技界最著名的叛逆天才、传奇黑客 George Hotz（网名 Geohot） 站了出来。他曾在 17 岁时成为全球首位解锁 iPhone 的人，随后又单枪匹马破解了 PS3，并创办了自动驾驶独角兽 Comma.ai。

最近，Geohot 在他的个人博客上发表了一篇名为《The Eternal Sloptember（永恒的垃圾九月）》的文章。在这篇文章里，他用极其冰冷且辛辣的笔触写道：

“我在这里立个 flag：在软件开发中引入 AI Agent，将是行业历史上代价最昂贵的错误之一。因为 Agent 根本不会写程序，而人们需要花越来越长的时间才能意识到这一点。”

这篇文章迅速引爆了开发者社区。在 Reddit 的 r/webdev 板块上，该话题斩获了数千个高赞，引发了无数一线架构师和开发者的强烈共鸣。

为什么这位顶级黑客会把 AI Agent 视为软件工程的毒瘤？他口中的“永恒垃圾九月”究竟隐藏着怎样可怕的行业真相？

典故溯源：什么是“永恒的垃圾九月”？

要理解 Geohot 的愤怒，我们首先需要理解他借用的一个历史梗——“永恒九月（Eternal September）”。

在互联网早期的 Usenet 时代，每年九月，都会有大批大学新生接入网络。这群新手由于不懂网络礼仪（Netiquette），会短暂地破坏原有技术社区的纯粹与优雅。但过去，老用户们只需花费一个月时间，就能将这些新生“同化”。

直到 1993 年 9 月，美国在线（AOL）向其数百万普通用户全面开放了 Usenet。新手的涌入再也没有停止过，原有社区的精致文化被彻底、永久地稀释了。从那以后，老网民将这个悲剧称为“永恒九月”。

Geohot 认为，现在的软件工程正在经历一场由 AI Agent 带来的“永恒垃圾九月（The Eternal Sloptember）”：

大模型（LLM）本质上是“高度复杂的统计模型，旨在模仿人类编程的分布”。它们吐出来的代码，在语法和格式上看起来天衣无缝，但在底层逻辑和系统架构上，往往是坏的、错的。最致命的是，这种“错”被包装得越来越隐蔽，越来越难以被察觉。

无数根本不具备底层系统思维的“调参手”，正在用 AI 疯狂向世界的开源社区和企业代码库里倾倒垃圾代码（Slop）。

“老虎机”效应：Geohot 历时半年的亲身实验

和那些只会纸上谈兵的评论家不同，Geohot 亲自用 AI 进行了长达 6 个月的深度开发实验。

他尝试用 AI Agent 编写他的深度学习框架 tinygrad 的部分代码，甚至尝试用 AI 逆向工程一块 USB 到 PCIe 的芯片。

他的实验结论可以用两个词来概括：极其失望。

“AI 确实非常擅长快速搭建一个原型（Prototype），”Geohot 承认。但当你试图去打磨它、消灭最后 5% 的边缘 Bug、让其达到工业级标准时，AI 就会变成一台“老虎机（Slot Machine）”：

[输入 Prompt] ───> 摇下老虎机摇杆 ───> [输出 buggy 代码 A]
                                             │ (发现错误，重新 Prompt)
                                             ▼
[输入修正 Prompt] ───> 再次摇下摇杆 ───> [输出稍微不同的 buggy 代码 B]

你一次次地拉下摇杆（修改 Prompt），AI 一次次给你吐出看似不同、实则依然带有微妙缺陷的代码。你感觉自己只差临门一脚，但你永远无法真正跨过那条代表“完美交付”的终点线。

“这种试错和盲目摸索（类似Ralph loop），比我自己从第一性原理出发去手写，要慢得多。”Geohot 坦言，“这完全达不到我工作过的任何一家公司的基本技术门槛。”

相比之下，他发现一个古老的自动漏洞挖掘工具 AFL（American Fuzzy Lop，模糊测试工具） 找出的代码漏洞都比大模型多。因为 AFL 是纯粹确定性的，它没有人类社交焦虑，更没有被 AI 公司的“心理战（Psyops）”所污染。

大厂病灶：为什么非技术管理层会成为“垃圾代码”的帮凶？

既然 AI Agent 开发如此低效，为什么现在各大巨头依然在疯狂推进？

Geohot 揭示了企业管理层一个极其荒谬的逻辑漏洞：对“虚假指标”的崇拜。

在大型企业中，管理层通常是非技术出身的。他们无法辨别代码的高级设计与品味，他们只能看懂看得见的指标——比如“开发进度图表”和“代码产出行数（Lines of Code, LOC）”。

“那些底层的、平庸的开发者（Bottom Performers），通过使用 AI，突然产出了 10 倍的代码量。”

管理层看到图表后大喜过望：“看啊！我们的团队多有效率！这个星期我们提交了 100 个 PR！”

但他们不知道，这多出来的 10 倍代码，全部都是无法维护的“工业垃圾（Slop）”。

这造成了极度扭曲的恶性循环：

1. 底层开发者用 AI 疯狂复制粘贴，提交海量垃圾 PR。
2. 由于大企业的反馈循环极慢、极官僚，这些黑盒垃圾代码顺利混入主干分支。
3. 认知负担转嫁：高水平的资深工程师（Top Performers）不得不花费双倍、甚至十倍的精力和认知负载（Cognitive Load），去帮这些 AI 审查代码擦屁股、Debug。

这就是为什么 Geohot 说：“AI Agent 对大企业的伤害，远比对个人或小团队的伤害要深得多。”

终局梦醒：当黑盒代码的“账单”到期

Reddit r/webdev 板块上的大批大厂老兵，用自己身边的真实惨剧，印证了 Geohot 的预言。

一位在 Fortune 100 强企业工作的开发者留言道：

他们的管理层在大会上狂热地宣称“AI 将接管一切开发，以后周五下午直接让 AI 部署 1 万行代码上线”。

“我们这些一线的工程师在下面默默看着。等这波 AI 狂热退去，账单到期，面对一堆无人能懂的‘黑盒代码（Black Boxes）’在半夜 3 点崩溃时，这些管理层会迎来极其残酷的梦醒时刻。”

目前的微服务和企业级软件，本就已经因为复杂的业务需求和拼凑的库而变得极其脆弱。一旦你引入 AI，让它用“在 StackOverflow 上抄来的、似是而非的代码”去填补这些系统的空隙，你实际上是在制造一个“无法被任何人理解、也无法被任何人重构”的终极怪胎。

“没有经验的 junior 开发者加上 AI，就是一场灾难的配方。” 另一位老兵写道。

幸存者法则：别在“AI 妄想症”中自残

面对这场由大厂和 AI 巨头联手制造的“AI 妄想症（AI Psychosis）”，真正的工程师该如何自救？

Geohot 在文章的结尾，给出了一个极具力量、甚至带有一丝英雄主义的生存守则：

“这个时代真正的故事，将是谁能在这场‘AI 妄想症’中保持清醒，不伤害到自己。”

1. 回归第一性原理（First-Principles）：放弃用 AI 盲目试错。当你遇到技术难题时，去读书，去查阅最干净、最硬核的一手的底层文档，搞清楚 CPU、内存和操作系统的底层运行机制。
2. 把 AI 降级为助手，而不是总监：Geohot 并不排斥 AI，但他对 AI 的定位极其清晰——它是一个更聪明的谷歌搜索，是一个帮你写样板代码、帮你写测试基准（Benchmarks）的高效秘书。但系统的架构设计、核心逻辑和最终决策，必须牢牢握在你自己的手里。
3. 拒绝成为平庸的羊群：当周围的人都在用 AI 批量生产垃圾代码并为此沾沾自喜时，保持克制，坚持对完美、优雅和高性能的代码品味的追求。

技术世界正在迎来一场由大量平庸代码构成的泥石流。但泥石流终会退去，那些在风暴中死守底层常识、拒绝交出思考方向盘的真正工程师，将在废墟之上，重建这个世界的数字基石。

资料链接：

• https://www.reddit.com/r/webdev/comments/1tvsfgj/im_calling_it_now_the_adoption_of_ai_agents_into/
• https://geohot.github.io/blog/jekyll/update/2026/05/24/the-eternal-sloptember.html

今日开放讨论：

你同意 Geohot 关于“AI 降低了代码质量，最终会拖垮大企业系统”的悲观论调吗？在你的团队里，是否也出现了“LOC（代码行数）增加，但系统却变得越来越像黑盒”的苗头？

欢迎在评论区分享你的一线工程经历，我们一起在这个狂热的时代保持冷峻的思考！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「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/06/04/master-new-tech-in-ai-era-counter-intuitive-learning-guide

大家好，我是Tony Bai。

最近，在开发者社区 Reddit 的 Golang（Go语言）板块上，一个求助帖引发了跨越语言和技术栈的集体共鸣。

发帖人是一位刚入行两年的新人，他的帖子大意是：

“我很迷茫。在这个AI时代，大家似乎都在用大模型疯狂地构建项目、飞速向前。如果我按照传统方式，看书、查文档、一行行敲代码，就会觉得自己慢得像个古董，正在被时代抛弃。

但当我向AI要答案时，我又觉得我根本不是在编程，我只是个在中间倒腾提示词的传话筒。看着那些跑起来的代码，我感到无比空虚——我感觉自己像个骗子，我根本没有真正掌握它。在AI时代，我到底该怎么学习？”

这个帖子之所以能得到成百条回复，是因为它戳破了当下几乎所有技术学习者的隐秘焦虑：当AI 能秒出代码、秒给方案时，我们该如何建立属于自己的、不可替代的技术壁垒？

如果你的学习方式依然停留在“遇到问题 -> 丢给AI -> 复制粘贴 -> 跑通收工”的循环中，那么你正在主动将自己推向被AI淘汰的边缘。

在这篇文章中，我们将结合这场技术社区的讨论，为你拆解一套在AI时代真正掌握一门新技术（我们以崇尚极简的Go语言为例）的“非主流”学习指南。

为什么“AI代写”是一粒甜美的毒药？

在Reddit的讨论区中，一位资深开发者留下了这样一句警示：

“Remember, lines produced are lines spent; not achieved.”（记住，生产出来的代码行数，是你的负债，而不是你的成就。）

在非AI时代，写代码的行数代表着你的思考与劳动；但在AI时代，生成一万行代码可能只需要几十秒钟。很多人因此陷入了“效率幻觉”，看着屏幕上飞速滚动的代码，误以为自己的能力也随之暴涨。

这是一种极度危险的认知幻觉。

1. 认知深度的“折叠”

编程不仅仅是输出语法，更核心的是在脑海中建立逻辑模型。当你遇到一个并发瓶颈或内存泄漏问题时，你为了排查它而去翻看源码、对比不同的垃圾回收机制、调整参数——这整个“痛苦挣扎”的过程，正是你大脑神经元建立连接、内化技术底层逻辑的唯一途径。

如果你直接问AI“怎么解决”，AI会直接把改好的代码喂给你。你跳过了挣扎，也就跳过了认知。你的技术肌肉不仅没有得到锻炼，反而开始萎缩。

2. 丧失对复杂系统的控制力

用AI拼凑出来的项目，在初期确实能跑得很快。但因为你没有亲手参与底层架构的微调，随着项目规模扩大，各个模块之间的耦合、并发冲突、边界条件会像雪崩一样爆发。由于你缺乏对这些代码的“微观掌控力”，一旦AI也无法给出正确答案时，你将面对满屏报错束手无策。

Senior与Junior的AI使用界限

在技术团队中，你会发现一个有趣的现象：资深工程师（Senior）用AI效率翻倍，而初学者（Junior）用AI却越来越平庸。

这背后的本质差异在于：你是否拥有“代码品味（Code Smell）”和“系统直觉”。

• 资深工程师的模式：【主导与审查】

高级开发人员对系统架构、设计模式、性能瓶颈有着深刻的肉体记忆。当他们使用AI时，他们把AI当作一个速度极快的“草稿撰写员”。AI给出的方案，Senior一眼就能看出哪里有潜在的内存泄漏，哪里不符合并发安全。他们是在评审（Review） AI，始终掌握着主导权。

• 初学者的模式：【盲从与执行】

初学者由于没有建立起完整的技术品味，无法分辨AI给出的方案到底是优雅的还是埋了雷的（即AI生成的“Slop/代码垃圾”）。初学者往往选择无条件信任，甚至连变量名、异常处理都直接套用。

一位大厂技术面试官在贴子中坦言：

“在最近的面试中，我看到了初级候选人理解能力的全面崩溃（collapse of comprehension）。他们能用AI在10天内做出一套复杂的分布式系统，但当我问及其中一个数据一致性问题是如何在Go中保证的，或者让他们手写一个简单的通道（channel）协作时，他们彻底哑口无言。”

这就是盲目依赖AI代写的代价：你以为你开挂了，其实你只是把自己的大脑外包了。

非主流学习指南（以Go语言为例）

那么，在AI时代，正确的学习姿势到底是什么？这套“非主流”路径建议你打印出来，贴在电脑旁。

第一步：开启“Cold Turkey（冷火鸡）”阶段，强制肌肉记忆

在学习一门新技术（如Go语言）的前几个月，请狠心关掉你IDE里的所有AI辅助插件（如Copilot、Cursor的Tab补全）。

Go语言的设计哲学是 “Clear is better than clever”。它的语法极其克制，没有复杂的语法糖。这使它成为最适合用古法一行行敲击来建立肌肉记忆的语言。

• 亲手去写每一个 if err != nil 的错误处理；
• 亲手去体验指针传递与值传递的区别；
• 亲手写一个基础的 for range 循环。

在这个阶段，痛苦是你的朋友。那些因为拼写错误、类型不匹配导致的编译失败，正是你建立语言直觉的养料。

第二步：系统化输入优先（先建立拼图框，再填充碎片）

AI最擅长提供零散的代码片段，但它无法为你提供系统的知识框架。因此，必须坚持阅读经典。

• 官方 Spec 优先：去读Go的官方文档《Effective Go》，去理解为什么官方不推荐使用过于复杂的技巧，而是强调代码的可读性。
• 经典图书不可替代：通读一本如《The Go Programming Language》这样的硬核著作，或《Go语言第一课》这样的系统化的专栏。书本/专栏能够提供一条由浅入深、逻辑连贯的学习脉络，这是AI那碎片化的回答永远无法提供的。

第三步：将AI角色重塑为“苏格拉底私人导师”

这是整套指南中最关键的改变：禁止让AI帮你写代码，强制让AI教你思考。

每次遇到难题，不要问 “帮我用Go写一个高并发的爬虫”，而是使用以下苏格拉底提问提示词（Prompt Template）：

苏格拉底学习 Prompt 模板：

“我现在正在学习Go语言的 [并发控制/通道/接口] 概念。在解决 [具体问题] 时，我卡住了。请你扮演一位资深的、注重启发式教学的导师。

在接下来的对话中，请严格遵守以下规则：
1. 绝对不要直接给我写出最终的代码答案。
2. 请指出我思路中可能存在的盲区或不合理的设计。
3. 用反问、类比或拆分步骤的方式，一步步引导我自己写出正确的代码。
4. 如果我的代码运行出错，请帮我分析报错信息背后的底层逻辑，而不是直接给出修改后的代码。

我的初步代码/想法如下：[贴出你的尝试]”

通过这种方式，AI从一个“抢你饭碗的枪手”，变成了一个“24小时无条件陪伴、温和且博学的私人教授”。

第四步：构建“双向反馈回路”

1. 自己先写：哪怕写得再烂，也要自己先用最基础的方式把功能实现。
2. 让AI Review：功能跑通后，把代码发给AI：“这是我自己实现的Go并发下载器。请站在资深Go开发者的角度，帮我挑挑刺。这里有没有通道泄露的风险？有没有更地道的写法（Idiomatic Go）？”
3. 对比重构：理解AI给出的优化建议，然后关掉AI的窗口，自己手动在编辑器里把优化后的代码重写一遍。

小结：在无限代码的时代，做掌握源头的人

在这个时代，最不缺的就是代码。随着大模型代码生成能力的指数级演进，写代码的成本正在无限趋近于零。

但正因如此，能够看懂代码、评估系统风险、做出架构决策的人，其价值正在成倍增长。

• 平庸的开发者：只学会了如何向AI索要现成的螺丝钉，一旦系统倒塌，他们不知道哪颗螺丝出了问题。
• 顶级的开发者：借助AI导师，以极快的速度弄懂了整个系统的构造原理，他们亲手组装，对每一个接口、每一次并发、每一处内存分配都了如指掌。

在AI时代，学习技术不是为了和AI比拼速度，而是为了借由AI的博学，更快、更深地抵达技术的本质。

关掉你的IDE/Copilot自动补全，打开一本经典的Go语言书，准备好你的键盘。

属于你的深水区探索，才刚刚开始。

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

为了便于你随时温习，我将这套“AI时代非主流学习法”整理成了4条核心原则，建议截图保存：

1. 主动戒断，重建肌肉记忆：在学习一门新技术（如Go语言）的前期，强制关闭所有AI代码自动补全。像前AI时代的程序员一样，亲手敲下每一行代码、解决每一次报错。
2. 系统输入，构建认知地图：拒绝用碎片化的AI回答代替系统学习。坚持阅读官方规范（Spec）和经典书籍，先在脑海中画出技术拼图的“边框”。
3. 重塑定位，将AI降级为导师：严禁向AI要直接的代码答案。使用“苏格拉底式提示词”，引导AI指出你的逻辑漏洞、解释底层原理、启发你独立思考。
4. 闭环反馈，完成深度重构：永远坚持“自己先写 -> AI审查 -> 闭环重构”的三步法。在对比与亲手重写中，真正内化代码的“好坏品味”。

今日开放讨论

学习的本质是思维的碰撞，面对汹涌而来的AI浪潮，我想听听你的真实想法：

1. 你目前在学习或工作时，对AI（如GitHub Copilot, Cursor, Claude Code等）的依赖程度有多高？
2. 在日常开发中，你是否也曾经历过“代码虽然跑通了，但感觉自己像个骗子”的空虚瞬间？你是如何克服这种技术焦虑的？
3. 除了文中提到的“苏格拉底提问法”，你在用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/06/02/no-more-boilerplate-go-proposal-function-to-interface-conversion

大家好，我是Tony Bai。

在 Go 语言日常开发中，有一个设计几乎人人写过，但写多了又让人觉得极其繁琐、甚至有些“脱裤子放屁”的样板代码。

假设你需要一个只读数据的 io.Reader，但它的行为非常简单（比如只是为了在测试里模拟数据），你通常需要这样写：

type ReaderFunc func(p []byte) (n int, err error)

func (f ReaderFunc) Read(p []byte) (n int, err error) {
    return f(p)
}

紧接着，在代码中通过 io.Reader(ReaderFunc(myFunc)) 进行双重套娃调用。

这种设计被称为 “适配器型定义”（如标准库中的 http.HandlerFunc）。虽然它工作得很好，但如果每个包都需要针对自己的单方法接口（Single-method Interface）定义一遍这种暖场代码，整个项目就会充斥着大量无意义的样板代码（Boilerplate）。

为了终结这个痛点，Go 语言的积极贡献者 Merovius 提交了一项提案——Issue #47487：允许将函数显式转换为单方法接口。

目前，该提案已被列为Active状态，并有了原型实现（CL 572835）。它不仅能让 Go 代码的清爽度提升一个量级，更是对 Go 语言底层类型系统的一次精妙微调。

痛点拷问：为什么我们讨厌“套娃”代码？

在复杂的微服务或系统级开发中，我们经常需要临时“包装”一些行为。比如，你想设计一个 io.Writer，用来统计实际写入了多少个字节：

// 传统写法：你需要定义一个专门的结构体
type countingWriter struct {
    w io.Writer
    n int64
}

func (w *countingWriter) Write(p []byte) (n int, err error) {
    n, err = w.w.Write(p)
    w.n += int64(n)
    return n, err
}

func main() {
    cw := &countingWriter{w: os.Stdout}
    // 写入数据到 cw
    fmt.Println(cw.n, "bytes written")
}

为了实现一个简单的计数逻辑，你被迫写了十多行结构体和方法定义。更糟糕的是，这破坏了内聚性——countingWriter 往往只用一次，却污染了整个包的命名空间。

现在，看看新提案下，利用闭包（Closure）和函数转接口后的极致美学：

func main() {
    var N int64
    // 核心：直接把匿名函数转换为 io.Writer 接口！
    cw := io.Writer(func(p []byte) (n int, err error) {
        n, err = os.Stdout.Write(p)
        N += int64(n)
        return n, err
    })
    // 写入数据到 cw
    fmt.Println(N, "bytes written")
}

对比极其鲜明：代码行数缩减了一半，状态逻辑（N）被完美锁死在当前函数作用域内，没有任何多余的结构体命名，逻辑高内聚。

方案博弈：为什么是显式“类型转换”，而不是“自动赋值”？

其实，社区早在几年前就提过更激进的提案（#21670）：允许将函数直接、隐式地赋值给匹配的单方法接口（Assignability）。

但是，该提案很快遭到了 Go 核心团队的否决，原因在于隐式赋值的二义性与安全隐患。

最经典的例子：

io.Reader 和 io.Writer 的核心方法，其函数签名是完全相同的：

• Read(p []byte) (n int, err error)
• Write(p []byte) (n int, err error)

如果允许隐式赋值，当你写下 var x = func(p []byte) (int, error) { … } 时，编译器根本无法得知你这个函数到底是一个“读者”还是一个“写者”。

为了守护 Go 语言类型安全、意图清晰的底层哲学，#47487 采取了折中但极度务实的路线：要求必须进行显式类型转换（Convertibility）。

// 必须显式声明你要转换成什么接口
r := io.Reader(myFunc)
w := io.Writer(myFunc)

程序员必须显式、大声地告诉编译器：“我知道这个函数签名的含义，现在我要把它当做 Reader/Writer 来用。” 这完美规避了隐式匹配导致的逻辑混乱。

编译器背后的魔法：如何处理反射与断言？

这是一个看似简单的语法糖，但对 Go 编译器的底层设计提出了巨大的挑战。

在 Go 语言的底层设计中，有一个坚不可摧的铁律：只有被定义（Defined）的类型才能携带方法，未命名类型（如普通的 func 类型）是没有方法集的。

如果我们将一个普通的匿名函数转换为了 io.Reader 接口，当我们对这个接口进行反射（reflect.TypeOf）或类型断言时，底层的动态类型（Dynamic Type）到底是什么？

为了解决这个“Trilemma（三难困境）”，Go 团队在原型 CL 572835 中展示了编译器的底层魔法：在编译期，自动生成虚拟的未导出类型。

当你写下 io.Reader(func…) 时，Go 编译器会在幕后自动为你生成一个类似于 runtime.io_reader.func 或 runtime.autogenerated_xxx 的未导出定义类型。它拥有一个名为 Read 的方法，该方法在调用时会直接执行你传入的函数体。

这种设计的精妙之处在于：

1. 完全向后兼容：不破坏任何既有反射代码的假设。
2. 不破坏语法直觉：由于自动生成的类型是未导出的，用户无法对其进行电击治疗（比如无法直接对这个虚拟类型进行类型断言），从而保证了底层的干净。

官方自曝：标准库里到底有多少无用的“套娃”代码？

在 Issue 的辩论中，Merovius 对 Go 语言的标准库进行了一次扫描，揭露了如果没有这个特性，标准库自己写得有多纠结：

• 测试代码中的大量复制：在标准库测试中，存在大量为了测试 io.Reader、io.Writer、io.Closer 而定义的临时函数类型。
• 同名不同命的尴尬：在 net/http 包中，为了支持函数转换，居然定义了两个功能、签名完全一致，但由于在不同测试文件而名称不同的类型——funcWriter 和 writerFunc。
• 为了便利被迫暴露 API：因为没有原生语言支持，标准库不得不主动暴露出一些公共辅助类型，比如 net/http.HandlerFunc、cmd/go 内部的 ActorFunc、以及 x/mod 的 HashReaderFunc。

如果这项提案落地，标准库中数十个这样“脱裤子放屁”的适配器定义和重复代码，将在瞬间被全部清理干净。

对于第三方库（如各类 mock 框架、测试断言库）来说，这也意味着繁琐的 Fake 实现可以被一键简化为极简的匿名函数传入。

小结：这就是 Go 务实的进化美学

在 Issue #47487 漫长的拉锯战中，我们可以清晰地感受到 Go 团队在面对语言进化时的审慎。

Go 从不轻易引入新的语法，每一次特性的加入，都要经历长达数年、多方视角的拷问与权衡。他们拒绝了不安全的隐式匹配，也拒绝了过于复杂的通用接口字面量，最终停在了一个“用显式类型转换，在编译器内部生成虚拟类型”的务实方案上。

这正是 Go 语言长盛不衰的工程美学：宁可让语言显得有些“无聊”和“保守”，也绝不在运行时的安全性和可预测性上做出半步妥协。

随着 CL 572835 原型的不断完善，我们有望在不久的将来，彻底告别写各种 HandlerFunc 的繁琐日常，让 Go 代码重新回归极致的清爽。

资料链接：

• https://github.com/golang/go/issues/47487
• https://go.dev/cl/572835

今日互动讨论：

你赞同 Go 官方坚持使用“显式转换（Explicit Conversion）”而不是“隐式自动匹配（Implicit Assignability）”的设计吗？在你的日常项目中，有哪些单方法接口（如 http.Handler 或自定义业务处理器）能被这个新特性瞬间治愈？

欢迎在评论区留下你的硬核见解，我们一起聊聊 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/06/01/coding-10x-faster-isnt-10x-development-speed-google-ai-bottleneck

大家好，我是Tony Bai。

在过去的两年里，所有的开发者都在经历一场前所未有的“效率狂欢”。

随着大语言模型（LLM）和编码智能体的突飞猛进，各种“一键生成应用”、“10倍速程序员”的口号不绝于耳。仿佛只要给 AI 喂一句自然语言，它就能吐出一个完美的架构。

然而，在刚刚结束的 Google I/O 2026 大会上，Google 首席工程师 Adam Bender 用一场名为《Software engineering at the tipping point》（处于临界点的软件工程）的硬核演讲，狠狠地戳破了这个幻觉。

Adam 在演讲中抛出了一个极其反直觉的观点：

“能够 10 倍速地生成代码，绝对不等于你能成为 10 倍速的工程师。”

如果你以为 AI 的引入只是让你的代码写得更快，那么你的团队、你的系统，甚至是你的职业生涯，都将在未来 18 个月内面临一场灭顶之灾。

为什么？因为我们忽略了一个比代码更庞大、更脆弱的存在——软件生态系统（Software Ecology），即软件不仅仅是代码的堆砌，它是一个由代码、工具、流程和人类文化共同编织的复杂社会技术系统（Socio-technical system）。

今天，我们就来深度拆解这场震撼硅谷的技术演讲，看看在 AI 洪流的冲击下，到底什么会被毁灭，什么又将成为我们不可替代的核心护城河。

打破“代码崇拜”：你不仅在写代码，你在经营一个“生态系统”

在讨论 AI 之前，我们必须先认清一个残酷的现实：你的工作，并不是你想象的那样。

很多开发者以为自己的工作就是“写代码”。但在一家现代科技公司里，写代码只占你工作的冰山一角。你真正的日常是：查阅文档、提交 PR、代码审查（Code Review）、等待 CI/CD 流水线构建、排查诡异的依赖冲突、以及参与无休止的架构撕逼会。

Adam 在演讲中引入了一个极其关键的概念：社会技术系统（Socio-technical systems）。

什么意思？就是说，你每天工作的环境，不仅仅是一堆没有感情的服务器和代码库（Technical），它还包括了活生生的人、组织的价值观、激励机制和沟通文化（Socio）。这两个部分紧密咬合，互相塑造。

这就是大名鼎鼎的康威定律（Conway’s Law）所揭示的真理：“组织设计出的系统，其架构必然是该组织沟通结构的缩影。”

如果你的公司极度强调“稳定和不背锅”，你的架构大概率会变成一堆厚重的微服务，每次发布都要层层审批；如果你的公司崇尚“敏捷和自治”，你的代码库可能就会像一棵野蛮生长的树。

在这个庞大的“社会技术生态系统”中，你写下的每一行代码，都会引发整个系统的连锁反应。

而现在，AI 这头狂野的巨兽，正在毫无顾忌地闯入这个脆弱的生态系统中。

灾难推演：当 AI 将代码量放大 10 倍，你的系统会崩溃在哪一环？

AI 确实能当一个超级加速器（Amplifier）。它能给你更多的测试用例、更多的文档、更快的代码生成速度。

但这正是问题所在。放大（Amplification）只是一个规模变量，它本身没有方向。 如果你的基础没打好，AI 放大的就不是生产力，而是纯粹的混乱（Confusion）。

让我们做一次极其真实的沙盘推演：假设通过 AI 辅助，你们公司的代码产出量突然飙升了 10 倍。你会迎来乌托邦吗？不，你会迎来以下四个致命的连环崩溃：

代码审查（Code Review）的瘫痪

如果你的团队突然多出了 10 倍的代码，谁来 Review？

现在的 AI 很擅长写代码，但在大厂的架构中，它往往缺乏对全局业务上下文的长远理解。这意味着，如果你放任 AI 提交 PR，资深工程师（Tech Leads）将不得不花费海量的时间，去逐行审查那些看似能跑、但架构设计极其糟糕的代码。

人类的注意力（Human Attention）是有限的，它将成为这场 10 倍速狂欢中最先熔断的瓶颈。

编译时间（Build Time）的黑洞

更多的代码 = 更长的编译时间。

你原本引以为傲的“每日部署（Daily Release）”，可能会因为代码库的急剧膨胀，导致一次完整的构建和集成测试需要跑上好几个小时。当你发现 CI/CD 永远在排队时，你还会觉得 AI 让你变快了吗？

测试与验证的雪崩

你拥有了 10 倍的代码，同时 AI 也帮你生成了 10 倍的单元测试。

但这不仅没有让你更安全，反而可能让你的系统陷入瘫痪。为什么？因为在庞大的依赖网络中，跑完数以百万计的测试需要极其恐怖的算力成本（Compute Cost）。

更致命的是，如果你的发布标准是“必须所有测试通过”，那么在 100 万个测试中(注：这显然是指Google量级的代码库测试)，只要有一个 AI 生成的、带有微小偏差的测试用例失败（Flaky test），你的整个软件就无法发布。

依赖地狱（Dependency Hell）的二次方爆炸

在一个代码库中，依赖关系的增长通常是二次方（Quadratically）的，而不是线性的。

当代码库扩大 10 倍时，你的模块依赖冲突、版本不一致的问题将呈几何级数爆发。一个几十人的小团队，可能会突然陷入只有上千人规模的巨头公司才会遇到的“架构死锁”。

下面是Adam Bender 展示的开发者生态系统节点互联图(Common developer ecosystem components):

我们看到：牵一发而动全身！代码生成只是其中一个节点，当它的产出飙升 10 倍时，版本控制、代码审查、构建工具和测试环境将全部面临过载崩溃。

破局法则：在 AI 时代，我们到底该关注什么？

既然单纯的代码生成速度并不能拯救我们，甚至可能毁灭系统，那么作为开发者和技术管理者，我们在这个“临界点”到底应该做什么？

Adam 的答案直指核心：重塑你的基础（Fundamentals）。

在大模型席卷一切的今天，决定一家公司、一个开发团队生死存亡的，不再是你用了多么牛逼的提示词（Prompt），而是那些古老、枯燥、却不可或缺的软件工程常识：

第一法则：打破盲目相信，重新定义测试策略

过去，我们追求极高的测试覆盖率。但在 AI 时代，你必须学会做减法。

如果算力成本飙升，你不能再奢求每次提交都跑完所有测试。你需要建立基于统计学和智能分析的新型测试策略，精准找出“最需要跑的测试”，而不是盲目追求 100% 的全部绿色（All green）。

第二法则：解耦，极致的解耦

为了防止 10 倍的代码量带来二次方爆炸的依赖冲突，你必须重新审视系统的架构。

如果你依然在维护一个紧密耦合的“大单体（Monolith）”，AI 的加入只会加速它的腐烂。建立清晰的服务边界、强制的模块隔离（Isolation），是让 AI 代码能够安全落地的唯一容器。

第三法则：保护人类的注意力（Human Attention）

不要让资深工程师沦为 AI 代码的“人肉校对机”。

如果你决定用 AI 生成代码，那么你也必须用 AI 去优化审批流。但千万记住：AI 可以辅助 Review，但最终的架构权必须牢牢握在有经验的人类手里。

第四法则：直面“共同命运（Shared Fate）”

在大型系统中，往往存在着牵一发而动全身的“共同命运（Shared Fate）”。比如，Google 的底层是一个庞大的单体仓库（Mono-repo），一次底层库的更新可能影响数十亿行代码。

在 AI 时代，你要极度警惕这种过度绑定。当 AI 能够瞬间制造大规模变更时，你必须拥有绝对可靠的回滚机制（Rollback）和灰度发布策略。如果你不能在秒级回滚一个破坏性的系统变更，你就绝对不能允许 AI 拥有直接上线的权力。

小结：谁将主宰未来的 10 年？

这不仅是一场属于 Google 的布道，这是一份写给所有开发者的生存指南。

AI 不会取代程序员，它只会无情地淘汰那些只会“翻译业务逻辑”的底层码农。

在未来的十年里，最值钱的技能，将不再是你精通多少种编程语言的语法，也不再是你敲键盘的速度。

最顶级的工程师，将是那些拥有“系统级思维（Systems Thinking）”的架构师：

• 他们能够站在高处，俯瞰整个组织的技术与文化生态；
• 他们知道如何利用 AI 这个超级放大器，去构建那些曾经遥不可及的庞大系统；
• 他们更知道，在何处设置隔离墙、在何处切断依赖，以防止 AI 的狂飙突进反噬整个工程底座。

代码的海洋正在以前所未有的速度膨胀。在这个波澜壮阔的航海时代，大模型只是为你提供狂风的引擎。

而能否避开暗礁、最终驶向那座名为“伟大产品”的彼岸，依然取决于握着达摩克利斯之剑的你——一个拥有智慧、直觉和系统大局观的人类工程师。

资料链接：https://www.youtube.com/watch?v=2n41YjR5QfU

今日互动探讨：

如果你的团队明天代码产出量突然飙升 10 倍，你现有的 CI/CD 流水线和 Code Review 流程还能撑得住吗？你会优先改造哪个环节？

欢迎在评论区分享你的“系统级防御”策略，我们一起交流 AI 时代的工程生存法则！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「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/31/google-io-2026-defining-the-agentic-ai-era

大家好，我是Tony Bai。

在刚刚结束的 Google I/O 2026 第二天的主题论坛上，一场被称为“决定下一个十年科技走向”的圆桌会议拉开了帷幕。

这场会议的阵容堪称奢华：

• Jeff Dean：谷歌首席科学家，Gemini 联合负责人，硅谷传奇编译器与分布式系统大神。
• Liz Reid：掌管着谷歌核心命脉——“谷歌搜索（Search）”的全球负责人。
• Koray Kavukcuoglu：DeepMind 首席技术官（CTO）兼谷歌首席 AI 架构师。
• Josh Woodard：Gemini 消费端应用、AI Studio 及 Google Labs 的掌舵人。

在这场高密度的技术对谈中，四位巨头向全球开发者宣布了一个极其震撼的行业共识：AI 已经全面跨入“智能体（Agent）时代”。而这个时代的到来，正在彻底瓦解并重构我们维系了数十年的软件开发范式与人机交互界面。

大模型不再只是一个陪你聊天的对话框，而是演变成了能够 24/7 独立工作的“数字员工集群”。在这场波澜壮阔的变革中，软件工程、硬件设计乃至人类程序员的职业路径，都迎来了颠覆性的重塑。

范式转移：从“同步对话框”到“异步任务控制中心（Mission Control）”

过去，我们使用计算机和 AI 的方式是“同步”的：你敲击键盘，期望系统在几毫秒或几秒内给出反馈。

但当 Gemini 3.5 带着强大的长期推理（Long Horizon Reasoning）和多模态理解能力到来时，“人机交互的时延观”被彻底颠覆了。

用户的“容忍时延”与任务价值成正比

搜索业务负责人 Liz 提出了一个非常新颖的系统设计理论：“用户的等待意愿，取决于你帮他省去了多少工作量。”

• 如果用户只想查一个快速答案，你必须在几毫秒内闪电般响应；
• 但如果用户让你“规划一个未来三周的度假行程、预订所有酒店并安排好行程单”——这个任务原本需要人类花费 20 到 30 分钟。此时，即便 AI 需要在后台思考、调用工具、反复验证并运行整整 1 分钟，用户也会极其耐心地等待。

异步时代的“任务控制台”

基于这种时延观的变化，Josh 透露，Gemini 应用端正在全速部署名为 Gemini Spark 的 24/7 始终在线的 Agent 核心。

它的行为模式完全是“异步”的：

• 你可以给它设定触发器（Triggers）：“如果收到重要邮件，立刻自动在后台做完背景调查，写好回复草稿，但千万别替我发送（人类在环中）。”
• 它可以像一个虚拟秘书一样，每天早晨默默扫描你的日程表，然后主动提醒你：“今天有三个会毫无意义，我建议你取消，并且我已经帮你写好了体面的拒绝话术。”

在这样的时代，人机交互界面将不再是一个“输入-输出”的对话框，而是一个类似于 NASA 控制大厅（Mission Control）的“仪表盘”。 你在这里发布任务、观察 30 个虚拟实习生的工作进度，并在关键节点进行一键确认。

杰夫·迪恩（Jeff Dean）的终极预言：软件将变得“即用即弃”（Ephemeral Software）

在整场对话中，最具思想穿透力的观点来自于 Jeff Dean 针对“软件本质”的工程哲学推演。

在传统的软件工程里，由于“软件开发成本极高”，我们被迫采用“标准化”的策略——开发一套通用的 ERP、一套通用的日程表、一套通用的播放器，然后让全世界不同需求的人去削足适履地适应这套软件。

但在 Agent 时代，这个商业逻辑将不复存在。

“在未来，因为大模型可以进行超长周期的自主开发，你可以直接让 AI 针对你当下的特定、临时需求，去‘无中生有’地定制一套专属软件。”Jeff Dean 展望道。

1. 软件的“转瞬即逝性（Ephemerality）”：你告诉 Agent：“我今天想用这种特异的视觉格式整理我的财务报表。”Agent 会立刻在后台自动写出代码，编译运行，生成一个精美的、专属于你此时此刻使用的可视化管理后台。
2. 用完即丢弃：你用完之后，直接把这套软件删掉。因为它的生成成本几乎为零。当下个月模型升级了，或者你有了新需求，直接让 AI 重新生成一套更好的。
3. 什么是永恒的？：软件代码本身变成了转瞬即逝的消耗品，只有你的数据（Data）、你的业务上下文（Context）以及你调教 AI 的指令集，才是企业最核心、最需要被精心守护的资产。

机器速度（Machine Speed）对传统代码的清洗：一晚将 Python 翻译为 Go

当 Agent 的运行速度提升到极限时，系统工程师们遇到了全新的物理瓶颈——阿姆达尔定律（Amdahl’s law）的无情审判。

Jeff Dean 分享了一个谷歌内部刚刚发生的真实工程案例：

大模型在调用外部工具时，其处理速度是极快的。但是，许多现有的内部工程工具当初是人类为了自己使用而用 Python 编写的。Python 缓慢的启动时间和运行时性能，在 Agent 进行高频并发调用时，成了最致命的堵塞点。

“如果 AI 在工具调用上浪费了 50% 的时间，哪怕你的模型推理芯片（TPU）快到无限大，你的系统整体速度最多也只能提升 2 倍。”

为了消灭这个瓶颈，谷歌团队想出了一个极其“简洁粗暴”的解法：让大模型对自己的工具链进行彻底的系统级重构。

[自然语言需求描述]
       ||
       \/
+------------------+         翻译与自动测试          +--------------------+
| 历史遗留 Python 工具 | =========================> |  全新 Go 语言工具   |
+------------------+      (一晚完成，性能提升20x)    +--------------------+

“我们直接把那些用 Python 写的工具和它们对应的完整测试集（Tests）丢给 Gemini 3.5。我们告诉它：‘请帮我把这个系统完好无损地翻译成 Go 语言。’”

因为有完整的测试集作为 spec（规范约束），这是一个对模型而言定义极其清晰的重构任务。仅仅通过一个晚上的后台自动运转，大模型就将谷歌大量的内部工具链全部用 Go 语言重写了一遍，系统运行速度瞬间飙升了 10 到 20 倍！

这个真实的案例不仅证明了 Agent 的自我进化能力，更再次无情地印证了我们之前的判断：在 AI 时代的运行时与工具链编排层，Go 语言正在凭借其极致的启动速度和并发能力，成为无可动摇的底层基座。

软硬件共生：八代 TPU 与 Antigravity 的全栈合围

为什么谷歌能率先在搜索和消费级应用中跑通如此沉重的 Agent 场景？因为谷歌拥有从芯片到应用的最深“护城河”——全栈 AI（Full Stack AI）的共生优势。

第八代 TPU：训练与推理的彻底解耦

Jeff Dean 指出，到了第八代 TPU，谷歌在硬件层面做出了重大的架构分离：不再让一颗芯片兼顾所有工作，而是针对“训练（Training）”和“推理 serving（Inference）”设计了完全不同的物理芯片架构。

这种硬件层面的精细化设计，直接反映在了 Gemini 3.5 恐怖的推理和响应速度上。哪怕是后台多智能体高并发调度，底层的硬件和软件 serving 栈也能提供丝滑的支撑。

Antigravity（反重力）SDK 的全面赋能

在应用层，Koray 强调，谷歌不仅在内部将用 Go 编写的 Antigravity 平台注入了谷歌搜索的核心（实现高度可定制的搜索信息智能体），更通过 Antigravity SDK 将这套经过海量用户洗礼的“多智能体编排底座”毫无保留地开放给了全球开发者。

无论你是独立开发者还是大厂，你都可以用谷歌搜索同款的底层 SDK，去构建你自己的多智能体协作网络。

变革之下的生存法则：大模型时代，程序员该如何自我迭代？

面对这样一个“AI 自己写工具、自己写软件、自己取消无用会议”的时代，人类程序员是否真的要迎来失业的黄昏？

作为硅谷技术之神，Jeff Dean 给出了一项极其务实且充满希望的建议。当被问及“2026 年最核心的开发者技能是什么”时，他回答道：

“学会如何使用代码工具与智能体，来让自己变得更具创造力，去构建那些在以前看起来不可思议的庞大系统。”

在 Agent 时代，开发者的工作逻辑发生了根本性的转变：

• 消灭“冷启动成本（Startup Cost）”：以前你想写一个数据分析工具，你得先去查 API 文档、折腾包依赖、初始化工程，大把时间浪费在非核心工作上。现在，你可以把这些“脏活累活”全部扔给 Agent，自己在高维层面进行架构把控。
• 打破岗位边界，重回“建造者（Builders）”：产品经理（PM）可以直接修改 design.md 文件，让 Agent 实时渲染出界面并当场调整创意，而不用再去和设计师、前端开发进行无休止的开会扯皮。人类不再只是单纯的“写代码机器（Coders）”，而是重新拿回了掌控全局、释放创意的“创造者”身份。

在这个被 AI 加持的黎明，人类工程师的职责，正在从“手写代码的泥瓦匠”升级为“指挥群星的建筑师”。

那座由代码筑起的钢铁巨塔，非但没有在 AI 的浪潮中坍塌，反而因为智能体的加入，正变得更加宏伟、精密、高耸入云。而掌控着设计图纸的我们，正在迎来职业生涯中，最波澜壮阔的黄金时代。

资料链接：https://www.youtube.com/live/krMacZewAGE

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「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/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. 版权所有.