本文永久链接 – 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：一场“微专栏”的内容实验

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：在喧嚣中寻找信号

翻看我 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 时代的巨大机会。

2026：Coding 廉价，眼光无价

如果说 2025 年是 AI 辅助编程进入Agent模式（Copilot、Cursor、Claude Code、Gemini cli等）的普及年，那么 2026 年，将是 自主智能系统（Agentic System） 的爆发年。

在 AI 能以百倍速度生成代码的时代，单纯的 Coding 能力正在不可避免地贬值。但架构设计的能力、技术选型的眼光、以及构建复杂系统的智慧，将变得无价。

基于此，在 2026 年，我将在公众号（付费微专栏）和知识星球（免费畅读）双线并行，重点规划以下三大战役：

战役一：AI 原生工程与 Agent 实战

这不再是写几个 Prompt 的游戏，而是真正软件工程范式的变革。

• 自主智能系统 (Agentic System) 构建实战：我们将深入研究如何构建真正的 AI Agent。不仅仅是调用 API，而是设计能够感知环境、规划任务、使用工具、具有记忆并能自我修正的智能系统。
• 以Claude Code为例的AI编码进阶实战：作为当前最强的 AI 编码 Agent，Claude Code 的潜力远未被挖掘。我们将探索如何用它实现L4级工作流，即AI 作为自主软件工程师，能够独立地、端到端地完成从需求理解到部署上线的整个软件开发生命周期，实现端到端的自动应用构建。同时我们还要考虑AI使用的经济性(省token，省money)。
• AI 时代的软件工程探索：当代码主要由机器生成时，我们的 CI/CD、Code Review 以及测试策略该如何演进？这将是我们探索的重点。

战役二：架构设计与系统思维

当“怎么写”变得容易，“写什么”和“怎么设计”就决定了你的上限。

• 分布式系统与架构设计微专栏：我们将跳出语言细节，探讨高可用架构、一致性难题、分布式事务等硬核话题。
• 最佳实践与反模式：从微服务拆分到单体演进，从 数据表查询性能设计到领域建模（DDD），我们将沉淀出一套经得起时间考验的工程智慧。

战役三：Go 语言的深耕与重塑

Go 依然是我们的基本盘，但在 2026 年，我们要换个玩法。

• AI 时代的角色转换：Go 在 AI 基础设施（推理服务、向量检索、Agent 后端）中的核心地位愈发稳固。我们将关注 Go 如何更好地服务于 AI 负载。
• 硬核实战：Porting（移植）系列：这是我今年最想做的一件事。我们将通过用 Go 复刻经典系统（如编写一个 Mini-Kafka 或 Mini-DB），来深入理解存储引擎、网络协议和分布式共识的底层原理。这是掌握系统编程最扎实的路。
• 传统艺能：Go 的极致性能优化与可观测性依然是很多读者的刚需，也是Go生产事件中的重中之重。我们将继续关注 Go Runtime 的演进（如 Green Tea GC、SIMD），确保我们始终站在性能的最前沿。

当然，作为系统编程的双子星之一，Rust 依然会在我的技术雷达范围内，作为我们拓宽技术视野的重要补充。

小结

2026 年的画卷已经展开。

这是一个技术人最焦虑的时代，也是最令人兴奋的时代。焦虑在于旧经验的快速折旧，兴奋在于个体生产力的无限放大。

新的一年，我希望通过这些深度微专栏和知识星球的陪伴，帮你建立起抵御技术通胀的护城河。

让我们左手握着 Go 与架构设计的工程底气，右手举起 AI Agent 的效率火把，从“代码工人”进化为“系统构建者”。

祝大家在 2026 年，代码无 Bug，架构有灵魂，人生有增量！

扫码加入我的知识星球，2026 全年微专栏以及存量微专栏免费畅读！

你的 2025 关键词

我的 2025 是“坚守与拥抱”。回顾你的 2025，如果用一个词或一句话来总结，会是什么？对于即将到来的 2026，你最大的技术期待又是什么？

欢迎在评论区留下你的年度关键词，让我们一起记录这段不平凡的时光！

如果这篇文章给了你前行的力量，别忘了点个【赞】和【在看】，并转发给你的朋友，让我们在 2026 顶峰相见！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/12/18/escaping-java-bicycle-shed-is-go-the-pure-land

大家好，我是Tony Bai。

“如果每次我看到‘为什么不这么写？’这种针对完美代码的 PR 评论都能得到一分钱，我现在已经退休了。”

近日，一位在 r/golang 社区发帖的开发者发出了这样的咆哮。他受够了 Java 生态中那种无休止的、关于细枝末节的争论——也就是所谓的“自行车棚效应”(Bike Shedding)。他正在认真考虑转向 Go 语言。

但问题是，换一门语言，真的就能彻底摆脱人性的弱点，找到那份久违的“简单”与“高效”吗？

这篇帖子迅速引发了数百条评论的热议，并形成了一次关于团队文化、工程效率以及如何在代码审查中保持理性的深度反思。

---

科普小贴士：什么是“自行车棚效应” (Bike Shedding)？

这个概念源自帕金森定律。典故是：一个委员会在审批核电站计划时，对极其复杂的反应堆设计匆匆通过（因为太难懂，大家不敢轻易发言），却为了旁边自行车棚该漆成什么颜色而争论了一个小时（因为每个人都能懂，都想发表意见）。

在软件开发中，它特指团队在无关紧要的琐事（如代码风格、变量命名、语法糖）上浪费大量时间，而忽略了真正重要的系统设计和逻辑问题。

审视“自行车棚”—— 无效争论的代价

发帖人的痛苦，源于一种许多开发者都深有体会的经历：PR 被琐碎的个人偏好所劫持。

• 症状：代码逻辑正确、测试通过、符合规范。但审查者依然会问：“为什么不用 Optional.of(…).orElse(…) 而是用 if-else？”
• 潜台词：“如果是我的话，我会这么写。我要指出这一点，以显示我有在认真看代码，而且我很聪明。”
• 后果：
  • 时间浪费：为了一个不影响功能的改动，需要重新提交代码、等待 CI 跑完（在企业级 Java 项目中可能长达 20-30 分钟）、等待再次审查。
  • 士气低落：开发者感到自己的工作不被尊重，变成了为了满足审查者个人喜好而工作的“打字员”。

正如一位评论者尖锐指出的：“这不仅是语言问题，更是‘人’的问题。” 有些开发者倾向于过度工程化，为了使用设计模式而使用设计模式，而忽略了代码的实际价值。

Go 是解药吗？—— “强制统一”带来的自由

为什么发帖人认为 Go 是解药？因为 Go 的设计哲学确实在很大程度上抑制了“自行车棚”的滋生土壤。

1. 极简的语法与“唯一解”

Go 语言的设计哲学是“少即是多”。它没有 Optional，没有复杂的流式操作符，没有十种不同的方式来实现同一个功能。
一位资深 Gopher 指出：“在 Go 中，很少有人会争论‘为什么不这么写’，因为通常只有一种地道的写法。” gofmt 更是从根本上消灭了关于格式化的争论。

2. “Not Invented Here” vs. “Just Copy It”

Java 生态倾向于构建通用的、高度抽象的框架。而 Go 社区更推崇“复制一点代码胜过引入一点依赖”。这种文化鼓励简单、直接的实现，而不是过早的抽象。
评论区有人提到：“在 Go 中，如果你看到重复代码，你可能会选择容忍它；但在 Java 中，你会被要求抽象出一个通用的 Factory 模式。”

3. 工具链的胜利

Go 的工具链（lint, vet）非常强大且统一。如果一个问题可以通过静态分析发现，那就交给机器去阻止，而不是在 PR 中由人来指指点点。

硬币的另一面 —— Go 社区的“新自行车棚”

然而，逃离了 Java，就能彻底摆脱“自行车棚”吗？社区的声音并非一边倒。Go 并不是没有任何争论的乌托邦。

• 新的争论点：虽然不再争论 Optional，但 Go 社区也有自己的“圣战”：
  • “为什么你要用这个第三方库？标准库不够好吗？”
  • “这个 struct 应该放在 pkg 目录下吗？”
  • “为什么你要定义这个接口？让消费者去定义！”
• 过度的“地道”追求：有时，对“Idiomatic Go”（地道 Go 代码）的追求也会演变成一种教条主义。一位评论者分享了自己的经历：仅仅因为不想在代码中看到哪怕一点点“Java 味”，审查者就拒绝了一个完美运行的 PR。

由此看来，Go 虽然减少了语法的复杂性，从而减少了语法层面的争论空间，但它也无法消除人类对于微小差异的执着。

给所有团队的“防杠指南”

无论你使用 Java 还是 Go，如何建立一个健康的 Code Review 文化才是根本。社区贡献了许多极具价值的建议：

1. 区分“阻塞”与“建议”：引入明确的前缀，如 nit: (吹毛求疵，不阻塞合并)、suggestion: (建议，可不采纳)、blocker: (必须修改)。这能清晰地传达审查者的意图。
2. 自己动手，丰衣足食：如果审查者对某个非功能性的风格问题非常在意，且有权限，不妨直接提交一个小改动，而不是阻碍原作者的 PR。
3. 规则自动化：凡是能用 Linter (如 Checkstyle, golangci-lint) 解决的问题，绝不在人工审查中讨论。让机器做坏人。
4. 接受“足够好”：Code Review 的目标是保证代码质量、发现 Bug 和分享知识，而不是追求“完美”。完美是完成的敌人。

小结：选择语言，更是选择文化

回到标题的问题：Go 是开发者的净土或避风港吗？是，也不是。

它确实通过强制的规范和极简的设计，消灭了许多“低级”的自行车棚，提供了一种更务实、更直接的编程体验。

但在任何有人的地方，争论都会寻找新的出口。如果你厌倦了 Java 的复杂，Go 绝对值得尝试；但请记得，真正的避风港不在语言里，而在一个成熟、理性、相互尊重的团队文化中。

资料链接：https://www.reddit.com/r/golang/comments/1pechqt/who_else_has_or_wants_to_move_from_java_to_go/

吐槽时间

“自行车棚效应”恐怕是每个程序员心中的痛。你在代码审查中遇到过最离谱、最让你抓狂的“自行车棚”争论是什么？是关于一个变量名，还是一个缩进？

欢迎在评论区吐吐槽，让我们一起把这些“无效卷”晒在阳光下！

如果这篇文章说出了你的心声，别忘了点个【赞】和【在看】，并转发给你的团队（也许能改变点什么）！

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

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

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

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

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

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

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

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

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