本文永久链接 – 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 语言诞生背后的真实故事。

压死骆驼的最后一根稻草：C++ 的“新特性”

故事发生在 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 的工程噩梦：10 行代码与 500 万行编译

当时的 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.”（我们该怎么办？让我们写个语言吧。）

这是一个完美的互补组合：

• Rob Pike：深刻理解 Google 的工程痛点（依赖地狱、构建速度、大规模协作）。
• Ken Thompson：拥有深厚的语言和编译器构建历史。
• Robert Griesemer：被称为“瑞士军刀般的语言专家”，熟悉理论上存在的所有语言特性，是团队的理论百科全书。

在设计 Go 语言时，他们制定了一个残酷但有效的规则：全员同意原则。

“我们必须都同意某个特性，它才能被加入。仅仅因为‘我想要这个特性’是不够的。”

这个规则过滤掉了绝大多数“花哨但非必要”的特性。Go 语言之所以能保持如此干净、紧凑，正是因为这三位创始人在最初就把住了关口。

遗产与未来

Ken Thompson 在 Go 语言开源并走上正轨后，逐渐淡出了核心开发。但他对 Go 的后续发展给予了极高的评价，特别是对标准库。

“在我离开后，后来的人写了一套极其出色（magnificent）的标准库。”

那之后，这位图灵奖得主在 Google 的工作中，几乎只使用 Go 语言，并且几乎只使用标准库。

他对 Go 的评价朴实无华：

“它很简单。任何人都可以在一小时内学会它。当你写代码时，它运行得足够快，给你即时的反馈。”

小结

重读这段访谈，我们就能理解：

• 为什么 Go 甚至不愿意引入三元运算符？
• 为什么 Go 的依赖管理（Go Modules）对版本控制如此严格？
• 为什么 Go 编译器宁愿牺牲一些优化也要保证极快的编译速度？

因为 Go 从诞生的那一刻起，就是为了反抗 C++ 的过度复杂，和解决 Google 级别的工程规模问题。

它不是为了在编程语言理论上创新，而是为了让像 Ken Thompson 和 Rob Pike 这样的工程师，不再需要在编译期等待 45 分钟，不再需要去猜测一段代码到底在通过指针玩什么花样。

Go 的诞生，是工程实用主义对无节制复杂性的一次伟大胜利。

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

你的“编译等待”时刻

45分钟的编译时间催生了Go语言。在你的开发生涯中，是否也经历过类似的“编译噩梦”？或者，你是否也曾被某些语言的“过度复杂”劝退过？

欢迎在评论区分享你的故事！ 让我们一起致敬那些为了“简单”而努力的先驱。

如果这篇文章让你对Go语言的设计哲学有了更深的理解，别忘了点个【赞】和【在看】，并转发给身边还在忍受漫长编译的朋友！

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

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

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

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

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

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

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

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

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

本文永久链接 – 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 的。

心法一：多线程并发 —— 做 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 负责重构。你不再是自己在写代码，你是在指挥一个“虚拟团队”。

心法二：上下文的艺术 —— 极简主义的 CLAUDE.md

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 犯错的概率。

心法三：将经验“代码化” —— Slash Commands 与 Sub-agents

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 替你执行经验，这才是高阶玩家的玩法。

心法四：自动化收尾 —— Hooks 的妙用

这也是我最喜欢的一部分。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 代码的自动格式化，简直是异曲同工！

心法五：安全第一 —— 拒绝 YOLO

最后，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 是这个工具的创造者，他定义了“上限”；而我们作为使用者，需要通过系统的学习，去触达这个上限。

如果你也想：

• 像 Boris 一样，构建一套属于自己的 AI 驾驶舱；
• 掌握 Slash Commands 和 Hooks，让 AI 乖乖听话；
• 学会 SDD（规约驱动开发），让代码生成一次做对；
• 搭建 Headless 自动化流水线，让 AI 在你睡觉时也能干活…

那么，欢迎加入我的极客时间新专栏 《AI 原生开发工作流实战》。

在这门课里，我不只会教你工具的用法，更会带你像 Boris 一样思考——如何用 AI 重塑你的开发习惯，成为新一代的“AI 架构师”。

扫描下方二维码，让我们一起，站在巨人的肩膀上，开启 AI 原生开发之旅！

(P.S. 专栏内容偏实战，以 Go 语言项目为例，但方法论通用于所有语言。Claude Code 也是一个刚刚诞生不到一年的新物种，我们都是探索者，期待在课程里与你交流碰撞！)

资料链接：https://x.com/bcherny/status/2007179832300581177

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

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

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

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

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

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