2026-05-14 07:43:21
本文永久链接 – https://tonybai.com/2026/05/14/uncle-bob-esr-on-why-we-are-turning-to-go-and-rust-in-the-ai-era
大家好，我是Tony Bai。
在软件工程的浩瀚星河中，有两位堪称“活化石”级别的宗师：
一位是 Eric S. Raymond (ESR)，开源运动的先驱，那本被誉为开源圣经的《大教堂与集市》以及《Unix编程艺术(The Art of UNIX Programming)》一书均是出自他手。他是一个写了 40 年 C 语言的硬核黑客。
另一位是 Uncle Bob Martin (Bob 大叔)，敏捷宣言的签署人之一，《敏捷软件开发》、《代码整洁之道 (Clean Code)》等程序员经典书籍的作者，无数 Java 和 C# 程序员的精神导师。
这两位加起来写了快一百年代码的传奇人物，最近却在 X (Twitter) 平台上，不约而同地抛出了一个足以引发技术圈大地震的论断：
在如今这个被 AI 席卷的时代，他们双双放弃了自己曾经最擅长的语言（C 和 Java），转而全面拥抱 Go 语言，并在特定底层场景下使用 Rust。
更令人震撼的是，ESR 直接宣告了手工古法编程模式的死刑：
“手写代码的时代基本结束了（The age of hand-coding is mostly over）。现在选择编程语言的标准，已经彻底变了。”
今天，我们就来深度扒开这场顶级黑客的“赛博夜话”，看看在 AI 智能体（Agent）狂飙突进的 2026 年，我们究竟该如何重新审视和选择我们手中的“兵器”。
我们过去是如何选择编程语言的？
语法是否优雅？生态是否繁荣？框架是否齐全？这些都是基于“人类如何高效手写代码”而设定的标准。
但 ESR 尖锐地指出，在如今我们拥有“机器朋友（Robot friends / AI）”来完成绝大部分代码生成和翻译工作的时代，这些旧标准已经失效了。
现在的核心标准只有两个：
1. 你的 AI 朋友，能不能高质量地生成这种语言的代码？
2. 生成之后，作为人类的你，能不能一眼看懂（Review）这些代码？
“如今，我使用什么计算机语言是否顺手，已经不再那么重要了，真正重要的是我正在使用的‘机器朋友’能否高质量地生成它。
同时也重要的是我能否读懂这门语言，因为我需要亲自去审查（Review）这些代码。”
在这个新标准下，那些充满了黑魔法（如各种奇葩的宏、复杂的继承体系、极度隐晦的元编程）的语言，瞬间成了灾难。因为当 AI 吐出几百行充满魔法的代码时，人类审查的“认知负荷”将是灾难性的。
在这个全新的游戏规则下，两位宗师给出了他们惊人一致的答案。
Bob 大叔的 Go 语言初体验：快、无聊、但完美契合 AI
Bob 大叔在评论区透露，他正在设计一门关于“使用 Agent 进行软件工程”的在线课程。
“在过去，我会选择像 Java、C# 或 JavaScript 这样流行的语言来做课程。但这次我选择了 Go。不是因为它流行，而是因为它很快（Fast）。我的学生们不会花太多精力去钻研 Go 的语法细节，但他们会看到 Go 的表现。”
Go 语言那常被诟病的“啰嗦”和“无聊”，在 AI 时代反而成了最强大的护城河。
因为 Go 的语法极度收敛，没有隐式类型转换，没有复杂的泛型继承。当 AI 生成一段 Go 代码时，那满屏极其直白的 if err != nil，让人类工程师一眼就能看穿它的逻辑底裤。在审查 AI 代码时，没有魔法，就是最高的生产力。
ESR 的决断：别了，我写了 40 年的 C 语言
ESR 的话更具传奇色彩和悲壮感：
“我可能再也不会用 C 语言开新项目了。那除了自虐还有什么意义？我花了 40 年写 C，我非常精通。但我会毫不留恋地把它，连同它的缓冲区溢出、堆破坏、未定义行为和可移植性问题，全部抛在脑后。”
他现在的探索性编程，全部交给了 Python 或 Go。
“我的机器朋友在生成这两种语言的代码时都非常出色。我认为它们在生成 Go 代码时的表现甚至略胜一筹，这可能是因为 Go 语言拥有更小的表面积（smaller surface）。”
(注：Smaller surface 意味着语法简单，AI 预测下一个 Token 时的歧义和错误率极低)
至于 Rust，ESR 将其定位为“终极的降落场”。
当他需要极其坚固的内存安全保证，且代码的探索期已经结束，进入严肃的生产部署阶段时，他会让 AI 把代码翻译成 Rust。
“Rust 满足了我的要求——我发现它写起来很麻烦，但读起来基本没问题。”
这场讨论，不仅是对 Go 和 Rust 的赞歌，更是对一些传统“大厂语言”的残酷揭底。
ESR 毫不客气地吐槽了 Python 曾经的混乱（尽管它现在有了类型提示和 uv 等现代工具，情况有所好转）：
“Python 曾是我的最爱，但在 Python 2 到 Python 3 的灾难性过渡、GIL 导致的并发地狱、以及包管理的混乱之后，我曾对它感到厌倦……如果我现在要写一个比 Python 粘合脚本大得多的东西，我只会耸耸肩，然后直接去用 Go。”
在推特的评论区，另一位开发者的一句话，道出了更多人的心声：
“Go 代码的质量，很大程度上是因为 Go 语言本身往往倾向于极高的质量（因为缺乏炫技的空间）。所以 AI 生成的代码，也顺理成章地继承了这种高质量。”
当一门语言为了迎合人类的“偷懒”和“炫技”而变得越来越复杂时（比如不断叠加新特性的 C++ 和 Java），它在 AI 时代反而会成为一种累赘。
因为 AI 不需要语法糖，AI 需要的是绝对的清晰和确定性。
两位古灰级黑客的这番言论，给所有还在为了“哪种语言的特性更酷炫”而争得面红耳赤的年轻程序员，狠狠地上了一课。
时代的列车已经呼啸而过。
当代码生成不再是瓶颈，软件工程师的核心价值，正在不可逆转地从“Writer（编写者）”向“Reader & Reviewer（阅读者与审查者）”迁移。
在这个新时代，我们评估一项技术的眼光必须升级：
如果连写了 40 年 C 语言的 Eric S. Raymond，和开创了现代软件工程思维的 Uncle Bob，都能毫不犹豫地放下过去的骄傲，全身心地拥抱 AI、Go 和 Rust。
我们这些普通开发者，还有什么理由紧抱着那些陈旧的“鄙视链”不放呢？
手写代码的时代正在落幕，但软件工程的黄金时代，才刚刚开始。
用 Go 来快速验证和构建业务，用 Rust 来打造坚不可摧的底层，让 AI 成为那个不知疲倦的打字员。这，就是顶级黑客们为我们指明的 2026 年生存法则。
资料链接：https://x.com/esrtweet/status/2054288478750597593
今日互动探讨：
连 Bob 大叔和 ESR 都倒戈了！你同意他们“手写代码时代已结束”、“更看重代码审查的可读性”的观点吗？在日常的 AI 辅助编程中，你觉得哪种语言的体验最好？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-13 08:44:46
本文永久链接 – https://tonybai.com/2026/05/13/go-mod-hidden-features-7-secret-switches-in-go-version
大家好，我是Tony Bai。
在这个“CV 工程师(复制粘贴工程师)”盛行的时代，很多 Go 开发者在新建项目时，不会使用go mod init来初始化一个模块，而是会熟练地从别的 go.mod 文件里，复制粘贴那行 go 1.xx，或者直接复制一个starter 脚手架Go 工程。我们似乎都默认了go.mod中go 1.xx 的作用——“嗯，就是声明一下我用的 Go 版本嘛，不重要。”
我们可能会花几天时间去争论 GOMAXPROCS 该设成多少，或者为了一个微小的性能优化而重构代码，但很少有人会去深究这行看似“平平无奇”的指令，到底在 Go 的世界里扮演着怎样的角色。
但如果我今天告诉你，这行被我们忽视了近 8 年的“魔法咒语”，在 Go 工具链的底层，其实悄悄地控制着多达 7 个维度的编译和运行时行为呢？
从你能不能用泛型，到 go mod tidy 的工作模式，再到你的程序在生产环境中的默认行为……这一切，都由这行代码说了算。
最近，我扎进了 Go 语言的源码，试图去解开这个“最熟悉的陌生人”的秘密。而我发现的真相，足以颠覆多数 Gopher 的认知。
今天，就让我们来一场硬核的“源码考古”，逐一拆解这行 go 指令背后的七大用途。
go.mod 中的 go directive 格式如下：
go 1.21.0
它由 golang.org/x/mod/modfile 包解析，并存储在 modfile.File.Go.Version 字段中。
// $GOROOT/src/cmd/vendor/golang.org/x/mod/modfile/rule.go
type Go struct {
Version string // "1.23"
Syntax *Line
}
有趣的是，如果你的 go.mod 文件里没有这一行（比如一些远古项目），Go 工具链并不会报错，而是会默默地为你应用一个默认值：go 1.16。
// $GOROOT/src/cmd/go/internal/gover/version.go
const DefaultGoModVersion = "1.16"
为什么是 1.16 这个看起来有点奇怪的数字？Go 源码的注释给了我们答案：
因为 Go 1.17 对模块图的语义进行了重大修改。为了保证对那些没有 go 指令的、极其古老的项目的兼容性，我们必须保守地假设它遵循 Go 1.16 的规则。这个默认值，永远不会再被提高了。
这背后，体现了 Go 团队对“向后兼容性”近乎偏执的坚守。
这是 go 指令最广为人知、也是最直接的作用：它决定了编译器允许你使用哪些语言特性。
在 Go 的源码深处，go 命令在编译每个包时，都会将 go.mod 中定义的版本号，通过 -lang 标志，像一道“圣旨”一样传递给编译器。
// $GOROOT/src/cmd/compile/internal/noder/irgen.go
conf := types2.Config{
GoVersion: base.Flag.Lang, // 来自 -lang 标志，由 go.mod 的 go directive 决定
...
}
编译器内部的类型检查器，会用一个名为 allowVersion 的函数，来判断你写的某段代码，是否“越界”使用了当前版本还不支持的“未来语法”。
// $GOROOT/src/cmd/compile/internal/types2/version.go
func (check *Checker) allowVersion(want goVersion) bool {
return !check.version.isValid() || check.version.cmp(want) >= 0
}
Go 1.22 修复了 for 循环变量在闭包中常年为人诟病的“共享变量”问题：
// go.mod: go 1.21 → 旧语义，所有迭代共享同一变量
// go.mod: go 1.22 → 新语义，每次迭代独立变量
而这个行为的开关，正是由 go 指令严格控制的。
// 示例：
// 当 go.mod 中是 go 1.21 时，以下代码会打印 3 个 "3"
// 当 go.mod 中是 go 1.22 时，以下代码会打印 0, 1, 2
funcs := make([]func(), 3)
for i := 0; i < 3; i++ {
funcs[i] = func() { fmt.Println(i) }
}
for _, f := range funcs {
f()
}
这意味着，仅仅是修改 go.mod 里的一行数字，就可能让你的程序的输出结果发生根本性的变化！
如果你试图在 go 1.21 的模块里写 for i := range 10，编译器会毫不留情地报错，并清晰地告诉你：“检查你的 go.mod 文件！”
这是 Go 1.17 引入的一项重要优化，它彻底改变了 Go 命令解析依赖图的方式，但很多开发者对此却知之甚少。
在 Go 的源码中，1.17 被定义为一个分水岭：
// src/cmd/go/internal/gover/version.go
ExplicitIndirectVersion = "1.17" // 启用图裁剪的版本
go.mod 中的版本号，将决定你的项目采用哪种依赖图模式：
// $GOROOT/src/cmd/go/internal/modload/modfile.go
func pruningForGoVersion(goVersion string) modPruning {
if gover.Compare(goVersion, gover.ExplicitIndirectVersion) < 0 {
return unpruned // < 1.17：加载完整传递依赖图
}
return pruned // >= 1.17：启用图裁剪
}
go < 1.17（完整模式 Unpruned）：
go >= 1.17（裁剪模式 Pruned）：
# go 1.17+ 的 go.mod 示例：间接依赖被显式列出
require (
github.com/some/direct v1.2.3
github.com/indirect/dep v0.1.0 // indirect ← 1.17+ 才会出现
)
go test all 这样的命令，在不同的 Go 版本下，其“all”所覆盖的范围，竟然是不同的！而这个“结界”的开关，同样是 go 指令。
在源码中，1.16 是另一个分水岭：
这个改动非常微妙，但影响深远。它意味着在 Go 1.16 之后，go test all 不再会因为某个你八竿子打不着的、间接依赖的测试代码写错了而失败，让 all 模式变得更加聚焦和实用。
这是 Go 1.21 引入的最具“魔力”，也最危险的一个特性：go 指令，决定了你的程序在生产环境中的 GODEBUG 默认值！
Go 团队为了在不破坏向后兼容性的前提下，修复一些语言的历史包袱（比如 panic(nil)），引入了 GODEBUG 环境变量。
当编译器在构建你的 main 包时，它会检查 go.mod 里的版本号，然后将一套与该版本行为相匹配的 GODEBUG 默认值，直接编译进你的二进制文件里。
// $GOROOT/src/cmd/go/internal/load/godebug.go
func godebugForGoVersion(v string) map[string]string {
// ...
def := make(map[string]string)
for _, info := range godebugs.All {
if n < info.Changed {
def[info.Name] = info.Old // 使用旧版本的默认值
}
}
return def
}
经典案例：
官方文档说得很清楚：
Go 工具链会修正自己的默认行为，以尽可能地匹配你声明的旧版本。
这意味着，升级 go 指令，是一项具有潜在风险的操作。 它可能在你不经意间，改变程序的运行时行为。
从 Go 1.21 开始，你的电脑上可以同时安装多个 Go 版本。而决定在编译某个特定项目时，到底该用哪个版本的“指挥官”，就是 go 指令。
当你的 GOTOOLCHAIN 环境变量设为 auto 时，go directive 会触发自动工具链切换。
// $GOROOT/src/cmd/go/internal/toolchain/select.go
if gover.Compare(goVers, minVers) > 0 {
gotoolchain = "go" + goVers
// ...
gover.Startup.AutoGoVersion = goVers
// 打印：go: upgrading toolchain to goX.Y.Z (required by go line in go.mod)
}
下面是一个示例：
# go.mod
module example.com/myapp
go 1.23.0
# 你的电脑当前默认安装的是 go1.21.0
# 当你在这个项目下运行 go build 时……
# → Go 命令会发现版本不匹配，自动去下载并切换到 go1.23.0 工具链！
# 并打印：go: upgrading toolchain to go1.23.0 ...
同时，Go 1.21 还引入了“严格版本约束”：一个 go 1.21+ 的模块，其 go 指令版本，必须 大于或等于 它所有依赖模块的 go 版本。
// $GOROOT/src/cmd/go/internal/gover/version.go
// GoStrictVersion is the Go version at which the Go versions became "strict"
// in the sense that every module must have a go version line ≥ all its dependencies.
GoStrictVersion = "1.21"
除了上述几大核心用途，go 指令还在一些细节上，扮演着“幕后推手”的角色。
从 Go 1.17 开始，go mod vendor 会在 vendor/modules.txt 文件里，为每一个依赖项记录其 go 版本：
## explicit; go 1.17
这确保了即使在离线 vendor 模式下，编译器也能为每个包应用正确的语言特性。
# go.mod: go 1.16 → vendor/modules.txt 不含版本信息，统一猜测为 1.16
# go.mod: go 1.17 → vendor/modules.txt 含版本信息，每个包用自己的版本
go 指令的版本，还会影响 tidy 命令在依赖保留范围、go.sum 校验范围、以及间接依赖分组显示等方面的细微行为。
1. 保留的依赖范围
// $GOROOT/src/cmd/go/internal/modcmd/tidy.go
// Go versions 1.17 and higher retain more requirements in order to
// support lazy module loading.
2. go.sum 的校验范围
// $GOROOT/src/cmd/go/internal/gover/version.go
// TidyGoModSumVersion is the Go version at which 'go mod tidy' preserves
// go.mod checksums needed to build test dependencies of packages in "all"
TidyGoModSumVersion = "1.21"
3. 间接依赖的分组显示
SeparateIndirectVersion = "1.17"
// go >= 1.17：// indirect 依赖单独成块
看到这里，你还会觉得 go 1.xx 只是一行简单的版本声明吗？
这短短的一行代码，像一根时间线，串联起了 Go 语言从诞生到成熟的整个演进历史。
go directive
│
├─ 编译器 -lang 标志
│ └─ 控制语言特性（泛型/loopvar/range整数...）
│
├─ 模块图裁剪模式
│ ├─ < 1.17：unpruned（完整传递依赖图）
│ └─ >= 1.17：pruned（显式间接依赖 + 图裁剪）
│
├─ "all" 模式范围
│ ├─ < 1.16：包含外部包的测试依赖
│ └─ >= 1.16：仅主模块的传递导入
│
├─ GODEBUG 运行时默认值
│ └─ 编译进二进制，影响运行时行为
│
├─ Toolchain 自动选择（>= 1.21）
│ └─ GOTOOLCHAIN=auto 时触发工具链下载/切换
│
├─ vendor/modules.txt 版本记录（>= 1.17）
│ └─ 影响 vendor 模式下的语言版本应用
│
└─ go mod tidy 行为
├─ 依赖保留范围
├─ go.sum 校验范围
└─ 间接依赖分组
它既是语言特性的“守门人”，又是模块系统的“总开关”，还是运行时行为的“默认存档”。
它身上，凝聚了 Go 团队对向后兼容性、工程效率、可重现性这三大核心哲学最深刻的思考与权衡。
下一次，当你新建一个项目，或者准备升级 go.mod 里的那个版本号时，请务必三思。
因为你修改的，不仅仅是一个数字，而是你与 Go 工具链之间，一份极其重要、且牵一发而动全身的“契约”。
今日互动探讨：
在你的日常Go编程中，你有没有遇到过写错Go version带来的“坑”？你觉得 Go 语言go.mod中的go version用起来怎样？是否还有改进的地方。
欢迎在评论区分享你的血泪史与感悟！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-12 07:50:26
本文永久链接 – https://tonybai.com/2026/05/12/the-embarrassing-truth-about-rust-adoption-in-china
大家好，我是Tony Bai。
如果只看国内的公众号和社交媒体，你可能会觉得 Rust 在中国IT技术圈已经很火了：大厂在重构核心链路和重写数据工程的基础设施、创业者在搞 Web 3.0和AI 原生开发、甚至连刚毕业的学生都在卷“所有权（Ownership）”。在一片“Rust 必火”的赞歌中，我们似乎已经默认了中国是全球 Rust 生态版图中最强的那一极。
但真相，往往藏在那些没人注意到的冷数据里。
最近，我做了一次极其枯燥的工作。我让Claude 翻阅了全球最权威的 Rust 社区周刊——《This Week in Rust》（简称 TWiR） 2025 年全年的所有 53 期内容，重点抓取了其中“Upcoming Events（近期活动）”板块。
注：可能存在一定幻觉和不准确的地方。
我想看看，在这一整年里，中国到底举办了多少场能够被国际主流社区感知到的 Rust 技术交流(meetup and conf)。
结果令我脊背发凉。
今天，我想撕开这层温情脉脉的“技术繁荣”假象，带大家看看中国 Rust 社区最真实的底色。
在 2025 年的 53 期 TWiR 中，全球范围内的 Rust 活动如火如荼。
更讽刺的数据还在后面。如果我们把目光缩到亚洲：
在 TWiR 的“Asia”板块中，以色列的特拉维夫（Tel Aviv）一个城市，全年的出现频次是 11 次。
是的，你没看错：特拉维夫 > 整个中国大陆 + 中国香港 + 中国台湾省。
全中国 14 亿人口、数千万程序员，在这个全球最活跃的 Rust 观察窗口中，竟然比不上一个中东城市活跃。
难道中国程序员不写 Rust 吗？显然不是。那是谁偷走了中国 Rust 社区的“声音”？
为什么中国 Rust 活动在全球视野中几乎消失了？通过一些调研，我发现了一个极其严重的“结构性问题”。
第一，我们的社区是“内向”且“封闭”的。
在国外，Rust 开发者习惯在 GitHub、Reddit、Discord、Twitter 或是通过电子邮件订阅列表交流。一旦有 Meetup，他们会第一时间向 TWiR 这种全球通用的周刊提交信息，寻求全球开发者的关注。
而我们呢？
我们活跃在微信群、钉钉群、飞书群，或者是在 B站 的某个直播间。
这些平台，本质上是“信息的黑洞”。 它们无法被搜索引擎抓取，无法被国际社区感知，甚至连跨个群都费劲。我们在一个个封闭的小圈子里讨论着高深的生命周期和异步并发，却对外面的世界“一声不吭”。
第二，中国开发者正在丧失“国际社区意识”。
即便是在 2025 年中国 Rust 的两个高光时刻——3 月的 Rust Asia 2025 (香港) 和 9 月的 RustChinaConf 2025 (杭州)，它们的曝光也是极其短暂的。
正如一位社区大佬所言：“如果你不在推特和 GitHub 上发声，你就相当于不存在。”
我们这种“躲进小楼成一统”的行为，正在让中国 Rust 生态沦为全球版图上的一个“暗物质”。
还有一个更深层的原因：中国 Rust 应用的“两极分化”极其严重。
在一极，是像字节跳动（ByteDance）、PingCAP、蚂蚁集团这样的顶级玩家。
他们拥有极深的技术功底，在核心系统中使用 Rust 已经到了炉火纯青的地步。但问题在于，这些能力被封锁在大厂的围墙之内。他们更倾向于内部的技术内卷，而不是建立开放的、具有影响力的公共社区。
在另一极，是广大的、依然在 CRUD 泥潭里挣扎的普通开发者。
对于他们来说，Rust 太难、编译太慢、门槛太高。他们看不到实际的应用案例，找不到线下的交流圈子，只能在网上看着“Rust 必火”的营销号文章陷入焦虑。
缺乏“中间层”的连接，导致中国 Rust 社区没有持续的、小规模的、日常化的技术碰撞(Meetup)。
我们只有一年一度的大会，却没有每周一次的 Meetup。这就好比一个只有春晚却没有日常市集的村庄，死气沉沉。
编程语言的生命力，不仅取决于它的编译器有多牛逼，更取决于它的社区网络效应。
当中国的 Rust 开发者集体消失在全球视野中，我们会失去什么？
Rust 的吉祥物是一只螃蟹（Ferris）。螃蟹虽然有硬壳，但它不应该只生活在自己的小沙洞里。
在国际视角下的中国 Rust 社区的“冷”，可能并不是用的人少，而是我们“跑得太慢、声音太小”。
如果你正在参与一个 Rust 项目，如果你所在的公司正在筹备一场技术分享，请记住：
除了发朋友圈，请去 GitHub 提个 PR，去 TWiR 投个稿，去国际社区喊一声：“Hey, we are here!”
不要让 2026 年的统计数据，依然显示中国是那个“隐形”的国家。
技术无国界，但影响力的版图，需要每一位开发者用行动去标注。
资料链接：https://this-week-in-rust.org/blog/archives/index.html
今日互动探讨：
看完这份数据，你感到惊讶吗？你觉得是什么阻碍了你参与国际开源社区的讨论？在你的身边，Rust 真的火了吗？
欢迎在评论区分享你的真心话！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-11 06:58:44
本文永久链接 – https://tonybai.com/2026/05/11/go-vs-rust-backend-architecture-the-2026-strategy
大家好，我是Tony Bai。
如果你经常逛各大技术社区，你一定会发现一个永远充满火药味的话题：Go 和 Rust，到底谁才是未来的后端霸主？
两派的支持者常常吵得不可开交。Go 开发者嘲笑 Rust 编译器像个严厉的教导主任，写个代码能让人掉光头发；Rust 开发者则鄙视 Go 的 GC（垃圾回收）带来的延迟毛刺，觉得它就是个“性能玩具”。
但在真实的商业战场上，这种“非黑即白”的零和博弈毫无意义。
最近，海外技术团队 CodeStax.Ai 发表了一篇文章，题目非常霸气：《Rust vs Go：2026 年唯一有意义的后端语言对决》。
这篇文章没有去纠结语法的优劣，而是直接从企业成本、团队扩张、以及系统演进的宏观视角，给出了一个极具颠覆性，却又务实到令人拍案叫绝的架构结论：
“用 Go 来构建（Build）系统，用 Rust 来优化（Optimize）系统。”
今天，我们就来拆解这套现代后端的终极生存哲学，看看顶级的架构师们，是如何在这对“冰与火”的语言中找到完美平衡的。
在讲语言之前，我们必须先认清系统演进的残酷规律。
当你刚刚启动一个新项目时，一切都很美好。
你用微服务框架快速拉起几个 API，部署到 AWS 的容器服务（ECS）里，挂上消息队列（SQS）。一切都运转良好：接口响应很快，团队每个星期都能迭代新功能，老板很开心，每月的云服务器账单也完全在可控范围内。
直到有一天，增长（Growth）发生了。
流量呈指数级上升。突然之间，原本平稳的系统开始出现各种诡异的症状：
这就是所有后端系统迟早都会撞上的“那堵墙（The Wall）”。
当撞墙的那一刻，老板问你的问题，将不再是：“我们最快多久能把这个功能做出来？”
而是变成了极其致命的灵魂拷问：
“我们如何在不拖慢业务团队开发速度的前提下，让这个庞大的系统保持稳定、高效，并且把那该死的云账单降下来？”
正是在这堵墙面前，Go 和 Rust 的选择，才真正具有了生死攸关的意义。
在跨越“那堵墙”之前的大部分时间里，以及在墙外 80% 的业务场景中，Go 语言是毫无争议的默认王者。
为什么？因为现代的后端架构，本质上不再是写一个庞大的单体应用，而是在做“服务编排（Orchestration）”。
你需要一个 API 网关来接收请求，需要一个个微服务去读写数据库（RDS），需要 Worker 去消费消息队列（Kafka），还需要后台的定时任务去跑批处理。
这些错综复杂的分布式场景，对语言的要求出奇的一致：
Go 语言完美地满足了这一切。它的设计哲学就是：“天下武功，唯快不破；保持简单，拒绝炫技。”
在 Go 的世界里，开发者的个人时间，永远比 CPU 的计算时间更昂贵。它用“相对够用”的性能，换取了团队极高的迭代速度和代码的一致性。
这就是为什么，Go 语言统治了业务服务的“编排层（Orchestration Layer）”。
然而，当你的系统撞上“那堵墙”，当系统中某些特定的组件，变成了吞噬资源的黑洞时，Go 语言的 GC（垃圾回收）和相对粗放的内存管理，就会显得力不从心。
这个时候，就是 Rust 拔剑出鞘的时刻。
Rust 不适合用来写那些三天两头变需求的业务 CRUD 接口，它真正的主战场，是系统里那些承担“重体力劳动（Heavy-lifting components）”的深水区：
在这些领域，Rust 的设计哲学展现出了降维打击般的威力：“控制所有重要的事情。”
Rust 假设：线上的 Bug 是极其昂贵的；规模化后的性能低下是致命的。因此，它用极其严苛的编译器，强迫你在写代码的阶段就解决掉所有可能的内存泄漏和并发竞争。
它没有 GC，内存效率极高。在 CPU 密集型的任务中，它通常比 Go 快 2 到 5 倍。
聪明的架构师早就看透了：我们不需要在 Go 和 Rust 之间二选一，我们需要的是将它们各自部署在正确的战线上。
在真实的硅谷大厂和独角兽公司中，最经典的架构模式已经浮出水面：
Pattern 1：用 Go 写服务层，用 Rust 写热点路径（Hot Path）
Pattern 2：为成本和延迟而战
最后，我想分享一下我最喜欢的一段话：
“在这个世界上，你永远无法通过选择一门‘最好的语言’来赢得战争。”
“你赢得战争的方式是：深刻理解你的系统会在哪里崩溃；知道哪种工具能精准地解决那个特定的问题；并且，只有在确实能带来巨大回报的地方，才引入复杂性。”
如果你的系统还在为了活下去而疯狂堆功能，请闭上眼睛，用 Go 语言全力冲刺。
如果你的系统已经庞大到每次发版都在流血，每多消耗 1MB 内存都在烧钱，那么，请翻开 Rust 的手册。
用 Go 来构建你的商业帝国，用 Rust 来捍卫它的边界。
这，才是 2026 年，一个成熟架构师应有的顶级大局观。
资料链接：https://codestax.medium.com/rust-vs-go-the-only-backend-language-comparison-that-actually-matters-in-2026-6b8303dbb7c2
今日互动探讨：
在你的公司里，是否也遇到了系统“撞墙”的时刻？你们目前是如何解决性能瓶颈的？有没有考虑过，或者正在尝试引入 Rust 来重写核心的 Go 模块？
欢迎在评论区分享你的实战经验与踩坑血泪史！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-10 10:31:13
本文永久链接 – https://tonybai.com/2026/05/10/scaling-uber-with-thuan-pham
大家好，我是Tony Bai。
在硅谷的黄金时代，曾有一家公司以一种近乎“暴力”的美学，重新定义了增长的速度。它的名字叫 Uber。
在最癫狂的岁月里，它以“周”为单位攻占新的城市，用海量的资本和补贴点燃市场，其业务增长曲线陡峭得如同悬崖峭壁。
但在这场增长的狂欢之下，是一套摇摇欲坠、濒临崩溃的技术系统。
2013 年，当 Tuan Pham（后来被称为 Uber 的“救火队长”）加入时，这家拥有 40 名工程师的公司，系统每周都会崩溃数次。而他面临的第一个挑战，就是公司的核心派单系统，只剩下 5 个月的寿命。
近日，这位传奇 CTO 接受了一次深度访谈。他不仅首次揭秘了当年与创始人 Travis Kalanick (以下称TK) 长达 30 小时的“魔鬼面试”，更详细复盘了 Uber 是如何在失控的边缘，被迫走上那条被全网群嘲、却又别无选择的 “5000 微服务” 之路。
今天，就让我们跟随 Tuan 的视角，重返那个硝烟弥漫的战场。
Tuan Pham 的人生开局，堪称地狱模式。
他出生于越南，是战争的亲历者。1975 年后，由于家庭背景，他和家人被迫成为“越南船民”，挤在破旧的渔船上，冒着不足 50% 的生还率，在深夜逃离故土。
在海上漂泊了四天三夜，躲过风暴和海盗，他们最终在马来西亚登陆，却又被拖回大海，最终被印尼的一个荒岛收留。
一年后，他们以难民身份来到美国。身无分文，不懂英语，第一套衣服来自教堂的捐赠衣橱。
“生存”，是刻在他骨子里的第一性原理。
和很多技术天才一样，Tuan 在数学上展现了过人的天赋。高中时，他靠着一台有两个软盘的 IBM PC 自学了编程，甚至用脚本语言帮政府机构把需要 3 周才能完成的财务对账工作，压缩到了 3 小时。
凭借着优异的成绩和推荐信，他被 MIT 录取，正式开启了他的计算机科学之旅。
在加入 Uber 之前，Tuan 的职业生涯并非一帆风顺。但正是这些宝贵的“失败”，让他积累了足以驾驭 Uber 这头巨兽的认知。
第一场失败，在 SGI（硅谷图形公司）。
上世纪 90 年代，他参与了一个极其超前的项目——交互式电视。在那个连手机和互联网都还没普及的年代，他们已经实现了“视频点播、在线购物”。斯皮尔伯格、迈克尔·杰克逊都来参观过。但这个项目最终惨败，因为机顶盒的成本高达 4.5 万美元。这让他得到一条教训：光有伟大的技术没用，你必须在正确的时间、以正确的价格，出现在正确的市场。
第二场失败，在 NetGravity（一家互联网广告公司）。
他们发明了动态广告系统，并成功上市。但另一家比他们晚成立的公司，靠着更轻量的“广告服务（Ad Service）”模式，野蛮生长，最终被 Google 收购。而他们，因为董事会要求“优先盈利”，错失了市场。这让他得到了另外一条教训：当市场窗口期出现时，增长速度压倒一切，哪怕是以亏损为代价。
这两条从真金白银和血泪中总结出的铁律，仿佛就是为日后的 Uber 量身定制的。
离开 VMware 后，Tuan 并未主动寻找工作。是 Benchmark 的传奇投资人 Bill Gurley（也是 Uber 的早期投资人）找到了他。Bill Gurley 认识 Tuan，源于十几年前那家失败的广告公司。
Tuan 在访谈中反复强调一个观点：
“我从不刻意经营人脉。你只需要把你手头的每一份工作做到极致，真诚地对待你身边的每一个人。随着时间推移，你的声誉会为你打开所有的大门。”
当他见到 Uber 的创始人 Travis Kalanick (TK) 时，一场长达 30 小时、横跨两周的马拉松式面试开始了。
TK 在白板上写下了密密麻麻的清单：从招聘开除、到代码质量、再到团队文化……他们每天 Skype 两小时，一个一个地辩论。
Tuan 回忆道，那根本不像面试，更像是两个合伙人在激烈地碰撞思想。有一次，聊到一半 TK 要赶飞机，他直接拿起电话让助理改签，然后继续辩论。
T.K. 对技术细节的痴迷，和近乎偏执的激情，让 Tuan 意识到，这是一个将技术视为公司命脉的创始人。
面试的最后，Tuan 发现，这 30 小时其实是一场“模拟工作”。TK 在用最高成本的方式，去观察当他们意见相左时，是否还能有效地沟通、并最终达成共识。
Tuan 加入 Uber 时，公司只有 40 个工程师，但系统每周都会宕机数次。整个后端是一个巨大的单体应用，派单系统是用单线程的 Node.js 写的。为了扩容，工程师们只能不断地把程序挪到 CPU 更快的机器上（垂直扩容）。
Tuan 问团队：“如果最快的 CPU 也扛不住了怎么办？”
工程师说：“那就换一个有多颗 CPU 的机器。”
Tuan 再问：“那这些进程之间怎么共享状态？”
团队沉默了。
Tuan 迅速算出，当时最大的城市纽约，将在 5 个月后彻底冲垮派单系统的物理上限。
重写，是唯一的活路。
他只提了两个要求：1. 一个城市必须能被多台机器支撑；2. 一台机器必须能支撑多个城市。 没有新功能，只要活下去。
最终，团队在 8 月份惊险上线了新系统，暂时续上了命。
但真正的噩梦，来自那个名为 API 的巨型单体应用。随着业务的爆炸式增长（UberX 上线、新城市扩张），这个单体应用成了所有团队的瓶颈。任何一个新功能，都可能要排队等好几个团队的开发资源。
为了活下去，Tuan 和 TK 做出了那个后来被全行业“群嘲”的决定：
“任何新功能，一律不许再往单体里加！必须作为独立的服务（Microservice）去开发。”
同时，成立一个专门的团队，去把旧的单体应用一块块“拆骨”。
这个拆骨项目，代号“达尔文（Darwin）”。Tuan 苦笑道，如果时间静止，这个项目 3-6 个月就能搞定。但他们花了整整两年。
因为在他们拆解的同时，业务的增长速度比他们拆解的速度还要快！新功能被疯狂地加回到那个正在被拆的单体里。
“当你把一块代码剥离出去后，剩下的部分因为业务增长，变得比你剥离出去的还要大。我们就像在追着自己的尾巴跑。”
5000 个微服务，不是一个被精心设计出来的架构蓝图。它是在极端增长压力下，为了让几百个工程师能够并行开发、不互相阻塞，而被迫做出的“最不坏”的选择。
这是 Uber 用每年几亿美元的服务器成本，换来的开发速度。
在 Uber 的历史上，最能体现这种“速度压倒一切”文化的，莫过于 2014 年底的“中国闪击战”。
圣诞节前，TK 宣布：新年过后，Uber 要全面进军中国。他给了 Tuan 两个月的时间，在中国本土，从零开始搭建一套完整的、物理隔离的数据中心。
Tuan 的工程团队评估后，给出的最快时间是 6 个月。他在湾区的朋友们听说后，都嘲笑他疯了：“没有 18 个月根本不可能。”
TK 不接受，最终两人“折中”到了 4 个月。
4 个月后，项目延期了。TK 很不爽。
5 个月后，项目再次延期。TK 暴怒。
Tuan 对 TK 承诺，再给一个月，但必须允许他们“分阶段上线”，而不是一次性点亮所有城市。
TK 同意了，但提了一个极其苛刻的条件：第一个上线的，必须是当时业务量最大的城市——成都。
Tuan 在访谈中回忆道，这在当时看来简直是自杀，但事后回想，这是 TK 做出的最天才的决定。
“当你把最硬的骨头啃下来之后，剩下的就全是下坡路了。整个团队的士气和信心都被拉满了。”
最终，他们真的做到了。IT 团队在两周内完成了服务器的跨国部署，软件团队在无数个通宵后，让代码在中美两地同时跑了起来。
没有人认为这能成功，但它就是成功了。 这就是 Uber 当时的魔力。
在访谈的最后，Tuan 聊到了如今最火热的 AI 编程。
他所在的新公司 FAIR，已经开始使用 Agent Swarm（智能体集群） 来辅助开发。他发现，顶级的工程师在使用 AI 后，产出能翻倍。
当被问及“AI 时代，如何区分优秀与平庸的工程师”时，Tuan 的回答，与他在 Uber 血战时总结出的经验如出一辙：
“好奇心、无畏、愿意尝试新事物、敢于打破常规。这些特质，在过去能让你脱颖而出，在今天，同样能让你成为驾驭 AI 的顶级玩家。平庸的人把 AI 当拐杖，而优秀的人把 AI 当作火箭推进器。”
从越南船民到硅谷之巅，Tuan Pham 的一生，就是一部关于“在混乱中寻找秩序，在极限压力下野蛮生长”的史诗。
Uber 的故事或许不可复制，但它留给我们的思考，远未结束。
在技术的世界里，从来没有完美的架构，只有与业务增长阶段相匹配的、充满妥协与权衡的草台班子。
而我们作为工程师的终极使命，就是在这个草台班子上，用最快的速度，把它搭成别人眼中坚不可摧的罗马。
今日互动探讨：
看完 Uber 的故事，你觉得在你的公司里，是应该优先选择“技术正确”的完美架构，还是“能快速上线”的野路子？你对微服务和单体架构有什么切身体会？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将>带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-09 18:01:06
本文永久链接 – https://tonybai.com/2026/05/09/anthropic-engineer-say-html-is-the-ultimate-language-for-ai
大家好，我是Tony Bai。
在这个大模型（LLM）席卷一切的时代，如果说有什么东西是全体程序员的“共识”，那绝对是 Markdown。
无论是写 Prompt，定义 Agent Skill，还是阅读大模型吐出的漫长代码审查报告，Markdown 凭借其极简的纯文本特性，几乎成了人类与 AI 沟通的“普通话（Lingua Franca）”。
但就在近日，这个牢不可破的共识，被大模型领域的绝对王者——Anthropic（Claude 的母公司）自己人给掀翻了。
Claude Code 团队的核心工程师 Thariq，在 X (Twitter) 平台上抛出了一篇长文：《使用 Claude Code：HTML 不讲理的有效性（The Unreasonable Effectiveness of HTML）》。
在这篇获得了上百万阅读量、上千次转发的神贴中，他毫不客气地宣称：
“我已经彻底停止使用 Markdown 了。对于智能体（Agent）时代来说，HTML 才是更完美的通信格式。”
这篇文章瞬间在技术圈引发了一场大地震。有人拍案叫绝，直呼“Game Changer（游戏规则改变者）”；也有人愤怒反驳，认为这简直是历史的倒车。
今天，我们也来解读一下这场顶级社区的论战，看看为什么连最懂大模型的人，都要抛弃我们最爱的 Markdown？而在 AI 时代，我们又该如何重新定义“代码的可读性”？
一直以来，我们喜欢 Markdown，是因为它“简单”。
在那个我们只让 AI 帮我们写两个小函数、查一个 Bug 的“手工作坊”时代，Markdown 是完美的。
但现在的 Agent 变了。它们太强大了。
正如 Thariq 在文章中指出的：
“随着 Agent 变得越来越强大，我开始觉得 Markdown 变成了一种限制性格式。当我面对一个超过 100 行的 Markdown 文件时，阅读它变得极其困难。我想要更丰富的可视化、颜色、图表，我想要能够轻松地分享它们。”
这精准地戳中了当前所有高级 AI 开发者的痛点：信息密度的坍塌。
当你让 Agent 去审查一个包含 5 个文件、上百行改动的复杂 PR（Pull Request）时，如果用 Markdown 输出，你只会得到一面密密麻麻的“文本墙（Wall of text）”。
你无法高亮关键的代码行，无法并排对比修改前后的差异，更无法画出一个交互式的调用链路图。
在这个时候，Markdown 的“极简”，反而成了人类理解 AI 复杂输出的最大障碍。
面对信息密度的瓶颈，Thariq 给出了一剂猛药：彻底转向 HTML。
他惊奇地发现，现代的大模型（尤其是 Claude Sonnet 4.x 版本），在处理和生成 HTML 方面的能力，已经到了令人发指的地步。
他总结了 HTML 在 AI 交互中的四大降维打击能力：
1. 恐怖的“信息密度（Information Density）”
HTML 不仅能表达简单的标题和格式，它还能通过 \<svg> 直接内联生成精美的流程图，通过 CSS 生成带颜色的代码差异对比（Diff），甚至可以利用绝对定位（Canvas）来表达空间数据。
“可以说，Claude 几乎没有什么是不能用 HTML 高效表示的。”
2. 极佳的“视觉清晰度与可读性”
当 AI 帮你完成了一个宏大的架构设计，与其看几百行的纯文本，不如让 Claude 直接生成一个带有选项卡（Tabs）、插图、侧边栏导航的完整 HTML 网页。
Thariq 提到：“在实践中，我发现自己几乎不会去读超过 100 行的 Markdown，我也绝对无法让组织里的其他人去读它。但 HTML 文档就容易阅读得多。”
3. “双向交互（Two-way Interaction）”的魔法
这是最让人拍案叫绝的一点！
你可以让 Claude 生成一个带有滑块（Sliders）或按钮的 HTML 原型。你在浏览器里拖动滑块调整参数，觉得满意后，直接点击“复制为 JSON（Copy as JSON）”，然后再把这串参数喂回给 Claude Code 继续开发。
UI 变成了你和 AI 之间最直观的“调试器”。
4. 完美的分享体验
Markdown 极难分享，大多数人的浏览器直接打开是一片乱码。但 HTML，你只需要把它扔进 S3 或者发给同事，任何人在任何设备上双击就能看，甚至还能做响应式适配。
这套理论绝不仅仅停留在纸面上。评论区里，无数被点醒的开发者开始疯狂晒出他们的实战案例。
正如一位开发者在评论中所说：
“所以你的意思是，我不应该要求一个 ASCII 字符画的草图，而是应该直接要求一个 HTML 的设计模型？？我得去试试这个。用 Markdown 做计划，用 HTML 做设计。”
当然，如此颠覆性的观点，必然会引发强烈的抵触。
在推特的评论区，一场关于“效率 vs 消耗”的论战正在上演。
反对派（Markdown 死忠党）的核心论点极其犀利：Token 成本与编辑摩擦。
“HTML 在命令行里根本没法读，而且极其容易因为缺少闭合标签而崩溃。大多数 LLM 在长上下文中处理 HTML 会非常吃力。”
“HTML 确实在视觉上提供了更高的信息密度。但为了这点视觉信号，你要多花 2-4 倍的 Token 成本！这让我感觉非常糟糕。”
“Markdown 最大的优势是‘可编辑性’。如果我们不再亲手编辑文件，那么格式的选择就从‘什么最容易写’变成了‘什么最容易检查、微调并反馈给 Agent’。”
这是一场深刻的哲学博弈。
Markdown 代表的是“以人类编写为中心”的过去；而 HTML 代表的，则是“以 AI 生成、人类消费为中心”的未来。
当我们不再亲手敲击每一行代码，而是扮演“审查员”和“导演”的角色时，我们真的还需要在乎生成过程消耗了多少个
<
div> 标签吗？
Thariq 的这篇文章，之所以能引发如此巨大的反响，是因为它极其敏锐地捕捉到了 AI 时代生产关系的变化。
在过去，程序员是“工人”，我们需要 Markdown 这样轻巧的工具来减轻手腕的负担。
在未来，程序员是“厂长”，我们需要 HTML 这样丰富的看板，来快速审阅成千上万个 AI Agent 提交的工作报告。
“Markdown 适合思考（Planning），HTML 适合展示（Acting）。”
或许，正如评论区的一位老哥半开玩笑的预言：“XML 才是最后的赢家。立帖为证。”
在 AI 这个不知疲倦的“超级打字员”面前，所有曾经因为“太啰嗦”而被人类抛弃的富文本标记语言，都可能迎来一场轰轰烈烈的文艺复兴。
资料链接：https://x.com/trq212/status/2052809885763747935
今日互动探讨：
在日常使用大模型时，你更倾向于让它输出极简的 Markdown，还是信息量爆炸但耗费 Token 的 HTML？你觉得在 AI 时代，“代码的可读性”定义是否已经被彻底改写了？
欢迎在评论区分享你的实战心得！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
