2026-01-25 08:24:12
本文永久链接 – https://tonybai.com/2026/01/25/claude-code-official-best-practices-50-core-rules
大家好，我是Tony Bai。
在使用 Claude Code 的过程中，你是否遇到过这种情况：
有时候它简直是神，几秒钟就能重构一个复杂的模块；但有时候它又蠢得让人抓狂，甚至会一本正经地写出跑不通的代码，或者把你刚刚纠正过的错误再犯一遍。
为什么？是模型不稳定吗？
不，这通常是因为你的“打开方式”不对。
Claude Code 本质上是一个运行在 CLI 环境中的自主智能体（Agentic Coding Environment）。它受限于一个核心物理法则：上下文窗口（Context Window）。
为了帮你跨越从“新手”到“高玩”的门槛，我精读了 Anthropic 刚刚发布的官方最佳实践文档，并结合实战经验，提炼出了这 50 条核心军规。
掌握了它们，你就是指挥 AI 军团的编排者（Orchestrator）了。
核心逻辑： 上下文是稀缺资源，清晰度是最高杠杆。
核心逻辑： 不要每次都手动教，把规则固化到文件里。
核心逻辑： 把重复的流程封装成“技能”，把 AI 集成到流水线。
核心逻辑： 识别“失败的味道”，及时止损。
刚开始使用 Claude Code，你可能靠的是直觉。但要在大规模工程中稳定产出，你必须依靠方法论。
这 50 条军规，就是从“抽盲盒”走向“工业化生产”的桥梁。掌握了它们，你就不再是被动的 User，而是这支硅基军团的 Commander。
资料链接：https://code.claude.com/docs/en/best-practices
深度实战：构建你的“AI 原生工作流”
Tip 只是冰山一角。真正的威力在于将这些技巧组合成一套“开发工作流”。
在我的极客时间专栏《AI 原生开发工作流实战》中，我将带你实战演示：
别再用蛮力写代码了。扫描下方二维码，学会用 AI 的杠杆。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-25 07:57:26
本文永久链接 – https://tonybai.com/2026/01/25/gas-town-multi-agent-orchestration-ai-programming-revolution
大家好，我是Tony Bai。
“启示录”（Apocalypse）在希腊语原意中并非仅指毁灭，更意味着“揭开面纱”。
2026 年的钟声敲响时，软件开发领域正经历着这样一场启示录。旧世界——那个由 IDE、手动键入代码、人类结对编程构成的世界——正在崩塌。我们拥有了前所未有的强大模型（Claude Sonnet/Opus 4.5、GPT-5、Gemini 3.0 Pro等），但当开发者试图用它们构建庞大的企业级系统时，却陷入了另一种混乱：我们被淹没在无数的 Prompt 中，我们在复制粘贴中迷失，我们变成了 AI 的保姆。
前 Amazon/Google 资深工程师、传奇技术博主 Steve Yegge 在其 57 岁生日之际，用一款名为 Gas Town 的工具，揭开了新世界的面纱。
他指出，行业的方向错了。我们一直在试图制造一只能够解决所有问题的“超级蚂蚁”（Super-Ant）。但纵观生物学与人类工业史，解决复杂规模化问题的从来不是一个个体，而是分工明确、协同工作的群体。
Gas Town 的发布，标志着 AI 编程正式从 “单点辅助” (Level 6) 迈向 “集群编排” (Level 
。在这个新世界里，IDE 变成了过时的手工作坊，而 Gas Town 则是一座由 Go 语言 构建的、轰鸣作响的 AI 软件工厂。
本文将带大家走进这片废土，见证多智能体编排如何开启这场工业革命。
Steve Yegge 在其著名的《Revenge of the Junior Developer》中曾预言，AI 将赋予初级开发者对抗资深专家的能力。但他现在的观点更进一步：人类开发者必须进化为“编排者”（Orchestrator）。
为了厘清从“手工作坊”到“工业化生产”的演变路径，他在《Welcome to Gas Town》一文中，提出了一套精准的开发者 AI 进化等级论。首先，你需要在表格中找到自己的位置：
Gas Town 就是 Stage 8 的产物。当你有 30 个 Agent 同时工作时，你不再写代码，你是在管理产能。
Gas Town 的核心隐喻是“工厂”。
在传统 IDE 模式下，AI 是你的结对编程伙伴（Partner）。这听起来很温馨，但不可扩展。你不能和 50 个人同时结对编程。
在 Gas Town 模式下，AI 是工人（Worker）。
Gas Town 的命名致敬了《疯狂的麦克斯》（Mad Max），暗示了 AI 编程早期的混乱与狂野。但在这层废土朋克的外衣下，是一套严密的分布式系统架构。
Gas Town 采用了一种类似 Kubernetes 的层级架构：
Gas Town 不使用通用的 AI，而是将 LLM 封装为特定的角色 (Persona)。每个角色都有独立的 System Prompt、上下文记忆和权限边界。
Gas Town 的运行依赖两大理论基石：
定义： “如果钩子（Hook）上有工作，Agent 必须运行它。”
LLM 通常被训练得非常礼貌，倾向于等待用户指令。Gas Town 必须打破这种“礼貌”。系统通过底层的事件循环，不断向 Agent 发送信号，强制驱动它们读取任务队列。
定义： 非确定性幂等性。
在 Temporal 等传统编排系统中，工作流要求是确定性的。但在 AI 领域，同样的 Prompt 每次生成的代码都不同。
Gas Town 接受这种混沌。它不要求过程一致，只要求结果收敛。
这就是 AI 时代的“最终一致性”。
Gas Town 能够运转，不仅仅是因为 Prompt 写得好，更因为它底层有一套极具颠覆性的数据存储技术。这也是为什么它必须用 Go 重写的原因。
Steve Yegge 曾尝试用 SQLite 甚至文本文件来存储 Agent 记忆，但最终发明了 Beads。
Beads 是什么？
它是一个分布式任务追踪系统，但它将 Issue（任务） 视为 Code（代码）。
基于 Beads，Gas Town 构建了 MEOW (Molecular Expression of Work) 技术栈。
这套机制让 Gas Town 能够定义复杂的“软件生产配方”。你可以编写一个 Formula（配方），定义“如何修复一个 Bug”，然后让 100 个 Agent 同时执行这个配方。
Steve Yegge 之前尝试过 TypeScript 和 Python，但最终 Gas Town (v4) 选择了 Go。这并非巧合，而是 AI 基础设施演进的必然。
AI 生成代码的“质量悖论”：
并发原语：
Gas Town 本质上是一个高并发的编排系统。它需要同时管理数十个 tmux 会话、监控数十个 Agent 进程、处理并行的 Beads 数据读写。Go 的 Goroutines 和 Channels 让这种复杂的并发模型变得可控且高效。
云原生基因：
Gas Town 的目标是成为 AI 时代的 Kubernetes。使用与 K8s、Docker、Terraform 相同的语言，意味着它可以无缝融入现有的云原生生态。
在 Gas Town 中，编程不再是打字，而是一种“氛围编程” (Vibe Coding)。
这种高效带来的副作用是 “决策疲劳”。
Steve 称之为 Bezos Mode。就像杰夫·贝佐斯一样，你不再做执行层的工作，你整天都在做高维度的决策：架构评审、产品方向判断、风险评估。
这种高密度的决策会迅速耗尽大脑的“缓冲区”。Steve 及其团队发现，使用 Gas Town 后，他们每天下午必须强制午睡（Nap Strike），否则大脑会罢工。
这预示着未来开发者的核心竞争力，将从“编码速度”转变为“决策质量”。
目前，Claude Code 只是“工人”，Loom 和 Ralph Wiggum 试图成为“包工头”，而 Gas Town 是唯一的“工厂”。
Gas Town 不关注单个 Agent 有多强，它关注的是账本 (Ledger)、审计 (Audit Trail) 和 流水线 (Pipeline)。这才是企业级软件开发的刚需。
Steve Yegge 做出了一个激进的预测：“一人一库” (One Engineer per Repo)。
随着 Gas Town 类工具的普及，一个装备了 AI 军团的 3 人精英小组，其产出将吊打 100 人的传统开发部门。大公司内部繁琐的沟通成本，在 AI 的光速执行面前，将成为无法忍受的累赘。
未来的独角兽，可能只有 3 名员工，但拥有 3000 个并发运行的 Agent。
对于开发者而言，现在是时候放下 IDE，学习 Beads，去尝试驾驭那个疯狂、混乱但充满无限可能的 Gas Town 了。
截至本文编写时，Gas Town 目前仍处于 v0.5.0 的早期阶段，它昂贵（消耗大量 Token）、危险（可能搞乱代码）、粗糙（基于 tmux）。但它代表了不可逆转的未来。
Gas Town 的出现，就是软件工程领域的“蒸汽机时刻”。它无情地宣告了手工作坊（IDE）时代的终结，并开启了工业化大生产（编排器）的序幕。
Go 语言凭借其稳健、高效和并发优势，再次赢得了这场 AI 基础设施战争的入场券。
“启示录”已经降临。旧世界的围墙正在倒塌，而 Gas Town 的大门已经打开。
因为正如 Steve 所说：“你是想继续做一只忙碌的蚂蚁，还是想成为那只在竹林里指挥若定的熊猫？”
Welcome to Gas Town.
The factory is open.
你的“进化”阶段
Gas Town 描绘的未来令人心潮澎湃，也让人心生敬畏。对照文中的“8个进化阶段”，你目前处于哪一级？你准备好迎接“一人一库”的时代，还是更享受传统的结对编程？
欢迎在评论区晒出你的“等级”，或者分享你对多智能体协作的看法！让我们一起在废土中寻找新世界的坐标。
如果这篇文章点燃了你对 AI 编程的全新想象，别忘了点个【赞】和【在看】，并转发给你的极客朋友，邀请他们一起加入 Gas Town！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-24 07:59:58
本文永久链接 – https://tonybai.com/2026/01/24/go-generics-finally-supports-generic-methods
大家好，我是Tony Bai。
“我们预计 Go 永远不会添加泛型方法。” —— Go FAQ (曾几何时)
对于许多期待 Go 泛型能像 C++ 或 Java 那样强大的开发者来说，这句话曾像一盆冷水。然而，就在最近，Go 语言之父之一、核心团队成员 Robert Griesemer 提交了一份重量级提案 #77273，正式建议为 Go 添加泛型方法 (Generic Methods) 的支持。
这是 Go 团队在设计哲学上的一次深刻反思与转变。为什么曾经被视为“不可能”的特性如今变得可行？它将如何改变我们编写 Go 代码的方式？本文将为你详细解读这份提案的来龙去脉。
在 Go 1.18 泛型落地之初，开发者们很快发现了一个令人困惑的“不对称性”：我们可以编写泛型函数，可以定义泛型类型，但我们却不能编写泛型方法。
// 泛型函数：OK
func Print[T any](s []T) { ... }
// 泛型类型：OK
type List[T any] struct { ... }
// 泛型方法（具体方法）：目前报错！
func (l *List[T]) Map[R any](f func(T) R) []R { ... }
这种限制让许多习惯了链式调用的开发者感到痛苦。例如，在处理集合操作时，我们不得不打断链式调用，转而使用函数：
// 目前的写法（函数式）：
result := Map(Filter(list, predicate), mapper)
// 期望的写法（方法式）：
result := list.Filter(predicate).Map(mapper)
为什么会有这个限制？ 根源在于 Go 的接口 (Interface) 设计。
在 Go 中，方法的主要职责曾被认为是“实现接口”。如果你允许在结构体上定义泛型方法，那么逻辑上，你也应该允许在接口中定义泛型方法。
然而，支持接口中的泛型方法在实现上极其困难。因为 Go 的接口是隐式实现的（Structural Typing），编译器无法在编译期知道所有可能实现该接口的类型及其泛型方法的实例化情况。这会导致需要在运行时动态生成代码（JIT），或者面临巨大的性能开销，这与 Go “快速编译、静态链接”的哲学相悖。
正因如此，Go 团队为了避免陷入接口泛型方法的泥潭，索性“一刀切”地禁止了所有泛型方法，包括具体的结构体方法。
77273 提案的核心，在于观念的转变。为了厘清讨论的基础，Robert Griesemer 在提案中首先明确了两个术语的定义：
Go 团队开始意识到，这两者虽然都叫“方法”，但其角色不必完全绑定。Robert Griesemer 写道：
“或许我们需要改变一下看法：具体方法本身就是一种有用的语言特性，独立于接口而存在。”
Go 团队开始意识到，具体方法不仅仅是为了实现接口，它更是代码组织和API 设计的重要手段。
既然“接口泛型方法”暂时无法实现，为什么不能先解放“具体泛型方法”呢？
于是，提案的核心逻辑变得简单而清晰：允许在具体类型上定义泛型方法，但这些方法不能用于匹配接口。
换句话说，如果一个接口定义了 m()，而你的结构体有一个泛型方法 mT any，那么这个结构体并不算实现了该接口。因为接口方法不能有类型参数，所以它们在签名上根本不匹配。
通过将“具体方法”与“接口实现”解绑，Go 团队终于找到了绕过技术壁垒、通过泛型方法的路径。
如果你熟悉 Go 的泛型函数，那么泛型方法的语法会让你感到非常亲切。它几乎就是将泛型函数的语法照搬到了方法声明中。
目前的规范中，方法声明如下：
func Receiver MethodName Signature
提案修改为：
func Receiver MethodName [TypeParameters] Signature
示例：
type S struct { ... }
// 定义一个泛型方法 m，接受类型参数 P
func (s *S) m[P any](x P) { ... }
接收者本身也可以是泛型的：
type G[P any] struct { ... }
// G 自身的类型参数 P 和方法 m 的类型参数 Q 同时在作用域内
func (g *G[P]) m[Q any](x Q) { ... }
调用泛型方法与调用泛型函数完全一致。支持显式实例化，也支持类型推断。
var s S
// 显式传入类型参数 int
s.m[int](42)
// 类型推断：编译器自动推断 P 为 int
s.m(42)
这是一个非常酷的特性。你可以将泛型方法作为一个函数值提取出来。
type List[E any] struct { ... }
func (l *List[E]) Format[F any](e E, f F) string { ... }
// 实例化 List 类型，提取 Format 方法
// 得到的 f 是一个泛型函数
f := List[string].Format
// f 的签名：func[F any](l *List[string], e string, val F) string
注意，你必须先实例化接收者类型（List[string]），但方法本身的类型参数（F）可以留待后续调用时确定。
泛型方法不实现接口：即使你的泛型方法实例化后（比如 m[int]）签名与接口匹配，它也不被视为实现了接口。
type Reader struct{}
func (r *Reader) Read[T any](buf []T) (int, error) { ... }
// 错误！Reader 并没有实现 io.Reader
// 因为 io.Reader 的 Read 需要 Read([]byte)，而 Reader 的 Read 是一个泛型模版
var _ io.Reader = &Reader{}
该提案一经发布，立即在 Go 社区引起了强烈反响。
实施计划：
这被视为一个完全向后兼容的变更。如果提案获批，我们最早可能在 Go 1.27 中看到它的身影（或许会先作为 GOEXPERIMENT 推出）。
对于工具链（如 gopls、go/types）来说，这将是一个巨大的工程挑战，可能需要几个版本周期来完全适配。
从坚决反对泛型，到引入泛型但限制方法，再到如今解绑接口与方法、拥抱泛型方法，Go 语言的演进之路始终贯彻着务实 (Pragmatism) 的哲学。
它不追求理论上的完美对称，而是优先解决工程实践中的痛点。虽然“接口泛型方法”的缺失依然是一个遗憾，但#77273 提案无疑为 Go 开发者打开了一扇通往更表达力、更优雅代码的大门。
让我们拭目以待，迎接 Go 泛型的完全体！
资料链接：https://github.com/golang/go/issues/77273
你的“泛型”期待
泛型方法的到来，无疑会让 Go 代码变得更流畅。在你的项目中，有哪些痛点是目前泛型无法解决，但有了泛型方法后就能迎刃而解的？或者，你
对“泛型方法不匹配接口”这一限制有什么看法？
欢迎在评论区分享你的代码场景或担忧！让我们一起期待 Go 语言的下一次进化。
如果这篇文章让你对 Go 的未来充满了期待，别忘了点个【赞】和【在看】，并转发给你的 Gopher 朋友，告诉他们：好日子要来了！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-23 08:09:06
本文永久链接 – https://tonybai.com/2026/01/23/go-developer-2025-survey-result
大家好，我是Tony Bai。
近日，Go 官方发布了 2025 年开发者调查报告。作为 Go 社区的年度“体检报告”，这份基于 5,379 份有效问卷的数据，为我们勾勒出了一幅清晰的 Go 生态全景图。
总体来看，Go 依然是一个令人愉悦的语言，拥有极高的用户忠诚度和稳固的云原生地位。但在这份光鲜的成绩单背后，我们也看到了一些值得深思的信号：关于最佳实践的迷茫、对 AI 工具的爱恨交织，以及对官方领导力的期待。
今天，让我们抛开表面的数字，一起来解读一下这份报告背后的趋势与挑战。
首先，让我们看看是谁在使用 Go。
隐忧：使用 Go 不满 1 年的新人比例从 2024 年的 21% 下降到了 13%。
这可能并非 Go 的吸引力下降，而是受宏观经济影响，入门级软件工程师岗位的招聘紧缩。由于许多人是为了特定工作才学习 Go，招聘市场的寒冬直接传导到了新人的流入率上。这提醒社区，需要更多关注新人的入门体验和职业引导。
Go 的核心竞争力依然坚挺：91% 的开发者对使用 Go 感到满意，其中“非常满意”的比例高达近 2/3。这一数据自 2019 年以来一直保持极高水平。
开发者们爱 Go 的理由很纯粹：简单、标准库强大、工具链完善。
一位来自能源行业的 10 年+ 资深开发者评价道：“我使用 Go 的全部原因就是其出色的工具和标准库… 它让开发面向服务的应用变得简单而可靠。”
然而，痛点依然存在：
Go 用来做什么？答案毫无悬念：
这“三驾马车”构成了 Go 的基本盘。
但在最热门的 AI 领域，Go 的表现呈现出一种“双刃剑”态势。
关于 AI 辅助编程（如 GitHub Copilot, ChatGPT，Claude Code, Gemini等），调查结果揭示了一个有趣的现象：用得越多，抱怨越多。
为什么？因为质量。
开发者们发现，AI 在“寻找信息”（如解释代码、查找 API 用法）和“消除苦力活”（如生成单测、写样板代码）方面表现出色。但在“编写核心代码”时，AI 经常生成不可运行、有 Bug 或不符合 Go 惯用写法 (Non-idiomatic) 的代码。
一位金融行业的开发者吐槽道：“我从未对 AI 生成的代码质量满意过……我也觉得审查 AI 生成的代码非常累人，这种开销扼杀了它的生产力潜力。”
这份报告最令人敬佩的一点，是 Go 团队对自己工作的坦诚审视。
官方回应：Go 团队已明确表示，2026 年将重点投资于鼓励更多贡献者参与，并加强与社区的沟通，以重建信任。
2025 年的 Go，像一位步入中年的稳重工程师。它在云原生领域有着不可撼动的地位，但也面临着来自新兴技术栈（如 AI 开发中 Python 的强势）和自身语言特性（如错误处理、枚举）的挑战。
对于 Gopher 而言，这份报告既是定心丸，也是冲锋号。它告诉我们：Go 依然是构建可靠后端服务的最佳选择，但我们也需要更积极地拥抱变化，探索最佳实践，并在 AI 浪潮中找到属于 Go 的独特生态位。
资料链接：https://go.dev/blog/survey2025
你的年度总结
看完这份官方报告，你觉得它准确反映了你的现状吗？在你看来，Go 语言目前最大的痛点是什么？对于 AI 辅助编程，你是“真香”还是“劝退”？
欢迎在评论区分享你的真实感受！让我们一起为 Go 社区的发展建言献策。
如果这篇文章让你对 Go 生态有了更全面的了解，别忘了点个【赞】和【在看】，并转发给你的 Gopher 朋友，看看他们怎么说！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-22 08:23:51
本文永久链接 – https://tonybai.com/2026/01/22/why-are-we-still-talking-about-containers-in-ai-age
大家好，我是Tony Bai。
“如果你在 2014 年告诉我，十年后我们还在讨论容器，我会觉得你疯了。但现在是 2025 年，我们依然在这里，谈论着同一个话题。”
在去年中旬举行的 ContainerDays Hamburg 2025 上，早已宣布“退休”的云原生传奇人物 Kelsey Hightower 发表了一场发人深省的主题演讲。在这个 AI 狂热席卷全球的时刻，他没有随波逐流地去谈论大模型，而是回过头来，向所有技术人抛出了一个灵魂拷问：
为什么我们总是在追逐下一个热点，却从来没有真正完成过手头的工作？
Kelsey 首先回顾了他职业生涯中经历的三次技术浪潮：Linux 取代 Unix(AIX、Solaris等)、DevOps 的兴起、以及 Docker/Kubernetes 的容器革命。
他敏锐地指出，技术圈似乎陷入了一个无休止的“海啸循环”：
“我们就像一群踢足球的孩子，看到球滚到哪里，所有人就一窝蜂地冲过去，连守门员都离开了球门。结果是，球门大开，后方空虚。”
这就是为什么 10 年过去了，我们还在谈论容器。因为我们当年并没有真正“完成”它。我们留下了无数的复杂性、不兼容和“企业级发行版”，却忘了初衷。
在演讲中，Kelsey 分享了他最近的一个惊人发现：Apple 正在 macOS 中原生集成容器运行时。
这不是 Docker Desktop，也不是虚拟机套娃，而是操作系统级别的原生支持。这就是 GitHub 上的一个名为 apple/container 的 Apple 开源项目：
Kelsey 提到 contributors 中有 Docker 元老 Michael Crosby ，Michael Crosby 正在 Apple 做着这件“不性感”但极其重要的事情。
Kelsey 认为，这才是容器技术的终局：
这正是那些没有去追逐 AI 热点，而是选择留在“球门”前的人，正在默默完成的伟大工程。
作为 Google 前员工，Kelsey 对 AI 并不陌生。但他对当前的 LLM 热潮保持着清醒的警惕。
他现场演示了一个有趣的实验：询问一个本地运行的 LLM “FreeBSD Service Jails 需要什么版本？”
* AI 的回答：FreeBSD 13（一本正经的胡说八道）。
* 真相：FreeBSD 15（尚未发布）。
Kelsey 指出，现在的 AI 就像一个热心但糊涂的路人，它不懂装懂，只想取悦你。
他的建议是：
演讲的最后，Kelsey 回答了关于开源、职业发展和未来的提问。他的几条忠告，值得每一位技术人铭记：
Kelsey Hightower 的这场演讲，是对当前浮躁技术圈的一剂清醒剂。
他提醒我们，技术的真正价值，不在于它有多新、多热，而在于它是否真正解决了问题，是否被完整地交付了。在所有人都在谈论 AI 的今天，或许我们更应该关注那些被遗忘的“球门”，去完成那些尚未完成的伟大工程。
资料链接：https://www.youtube.com/watch?v=x1t2GPChhX8
你的“烂尾”故事
Kelsey 的“海啸循环”论断让人深思。在你的职业生涯中，是否也经历过这种“还没做完旧技术，就被迫去追新热点”的无奈？你认为在这个 AI 时代，我们该如何保持“工匠精神”？
欢迎在评论区分享你的经历或思考！让我们一起在喧嚣中寻找内心的宁静。
如果这篇文章让你停下来思考了片刻，别忘了点个【赞】和【在看】，并转发给那些还在焦虑中奔跑的同行！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
