本文永久链接 – https://tonybai.com/2026/05/07/aws-guru-slams-go-concurrency-as-a-joke-vs-jvm

大家好，我是Tony Bai。

过去十年，如果要在后端技术圈选出一个“金字招牌”，那无疑是 Go 语言的并发。

凭借其极简的 go 关键字和优雅的 channel，Go 将并发编程的门槛从“博士级”拉到了“入门级”。在云原生和微服务的浪潮中，Go 几乎就是“高并发”的代名词。

但就在前几天，AWS 的资深布道师 James Ward，在 X 平台上突然向 Go 语言的这个“优势高地”发起了猛烈炮轰：

“开发者普遍认为 Go 在并发方面很出色。但事实并非如此。JVM 的方案要优越得多。当你把虚拟线程、结构化并发和 Effects 加进来时，它甚至是全行业最好的方案之一。”

为了证明自己的观点，他还引用了前 Google 工程师 Ahmetb（以其在 K8s 社区的贡献而闻名）设计的一道极其刁钻的并发编程“考题”——实现一个工业级的、线程安全的网络连接池。

这道题，像一块试金石，炸出了 Go 并发模型背后那些被“易用性”所掩盖的无数“天坑”。

这场由大神发起的“语言战争”，瞬间引爆了技术圈。从前 Uber 工程师到 Victoria Metrics 的核心开发者，无数 Gopher 下场“护驾”。

今天，我们就来复盘这场神仙打架，看看当 Go 的“平民法拉利”遭遇现代 JVM 的“德系重装甲”时，到底谁才是真正的并发之王？

战火的点燃：一道价值千金的“并发考题”

让我们先来看看点燃这场战争的导火索，Ahmetb 设计的这道“连接池”考题：

你需要实现一个线程安全的、有界连接池。
1. Acquire()：当池中无可用连接时，必须阻塞。必须响应 context 的超时和取消。
2. Release()：归还连接。如果池已满或连接已损坏，则关闭连接而不是泄漏。
3. Close()：必须干净利落地关闭整个池。停止接受新请求，立即关闭所有空闲连接，并等待所有正在被使用的连接被归还后，再关闭它们。
4. IdleTimeout：自动清理超过空闲时长的连接。

这道题，看似简单，实则布满了“杀机”。

它几乎涵盖了并发编程中所有最令人头疼的场景：资源限制、优雅启停、生命周期管理、超时与取消、后台清理……

Ahmetb 坦言：

“如果你享受 Go 的并发原语，那就挑战一下自己去实现它。这里面的边缘情况，比我最初想象的要多得多。”

而 James Ward 正是借着这道题，打出了他的第一炮：用 Go 的原生 channel 和 select 去完美地解决所有这些问题，其代码量和心智负担，将远超现代 JVM 的解决方案。

两派的交锋：Go 的“野路子” vs JVM 的“正规军”

面对 James 的炮轰，评论区迅速分裂成两大阵营。

Go 阵营（以实战派为首）的反击：

前 Uber 工程师 Ovais Tariq 现身说法：

“Go 在高并发工作负载下更优越——这是我在 Uber 运营大规模 Go 服务的实践经验。”

另一位开发者则指出了 Go 的核心优势：

“我完全同意（Go 更优）。这个工具（Go）被创造出来，就是为了无缝处理成千上万个大部分时间都在‘等待’I/O 的任务。在这个角色上，Go 至今仍然表现卓越。”

Go 阵营的核心观点是：Go 的并发模型（Goroutine + Channel），就像一把简单、锋利的匕首。它足够轻、足够快，虽然需要使用者自己具备高超的技巧，但在真实的、海量的 I/O 密集型场景下，它的实战表现就是最好的证明。

JVM 阵营（以理论派为首）的降维打击：

James Ward 则对这些“实践经验”嗤之以鼻：

“真的吗？像 Scala ZIO 这样的 Effect 调度器和虚拟线程，在安全处理非阻塞任务时，看起来比 Goroutine 要容易得多。”

JVM 阵营的核心观点是：Go 的并发原语太“低级”了。 它把所有关于取消、超时、错误传播、资源清理的复杂性，全部甩给了开发者。而现代 JVM 生态，通过虚拟线程、结构化并发（Structured Concurrency）和函数式 Effect 系统（如 ZIO, Arrow Fx），已经从语言和框架层面，为你提供了一套“三位一体”的、体系化的解决方案。

• 虚拟线程：让 JVM 拥有了和 Goroutine 一样廉价的“百万级”并发能力。
• 结构化并发：强制所有并发任务拥有清晰的父子关系和生命周期，彻底消灭“野 Goroutine”和资源泄漏。
• Effect 系统：用类型系统来管理异步任务的副作用，让并发代码像写同步代码一样清晰和安全。

这场争论的本质，是“游击队”与“正规军”的对决。Go 提供了最灵活的单兵作战武器，而 JVM 则提供了一整套陆海空协同作战的军事体系。

Go 的“平民化”哲学 vs JVM 的“专家级”哲学

在这场混乱的口水战中，Victoria Metrics 的工程师 Phuong Le 的一篇复盘长文，将整个讨论提升到了哲学的高度。

他没有去争论谁快谁慢，而是深刻地剖析了两种技术路线背后的设计哲学差异：

“Go 在并发方面并不差。一个更真实的说法是：Go 擅长让并发变得廉价、显式和易于上手，尤其是在常见的后端模式中。”

Phuong Le 指出，Go 的核心优势在于“平民化（Approachable）”。

它用极其简单的原语，让一个普通的开发者，也能快速地写出“看起来能用”的并发代码。但这种“简单”的代价是，它把大量的“正确性”责任，下放给了开发者自己。

“Go 给了你相对低级的原语。大量关于取消、任务生命周期、清理、错误传播和背压的正确性保证，都留给了我们程序员自己去处理。”

而现代 JVM 生态，则走向了另一个极端——“专家系统”。

它试图在框架和语言层面，构建一个极其复杂、但理论上绝对安全的“象牙塔”。开发者需要学习大量的概念（Monad, Functor, Fiber…），但一旦学会，就能获得极高的安全性保障。

Phuong Le 的结论是：

“所以，公平的比较不是‘Go vs JVM，谁赢？’，而是：Go 优化的是简单的、实用的并发；而现代 JVM 生态，拥有更强大的工具来处理结构化的、资源安全的并发。 到底哪个更好，取决于你面临的并发问题有多复杂。”

你的团队，需要匕首还是航母？

这场神仙打架，最终没有赢家。但它为我们所有后端架构师，提供了一次极其宝贵的“架构选型”公开课。

1. 承认 Go 的“天花板”

我们必须承认，Go 的原生并发原语，在处理极其复杂的、需要精细化资源管理的场景时，确实存在“天花板”。Ahmetb 的那道“连接池”考题，就是一个完美的试金石。如果你团队的业务复杂到这种程度，直接引入一个成熟的第三方库（或者评估 JVM 生态），可能比自己手搓 Channel 要明智得多。

2. 警惕 JVM 的“学习曲线”

虚拟线程虽然抹平了 JVM 在并发“数量”上与 Go 的差距，但结构化并发和 Effect 系统，依然是较为陡峭的学习曲线。在一个追求快速迭代、人员流动频繁的团队里，引入这些“重型武器”的培训成本和心智负担，是必须被严肃评估的。(注：不知道有多少Java开发至今也没有使用过虚拟线程)

3. “足够好”也许就是最好的

评论区里，Jacob Voytko 的观点极具代表性：

“Go 的并发原语并非在所有方面都理想，但对于终端用户（业务开发者）大多数时候写的那些东西来说，它们是完美的。管理 fan-in/fan-out、处理带超时的异步任务……对于这些 80% 的场景，Go 的‘足够好’方案已经足够了。”

小结：没有银弹，只有权衡

这场由 James Ward 发起的“Go 并发之战”，最终以一场关于“架构权衡（Trade-offs）”的深刻反思而告终。

它像一面镜子，照出了我们这个行业最真实的底色：从来没有“最好的”语言，只有“最适合的”场景。

Go 的成功，在于它用最简单的武器，解决了云原生时代最大多数的并发问题。它的哲学，是牺牲一部分理论上的“完美”，去换取工程上的“极致效率”。

而现代 JVM 的进化，则代表了另一种可能：通过不断叠加更高级的抽象，去追求一个理论上“绝对安全”的并发乌托邦。

作为架构师，我们的终极使命，不是去争论哪条路更高贵，而是在理解了所有路径的代价之后，为我们的团队、我们的业务，选择那条最务实的、能活着走到终点的路。

资料链接：

• https://x.com/JamesWard/status/2049498133013344285
• https://x.com/func25/status/2050243999123009662
• https://x.com/ahmetb/status/2049341220707844340

今日互动探讨：

你如何看待 James Ward“Go 并发不行”的观点？在你的实战中，Goroutine+Channel 是否真的“够用”？或者你更期待 Go 能引入类似 JVM 的“结构化并发”？

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

还在为写 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/06/robert-griesemer-on-go-arrow-functions

大家好，我是Tony Bai。

在 Go 语言的演进史上，很少有一个 Issue 能像 #21498 这样，跨越 9 年时光，累积近千条评论，却依然让官方核心团队如履薄冰。

这个 Issue 的目标很单纯：为 Go 提供一种更简洁的匿名函数语法（Short Function Literals）。或者用大白话说，大家想要一个像 JavaScript 或 Rust 那样的“箭头函数”。

每当一个 Gopher 在代码里写下：

slices.SortFunc(users, func(a, b User) int { return cmp.Compare(a.Age, b.Age) })

他大概率会在心里暗骂一句：“这代码真够笨重的。”

然而，Go 团队对此的回应一直是：“我们不想要魔法，我们只想要清晰。” 这种坚持让社区陷入了长达数年的僵局。

但就在最近，这场僵局似乎正在被化解。

Go 语言之父之一的Robert Griesemer 亲自下场发表了一段重量级评论。他没有给出一个试图满足所有人的复杂方案，而是抛出了一个充满工程智慧的诠释：

“也许试图为任何函数解决这个语法问题是误导性的。我们应该只为那些本来就很短的函数提供支持。”

今天，我们就来看看 Robert 最新诠释中的这个“只解决 90% 问题”的箭头函数，到底长什么样？应该如何用？

底层觉醒：放弃对“全能语法”的执念

Robert Griesemer 的这段话，实际上是对过去 9 年社区争论的一次“终极复盘”。

在这 9 年里，无数天才开发者试图设计出一种“完美”的缩写语法：有的想省掉括号，有的想省掉类型声明，有的甚至想通过 $1, $2 这样的占位符来彻底消灭参数列表。

但这些方案无一例外都让 Go 编译器头疼，更让代码的可读性变得支离破碎。

Robert 意识到，真正的问题不在于匿名函数太长，而在于我们试图让“箭头函数”承载它本不该承载的重量。

如果一个匿名函数里包含了 if 逻辑、for 循环、甚至是一个 switch 分支，那么它本质上就是一个多行逻辑块。对于这种逻辑，写出完整的 func() 语法，带上明确的参数名和结果类型，不仅不是负担，反而是对读者的仁慈。

于是，Robert 划定了一条冷酷的边界线：短函数语法，只服务于单表达式或单语句。

蓝图拆解：Robert 亲自执笔的语法模型

在 Robert 的设想中，Go 的短函数（箭头函数）应该由两个核心部分组成。

第一部分：针对“有返回值”的场景（单表达式）

这是高阶函数（如 Map、Filter、Sort）最常用的场景。Robert 提议采用 (args) -> expr 的符号：

ShortFunctionLit = “(” [ IdentifierList ] “)” “->” ( Expression | “(” ExpressionList “)” ) .

这意味着你可以写出如下的代码：

() -> 42                         // 无参数，返回常数
(x) -> math.Sin(x)               // 单参数，返回计算结果
(x, y) -> x < y                  // 多参数，返回布尔值
(x, y) -> (x + y, x * y)         // 多返回值（需括号包裹）

这里的精髓在于两点：

1. 彻底消灭 return 关键字：如果右侧是一个表达式，结果会自动返回。
2. 极简的类型推断：由于它是作为参数传递给某个已知签名的函数（赋值上下文），编译器可以 100% 确定 x 和 y 的类型。你不再需要写 (a int, b int) int 这种啰嗦的废话。

第二部分：针对“无返回值”的场景（单语句）

除了返回值，还有一种场景是“简单回调”：执行一个动作，但不返回结果。

为了严格区分这两种场景，Robert 引入了一个极其精妙的设计：利用大括号 {} 来作为“不返回结果”的视觉信号。

ShortFunctionLit = … | “{” SimpleStmt “}” ) .

例子如下：

() -> { /* do nothing */ }
(x) -> { fmt.Printf("log: %v\n", x) } // 执行打印，无返回
(x) -> { ch <- x }                    // 往通道发数据，无返回
(p) -> { (*p)++ }                     // 修改指针值，无返回

Robert 的设计逻辑非常清晰：

• 没有 {}：必须返回一个值（表达式）。
• 有 {}：必须不返回值（语句）。

这个视觉区分，让任何一个读者在扫过代码的一瞬间，就能理解这个匿名函数的副作用。

架构师的必修课：为什么“只解决 90%”才是最佳答案？

Robert 在评论中提到：

“这能解决 90% 的常见案例，就像短变量声明（:=）一样。”

这正是这篇文章最值得我们升维思考的地方。

一个平庸的语言设计者，会试图通过复杂的规则去覆盖 100% 的场景，最终让语言变得像 C++ 一样臃肿。而一个顶级的语言设计者（如 Robert），懂得利用“帕累托法则（二八定律）”。

:= 并不完美，它在某些特定的作用域重叠情况下会引发困惑。但它解决了 90% 的声明问题，让 Go 代码变得极其清爽。

同样，Robert 提出的这个“箭头函数”蓝图：

• 它不能写多行逻辑？ 没关系，剩下的 10% 复杂场景，写 func() 更有助于维护。
• 它不能省掉参数括号？ 没关系，强制带上 () 可以避免解析歧义，保持 Go 一贯的“明确”风格。

*这种“克制”的艺术，正是 Go 语言在云原生时代能够取得成功的重要原因之一。** 它不追求在每一行代码上都胜过别人，它追求的是在大规模协作、在百万行代码库的维护上，保持最低的认知负荷。

未来的模样：现代化的代码重构

Robert 在文章末尾甚至已经想好了如何推广这个特性：

“如果我们引入了这个短格式，我们可以一键使用现代工具（modernizer）将现有的所有旧代码重写。”

想象一下，当你把你的项目升级到未来的 Go 版本，运行一下格式化命令。原本满屏的：

users.Map(func(u User) string {
    return u.Name
})

会瞬间收缩为：

users.Map((u) -> u.Name)

这既是字符的缩减，更是一场视觉的解放。

小结：在万变中，寻找最地道的“Go 味儿”

看完 Robert Griesemer 的这份亲述，你是否感受到了一种跨越时空的工程美学？

箭头函数在其他语言里早就不是新闻了。但 Go 团队为了把它设计得“更地道、更不容易出错、更符合长期维护利益”，足足纠结了 9 年。

这种对语法的敬畏，才是我们作为开发者真正应该学习的财富。最好的技术方案，往往不是那个功能最全的，而是那个能以最小的代价，解决最普遍痛点的。

只解决 90% 的问题，剩下的 10% 留给严谨与克制。

这，就是 Go 语言的“中庸之道”，也是它最强大的地方。

今日互动探讨：

你认同 Robert 这种“只做单行缩写”的底线吗？你觉得在 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/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. 版权所有.

本文永久链接 – https://tonybai.com/2026/05/03/flask-creator-pi-author-on-ai-coding-the-cruel-truth

大家好，我是Tony Bai。

过去的一年，我们见证了 AI 工具从“玩具”到“神器”的进化。从 Copilot 到 Claude Code，再到OpenClaw和Hermes等，整个技术圈都沉浸在一种“效率无限提升”的乐观主义狂欢之中。

但就在前几天，两位在开源世界里的大神——Flask 框架之父 Armin Ronacher 和 Pi (OpenClaw的agent runtime) 的创造者 Mario Zechner——进行了一场极其深刻、甚至有些“悲观”的对话。

他们没有去鼓吹 AI 带来了多高的效率，反而用一种极其冷静的视角，对当下这场“AI 狂欢”提出了拷问。这场对话，值得我们每一个身处其中的技术人，暂停手中飞速生成的代码，静下心来，一字一句地读完。

幻灭的开端：从“代码的奴隶”到“代码的奴隶主”

故事的开端，源于两位大神对 AI 的“第一印象”。

作为 Flask 的作者，Armin Ronacher 最初对 Copilot 的出现充满了警惕。他做的第一件事，就是去“钓鱼执法”，诱导 Copilot 复现那段著名的《雷神之锤III》中的快速平方根倒数算法，并发现 AI 果然在没有正确署名的情况下，吐出了 GPL 协议的代码。

而 Mario Zechner，这位同样拥有数十年开发经验的老炮，则是在厌倦了 Claude Code 越来越臃肿、越来越不可控之后，愤然决定自己动手，从零打造一个极简的编码智能体——Pi。

两位大神殊途同归，最终都成了 AI Agent 的重度用户。但他们发现，这场看似美好的“生产力革命”，正在把我们引向一个危险的深渊。

血泪的教训：当 Agent 失去“痛感”

访谈中，Mario 提出了一个极其深刻的洞见：AI Agent 正在用“无痛”的方式，批量制造“屎山（Slop）”。

“人类是有痛感的。当你写了一段极其恶心的代码，你会感到痛苦。为了避免这种痛苦，你会花时间去重构，去梳理架构。痛苦，逼着人类去学习和进化。”

“但 Agent 呢？它是一台没有感情的打字机。它可以在几分钟内生成两万行代码。如果其中包含了一个微小的设计缺陷，它不会感到痛苦。相反，它会在你看不见的地方，将这个缺陷以成百上千倍的速度复利式地放大。”

Armin 对此深有同感。他把 AI 生成的代码，比作一个“涌现式状态机（Emergence State Machine）”。

“我们曾经重构过一个游戏的撮合系统，里面有 16 个布尔值标志位，理论上只有 6 个有效状态，但实际上却能组合出几何级爆炸的可能状态。AI 生成的代码就是这样，它为了处理各种异常，会不断地添加 catch 和默认值，让你的系统在不知不觉中，变得比人类手写的屎山还要复杂。”

更可怕的是，这些屎山一旦形成，连 AI 自己都救不了。因为当代码库膨胀到一定程度后，Agent 极其有限的上下文窗口，让它只能基于局部的视野（Local View）去做决策，最终在“修复”的过程中，制造出更多的垃圾。

架构师的终极拷问：我们正在失去“摩擦力”

在这场对话中，Armin 提出了一个极其反直觉、却又极具哲学思辨的观点：一个好的工程系统，需要被刻意地注入“摩擦力（Friction）”。

“在最好的工程团队里，为了让服务更成熟，你需要定义 SLO，你需要做 Code Review，你需要让架构委员会审批。这些看似‘官僚’的流程，其实是在故意减慢速度，逼着你去思考：我真的需要做这个改动吗？”

“但现在，所有人都想把这些‘摩擦力’去掉，好让 Agent 能更自主地运行。结果就是，我们失去了刹车。”

这个观点，完美地解释了为什么软件质量正在全面倒退。

当一个产品经理、甚至市场部员工，都能用 AI 在几分钟内生成一个看似可行的功能并提交 PR 时，整个工程的“质检防线”就被彻底冲垮了。

两种路线的博弈：MCP vs CLI

对话中，两位大神还深入探讨了当前 Agent 工具链的两种路线之争：MCP（模型上下文协议） vs CLI（命令行界面）。

• MCP：被大厂（尤其是 Anthropic）主推，试图为 AI 定义一套标准化的、结构化的工具调用接口。
• CLI：被社区极客（如 OpenClaw）所钟爱，直接把 50 年前的 Unix 命令行哲学，扔给大模型。

Armin 认为，MCP 在企业级的 Auth（认证） 场景下有其价值，但在“组合性（Composability）”上却是一场灾难。

“MCP 就像是给 AI 一堆独立的、互不相关的玩具。而 CLI，给了 AI 一整套乐高积木和管道。当 AI 拿到 curl、grep、sort 这些工具时，它能自发地创造出你从未预料到的、极其强大的工作流。”

Mario 对此完全赞同，并补充道，Pi 的核心哲学，就是将一切能力都封装成 CLI 工具，然后通过“自修改”的方式，让 AI 自己去扩展自己的工具集。

“Pi 没有 MCP 支持，但用户可以自己教 Pi 去构建一个 MCP Server。Pi 本身，是可以自我进化的。”

人类的最后防线：从“写代码”到“品代码”

在这场充满悲观与反思的对话中，两位大神依然为我们这些身处其中的人类工程师，指明了一条生路。

第一，夺回“说不”的权力。

Mario：“一个好的工程师，是那个经常说‘不’的人。这能让系统的复杂性保持在最低。但当你用 Agent 时，你会忍不住说‘是、是、是’，因为你不需要自己打字了。”

第二，从“代码编写者”进化为“代码品鉴师”。

Armin：“我不再享受‘把一个函数写得天衣无缝’的快感了。因为机器能做得更好。我的乐趣，转移到了‘理解整个系统’上。因为在‘雕琢细节’这件事上，我们已经失去了杠杆。”

第三，拥抱“慢思考”与“主动重构”。

Mario：“我会有意地放慢速度。我强迫自己去重构那些 AI 生成的代码，因为只有通过重构，我才能真正理解系统的脉络，重新找回那种‘人剑合一’的感觉。”

AI 正在剥夺我们“感受痛苦”的权利，而这，恰恰是我们作为人类工程师最宝贵的财富。

小结：在狂欢中，保持清醒

这场持续了一个多小时的对话，没有给出任何关于“如何写 Prompt”的答案。

但这两位穿越了数个技术周期的智者，用他们的人生经验，为我们揭示了 AI 这场史无前例的巨浪中，唯一能抓住的几块礁石：

1. 警惕“无痛”的效率提升，那是系统腐化的开始。
2. 放弃对“全自动化”的幻想，人类必须永远在环（Human-in-the-loop）之中。
3. 你的核心价值，不再是“写得多快”，而是“看得多深”。

机器可以写下每一行代码，但只有你，才能为这堆代码注入灵魂，并为它的最终结果，承担责任。

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

今日互动探讨：

在使用 AI 编程后，你是否也像 Armin Ronacher 一样，感觉失去了那种“雕琢代码”的快感？在 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/02/from-vibe-coding-to-agentic-engineering-karpathy-survival-guide

大家好，我是Tony Bai。

过去的一年，我们中的许多人，都经历了一种全新的、令人上瘾的编码体验，它被前特斯拉 AI 总监 Andrej Karpathy 戏称为 “Vibe-Coding（氛围编码）”。

我们不再逐行挣扎，而是凭着“感觉”，用模糊的自然语言指挥 AI，看着代码在屏幕上如瀑布般涌现。

这种“氛围感”，让编程的门槛被前所未有地夷为平地。但它也像一剂甜蜜的毒药，正在麻痹我们的工程知觉。

就在前几天，在红杉资本组织的 AI Ascent 2026 顶级峰会上，Karpathy 再次发声，为这场狂欢踩下了“刹车”。

他警告说，如果我们仅仅停留在“Vibe-Coding”的舒适区，我们将很快被时代淘汰。真正的未来，属于一种更严谨、更具工程化思维的全新范式——“Agentic Engineering（智能体工程）”。

今天，我们就来深度拆解 Karpathy 的这场最新演讲，看看从“Vibe-Coding”到“Agentic Engineering”，到底隔着怎样一条鸿沟，以及我们作为普通开发者，该如何掌握这套 AI 时代的终极“生存法则”。

两个时代：当“代码消费者”遇见“代码指挥家”

Karpathy 在演讲中，清晰地描绘了两种截然不同的开发者画像。

第一种：Vibe Coder（氛围感编码者）

这是 AI 时代的“新手村玩家”。他们是 AI 生成代码的“消费者”。

他们的典型特征是：

• 对 AI 有着近乎“盲目”的信任。
• 将 AI 视为一个能解决一切问题的“黑盒许愿池”。
• 当 AI 犯错时，他们无法理解错误的根源，只能通过不断调整 Prompt 来“玄学 Debug”。

Karpathy 坦言，自从去年 12 月大模型能力发生“突变”后，他自己也曾沉迷于 Vibe-Coding。

“我只是不停地要求更多，而它（AI）输出的总是对的。我记不清我上一次纠正它是什么时候了。”

但这种“顺滑”的体验，恰恰是最危险的。

第二种：Agentic Engineer（智能体工程师）

这是 AI 时代的“高阶玩家”。他们是 AI Agent 的“指挥家”和“架构师”。

他们深刻理解 AI 的能力边界，并将 AI 视为一个强大但不稳定、需要被严格约束的“实习生”。

他们的核心工作，不再是“写代码”，而是：

1. 为 Agent 构建坚不可摧的“护栏（Guardrails）”。
2. 设计一套能够自动化验证 Agent 产出的“评测体系（Evals）”。
3. 将自己的“品味（Taste）”和“判断力（Judgment）”固化为系统规则。

Karpathy 总结道：

“Vibe-Coding 是在提升所有人的下限。而 Agentic Engineering，是在探索质量与效率的上限。”

生存法则一：警惕“参差不齐的智能”

从“Vibe Coder”进化为“Agentic Engineer”的第一步，是彻底放弃对 AI“无所不能”的幻想，深刻理解其“参差不齐的智能（Jagged Intelligence）”。

Karpathy 提出了一个经典的“卡帕西难题”：

“为什么 Claude Opus 4.7 能够在一瞬间重构十万行代码、发现 0-day 漏洞，但当你问它‘我想到 50 米外的洗车店洗车，我该开车还是走路？’时，它却会一本正经地告诉你应该走路？”

这种“时而天才，时而智障”的诡异表现，源于 AI 的训练机制。大模型的能力，高度依赖于“可验证性（Verifiability）”和“数据分布（Data Distribution）”。

• 在代码和数学这种拥有“绝对正确答案”的领域，AI 可以通过海量的强化学习获得极高的能力。
• 但在那些充满人类常识、没有标准答案的领域，AI 的表现就会变得极其不稳定。

作为一个智能体工程师，你必须像一个经验丰富的老猎人，清晰地知道你面前这头“猛兽”的狩猎范围。在它擅长的领域，大胆授权；在它不擅长的领域，寸步不让。

生存法则二：从“实现者”退到“设计师”

当 AI 接管了“How（如何实现）”之后，人类工程师的唯一护城河，就只剩下了“What（做什么）”和“Why（为什么做）”。

Karpathy 举了他自己写的 MenuGen 项目的例子。AI 生成了一个版本，试图用 email 地址去关联 Stripe 支付和 Google 登录。

“这是一个极其愚蠢的错误。因为用户完全可能用不同的邮箱。但 AI 不知道。这种判断力、这种对业务的审美（Taste），是 AI 暂时无法拥有的。”

停止在代码的细枝末节上与 AI 较劲。把你的时间，投入到更高维度的抽象工作中去——梳理业务逻辑、定义系统边界、规划数据流转。

AI 可以帮你画出每一块砖，但只有你，才能画出整座教堂的蓝图。

生存法则三：外包你的思考，但别外包你的理解

这是 Karpathy 在整场演讲中，提出的最核心、也最具有哲学思辨的一条法则。

“最近有一条推文让我非常震撼：你可以外包你的思考，但你无法外包你的理解（You can outsource your thinking but you can’t outsource your understanding）。”

AI 可以替你思考如何用一个高效的算法来解决问题，它可以替你思考如何组织代码的结构。

但它无法替你理解这个系统为何而建，无法替你理解你的用户真实的需求，更无法替你理解一个微小的改动可能对整个系统带来的长远影响。

把 AI 当作一个无限算力的“外部大脑”，去帮你探索、试错、执行。但最终，所有的信息都必须回流到你自己的“内部大脑”中，由你来完成最关键的“理解”与“决策”闭环。

你，才是系统的最终责任人。

终极图景：软件 3.0 与“神经计算机”

在演讲的结尾，Karpathy 描绘了一幅极其遥远、甚至有些科幻的未来图景。

他认为，我们正在从“经典计算机”时代，重新回归到上世纪 50 年代那个“神经计算机”与“图灵机”分道扬镳的历史岔路口。

“未来，神经网络可能会成为‘主处理器’，而我们现在的 CPU，则降级为处理确定性任务的‘协处理器’。”

在这个被他称为“软件 3.0”的时代，软件的形态将被彻底重塑。我们将不再编写传统的 UI 界面，而是直接将摄像头采集的原始视频流，喂给一个巨大的神经网络，由它通过扩散模型（Diffusion），实时地为你“画”出一个独一无二的界面。

我们作为工程师的角色，将变成定义这个世界的“传感器（Sensors）”和“执行器（Actuators）”，并为 Agent Native（智能体原生）的世界，重写所有的基础设施。

小结：在不确定的浪潮中，抓住不变的礁石

Andrej Karpathy 的这场演讲，没有给出任何一行代码，却比任何一篇技术教程都更令人震撼。

他用一种极其诚实、甚至有些残酷的方式，为我们揭示了从“Vibe-Coding”到“Agentic Engineering”的进化路径。

AI 正在用它的“参差不齐”，逼迫我们放弃对“编码”这项体力劳动的迷恋，转而去拥抱那些更高级、更接近本质的人类智慧——理解、品味、与判断。

“你可以外包你的思考，但你无法外包你的理解。”

这或许是对 AI 时代，我们这些“数字工匠”最深刻、也最充满希望的生存箴言。

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

今日互动探讨：

听完 Karpathy 的分享，你认为自己目前更接近于一个“Vibe Coder”还是“Agentic Engineer”？你认为“你可以外包思考，但无法外包理解”这句话，是对的，还是错的？

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

还在为写 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/01/open-source-civil-war-bun-founder-predicts-ban-on-human-contributions

大家好，我是Tony Bai。

过去的一年，AI 编程的浪潮席卷了整个技术圈。但在这片繁荣之下，一场关于“开源精神与 AI 伦理”的深刻裂痕，正在悄然扩大。

就在前几天，这场裂痕，以一种极其戏剧性的方式，被彻底引爆了。

事件的导火索，来自当红 JavaScript 运行时 Bun 的一则看似平平无奇的技术更新：Bun 团队 fork 了 Zig 语言的编译器，通过引入并行分析等优化，将自己的调试构建速度提升了 4 倍。

但真正引爆全网的，是 Bun 官方账号在 X 平台发布的一条补充说明：

“我们目前不打算将这些改进提交回上游（Zig 社区），因为 Zig 有一条严格的禁令：禁止任何由 LLM（大模型）创作的贡献。”

这条推文，像一根火柴，瞬间点燃了整个开源社区的火药桶。

Bun 的创始人 Jarred Sumner 更是亲自下场，抛出了一个极其激进、甚至有些“疯狂”的预言：

“我预感开源社区会走向另一个极端：未来将不再允许人类贡献代码。人类写的垃圾代码（Slop），将成为 2025 和 2026 年的怀旧遗物。”

一边是 Zig 社区对 AI 的严防死守，另一边是 Bun 创始人对“纯 AI 开发”的狂热鼓吹。这场突如其来的“内战”，引来了包括网景创始人 Marc Andreessen、开源运动领袖 Eric S. Raymond 等一众硅谷大佬的围观和站队。

今天，我们就来复盘这场神仙打架，看看在这场关于“Pro-AI”与“Anti-AI”的论战背后，到底隐藏着怎样的技术哲学、利益博弈与生存法则。

分裂的开端：当“贡献”的定义被改写

Zig 社区为什么要禁止 AI 贡献？

这背后，是传统开源精神对“贡献”二字的捍卫。在他们看来，一个 Pull Request 不仅仅是一段代码，它更代表了贡献者投入的心血、思考、以及对社区文化的认同。

而由 AI 生成的、未经深入理解的“垃圾代码（Slop）”，正在无情地摧毁这种信任契约，将 Code Review 的沉重负担，转嫁给那些用爱发电的维护者。

但 Bun 的创始人 Jarred Sumner 显然不这么认为。他坚信，AI 将彻底重塑生产关系。

在他的设想中，未来的开源协作将是这样的：

“和人类不同，AI 会严格遵守你的代码风格指南，并在几分钟内完成你提出的每一个修改。它们会编写详尽的测试和文档。它们会研究竞争对手的实现方案。它们会不知疲倦地进行迭代，直到通过所有第三方的一致性测试。”

在这场辩论中，著名浏览器 Ladybird 的作者 Andreas Kling，给出了一个更宏大、也更令人不安的预言：

“我的猜测是，开源社区将分裂成两个阵营：Pro-AI（亲 AI）和 Anti-AI（反 AI）。
1. Pro-AI 阵营的项目，将以惊人的速度超越 Anti-AI 阵营。
2. 那些被 Anti-AI 项目拖慢了脚步的 Pro-AI 开发者，最终会选择 fork 或者重写这些项目。”

Bun 对 Zig 的这次 fork，似乎正是这个预言的第一次应验。

神仙打架：硅谷大佬的站队与嘲讽

这场论战迅速升级，引来了各路神仙的围观。

传奇投资人、a16z 联合创始人 Marc Andreessen，用一个简单的“+1”表情，旗帜鲜明地站在了 Jarred Sumner 的“未来无人类”阵营。

开源运动的“教父级”人物、《大教堂与集市》的作者 Eric S. Raymond，也对“Anti-AI”派发起了无情的嘲讽：

“我发现了一个规律。在开源社区里，那些反对 AI 的人，和之前被‘Woke Mind Virus’（觉醒文化病毒）完全俘获的，是同一批人。他们是白痴。 这是我作为创始人的肺腑之言。”

当然，也有大量的资深开发者对 Jarred 的观点嗤之以鼻。

一名游戏引擎开发者直接发问：

“在保持高质量标准的前提下，‘超越’的证据在哪里？还是说你认为质量对于客户来说已经不重要了？”

Gary Marcus（著名 AI 评论家）更是引用了一句名言来讽刺 AI 的不可靠：

“当你不了解一个主题时，AI 看起来最令人印象深刻。一旦你对某个领域了如指掌，你就会发现它说的全是废话。”

AI 时代的“阶级固化”：谁在定义“高质量”？

这场争论的背后，其实隐藏着一个更深层次的权力问题：当 AI 能够生成 90% 的代码时，谁来定义剩下的 10% 的“质量”？

Bun 创始人 Jarred Sumner 的答案是：Agent。

他认为，未来的代码质量将由自动化的测试、严格的类型系统和不知疲倦的 Agent 来保证，人类的角色将被无限削弱。

但反对者认为，这是一种极其天真的“技术幻想”。

Darren Shepherd（Rancher 联合创始人）在评论中指出：

“所有迹象都表明，未来由 AI 辅助生成的代码，其质量将远高于纯人类编写和维护的代码。”

这场辩论最终走向了一个无法调和的哲学分歧：

• Pro-AI 派相信，通过强大的 Harness（驾驭系统）和自动化评估（Evals），AI 生成代码的质量和速度，将很快超越人类的上限。
• Anti-AI 派则坚信，软件工程中那些最宝贵的特质——品味、洞察力、对复杂系统的直觉——是 AI 永远无法模拟的。而放任 AI 生产“看似合理”的代码，最终只会导致整个行业的“审美降级”和“智力衰退”。

生存法则：在“内战”中，我们该如何站队？

作为身处一线的工程师，我们不必陷入这种非黑即白的“信仰之争”。

无论是 Pro-AI 还是 Anti-AI，在这场混乱的辩论中，我们依然能找到几条极其清晰的生存法则。

第一，警惕“立场先行”，回归“工程现实”。

无论是 Bun 还是 Zig，他们的选择，都是基于自身项目所处的特定工程阶段和社区文化。

• Zig：作为一门底层语言，它追求的是极致的稳定性和可预测性。任何由黑盒 AI 生成的、可能引入未知风险的代码，都是不可接受的。
• Bun：作为一门上层应用的运行时，它追求的是极致的迭代速度和生态兼容性。为此，他们愿意拥抱 AI，甚至不惜与上游社区决裂。

你的项目，更像 Zig，还是更像 Bun？这个问题，比单纯地喊“AI 万岁”或“AI 垃圾”要有意义得多。

第二，不要成为“AI 的传声筒”，要做“AI 的驾驭者”。

即使在 Pro-AI 阵营内部，大佬们也普遍承认一个事实：无脑地让 AI “Vibe-Coding”，结果就是灾难。

你需要为 AI 构建强大的“护栏（Guardrails）”，你需要设计精密的“评测体系（Evals）”，你需要像一个真正的架构师一样，去定义系统的边界和验收标准。

AI 正在把开发者的能力，从“写代码”，向上推到“设计系统”和“定义规则”。

第三，拥抱“阵营分裂”的未来。

Andreas Kling 的预言，大概率会成为现实。

未来的开源世界，将不再是一个“其乐融融”的大家庭。它会分裂成：
* Anti-AI 社区：坚守人类智慧的最后防线，可能会变得更加封闭、审核更严，成为“小而美”的精英俱乐部。
* Pro-AI 社区：以惊人的速度进行迭代和演进，可能会涌现出大量创新，但同时也伴随着巨大的混乱和泡沫。

作为开发者，你需要提前思考：你的价值观和职业规划，更适合哪一个“宇宙”？

小结：一场没有回头路的豪赌

Bun 与 Zig 的这次“决裂”，可能只是未来十年开源社区大分裂的第一次预演。

当 Jarred Sumner 喊出“未来将禁止人类贡献”时，他开启了一场极其危险的“社会实验”。这背后，是资本对“效率”的无限渴求，是对“开源社区协作成本”的极度不耐烦。

而 Zig 社区的坚守，则是对“人类智慧不可替代性”的最后捍卫。

这场战争，没有对错，只有选择。

但无论你选择哪条路，请记住：工具终将过时，但工程的智慧与审美的品味，永不褪色。

资料链接：https://x.com/i/trending/2048470411793563936

今日互动探讨：

你更认同 Bun 的“Pro-AI”哲学，还是 Zig 的“Anti-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/04/30/ghostty-creator-leads-github-exodus-cto-apology-go-fix

大家好，我是Tony Bai。

在程序员的江湖里，GitHub 从来不仅仅是一个代码托管平台。它是开源精神的麦加，是数千万开发者的“赛博故乡”，是这个行业赖以运转的、最坚实的“基础设施”。

但就在近几个月，这座我们无比信赖的“圣城”，似乎正在走向“崩塌”。

4 月 28 日，Github 的第1299位用户，在自己的推特与博客上发表了一篇极其悲伤的“分手信”，标题是：《Ghostty Is Leaving GitHub》（Ghostty 正在离开 GitHub）。

这位用户，不是别人，正是 HashiCorp 的联合创始人、一手缔造了 Terraform、Vagrant、Vault、Consul 等一系列云原生和 Devops 神器的“教父级”人物——Mitchell Hashimoto。而 Ghostty，正是他当下倾注心血的、备受期待的新一代终端项目。

他在这封信中，用一种近乎“心碎”的口吻写道：

“写下这些让我感到莫名的悲伤。我从 2008 年 2 月开始使用 GitHub，至今已超过 18 年，横跨了我半个人生。……我曾深爱着 GitHub，胜过一个人应该去爱一个东西。但现在，我受够了。18 年了，我得走了。”

是什么，让这位曾经的“ GitHub骨灰粉”毅然决然地带着自己的“亲儿子”项目“出走”呢？

答案简单得令人窒息：GitHub 正在变得越来越不可用。

“在过去的一个月里，我用日记记录了每一次 GitHub 宕机对我工作的影响。几乎每一天，旁边都画着一个‘X’。就在我写下这些文字的时候，GitHub Actions 又挂了 2 个小时。……如果一个平台每天都要瘫痪几个小时，那它就不再是一个适合严肃工作的地方。”

Mitchell 的这封“分手信”，像一颗炸弹，瞬间引爆了整个技术圈。

就在文章发布的几个小时后，GitHub 的 CTO Vlad Fedorov 紧急发表了一篇官方博客，标题同样沉重：《An update on GitHub availability》（关于 GitHub 可用性的更新）。

在这篇近乎“道歉信”的回应中，GitHub 官方不仅承认了问题的严重性，更罕见地揭示了这场“可用性雪崩”背后的真正罪魁祸首，以及他们正在秘密进行的“技术自救”——其中，Go 语言扮演了至关重要的“救火队长”角色。

今天，就让我们来复盘一下这场由“分手信”引发的技术公案。

压垮骆驼的稻草：被 AI “撑爆”的古老架构

GitHub 到底怎么了？

在官方的回应中，CTO Vlad Fedorov 给我们展示了一张极其恐怖的增长曲线图：“Record Acceleration”（创纪录的加速）。

自 2025 年下半年以来，随着 AI Agent（智能体）编程工作流的急剧加速，GitHub 的各项核心指标都呈现出近乎垂直的指数级增长：

• 每月新增仓库数：2000 万
• 每月合并的 PR 数：9000 万
• 每月 Commits 数：14 亿

GitHub 官方坦言：

“这种指数级的增长，不是只对一个系统造成压力。一个 PR 会触及 Git 存储、合并检查、分支保护、GitHub Actions、搜索、通知、权限、API、后台任务、缓存和数据库。在巨大的规模下，微小的低效会被无限放大。”

队列加深、缓存击穿、索引落后……这些经典的分布式系统“并发症”，在 AI 制造的流量洪峰面前，被彻底引爆了。

Mitchell Hashimoto 的“出走”，只不过是压垮骆驼的最后一根稻草。

Go 语言的救赎：从 Ruby 单体地狱中“紧急救火”

面对这场史无前例的“流量洪水”，GitHub 的工程师们正在进行一场惊心动魄的“架构自救”。

在官方博客的What we’re doing一小节中，我们看到了一个熟悉的身影——Go 语言。

“我们加速了将性能或规模敏感的代码，从 Ruby 单体应用中迁移到 Go 语言的过程。”

这短短的一句话，信息量巨大。它揭示了 GitHub 这座“上古神殿”最核心的技术债之一：一些庞大、沉重、且难以扩展的 Ruby 单体应用。

在过去，当我们需要提升性能时，可能会选择更深入地优化 Ruby 代码，或者在前面加更多的缓存。

但在 AI 时代，这种“小修小补”可能已经毫无意义了。面对 10 倍甚至 30 倍的流量增长预期，唯一的出路，就是对系统进行“外科手术式”的重构。

为什么选择 Go 来“救火”？

因为 Go 语言几乎是为这种“救火”场景量身定制的：

1. 极致的性能与并发：Go 的性能远超 Ruby，其原生的 Goroutine 并发模型，能极其轻松地榨干现代多核服务器的性能，应对海量的网络请求。
2. 极低的资源占用：相比于 Ruby 或 Python 这种动态语言，Go 的内存占用更小、更可控，能极大地降低服务器成本。
3. 简单的部署：静态编译的单一二进制文件，使得将新的 Go 微服务部署到庞大的 Kubernetes 集群中，变得极其简单。

我们可以想象，在 GitHub 内部，正有无数个由 Go 语言编写的、小而美的微服务，像一支支训练有素的“消防队”，正在冲入火场，小心翼翼地从那个庞大的 Ruby 巨人身上，一块块地切下那些已经“燃烧”的性能瓶颈模块（如 Webhooks、认证授权、Git 操作等）。

Go 语言，正在成为 GitHub 这艘巨轮在 AI 洪流中，避免沉没的“压舱石”。

从“深情”到“决绝”：一个顶级开发者的 18 年之痒

Mitchell 的“分手信”，之所以能在社区引发如此巨大的共鸣，不仅仅是因为他的技术地位，更在于信中那份令人动容的“爱之深，责之切”。

他坦言，自己 20 岁时创建 Vagrant 这个成名作，很大程度上就是为了能获得一份在 GitHub 的工作。

“GitHub 是我的梦想。那里的工程师令人难以置信，产品令人难以置信。在过去的 18 年里，我每天都在呼吸着它的空气。”

“当我的感情经历挫折时，我把自己沉浸在 GitHub 的开源世界里；当我在大学里通宵时，我会在凌晨 4 点偷偷提交一个 commit；甚至在我的蜜月期间，我都会趁着妻子还在睡觉时，打开 GitHub。”

但正是这份深沉的爱，让 GitHub 的每一次宕机，都像一把刀子，刺在他的心上。

“这对我来说是私人的。我对 GitHub 的爱，超过了一个人应该对一个东西的爱。所以我对它感到愤怒。”

在文章的最后，他给所有“Git 是分布式的，你怕什么”的言论，给出了最沉重的回击：

“问题不在于 Git，而在于我们围绕它建立的、赖以为生的基础设施：Issues, PRs, Actions……如果它每天都要让你停工几个小时，那它就不再是一个适合严肃工作的地方。”

小结：当“基础设施”不再是理所当然

Mitchell Hashimoto 的“出走”，和 GitHub 官方的“道歉”，共同为我们揭示了 AI 时代一个极其深刻的现实：

当生产力工具的效率被提升 10 倍、100 倍时，它对底层基础设施稳定性的要求，也将被以同样指数级的规模放大。

我们曾经以为像水和电一样“理所当然”的 GitHub，正在成为整个行业发展的瓶颈。

这场危机，对 GitHub 来说是“生死存亡”的挑战，但对我们这些身处其中的技术人来说，又何尝不是一次“机遇”？

它告诉我们：

1. 基础软件领域，永远有仗可打。 当所有人都涌向应用层，去卷 AI Agent 的花活时，那些能用 Go 或 Rust，去重构和加固底层基础设施的硬核工程师，其价值将变得空前稀缺。
2. “稳定性”是最高的壁垒。 在一个功能可以被 AI 瞬间生成的时代，一个系统的长期价值，越来越多地体现在它的可用性、可靠性和可扩展性上。
3. 保持警惕，准备“B 计划”。 将所有的鸡蛋都放在 GitHub 这一个篮子里，可能不再是一个明智的选择。无论是自建 GitLab或Forgejo，还是探索其他新兴的代码协作平台，都值得我们重新审视。

旧神正在踉跄，新王尚未诞生。

在这场由 AI 引发的、史无前例的“基础设施大迁徙”中，你，准备好你的船票了吗？

资料链接：

• https://mitchellh.com/writing/ghostty-leaving-github
• https://github.blog/news-insights/company-news/an-update-on-github-availability/
• https://x.com/mitchellh/status/2049213597419774026

今日互动探讨：

在过去几个月里，你是否也曾被 GitHub 的频繁宕机所困扰？你认为 GitHub 这次“中年危机”的根源，真的是 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/04/29/go-1-27-default-simd-for-amd64-portable-simd-proposal

大家好，我是Tony Bai。

过去十年，Go 语言以其惊人的简洁和强大的并发能力，席卷了整个云原生领域。但在这片繁荣之下，一个尴尬的“阿喀琉斯之踵”，始终困扰着所有追求极致性能的 Gopher：

Go 语言，无法像 C++ 或 Rust 那样，原生且优雅地利用现代 CPU 的 SIMD（单指令多数据流）能力。

当你需要处理海量数据（如向量计算、图像处理、加解密）时，手写 Go 代码的性能，往往会被隔壁 C++/Rust 的 SIMD 优化版本，拉开数倍甚至数十倍的差距。为了榨干 CPU 的最后一滴性能，我们不得不去手写那些极其晦涩、难以维护、且无法被 GC 优雅调度的 Go 汇编。

但就在今年年初发布的Go 1.26版本中，这场长达十年的“性能怨念”，终于迎来了终结的曙光。Go 1.26以实验特性形式在AMD64架构上提供了SIMD的支持。

近期，Go 核心团队在官方 GitHub 仓库中，又密集地抛出了一系列重磅提案（#78902, #78979等）。这些提案不仅宣告了在 Go 1.26 中实验性加入的 SIMD 功能大获成功，更进一步宣布： 在即将到来的 Go 1.27 中，simd/archsimd 包将默认开启！同时，一个早已规划好的、架构无关的“可移植（Portable）”SIMD API 也已正式提案！

Go 团队试图用一种极其“Go-like”的优雅方式，为我们揭开 SIMD 这头性能怪兽的封印。

今天，就让我们来拆解这场 Go 语言的“性能下半场”革命，看看 Go 团队到底在下一盘怎样的大棋。

Go 的 SIMD 哲学：syscall vs os 的“两层模型”

要理解 Go 的 SIMD 设计，我们必须先看懂官方在 Issue #73787 中提出的核心哲学——“两层模型（Two-level approach）”。

Go 团队清醒地认识到，SIMD 的世界充满了矛盾：

• 底层：硬件指令集是非可移植的（Non-portable）。AMD64 上的 AVX512、ARM 上的 NEON/SVE、Wasm 里的 SIMD，它们的向量宽度、指令名称、甚至掩码（Mask）的表示方式都截然不同。
• 上层：Go 语言的核心魅力，恰恰是它的可移植性（Portability）。一份代码，处处运行。

如何调和这个矛盾？Go 团队从标准库中 syscall 和 os 包的关系里，找到了灵感。

第一层：simd/archsimd —— 你的“syscall”

这一层，是架构绑定的、低级别的。它将 CPU 的 SIMD 指令，近乎一对一地封装成 Go 的函数。比如 VPADDD 指令，就对应着 Uint32x4.Add()。

这一层追求的是极致的表达力和与硬件的零距离。它就是为那些需要手写汇编的“性能狂人”准备的。如果你想调用某个 AVX512 的独有指令，来这里就对了。

第二层：simd —— 你的“os”

这一层，将是架构无关的、高级别的。它会定义一套通用的、不依赖特定向量宽度的向量类型（如 simd.Float32s），以及一套通用的操作（如 Add, Mul）。

当你写下 a.Add(b) 时，编译器会根据你当前的编译目标（GOARCH），自动将其翻译成最高效的底层 archsimd 指令。

这一层追求的是极致的可移植性和易用性。对于 99% 的开发者来说，你只需要和这一层打交道。

硬核拆解：Go 1.27 即将转正的 simd/archsimd

在 Go 1.26 的 GOEXPERIMENT=simd 实验成功后，Go 团队在 Issue #78979 中正式提案，将 simd/archsimd for AMD64 在 Go 1.27 中默认开启！

让我们来一睹这把“屠龙刀”的真容：

1. 强类型的向量定义

告别 unsafe.Pointer 和丑陋的字节数组！archsimd 为不同位宽和数据类型，定义了极其清晰的结构体：

// 128位，4个 uint32
type Uint32x4 struct { a0, a1, a2, a3 uint32 }
// 256位，8个 float32
type Float32x8 struct { /* ... */ }

2. 易于理解的方法链

所有的 SIMD 操作，都被设计成了易于阅读和链式调用的方法。注释里甚至贴心地标出了对应的汇编指令。

// Add each element of two vectors.
//
// Equivalent to x86 instruction VPADDD.
func (Uint32x4) Add(Uint32x4) Uint32x4

3. 抽象的掩码（Mask）类型

如何处理不同架构下千奇百怪的掩码，是 SIMD API 设计中最头疼的问题。Go 团队选择了用一个不透明的 Mask 类型来屏蔽底层差异，让编译器自己去选择最高效的实现（K-register 还是 Vector-register）。

Go的野心：可移植的 simd 包提案出炉

如果说 archsimd 只是让 Go “追平”了 C++/Rust，那么 Issue #78902 中提出的高级 simd 包，则真正展现了 Go 语言的“野心”——在可移植性上，超越所有前辈。

在这个提案中，dr2chase 描绘了一个极其诱人的未来。你将可以这样写代码：

// 一个 inner product 示例
func ip(x, y []float32) float32 {
    var a simd.Float32s // 注意！这里没有指定位宽！
    var i int
    // a.Len() 会在运行时自动返回当前 CPU 支持的最佳向量宽度
    for i = 0; i < len(x)-a.Len()+1; i += a.Len() {
        u := simd.LoadFloat32Slice(x[i : i+a.Len()])
        v := simd.LoadFloat32Slice(y[i : i+a.Len()])
        a = a.Add(u.Mul(v))
    }
    // ... 处理剩余的尾部数据
    return sum(a) // 水平求和
}

sum函数在amd64平台的具体实现：

//go:build amd64
package main
import (
    "simd"
    "simd/archsimd"
)

func sum(x simd.Float32s) float32 {
    switch a := x.ToArch().(type) {
    case archsimd.Float32x8:
        a = a.AddPairsGrouped(a)
        a = a.AddPairsGrouped(a)
        return a.GetLo().GetElem(0) + a.GetHi().GetElem(0)
    case archsimd.Float32x16:
        s := make([]float32, a.Len())
        a.StoreSlice(s)
        var r float32
        for _, e := range s {
            r += e
        }
        return r
    case archsimd.Float32x4:
        s := make([]float32, a.Len())
        a.StoreSlice(s)
        var r float32
        for _, e := range s {
            r += e
        }
        return r
    }
    panic("not a known type")
}

看懂了吗？

你只需要写一份代码，把它扔到一台只支持 AVX2 的机器上，a.Len() 会返回 8；把它扔到一台支持 AVX512 的机器上，a.Len() 会自动变成 16！

编译器会自动为你生成多个版本的代码，并在运行时动态选择最优路径。这彻底将开发者从“为不同 CPU 手写不同优化版本”的地狱中解放了出来。

神仙打架：一场关于“命名哲学”的激烈辩论

在 Issue #73787 的评论区，一场关于 SIMD 函数命名哲学的“神仙打架”，精彩绝伦。

• 以 Ian Lance Taylor 为首的“专家派”认为：

  “应该直接使用 VPADDD 这样的汇编指令名。这对于专家来说更友好，他们不需要在脑子里多做一次‘Go 风格名称’到‘Intel 手册名称’的翻译。”

• 以 Cherry Mui 为首的“可读性派”则坚决反对：

  “代码的读者，远比代码的作者多。一个普通开发者能轻易猜出 Add 的意思，但绝对猜不出 VPADDD 是什么鬼。我们应该为读者优化，而不是为专家。”

最终，“可读性派”胜出。这也再次印证了 Go 语言一以贯之的设计哲学：明确性与可读性，永远高于一切。

小结：Go 语言的“性能下半场”

SIMD 的正式入场，标志着 Go 语言的演进，正在进入一个全新的阶段。

如果说过去十年，Go 靠着“并发”和“简洁”赢得了云原生的上半场；那么在未来十年，它将靠着这套兼具“优雅可移植”与“极致性能”的 SIMD 工具链，去硬刚 AI、数据科学、游戏引擎这些性能深水区（如果后续新版本的 AI 学会了如何使用这些新增SIMD特性）。

Go 团队没有选择像 C++ 那样直接暴露几百个晦涩的 Intrinsics，也没有像 Rust 那样在稳定性和表达力之间反复纠结。

它用一套极其深思熟虑的“两层模型”，试图在这场性能的终局之战中，走出一条属于自己的路。

Go 1.27，将是我们所有 Gopher 重新认识这门语言的开始。

那扇通往极致性能的大门，正在被缓缓推开。你，准备好了吗？

资料链接：

• https://github.com/golang/go/issues/73787
• https://github.com/golang/go/issues/78979
• https://github.com/golang/go/issues/78902

今日互动探讨：

在你的日常工作中，有哪些场景是目前 Go 语言性能的瓶颈，让你极其渴望 SIMD 的加持？对于 Go 团队设计的这套“两层 SIMD API”，你是更看好它的“可移植性”还是“性能潜力”？

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

还在为写 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/04/28/go-conditional-expressions-propsal

大家好，我是Tony Bai。

在 Go 语言的江湖里，有一个话题，像幽灵一样，每隔几个月就会重燃战火。它引发的争论之激烈、持续时间之长，甚至超过了当初的“泛型”和“错误处理”。

它就是——三元条件运算符（Ternary Conditional Operator）。

condition ? then : else

这个在 C、Java、JavaScript 里被视为天经地义的语法糖，在 Go 的世界里，却成了一道不可逾越的“柏林墙”。

十几年间，无数开发者前赴后继地在官方 GitHub 仓库发起提案（从 Issue #23248 到 #33171 再到 #78865），用各种详实的数据和血泪案例，请求 Go 核心团队为这门以“简洁”著称的语言，补上这个“最该有”的特性。

但每一次，都遭到了 Go 团队近乎“铁板一块”的无情拒绝。官方 FAQ 里的那句“一门语言只需要一种条件控制流结构”，像一句神圣不可侵犯的教条，终结了所有讨论。

但就在前几天，这座最顽固的堡垒，似乎从内部出现了一丝松动。

Go 语言圣经《The Go Programming Language》的联合作者、Go 核心团队成员、Go 静态分析工具链的大神 Alan Donovan，亲自下场，发起了一个三元运算符的折中提案：Issue #78940。

他提出的新语法，试图在 Go 的“啰嗦哲学”与 C 的“简洁美学”之间，找到一条前人从未走过的“第三条路”。

今天，就让我们来深度复盘这场持续了 15 年的史诗级“内战”，看看 Go 团队为何对一个“小小的”三元运算符如此“深恶痛绝”，以及 Alan Donovan 的“折中提案”，能否为这场旷日持久的战争，画上句号。

为了一个简单的赋值，我被迫写了 5 行代码

让我们先回到一切争论的起点。

在曾经的提案 #78865 中，一位开发者贴出了一个让所有 Gopher 都感同身受的场景：

// 只是想根据一个 bool 值，给变量赋不同的字符串

var priority string
if t.Urgent {
    priority = "high"
} else {
    priority = "normal"
}

看懂了吗？一个在 C 语言里只需要一行 priority = t.Urgent ? “high” : “normal” 就能搞定的简单赋值，在 Go 里，我们被迫写了一个长达 5 行的、笨重的 if-else 流程控制块！

这位开发者甚至写了一个静态分析工具，扫描了包括 golang/go、kubernetes、terraform 在内的多个顶级开源项目。结果惊人：

平均每 6-7 个函数中，就有一个包含这种可以被三元表达式轻易优化的“啰嗦”模式。

这不仅仅是多敲几下键盘的问题。它背后隐藏着更深层次的哲学冲突：

• 三元运算符，是关于“值（Value）”的表达式。
• if-else，是关于“流程（Flow）”的语句。

用一个笨重的“流程控制语句”，去模拟一个轻巧的“值选择表达式”，在很多追求代码表达力的开发者看来，是一种彻头彻尾的“设计缺陷”。

核心团队的“铁壁”：我们到底在恐惧什么？

面对社区排山倒海的请愿，Go 核心团队（主要是 Ian Lance Taylor）为什么十几年如一日地坚决说“不”？

他们的核心论点，在 Issue #33171 的回复中，被总结得淋漓尽致：对“嵌套地狱（Nested Hell）”的恐惧。

在 C 语言中，一个新手程序员很容易写出下面这种连上帝都看不懂的“天书”：

result := a > b ? a > c ? "a" : c > b ? "c" : "b" : b > c ? "b" : "c"

这种缺乏明确括号和作用域的嵌套，极大地增加了代码的阅读和维护成本。

Go 语言从诞生之初，就对这种“隐晦”的复杂性深恶痛绝。它强制 if-else 必须带 {}，就是为了从语法层面杜绝当年 C 语言“悬挂 else”的经典歧义。

Go 团队的哲学是：宁愿让你多写几行“笨”代码，也绝不给你任何机会去写一行“聪明”的、但可能会让同事抓狂的“黑魔法”代码。

社区的声音：这是对开发者的“有罪推定”！

面对Go核心团队的“铁壁”，社区也给出了极其犀利的反驳声音。

一位开发者针对性地指出：

“导致代码不可读的风险，源于‘嵌套’，而不是三元运算符本身。Go 语言并没有限制你写出 15 层嵌套的 if-else。为什么你们相信开发者能管住自己的手不去滥用 if，却不相信他们也能管住手不去滥用 ?: 呢？”

这简直是灵魂拷问。

更重要的是，之前的提案者曾提出，可以通过 go vet 或 linter，在工具链层面直接禁止“嵌套三元表达式”的出现，只允许最简单的“扁平”形式。

Java、C++ 这些拥有三元运算符的工业级语言，早已形成了一套成熟的最佳实践。为什么 Go 社区就不能做到呢？

这种“一刀切”的拒绝，在很多开发者看来，是对整个开发者群体的一种不信任和“有罪推定”。

折中提案：Go 圣经作者的“第三条路”

就在双方僵持不下，ianlancetaylor 再次以“没有新信息”为由准备关闭提案#78865 时，Alan Donovan 出现了。

他没有直接支持经典的 ?: 语法，而是另辟蹊径，提出了一个折中的、极具“Go 语言特色”的语法提案：

(if cond then expr else expr)

这个提案的精妙之处，在于它完美地融合了双方的诉求：

1. 它是一个“表达式（Expression）”，而不是“语句（Statement）”

你可以直接用它来赋值：

role := (if isAdmin then "admin" else "user")

这彻底解决了用 if-else 语句进行赋值的“别扭感”。

2. 它强制使用括号 () 包裹

这是对 Go 语言“明确性”哲学的极致致敬。就像 if 强制使用 {} 一样，() 的强制使用，从语法层面彻底消灭了 C 语言 ?: 运算符在嵌套时产生的歧义和视觉混乱。

嵌套的写法会变得极其清晰（虽然也很丑，但这就是 Go 的目的——让你不想去嵌套它）：

(if (if cond1 then expr1 else expr2) then expr3 else expr4)

3. 它引入了一个新的关键字 then（或者用 ? 替代）

这使得语法在形式上，与传统的 if-else 语句产生了明确的区分，避免了解析器的歧义。

Alan Donovan 的这个提案，试图在“简洁表达力”和“语法无歧义”这两个看似不可调和的矛盾之间，找到一个平衡点。

它既满足了社区对“条件表达式”长达 15 年的渴望，又坚守了 Go 团队对“可读性”和“反魔法”的底线。

小结

Alan Donovan 的新提案（Issue #78940），目前已经被正式提交，并引发了新一轮的激烈讨论。

有人认为这是天才的设计，有人则觉得引入新关键字 then 的代价过高，不如直接用 ?。

这场争论的结果，我们还不得而知。

但它本身，就是 Go 语言魅力的一次完美展现。

它告诉我们：一门伟大的编程语言，其演进过程，从来不是核心团队的“一言堂”。而是在与社区的反复拉扯、辩论、甚至争吵中，不断地寻找那个“更不坏”的解。

Go 对“简单”的定义，也从来不是“代码行数最少”。

它追求的，是一种更高维度的简单——心智负担的最小化（Minimizing Cognitive Load）。

资料链接：

• https://github.com/golang/go/issues/33171
• https://github.com/golang/go/issues/78865
• https://github.com/golang/go/issues/78940

今日互动探讨：

你支持 Go 语言加入三元运算符（或条件表达式）吗？对于 Alan Donovan 提出的 (if cond then expr else expr) 这种新语法，你是拍手叫好，还是觉得多此一举？

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

还在为写 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. 版权所有.