2026-01-05 12:02:10
本文永久链接 – https://tonybai.com/2026/01/05/how-ken-thompson-developed-go-language-at-google.
大家好，我是Tony Bai。
为什么 Go 语言极其痛恨复杂的特性？为什么 Go 如此执着于编译速度？我们常说 Go 是一门“工程实用主义”的语言，它的设计哲学是“少即是多”。但你是否想过，这种近乎偏执的简洁，究竟是为了对抗什么？
这一切的答案，都藏在 2007 年 Google 内部的一场 C++ 标准委员会汇报演讲中。当图灵奖得主 Ken Thompson 发现自己竟然“看不懂”新的 C++ 特性时，一颗变革的种子就此埋下。
最近，我重温了这段 Ken Thompson（Unix 之父、Go 语言联合创始人）的珍贵访谈。在访谈中，老爷子毫无保留地讲述了 Go 语言诞生的前因后果。 故事的起点，并非某次高瞻远瞩的战略规划，而是一次“听不懂”的 C++ 技术分享，以及 Google 内部那令人绝望的 45 分钟编译时间。
本文基于 Ken Thompson 的访谈实录，带你回到那个决定性的瞬间，还原 Go 语言诞生背后的真实故事。
故事发生在 2007 年左右。当时，Google 内部有一位 C++ 标准委员会（ANSI C++）的代表。
有一天，这位代表刚开完标准会议回来，在 Google 内部做了一场技术分享，向大家介绍 C++ 即将引入的“新特性”（注：推测是指当时的 C++0x，即后来的 C++11 草案）。
Ken Thompson 就在台下。作为发明了 B 语言（C 语言的前身）并重写了 Unix 内核的宗师级人物，他在听完这场一小时的密集分享后，感受到的不是兴奋，而是困惑。
“这所谓的‘新东西’，在我看来比语言本身还要大。”
“那些关于指针的形式，除了指针之外还意味着其他东西……我告诉你，我没听懂。”
想象一下，连 Ken Thompson 都直言自己“没听懂” C++ 的新特性，这说明了什么？
在他看来，这些所谓的“改进”，只是在不断地堆砌复杂度。这场演讲成为了催化剂。Ken 回到办公室，找到了同样对现状不满的 Robert Griesemer 和 Rob Pike。
Ken 的不满在于语言的过度复杂，而 Rob Pike 的痛点则在于 Google 庞大的工程规模。
当时的 Google 面临着一个前所未有的工程挑战：Monorepo（单一代码仓库）的膨胀。
Ken 在访谈中描述了一个令人窒息的场景：
“在 Google，你可以从任何源文件中引用库。你可能只写了一个 10 行的程序，但最终却需要处理 500 万行的编译量。”
这不是夸张。由于缺乏严格的依赖管理和可见性控制，一个微小的依赖引入，可能会像滚雪球一样，将底层的庞大库（如 Protocol Buffers、基础库等）全部卷入编译过程。
更糟糕的是，头文件（Header files）的包含机制导致了严重的重复劳动。
“像最简单的库，可能会被加载和检查成百上千次。”
虽然 Google 拥有当时世界上最强大的分布式编译集群（成百上千个 CPU 并行工作），虽然工程师们发明了各种缓存机制和 ifdef 技巧来避免重复包含，但物理定律是不可违背的。
编译一个简单的程序，需要等待 15 分钟，甚至 45 分钟。
Rob Pike 对此深恶痛绝。这种低效的开发循环，正在扼杀 Google 工程师的创造力。
于是，在 Google 的一间办公室里，Ken Thompson、Rob Pike 和 Robert Griesemer 聚在了一起。
Ken 说出了那句改变历史的话：
“What are we going to do about it? Let’s write a language.”（我们该怎么办？让我们写个语言吧。）
这是一个完美的互补组合：
在设计 Go 语言时，他们制定了一个残酷但有效的规则：全员同意原则。
“我们必须都同意某个特性，它才能被加入。仅仅因为‘我想要这个特性’是不够的。”
这个规则过滤掉了绝大多数“花哨但非必要”的特性。Go 语言之所以能保持如此干净、紧凑，正是因为这三位创始人在最初就把住了关口。
Ken Thompson 在 Go 语言开源并走上正轨后，逐渐淡出了核心开发。但他对 Go 的后续发展给予了极高的评价，特别是对标准库。
“在我离开后，后来的人写了一套极其出色（magnificent）的标准库。”
那之后，这位图灵奖得主在 Google 的工作中，几乎只使用 Go 语言，并且几乎只使用标准库。
他对 Go 的评价朴实无华：
“它很简单。任何人都可以在一小时内学会它。当你写代码时，它运行得足够快，给你即时的反馈。”
重读这段访谈，我们就能理解：
因为 Go 从诞生的那一刻起，就是为了反抗 C++ 的过度复杂，和解决 Google 级别的工程规模问题。
它不是为了在编程语言理论上创新，而是为了让像 Ken Thompson 和 Rob Pike 这样的工程师，不再需要在编译期等待 45 分钟，不再需要去猜测一段代码到底在通过指针玩什么花样。
Go 的诞生，是工程实用主义对无节制复杂性的一次伟大胜利。
资料链接：https://www.youtube.com/watch?v=NTrAISNdf70
你的“编译等待”时刻
45分钟的编译时间催生了Go语言。在你的开发生涯中，是否也经历过类似的“编译噩梦”？或者，你是否也曾被某些语言的“过度复杂”劝退过？
欢迎在评论区分享你的故事！ 让我们一起致敬那些为了“简单”而努力的先驱。
如果这篇文章让你对Go语言的设计哲学有了更深的理解，别忘了点个【赞】和【在看】，并转发给身边还在忍受漫长编译的朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-05 08:08:04
本文永久链接 – https://tonybai.com/2026/01/05/claude-code-author-reveals-private-ai-coding-config
大家好，我是Tony Bai。
自从 Claude Code 发布以来，我和大家一样，都在探索这个“终端里的 AI 智能体”到底能爆发出多大的能量。
就在昨天，Claude Code 的创造者、Anthropic 的核心工程师 Boris Cherny 在社交媒体上毫无保留地晒出了他自己的 Claude Code Setup（配置与工作流）。
看完他的分享，我最大的感受是：英雄所见略同！
Boris 的很多“私房技巧”，不仅验证了 AI 原生开发的高效性，更令人惊喜的是，其中 80% 的核心实践，竟然都与我的专栏《AI 原生开发工作流实战》中的教学内容完美印证。
今天，我就带大家深度拆解一下这位“Claude Code 之父”的开发心法，结合他晒出的真实配置代码，看看Claude Code作者们都是如何驾驭 AI 的。
Boris 分享的第一个技巧就非常硬核：
“I run 5 Claudes in parallel in my terminal… I also run 5-10 Claudes on claude.ai/code.”
（我在终端里并行运行 5 个 Claude… 同时在网页端也运行 5-10 个。）
这意味着什么？这意味着他把自己变成了一个“任务调度器”。
这正是我们在专栏 “概念篇” 中反复强调的开发者角色转型：从“代码的生产者”转变为“工作流的指挥家”。
在 Boris 的截图中，我们可以清晰地看到他正在运行多个独立的 Session，其中一个正在处理复杂的类型检查和构建任务：
Bash(bun run typecheck 2>&1 | head -100)
Bash(bun run build:agent-sdk-typings && tsc ...)
# ... AI 正在自主修复类型错误 ...
在 AI 原生时代，我们的生产力不再受限于打字速度，而是受限于并发管理能力。你可以同时开启多个 Session：1 号 Claude 负责修 Bug，2 号 Claude 负责写测试，3 号 Claude 负责重构。你不再是自己在写代码，你是在指挥一个“虚拟团队”。
Boris 也晒出了他的 CLAUDE.md 文件。出乎意料的是，它非常简洁，没有任何冗余的废话。
Boris 的 CLAUDE.md 真实代码：
# Development Workflow
**Always use bun, not npm.**
```sh
# 1. Make changes
# 2. Typecheck (fast)
bun run typecheck
# 3. Run tests
bun run test -- -t "test name" # Single suite
bun run test:file -- "glob" # Specific files
# 4. Lint before committing
bun run lint:file -- "file1.ts" # Specific files
bun run lint # All files
# 5. Before creating PR
bun run lint:claude && bun run test
这完美印证了我们在专栏 第 06 讲《上下文的艺术（上）：详解CLAUDE.md 与 AGENTS.md》 中的观点：CLAUDE.md 是 AI 的操作手册，必须精准、可执行。
注意看他的第一句：Always use bun, not npm. —— 这是一个典型的“负向约束”。他在教 AI “做什么”的同时，更明确了“不做什么”，这能极大地减少 AI 犯错的概率。
Boris 提到他极度依赖 Slash Commands（斜杠指令） 和 Sub-agents（子智能体）：
“I use slash commands for every ‘inner loop’ workflow… This saves me from repeated prompting.”
（我把所有高频工作流都封装成了 Slash Commands，这让我免于重复写 Prompt。）
他展示的 .claude/commands/ 目录结构简直就是我们专栏 第 08 讲 自定义指令：精通Slash Commands，打造你的私人命令集 的最佳教具：
.claude/
commands/
build-validator.md # 专门负责构建验证的指令
code-architect.md # 专门负责架构设计的指令
agents/
code-simplifier.md # 一个专门负责简化代码的 Sub-agent
verify-app.md # 一个专门负责全链路测试的 Sub-agent
他把“架构设计”、“代码简化”、“应用验证”这些复杂的脑力劳动，全部封装成了可一键调用的指令和专家分身。把你的经验变成代码，让 AI 替你执行经验，这才是高阶玩家的玩法。
这也是我最喜欢的一部分。Boris 展示了一个非常漂亮的 PostToolUse Hook 配置，用来解决代码格式化问题：
Boris 的 settings.json 配置片段：
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "bun run format || true"
}
]
}
]
这段配置的含义是： 每当 AI 使用 Write 或 Edit 工具修改了文件后，立刻、自动执行 bun run format。
他的逻辑非常清晰：AI 负责写逻辑，Hook 负责格式化。 AI 生成的代码可能有格式问题，但通过 Hook 自动运行 prettier 或 gofmt，就能解决这“最后的 10%”。
这完全对应了我们专栏 第 11 讲《事件驱动：详解Hooks机制，让AI在关键节点自动触发》 的实战案例。我们当时也演示了如何用 Hook 实现 Go 代码的自动格式化，简直是异曲同工！
最后，Boris 特别展示了他的权限配置搜索界面，并强调：
“I don’t use –dangerously-skip-permissions. Instead, I use /permissions.”
（我从不使用危险的跳过权限模式，而是使用权限白名单。）
即使是工具的开发者本人，也对安全保持着绝对的敬畏。他展示的权限白名单列表（Allowlist）非常详细：
Bash(bq query:*)
Bash(bun run build:*)
Bash(bun run lint:*)
Bash(bun run test:*)
...
Bash(cc:*)
Bash(comm:*)
他宁愿多花点时间把常用的 bun run、bq query 命令一条条加入白名单，也不愿意让 AI 在“裸奔”状态下运行。
这也正是我们在 第 09 讲《安全基石（上）：用权限控制与沙箱为AI戴上“安全镣铐”》 中苦口婆心强调的：没有安全，就没有生产力。 盲目追求全自动（YOLO 模式），是在给未来埋雷。
看完 Boris 的分享，我更加确信：我们正在经历一场软件工程范式的彻底重塑。
Boris Cherny 是这个工具的创造者，他定义了“上限”；而我们作为使用者，需要通过系统的学习，去触达这个上限。
如果你也想：
那么，欢迎加入我的极客时间新专栏 《AI 原生开发工作流实战》。
在这门课里，我不只会教你工具的用法，更会带你像 Boris 一样思考——如何用 AI 重塑你的开发习惯，成为新一代的“AI 架构师”。
扫描下方二维码，让我们一起，站在巨人的肩膀上，开启 AI 原生开发之旅！
(P.S. 专栏内容偏实战，以 Go 语言项目为例，但方法论通用于所有语言。Claude Code 也是一个刚刚诞生不到一年的新物种，我们都是探索者，期待在课程里与你交流碰撞！)
资料链接：https://x.com/bcherny/status/2007179832300581177
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-04 13:27:08
本文永久链接 – https://tonybai.com/2026/01/04/stop-lying-to-the-compiler
大家好，我是Tony Bai。
“半夜被值班的运维同事叫醒，发现生产环境崩了，原因是一个深藏在业务逻辑里的 nil 指针异常。”
这个场景，对于每个后端开发者来说都是挥之不去的噩梦。事后复盘时，我们往往会懊恼：“为什么这里没加 if != nil 判断？”然后，我们在代码里撒上一把防御性检查的“盐”，祈祷下次好运。
但这真的是解决之道吗？
最近，Daniel Beskin 的一篇深度好文《The Compiler Is Your Best Friend, Stop Lying to It》（编译器是你最好的朋友，别再对它撒谎了），为我们提供了一个全新的视角：这些运行时崩溃，本质上是因为我们在编译时对编译器撒了谎。
我们告诉编译器“这是一个字符串”，但实际上它可能是 nil；我们告诉编译器“这个函数返回一个整数”，但实际上它可能抛出一个 panic。当我们停止撒谎，开始用类型系统表达真实意图时，编译器将从一个“报错机器”，变成我们最强大的“安全副驾驶”。
在 Go 语言的日常开发中，我们常常为了“方便”而向编译器撒谎，埋下了日后爆炸的地雷。
当我们定义 func Process(u *User) 时，我们告诉编译器：“给我一个 User，我处理它。” 但在 Go 中，指针可以是 nil。
* 谎言：我承诺会处理一个 User。
* 真相：我可能会收到一个 nil，然后炸掉。
* 后果：为了弥补这个谎言，我们需要在函数内部写无数的 if u == nil 防御性代码。一旦遗漏，就是生产事故。
当我们使用 interface{} (或 any) 时，我们实际上是在对编译器说：“别管这个，我知道我在做什么。”
* 谎言：这个 any 类型的变量，其实是一个 int。
* 真相：它可能是一个 string，或者 nil。
* 后果：运行时的 panic: interface conversion: interface {} is string, not int。
当我们看到一个函数签名 func Parse(s string) int 时，编译器认为它是一个将字符串映射为整数的函数。
* 谎言：这是一个纯粹的转换函数。
* 真相：如果字符串格式不对，我会直接 panic，中断整个 goroutine。
* 后果：调用者无法通过函数签名预知风险，导致程序在边缘情况下意外崩溃。
如何重建与编译器的信任关系？答案是：将运行时的检查，提前到编译时的类型定义中。
这是消除 nil 和无效数据的终极心法。
诚实的设计：
type Port int
// 使用构造函数来保证 Port 的合法性
func NewPort(p int) (Port, error) {
if p < 0 || p > 65535 {
return 0, fmt.Errorf("invalid port")
}
return Port(p), nil
}
一旦你通过 NewPort 拥有了一个 Port 类型的值，编译器就为你担保：它一定是一个合法的端口号。你后续不再需要防御性检查(未通过NewPort获得的除外)。
诚实的设计：
type UserID int64
type OrderID int64
func GetOrder(uid UserID, oid OrderID) { ... }
现在，如果你试图把 UserID 传给 OrderID，编译器会直接报错。这不是繁琐，这是编译器在帮你 Review 代码。
虽然 Go 没有 Rust 的 Option
go
type UpdateUserRequest struct {
Name *string // nil 表示不更新，非 nil 表示更新为新值
Age *int
}很多时候，我们觉得编译器很烦人：它阻止我们快速写出“能跑”的代码，强迫我们处理每一个 err，纠结于类型转换。
但 Daniel Beskin 提醒我们：编译器是你唯一一个会不厌其烦地帮你检查每一个细节、永远不会疲倦、永远不会因为“差不多就行”而放过 Bug 的队友。
当你觉得编译器在“阻碍”你时，停下来想一想：是不是我在试图对它撒谎？
“防御性编程”是一种补救措施，它假设代码是脆弱的。而“类型驱动开发”是一种预防措施，它利用编译器构建坚固的堡垒。
当我们开始尊重类型，停止用 any 和隐式约定来糊弄编译器时，我们获得的回报是巨大的：
资料链接：https://blog.daniel-beskin.com/2025-12-22-the-compiler-is-your-best-friend-stop-lying-to-it
你的“撒谎”时刻
读完这篇文章，你是否也意识到了自己曾在代码中对编译器撒过的“谎”？在你的项目中，有哪些因为类型定义不清而导致的“血案”？或者，你有哪些利用类型系统来规避 Bug 的独门绝技？
欢迎在评论区分享你的反思与心得！ 让我们一起学会“诚实”编程，睡个好觉。
如果这篇文章颠覆了你对编译器的认知，别忘了点个【赞】和【在看】，并转发给你的团队，一起提升代码的“诚实度”！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-04 07:17:15
本文永久链接 – https://tonybai.com/2026/01/04/stick-to-the-core-embrace-variables-2025-review-2026-outlook
大家好，我是Tony Bai。
当时钟拨向 2026 年，我不禁回望刚刚过去的 2025。
在技术史上，这注定会被定义为“分水岭”的一年。如果说之前我们还在观望 AI 能画出什么样的图，生成怎样的代码，那么在 2025 年，我们真切地感受到了它对软件工程核心领地的冲击与重塑——从 Google 三巨头定义“AI Agent 元年”，到 CodeRabbit 报告揭示 AI 代码的质量隐忧，再到 Rob Pike 对那封AI “致谢信”的罕见愤怒。
在这样的洪流中，保持定力并不容易。回顾这一年，我庆幸自己做对了一件事：在变化的浪潮中，依然坚持系统性地输出“不变”的价值。
今天，在这个2026年元旦后开工的第一天，我想和大家聊聊我的 2025，以及我对 2026 的硬核规划。
2025 年，我做了一个重要的决定：重塑公众号的内容形态。
在碎片化阅读盛行的当下，我深感很多技术痛点——如并发调度、网络协议、系统底层——是无法通过单篇千字文章讲透的。于是，我推出了“微专栏”模式：用 3-10 篇的体量，像写书一样去深度拆解一个技术专题。
这是一次冒险，但结果令人欣慰。这一年，我们通过 16 个微专栏，构建了一张从底层原理到 AI 前沿的完整技术拼图：
第一块拼图：攻克 Go 并发的“深水区”
并发是 Go 的灵魂，也是最容易出错的地方。
我们通过 《Go并发调度艺术》，跟随 Dmitry Vyukov 的视角亲历了 GMP 模型的演进；通过 《Go并发心智模型课》，完成了从“共享内存”到“信道通信”的思维转变；更为关键的是，《征服Go并发测试》 让我们终于掌握了驯服 Flaky Test 的新武器。
第二块拼图：夯实系统编程与工程底座
在应用层之下，是冰山般的底层细节。
我们潜入内核，在 《Go系统编程：揭秘进程控制、I/O与IPC》 中手写系统级工具；在 《Go网络编程全解：从Socket到HTTP/3》 中打通了网络协议栈的任督二脉。
同时，我们补齐了工程化的关键短板：通过 《Go Context解惑》 掌握了生命周期管理，通过 《Go模块构建与依赖管理》 走出了依赖地狱，用 《Go密码学101》 和 《用Go解锁位运算之美》 强化了基本功，并用 《Go 测试之道》 建立了交付信心。
第三块拼图：架构设计与交互体验
当 Coding 能力溢出，设计能力便决定了上限。
我们探讨了 《API 设计之道：从设计模式到 Gin 工程化实现》 和 《Go开发者的数据库设计之道》，拒绝面条代码。甚至，我们还玩了一把复古与现代结合的 《重塑终端：Go TUI开发入门课》，让命令行工具也能拥有惊艳的交互。
第四块拼图：Gopher 的 AI 破局
这一年，我们不再旁观，而是下场实战。
从 《AI应用开发第一课》 入门，到掌握 《Gemini CLI：重新定义命令行AI开发》，再到硬核的 《Google ADK 实战：用 Go 构建可靠的 AI Agent》，我们证明了 Go 在 AI 时代的无限可能。
除了微专栏，2025 年也是我“系统化输出”的大年。
在极客时间，《Go语言进阶课》 正式上线，帮助无数 Gopher 完成了从熟练到精通的跨越。
更让我惊喜的是，《AI原生开发工作流实战》 在上架短短一个多月内就获得了 3600+ 订阅。这说明大家已经意识到：AI 不仅仅是工具，更是一种全新的开发范式。
与此同时，《Go语言第一课》纸质书也在这一年正式出版，为这一年的“内容实验”画上了一个厚重的句号。
这一系列的产出证明了：在浮躁的时代，深度、系统化的内容依然有着旺盛的生命力。
翻看我 2025 年的博客列表，你会发现我的关注点始终在“底层原理”与“前沿变革”之间穿梭。
关于 Go，我们不仅向前看，也向后看。
Go 团队在这一年对底层的打磨可谓大刀阔斧。我们见证了 GC 的重大演进，《Go新垃圾回收器登场：Green Tea GC》 详细剖析了它如何通过内存感知降低 CPU 开销，《深入 Go Green Tea GC》 则进一步揭示了其架构演进。在性能压榨上，《解锁CPU终极性能：Go原生SIMD包预览版初探》 让我们看到了 Go 在高性能计算领域的野心，尽管 《连 Rob Pike 都感到“担忧”》 也提醒了我们随之而来的复杂性。
同时，我们也向后进行了“Go 考古”，探究了 《错误处理的“语法糖”之战》，以及 《Slice 的“隐秘角落”》 中扩容策略的演变。我们还深入探讨了 《Go 1.26 新特性前瞻》 中的语法糖 new(expr)，以及 《Go 编译器崩溃背后》 的语言规范修正。
关于软件工程，我们保持清醒。
当业界盲目推崇微服务时，我们通过 《“6 个月，47 个微服务”：一场由“简历驱动”引发的架构灾难》 发出了警示；当所有人都在由 AI 生成代码时，我们解读了 《Bug 激增 1.7 倍！AI 写代码：是速度的蜜糖，还是质量的砒霜？》。我们探讨了 《无聊设计的终极奥义》，也重温了 《Code Review 已死？Kent Beck：当 AI 成为“副驾驶”，我们该如何审查代码？》。
关于 AI，我们从旁观走向入局。
这一年，我不再满足于仅仅介绍 AI 工具，而是开始探索 Go 与 AI 的结合点。从 《Google I/O 2025 Go 语言进展》 看到的 AI 赋能，到 《Cloudflare 2025 年度报告》 中 Go 在自动化 API 领域的统治力，再到 《MCP协议注册中心发布》 带来的基础设施变革，我们看到了 Gopher 在 AI 时代的巨大机会。
如果说 2025 年是 AI 辅助编程进入Agent模式（Copilot、Cursor、Claude Code、Gemini cli等）的普及年，那么 2026 年，将是 自主智能系统（Agentic System） 的爆发年。
在 AI 能以百倍速度生成代码的时代，单纯的 Coding 能力正在不可避免地贬值。但架构设计的能力、技术选型的眼光、以及构建复杂系统的智慧，将变得无价。
基于此，在 2026 年，我将在公众号（付费微专栏）和知识星球（免费畅读）双线并行，重点规划以下三大战役：
这不再是写几个 Prompt 的游戏，而是真正软件工程范式的变革。
当“怎么写”变得容易，“写什么”和“怎么设计”就决定了你的上限。
Go 依然是我们的基本盘，但在 2026 年，我们要换个玩法。
当然，作为系统编程的双子星之一，Rust 依然会在我的技术雷达范围内，作为我们拓宽技术视野的重要补充。
2026 年的画卷已经展开。
这是一个技术人最焦虑的时代，也是最令人兴奋的时代。焦虑在于旧经验的快速折旧，兴奋在于个体生产力的无限放大。
新的一年，我希望通过这些深度微专栏和知识星球的陪伴，帮你建立起抵御技术通胀的护城河。
让我们左手握着 Go 与架构设计的工程底气，右手举起 AI Agent 的效率火把，从“代码工人”进化为“系统构建者”。
祝大家在 2026 年，代码无 Bug，架构有灵魂，人生有增量！
扫码加入我的知识星球，2026 全年微专栏以及存量微专栏免费畅读！
你的 2025 关键词
我的 2025 是“坚守与拥抱”。回顾你的 2025，如果用一个词或一句话来总结，会是什么？对于即将到来的 2026，你最大的技术期待又是什么？
欢迎在评论区留下你的年度关键词，让我们一起记录这段不平凡的时光！
如果这篇文章给了你前行的力量，别忘了点个【赞】和【在看】，并转发给你的朋友，让我们在 2026 顶峰相见！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-03 07:49:14
本文永久链接 – https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast
大家好，我是Tony Bai。
“软件拿走性能的速度，永远比硬件提供性能的速度要快。”
在 AI 狂热、Python 统治胶水层、硬件算力看似无限增长的今天，C++ 标准委员会主席 Herb Sutter 却抛出了一个反直觉的结论：C++ 和 Rust 正在经历前所未有的高速增长。
这并非幸存者偏差。在他最新的博文《Software taketh away faster than hardware giveth》中，Sutter 结合 2025 年的行业数据、巨头财报和底层物理限制，为我们揭示了一个残酷的真相：我们正面临计算能力的“硬墙”，而高效能编程语言，是撞破这堵墙的唯一工具。
如果你认为算力增长的瓶颈仅仅是芯片（GPU/TPU）的供应，那你就错了。Sutter 引用了微软、亚马逊和 NVIDIA 财报电话会议的内容，指出 2025 年计算增长的第一大瓶颈是“电力”。
在这个背景下，能效 (Energy Efficiency) 不再是一个锦上添花的指标，而是直接关乎成本、收入乃至可行性的生死线。
这解释了为什么 C++ 和 Rust 如此重要：它们是目前仅有的、能够提供极致“每瓦性能”和“每晶体管性能”的主流便携式语言。在电力成为硬通货的今天，低效的软件就是在烧钱。
Sutter 提出了一个深刻的观点：我们对解决更复杂问题的需求，总是超过我们构建更强计算能力的速度。
每一次硬件性能的飞跃，都会迅速被新兴的、更加“贪婪”的软件需求所吞噬。AI 只是这一长串名单中的最新一员。这意味着，我们永远不会拥有“足够快”的硬件，我们永远需要压榨出硬件的最后一滴性能。
因此，C++ 和 Rust 的开发者数量在过去三年（2022-2025）增长最快，这并非巧合，而是行业对高效能计算需求的直接反映。
面对 Rust 在内存安全方面的挑战，C++ 并没有坐以待毙。Sutter 详细介绍了即将发布的 C++26 标准在安全性上的重大突破：
Sutter 甚至提出了一个大胆的设想：未来的 C++29 是否应该暂停新特性的开发，专注于“修补漏洞”和“全面硬化”？ 这显示了 C++ 社区在安全性上的决心。
针对“AI 将取代程序员”的焦虑，Sutter 给出了一个冷静而乐观的比喻：AI 之于编程，就像计算器之于数学，或者搜索引擎之于知识。
Herb Sutter 的这篇文章，是对高性能编程语言的一次强力辩护。在摩尔定律放缓、能源危机逼近、AI 需求爆发的今天，掌握一门能与硬件“对话”、能极致利用资源的语言（无论是 C++ 还是 Rust），不仅没有过时，反而变得比以往任何时候都更加重要。
正如他所说：“软件拿走性能的速度，永远比硬件提供性能的速度要快。” 在这场追逐赛中，高效能开发者将永远是稀缺资源。
资料链接：https://herbsutter.com/2025/12/30/software-taketh-away-faster-than-hardware-giveth-why-c-programmers-keep-growing-fast-despite-competition-safety-and-ai
你的“能效”焦虑
在你的日常开发中，是否也感受到了“算力不够用”或者“云成本过高”的压力？你认为在 AI 时代，掌握一门高性能系统级语言（C++/Rust）是变得更重要了，还是更边缘化了？
欢迎在评论区分享你的看法和职业规划！ 让我们一起探讨如何在算力瓶颈时代突围。
如果这篇文章为你拨开了迷雾，别忘了点个【赞】和【在看】，并转发给身边那些坚持底层开发的“硬核”朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
