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

他敏锐地指出，技术圈似乎陷入了一个无休止的“海啸循环”：

1. 热点爆发：一个新的技术（如 Docker）出现，VC 资金涌入，所有人都在谈论它。
2. 疯狂追逐：为了抢占市场，大家都只做“足够发布”的工作，追求速度而非完美。
3. 未竟而散：还没等这项技术真正成熟、稳定、标准化，下一个热点（如 AI）就来了。于是，半数工程师跳船去追新热点，留下一地鸡毛。

“我们就像一群踢足球的孩子，看到球滚到哪里，所有人就一窝蜂地冲过去，连守门员都离开了球门。结果是，球门大开，后方空虚。”

这就是为什么 10 年过去了，我们还在谈论容器。因为我们当年并没有真正“完成”它。我们留下了无数的复杂性、不兼容和“企业级发行版”，却忘了初衷。

Apple 的“非性感”工作——这才是未来

在演讲中，Kelsey 分享了他最近的一个惊人发现：Apple 正在 macOS 中原生集成容器运行时。

这不是 Docker Desktop，也不是虚拟机套娃，而是操作系统级别的原生支持。这就是 GitHub 上的一个名为 apple/container 的 Apple 开源项目：

Kelsey 提到 contributors 中有 Docker 元老 Michael Crosby ，Michael Crosby 正在 Apple 做着这件“不性感”但极其重要的事情。

Kelsey 认为，这才是容器技术的终局：

• 标准化：容器运行时将成为像 TCP/IP 协议栈一样的操作系统标配，无论你是 Linux、macOS 还是 Windows。
• 隐形化：你不再需要安装 Docker，不再需要关心运行时。它就在那里，像水和电一样自然。
• 应用商店的重构：未来，App Store 分发的可能就是容器镜像，彻底解决依赖冲突和安全沙箱问题。

这正是那些没有去追逐 AI 热点，而是选择留在“球门”前的人，正在默默完成的伟大工程。

关于 AI——不要做“盲目的复制者”

作为 Google 前员工，Kelsey 对 AI 并不陌生。但他对当前的 LLM 热潮保持着清醒的警惕。

他现场演示了一个有趣的实验：询问一个本地运行的 LLM “FreeBSD Service Jails 需要什么版本？”
* AI 的回答：FreeBSD 13（一本正经的胡说八道）。
* 真相：FreeBSD 15（尚未发布）。

Kelsey 指出，现在的 AI 就像一个热心但糊涂的路人，它不懂装懂，只想取悦你。

他的建议是：

1. 不要迷信生成：不要因为 AI 生成了代码就直接用，就像你不会盲目复制 Stack Overflow 的代码一样。
2. 上下文为王：AI 不是魔法，它只是一个强大的搜索引擎。如果你想得到正确答案，你必须先给它提供正确的上下文（Context）。
3. 先训练自己，再训练模型：在成为“提示词工程师”之前，先成为一名合格的工程师。只有当你自己深刻理解了问题，你才能判断 AI 的回答是天才还是垃圾。

给技术人的最后忠告

演讲的最后，Kelsey 回答了关于开源、职业发展和未来的提问。他的几条忠告，值得每一位技术人铭记：

• 关于职业：“你的职业生涯不应该是一场马拉松，而应该是一场接力赛。当你到达巅峰时，想的应该是如何把接力棒交给下一个人，而不是霸占着位置直到倒下。”
• 关于开源：“不要被商业公司的许可证游戏迷惑。如果代码是公开的，你可以 fork，可以学习。真正的开源精神在于分享和协作，而不在于谁拥有控制权。”
• 关于专注：像那家只做钳子的德国公司（Knipex）一样，专注做好一件事。技术圈不缺追风者，缺的是能够沉下心来，把一项技术打磨到极致、直到它变得“无聊”和“隐形”的工匠。

小结

Kelsey Hightower 的这场演讲，是对当前浮躁技术圈的一剂清醒剂。

他提醒我们，技术的真正价值，不在于它有多新、多热，而在于它是否真正解决了问题，是否被完整地交付了。在所有人都在谈论 AI 的今天，或许我们更应该关注那些被遗忘的“球门”，去完成那些尚未完成的伟大工程。

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

你的“烂尾”故事

Kelsey 的“海啸循环”论断让人深思。在你的职业生涯中，是否也经历过这种“还没做完旧技术，就被迫去追新热点”的无奈？你认为在这个 AI 时代，我们该如何保持“工匠精神”？

欢迎在评论区分享你的经历或思考！让我们一起在喧嚣中寻找内心的宁静。

如果这篇文章让你停下来思考了片刻，别忘了点个【赞】和【在看】，并转发给那些还在焦虑中奔跑的同行！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/20/ai-and-go-opportunities-and-challenges

大家好，我是Tony Bai。

在 AI 的滔天巨浪面前，每一位 Go 开发者心中或许都曾闪过一丝不安：Python 似乎统治了一切，我的 Go 语言技能树还值钱吗？AI 会取代我写代码吗？我该如何在这个喧嚣的时代保持清醒？

在 GopherCon 2025 的压轴圆桌会议上，一场名为“AI 与 Go：机遇与挑战”的深度对话给出了答案。

嘉宾阵容堪称豪华(从左二到右分别是)：

• Ian Cottrell: Google工程师，现从事 AI Agent 开发
• Katie Hawkman: 前 Go 团队成员，现 Mercari 平台工程师
• David Soria Parra: Anthropic 技术专家，MCP (Model Context Protocol) 联合创始人
• Jaana Dogan: 前 Go团队成员，Google Gemini Serving 团队专家, adk-go项目成员
• Samir Ajmani: Google Go 团队工程总监

他们没有贩卖焦虑，也没有盲目吹捧，而是用冷静、务实的工程师视角，为我们描绘了 Go 在 AI 时代的真实版图。

Go 的新机遇：AI 基础设施的“基石”

当被问及“Go 能提供什么 Python以及其他编程语言 无法提供的价值”时，嘉宾们的回答出奇一致：生产级的可靠性与并发能力。

Samir Ajmani 提出了一个精准的洞察：Go 的崛起得益于云原生时代的爆发，而 AI 正在带来“第二次云原生机遇”。

• 现状：目前的 AI/ML 基础设施大量依赖 Python，适合快速原型和实验。
• 痛点：当这些原型需要走向大规模生产，需要处理高并发推理、构建复杂的 Agent 编排、或者实现像 MCP (Model Context Protocol) 这样需要高度可靠性的协议时，Python 的动态特性和性能瓶颈开始显现。
• Go 的位置：Go 语言天生的高并发模型、静态类型安全、以及构建大规模分布式系统的基因，使其成为构建 AI 生产基础设施（Serving, Orchestration, Agent Protocols）的完美选择。

Katie 分享了一个真实案例：她在黑客马拉松中选择用 Go 而非 TypeScript 来编写 MCP Server，因为 Go 的代码在处理复杂协议逻辑时更易读、更易维护。

David(Anthropic)就个人经验和观察，认为Go 是目前AI最擅长生成的语言代码之一，这也是Go的一大优势！

Python 也许是 AI 的“训练语言”，但 Go 有望成为 AI 的“运行语言”。

职业焦虑：AI 会取代我们吗？

面对“AI 取代程序员”的言论，嘉宾们的态度是——“这只是另一种生产力工具，它改变了工作方式，但提升了人的价值。”

• Samir Ajmani：未来的软件构建方式可能会变成“组件组装”。但这依然需要懂系统设计、安全性和可靠性的专业人士来构建这些高质量的组件。对于初级开发者，门槛确实变高了（简单的代码生成不再是技能壁垒），但对于具备系统思维的工程师，这是最好的时代。
• Jaana Dogan (Google)：她提出了一个令人耳目一新的视角——“代码写得快了，不仅没让我失业，反而让我更强大了。” AI 极大地缩短了编码时间，这意味着工程师可以更快地去“连接点” (connect the dots)：将孤立的组件串联成系统，与更多人协作，验证更多设计想法。个人的产出能力被放大了，你不再是一个单纯的“螺丝钉制造者”，而更容易成为一名“系统架构师”。
• David Suryapara (Anthropic)：作为一名非 Go 核心开发者，David 的观察更为冷静。他认为，纯粹的“代码编写”技能（例如熟练背诵 API、手写 CSS）确实面临贬值。但核心工程能力——如拆解复杂需求、设计分布式系统、处理边缘情况——将变得前所未有的重要。 AI 抬高了入行的地板，但也让那些拥有深厚解决问题能力的工程师变得更加不可替代。
• Katie Hawkman：写代码从来不是工作中“最难”的部分，而是“最有趣”的部分。真正的难点在于——如何渐进式交付？如何设计良好的 UX？如何优化系统性能？这些是 AI 短期内无法完全替代的工程智慧。
• Ian Cottrell：我有 40 年的开发经验，每一次生产力工具的飞跃（从汇编到 C，从 IDE 到自动补全），人们都说“不需要程序员了”。结果呢？我们的需求量反而更大了。我们只是在提升期望值，尝试解决更难的问题。

不要试图成为每一个 AI 工具的专家。选择一个工具（如 Cursor 或 Claude Code），深入掌握它，让它服务于你的工作流，而不是被它淹没。

理性审视：算力、能源与负责任的 AI

主持人提出了一个尖锐的问题：在区块链曾因高能耗饱受诟病之后，我们该如何理性看待 AI 巨大的算力和能源消耗？作为开发者，我们该如何权衡使用 AI 工具的成本？

嘉宾们的回答，揭示了工程优化在 AI 时代的巨大潜力：

• Samir Ajmani (Google) 分享了一个令人振奋的实验：Go 团队尝试将 MCP 支持集成到 Go 语言服务器 (LSP) 中。结果发现，当 AI 能够直接调用精确的工具（Tools）而不是在那“空想”时，任务完成率提高了，延迟降低了，最重要的是——Token 消耗量减少了近 50%。 这意味着，通过优秀的工程工具（如 Go），我们可以显著降低 AI 的运行成本和碳排放。
• Jaana Dogan (Google) 认为我们正处于优化的早期阶段。就像当年的数据库优化一样，模型推理 (Inference) 的效率优化将是接下来的重头戏。缓存、量化、专用硬件，这些工程手段将大幅抵消模型增长带来的成本。
• David Suryapara (Anthropic) 提到了“小模型与蒸馏”。我们不需要每次都动用最昂贵、最慢的“超大模型”来解决所有问题。未来，针对特定领域（如代码生成）进行微调和蒸馏的小模型，将在效能和成本之间找到完美的平衡点。

不要盲目堆砌算力。“负责任的 AI”不仅是道德要求，更是工程优化的必然方向。 用更少的 Token 做更多的事，这本身就是 Go 开发者擅长的“资源优化”技能的延伸。

务实派的生存指南：过滤噪音，回归本质

在 AI 炒作的喧嚣中，如何保持清醒？

1. 从“小”开始：不要被“AGI 即将到来”的宏大叙事吓倒。像 Katie 建议的那样，承认自己是初学者，哪怕是 MCP 的创始人也说“现在没有所谓的专家”。放下包袱，去尝试写一个简单的 Agent，去用 Go 写一个 MCP Server。
2. 关注“确定性”：Jaana 和 Ian 都提到，AI 模型本质上是概率性的（非确定性），而工程系统需要确定性。Go 语言强大的静态分析、测试工具链和类型系统，是约束 AI 幻觉、构建可靠系统的最佳防线。用 Go 的“确定性”去包裹 AI 的“不确定性”，是未来的核心工程模式之一。
3. 解决实际问题：不要为了 AI 而 AI。如果老板让你“加点 AI 进去”，试着去寻找那些真正能通过 AI 提升效率的痛点（比如自动化文档更新、复杂日志分析），而不是生搬硬套。

小结：Go 社区的“绿地”时刻

这场圆桌会议传递出的最强烈信号是：乐观。

我们正处于一个类似于 2013 年 Docker 诞生前夜的时刻。AI 领域的“Kubernetes”、“Prometheus”还没有被写出来。这片巨大的空白，正是 Go 开发者施展拳脚的“绿地” (Greenfield)。

正如 Samir 所言：

“如果我想让 AI 真正能够与现实世界进行交易（比如订购 Pizza 并且真的送到），这中间需要大量的、可靠的基础设施。而 Go，是构建这一层的绝佳语言。”

所以，Gopher 们，别慌。带上你的并发模型，带上你的工程智慧，去构建 AI 时代的钢铁地基吧。

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

你的 AI 实践

听了这些顶级专家的观点，你是否对 Go 在 AI 时代的未来更有信心了？在你目前的开发工作中，是否已经开始尝试用 Go 构建 AI 应用或基础设施？你认为 Go 在 AI 领域最大的短板是什么？

欢迎在评论区分享你的实战经验或困惑！让我们一起探索 Go + AI 的无限可能。

如果这篇文章为你扫除了职业焦虑，别忘了点个【赞】和【在看】，并转发给身边迷茫的 Gopher 朋友！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/17/ai-era-cognitive-friction-as-your-last-moat

大家好，我是Tony Bai。

我们正在经历一场前所未有的知识通胀。

在 AI 时代，获取答案的成本已经降到了零。遇到 Bug？粘贴报错给 AI。写不出周报？给个主题让 AI 生成。想学新框架？让 AI 总结核心概念。

一切都变得无比丝滑，无比高效。

但你有没有发现，在这种“顺滑”的表象下，一种隐秘的症状正在蔓延：

• 离开 AI，你甚至很难完整地写出一个 500 字的逻辑闭环的观点。
• 面对一个稍微复杂的空白项目，如果不先问问 AI，你甚至不知道第一行代码该从哪里下笔。
• 你的思维变得越来越“平”，越来越像那个永远正确但毫无生气的标准答案。

《纽约时报》畅销书《五种财富》的作者Sahil Bloom 将这种症状称为 “AI Brain”（AI 大脑）。

这并不是说你变笨了，而是说你变钝了（Dull）。

就像一个长期坐轮椅的人，腿部肌肉必然会萎缩。当我们习惯了 AI 这种“认知轮椅”，我们大脑中负责深度思考、构建逻辑、处理混乱的那些神经连接，正在慢慢断开。

AI 消除了“摩擦”，但人类的智慧，恰恰诞生于“摩擦”之中。

摩擦的价值：为什么痛苦是必要的？

我们一直被教育要追求效率，要消除阻力。但在认知科学领域，这个逻辑是反的。

真正的学习和创造，发生于“First-pass Thinking”（第一遍思考）的挣扎中。

当你面对一个复杂的架构难题抓耳挠腮时，当你面对一张白纸试图构建文章结构感到挫败时，请珍惜这种痛苦。

这正是你的大脑在“举铁”，神经突触正在高强度地建立新的连接。这种不适感，是你正在突破认知边界的信号。

如果你在这个时刻按下了 AI 的生成键，它确实给了你一个完美的答案，就像剥好了的送到嘴边的虾肉。但你失去了什么？

你失去了咀嚼、消化、甚至感受饥饿的机会。你跳过了“构建心理模型”的过程，直接快进到了结果。

外包了痛苦，也就外包了成长的机会。

拯救大脑：4 条反直觉的“反内卷”法则

那么，我们该如何对抗这种“认知萎缩”？并不是要扔掉 AI 回归原始，而是要主动设计“认知摩擦”。

Sahil Bloom 基于个人洞察，为我们总结了 4 条适合技术人的自救法则：

法则一：拥抱“第一遍思考” (Embrace First-Pass Thinking)

原则： I write before I refine.（先写再润色，而不是先生成再修改。）

不要一上来就让 AI 写代码或写草稿。

强迫自己写出那个烂透了的初稿，强迫自己先在白板上画出架构图的草图。

因为 AI 只能基于概率生成“平均值”，只有你的“第一遍思考”才带有“方差”——也就是你的原创性（Originality）和个性。

下次写文档，不妨先自己写 300 字的大纲，再让 AI 补充；而不是让 AI 生成大纲，你来修改。

法则二：人为制造“认知摩擦” (Preserve Cognitive Friction)

原则： I sit with problems.（让问题飞一会儿。）

遇到难题，不要通过条件反射式地 Alt+Tab 切到 与大模型聊天的页面。

允许自己困惑，允许自己焦虑，允许自己在那里发呆 10 分钟。

这种“滞后”是必要的。它给了你的大脑后台进程运行的时间（思考脑启动）。很多深刻的洞察，往往是在你“卡住”的时候涌现的。

不妨设定一个“无 AI 时间窗口”。比如每天上午的头 2 小时，强制断开 AI 助手，只靠自己的大脑工作。

法则三：做少，但做深 (Do Less, But Deeper)

原则： One kick 10,000 times.（不怕千招会，只怕一招精。）

AI 让我们能做 100 件事：能写前端、能写后端、能画图、能剪视频。但每件事我们都只能做到 60 分的平庸水平。

既然 AI 把广度的成本降到了零，那么深度就成了唯一的护城河。

试试利用 AI 帮你处理那些琐碎的、低认知的杂事，然后把节省下来的精力，全部投入到那个 1% 的核心领域中去。钻研到连 AI 都无法回答的深度。

法则四：回归“物理世界” (Do More Human Things)

原则： Stay anchored.（保持锚定。）

AI 没有身体，没有痛感，没有疲惫。

人类的直觉、审美和同理心，建立在我们肉身的经验之上，这是 AI 永远无法模拟的底色。

动起来！去面对面交流，去感受代码运行在真实物理设备上的延迟，去用身体感受世界。这些“肉身经验”是你作为人类的最后防线。

小结：你的未来，取决于你拒绝让 AI 做什么

我们正在进入一个“分化”的时代。

• 一类人把 AI 当作拐杖，离了它就寸步难行，最终沦为算力的附庸。
• 另一类人把 AI 当作外骨骼，他们依然拥有强壮的肉体（核心思考力），AI 只是放大了他们的力量。

区别在于边界的划分。

Your future is defined by what you refuse to let AI do.
（你的未来，取决于你拒绝让 AI 做什么。）

请守住你的“思考领地”。

我可以让 AI 帮我优化代码，但我决不允许它替我设计架构；
我可以让 AI 帮我润色文字，但我决不允许它替我定义观点。

在这个充满“灰度”和“平庸”的 AI 生成世界里，请保持你大脑的“色彩”和“锋利(Sharp)”。

Don’t become dull.

你的“戒断”计划

读完这篇文章，你是否也意识到了自己对 AI 的过度依赖？如果让你现在关掉 AI 助手，你能独立完成手头的工作吗？你打算如何找回自己的“认知摩擦”？

欢迎在评论区立下你的 Flag，或者分享你的“人机边界”思考！让我们一起守护大脑的锋利。

如果这篇文章戳中了你的痛点，别忘了点个【赞】和【在看】，并转发给身边那些“沉迷 AI”的朋友，给他们提个醒！

深度实战：构建“以人为本”的 AI 工作流

在 AI 原生开发中，我们同样强调：User 必须是机长，AI 只是副驾驶。

如何在利用 AI 提效的同时，还能迫使自己进行深度的架构思考？

如何在 Spec-Driven Development (SDD) 中，保留人类的“第一遍思考”权利，让 AI 只做执行者？

欢迎关注我的极客时间专栏《AI原生开发工作流实战》。

在这里，我们不教你如何偷懒，我们教你如何利用 AI 进行更高维度的认知进化。

扫描下方图片二维码，开启你的进化之旅。

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/13/how-markdown-took-over-the-world

大家好，我是Tony Bai。

在这个由科技巨头主导、充斥着复杂算法和封闭生态的数字世界里，有一种技术显得格格不入。它没有专利壁垒，没有复杂的构建流程，甚至不需要特定的软件就能阅读。

它是 Markdown。

近期，知名科技博主 Anil Dash 发布了一篇题为《How Markdown Took Over the World》的长文。他在文中深情回顾了这一格式的诞生与崛起，并指出：在这个由科技巨头主导、充斥着封闭生态的数字世界里，Markdown 是一场属于普通人的胜利。

如今，从 GitHub 上的亿万代码仓库，到 ChatGPT等大模型 生成的每一个回答，再到你随手记下的 Apple Notes，Markdown 无处不在。它不仅成为了技术人员的“普通话”，更意外地成为了 AI 时代的“通用语”。

这一切，都始于 20 年前一位“固执”的苹果博主为了偷懒而写的一个小脚本。今天，让我们跟随 Anil Dash 的视角，回顾这段充满偶然与必然的技术传奇。

缘起：一个博主的“偷懒”计划

2002 年，John Gruber 做了一个在当时看来极其不理性的决定：全职运营一个只关注苹果公司动态的博客——Daring Fireball。

在那个博客刚刚兴起的蛮荒时代，发布内容并不容易。你要么忍受简陋的输入框，要么得手写复杂的 HTML 标签。为了能在写文章时（比如加粗、插入链接）不被繁琐的 HTML 标记打断思路，John 决定为自己开发一套工具。

他的核心理念是：既然 HTML (HyperText Markup Language) 太复杂，那就叫它 Markdown 吧。

如果你想加粗，就用 **；想引用，就用 >；想列表，就用 -。这些符号并非凭空创造，而是深受电子邮件时代纯文本格式习惯的影响。John 的天才之处在于，他将这些约定俗成的习惯标准化，并写了一个 Perl 脚本将它们转换为合法的 HTML。

2004 年 3 月，在 Aaron Swartz（那位早逝的天才少年）的协助测试下，Markdown 正式发布。没有人预料到，这个小小的工具将改变互联网的未来。

统治世界：从程序员到 AI

Markdown 的崛起并非一夜之间，但它的生命力却异常顽强。

1. 开发者的拥抱：GitHub 的出现是关键转折点。它将 README.md 设为项目标配，使得 Markdown 成为了开发者描述项目的标准格式。
2. 应用的普及：从 Slack 到 Discord，从 Notion 到 Obsidian，现代生产力工具几乎全部内置了 Markdown 支持。哪怕是 Google Docs 和 Apple Notes 这样的大众软件，最终也向用户需求妥协，加入了 Markdown 支持。
3. AI 的通用语：最令人意想不到的转折发生在当下。当最前沿的 LLM（大型语言模型）需要一种格式来输出结构化内容时，它们不约而同地选择了 Markdown。因为它既对人类可读，又对机器友好，且完全开放。

Anil Dash 在他的回顾文章中总结了 Markdown 成功的 10 个技术原因，其中几点尤为深刻：

• 解决真实问题：它不是为了“发明一种新格式”，而是为了解决“手写 HTML 太痛苦”这个具体痛点。
• 利用现有习惯：它没有强迫用户学习新符号，而是沿用了电子邮件时代的纯文本习惯（如 > 表示引用）。
• 没有知识产权 (IP) 负担：John Gruber 从未试图将其商业化或申请专利，这种彻底的开放性消除了所有采用者的顾虑。
• “查看源码”的哲学：Markdown 文件本身就是教程。你只需要看一眼源文件，就能立刻学会怎么写。

硬币的另一面：自由的代价

当然，Markdown 这种彻底的自由和缺乏中央控制，也带来了一个长期的副作用——碎片化。

正因为 John Gruber 当年只给出了一个 Perl 脚本而没有定义极其严谨的规范，导致后来出现了各种“方言”。GitHub 有自己的 GitHub Flavored Markdown (GFM)，Reddit 有自己的解析规则，Obsidian 和 Notion 也都添加了各自的私有语法（如双向链接 [[Link]]）。

这导致了一个尴尬的现实：虽然 Markdown 到处都是，但你的 Markdown 文件未必能在所有地方都完美渲染。 表格的语法支持不一，数学公式的写法各异，甚至连换行符的处理都有微妙差别。

直到后来 CommonMark 等项目的出现，才试图事后诸葛亮式地去修补这种分裂。

但幸运的是，Markdown 的核心语法（标题、列表、粗体、引用、链接）已经足够稳固，成为了事实上的标准。正是这最基础的 80% 功能，支撑起了它在 AI 时代的通用性。对于大语言模型而言，这些细微的方言差异完全可以忽略不计——它只需要用最基础的语法，就能让全世界读懂。

这也再次印证了那个道理：在规模化面前，简单且“足够好”的方案，往往能战胜完美但复杂的方案。

启示：善良与开放的力量

Markdown 的故事，是对当代科技行业的一种温柔提醒。

真正的互联网基础设施，往往不是由拿了巨额风投的初创公司在董事会里规划出来的。它们往往源于像 John Gruber 或 Aaron Swartz 这样的人——他们有正职工作，但也充满热情；他们为了解决自己的问题而造轮子，然后慷慨地将其分享给世界。

在这个被“护城河”、“生态闭环”和“商业化变现”充斥的时代，Markdown 证明了：一个好的点子，加上一颗慷慨的心，依然可以改变世界。

下次当你用 ** 加粗文字，或者看着 ChatGPT 逐行吐出格式完美的回答时，请记得：这背后没有复杂的商业算计，只有一位在费城看球赛的博主，想让你打字时能稍微轻松一点。

资料链接：https://www.anildash.com/2026/01/09/how-markdown-took-over-the-world/

你的 Markdown 记忆

Markdown 已经陪伴了我们 20 年。你还记得自己第一次接触 Markdown 是在什么场景下吗？是写 GitHub README，还是做笔记？你最喜欢的 Markdown 编辑器又是哪一款？

欢迎在评论区分享你的 Markdown 故事和神器推荐！ 让我们一起致敬这个简单而伟大的工具。

如果这篇文章让你对 Markdown 有了全新的认识，别忘了点个【赞】和【在看】，并转发给你的朋友，哪怕他只是个爱记笔记的非程序员！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – 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技能再上一个新台阶！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – 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 年的行业数据、巨头财报和底层物理限制，为我们揭示了一个残酷的真相：我们正面临计算能力的“硬墙”，而高效能编程语言，是撞破这堵墙的唯一工具。

2025 年计算的双重瓶颈——电力与芯片

如果你认为算力增长的瓶颈仅仅是芯片（GPU/TPU）的供应，那你就错了。Sutter 引用了微软、亚马逊和 NVIDIA 财报电话会议的内容，指出 2025 年计算增长的第一大瓶颈是“电力”。

• 微软 CFO：我们不缺 GPU，我们缺的是把它们放进去的“空间和电力”。
• 亚马逊 CEO：AWS 过去 12 个月增加了 3.8 吉瓦的电力容量，这相当于他们 2022 年的总容量。
• NVIDIA CEO 黄仁勋：1 吉瓦的数据中心就是 1 吉瓦的电力。你的“每瓦性能 (Performance per Watt)”直接决定了你的收入。

在这个背景下，能效 (Energy Efficiency) 不再是一个锦上添花的指标，而是直接关乎成本、收入乃至可行性的生死线。

这解释了为什么 C++ 和 Rust 如此重要：它们是目前仅有的、能够提供极致“每瓦性能”和“每晶体管性能”的主流便携式语言。在电力成为硬通货的今天，低效的软件就是在烧钱。

软件的贪婪与硬件的无奈

Sutter 提出了一个深刻的观点：我们对解决更复杂问题的需求，总是超过我们构建更强计算能力的速度。

• 2007 年的 iOS 开启了移动计算时代。
• 2022 年的 ChatGPT 开启了生成式 AI 时代。

每一次硬件性能的飞跃，都会迅速被新兴的、更加“贪婪”的软件需求所吞噬。AI 只是这一长串名单中的最新一员。这意味着，我们永远不会拥有“足够快”的硬件，我们永远需要压榨出硬件的最后一滴性能。

因此，C++ 和 Rust 的开发者数量在过去三年（2022-2025）增长最快，这并非巧合，而是行业对高效能计算需求的直接反映。

C++26 —— 安全与性能的“双重奏”

面对 Rust 在内存安全方面的挑战，C++ 并没有坐以待毙。Sutter 详细介绍了即将发布的 C++26 标准在安全性上的重大突破：

1. 消灭未初始化变量：C++26 将默认消除局部变量未初始化导致的未定义行为 (UB)。这是一个迟到但巨大的进步，直接消灭了一大类常见的安全漏洞。
2. 标准库“加固” (Hardening)：C++26 将引入标准库的“加固模式”，对常用的操作（如 vector 访问）进行边界检查。谷歌和苹果的实践数据表明，这种检查的开销极低（小于 1%），但能预防数以千计的潜在 Bug。
3. 契约 (Contracts)：C++26 将引入契约编程（Preconditions, Postconditions），将功能安全提升到语言层面。

Sutter 甚至提出了一个大胆的设想：未来的 C++29 是否应该暂停新特性的开发，专注于“修补漏洞”和“全面硬化”？ 这显示了 C++ 社区在安全性上的决心。

AI 不会取代程序员，它只是计算器

针对“AI 将取代程序员”的焦虑，Sutter 给出了一个冷静而乐观的比喻：AI 之于编程，就像计算器之于数学，或者搜索引擎之于知识。

• 它是乘数，不是替代品：AI 能极大地减少死记硬背和样板代码的工作，让程序员专注于解决更难、更新的问题。
• 需求在增长：即使有了 AI 加持，人类程序员的数量依然在快速增长。Atlassian CEO 指出：“如果软件开发的成本减半，我们不会减少一半的程序员，而是会编写两倍的软件，或者解决更复杂的问题。”
• AI 的局限：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 Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/02/kent-beck-ai-era-code-review-end-and-rebirth

大家好，我是Tony Bai。

“以前是‘嘿，能在合并前帮我看一眼吗？’……现在是‘我在海滩上和一个神灯精灵结对编程’。”

极限编程 (XP) 和测试驱动开发 (TDD) 的奠基人 Kent Beck，最近发表了一篇题为《Party of One for Code Review!》（代码审查的一人派对！）的博客。

这是一个略带伤感，却又无比清醒的时刻。曾经，代码审查是软件工程中最具社交属性的活动之一，是团队知识共享的纽带。但在 AI 能够以百倍于人类的速度生成代码的今天，那个属于人类互相 Review 的黄金时代，似乎正在走向终结。

取而代之的，是一场孤独的、高效的、由人类与 AI 共舞的“一人派对”。在这场派对中，代码审查并未消失，而是迎来了一场深刻的重生。

终结 —— 崩溃的“社交契约”

在过去的几十年里，代码审查建立在一个默认的“社交契约”之上：我们是平等的队友，我们以相似的速度工作，我们有义务互相检查。

然而，生成式 AI 的介入，彻底打破了这个平衡，导致了旧式 Code Review 的终结。

速度的失衡

Kent Beck 指出，当 AI 这个“神灯精灵”成为你的结对伙伴时，生产代码不再是瓶颈。你可以还没到午饭时间，就生成并探索了三种不同的实现方案。这种速度是任何人类同事都无法匹配的。

上下文的断裂

当你的同事还在为自己的任务焦头烂额时，你已经用 AI 生成了海量的代码。要求他们在一个下午读懂你和 AI 交互了数小时产生的逻辑，不仅是不公平的，甚至是不可行的。

于是，我们被迫进入了“一人派对”模式。你是唯一的作者，也是唯一的审查者。 传统的、依赖同步协作的审查模式，在 AI 的洪流面前显得苍白无力。

重生 —— 代码审查的新使命

如果不再依赖同事来找 Bug，代码审查还有存在的必要吗？Kent Beck 认为，它不仅有必要，而且比以往任何时候都重要。

代码审查正在重生，它的关注点从“纠错”转移到了两个更高维度的使命上：

健全性检查 (Sanity Check)：对抗“幻觉”

AI 是自信的，它生成的代码往往看起来完美无缺。新时代的审查，首先是一场“图灵测试”般的博弈。
你需要时刻保持警惕：“这看起来是对的，但它真的在做我要求它做的事吗？” Review 的本质，变成了确认 AI 是否忠实执行了人类的意图，而非纠结于语法细节。

对抗“结构性漂移” (Structural Drift)：守护架构的灵魂

这是 Kent Beck 最深刻的洞见。他担忧的不是 Bug，而是代码库的可操作性。

“如果结构变得过于纠缠，耦合变得太紧，精灵（AI）就会开始犯错。”

当大量代码被快速生成时，代码库很容易陷入混乱的熵增，这种现象被称为“结构性漂移”。一旦代码结构腐化，AI 对上下文的理解能力就会断崖式下跌，最终导致开发效率的崩盘。

因此，重生的代码审查，其核心使命是守护架构的健康。我们要确保代码库始终保持在一个“既让人类可读，又让 AI 可理解”的状态。

新工具 —— 用魔法打败魔法

在“一人派对”中，既然没有了人类队友，我们就需要新的盟友。Kent Beck 提到，他正在尝试使用像 CodeRabbit 这样的 AI 代码审查工具。

但他并不是想找一个“自动通过器”，而是将 AI 视为一个“不知疲倦的检查员”：

• 自动摘要与可视化：当 AI 生成了大量变更时，让另一个 AI 来总结这些变更，生成架构图，帮助人类快速找回上下文。
• 模式守护者：通过训练 AI 学习代码库的既有模式，让它来标记那些偏离了设计规范的“漂移”。

这就是新时代的讽刺与美妙：我们正在用 AI 来审查 AI，以确保人类依然掌握着系统的控制权。

孤独的领航员

文章的字里行间，流露出一种作为“老派黑客”的孤独感。Kent Beck 怀念那些与人激烈讨论、在白板前碰撞思维火花的日子。

“我现在独自工作，生成代码飞快……但这不那么令人满足。”

在 AI 时代，工程师的角色正在发生质变。我们从一群围着篝火（代码）取暖的部落成员，变成了独自驾驶飞船穿梭星际的领航员。AI 是我们强大的副驾驶，但方向盘，始终在且必须在人类手中。

小结

“一人派对”并不意味着彻底的孤独，它意味着更高的责任。

代码审查并没有死，它只是褪去了社交的外衣，重生为一种更纯粹、更严谨的工程纪律。在这场派对中，我们虽然独自起舞，但我们的舞步（代码结构）必须足够清晰、优雅，才能让那位强大的 AI 舞伴，始终跟随我们的节奏，而不至于踩到我们的脚。

资料链接：https://tidyfirst.substack.com/p/party-of-one-for-code-review

你的“派对”体验

Kent Beck 的“一人派对”，或许是每位 AI 时代开发者的必经之路。在你的工作中，是否也体验过这种“生成代码飞快，但无人Review”的孤独与不安？你是如何保证这些 AI 代码的质量和架构健康的？

欢迎在评论区分享你的故事或困惑，让我们在这场孤独的派对中找到彼此。

如果这篇文章触动了你，别忘了点个【赞】和【在看】，并分享给那些同样在 AI 浪潮中思考未来的朋友！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/01/ai-is-the-fastest-way-to-forget-how-to-code

大家好，我是Tony Bai。

在 Copilot、Cursor、Claude Code等普及的这两年，编程似乎变得前所未有的轻松。

Tab 键一按，十行代码倾泻而出；回车一敲，整个函数自动补全；一个Prompt发出，一个项目的框架代码便完成了。那种多巴胺分泌的快感是真实的，效率提升的数据也是真实的。我们仿佛一夜之间都变成了“十倍工程师”。

但在这种虚幻的快感背后，一种隐秘的焦虑正在资深开发者群体中蔓延：离开 AI 提示词，你还能流畅地写出一个复杂的递归，或者手撸一个带有完整错误处理的 HTTP Client 吗？

最近，我在技术社区看到一段发人深省的论述，它像一盆冷水，浇在了在这个狂热的 AI 时代：

“AI is the fastest way to forget how to code and how to think.”
（AI 是让你忘掉如何编程、忘掉如何思考的最快方式。）

这句话听起来很刺耳，但很真实。

如果我们习惯了让 AI 替我们思考，我们的大脑正在经历一场无声的“认知肌肉萎缩”。在 AI 时代，写下每一行代码依然重要。这不是一种复古的情怀，而是关乎我们职业生存的“认知保留”。

警惕“GPS 效应”：你是在驾驶，还是在被运送？

心理学中有一个著名的“GPS 效应”：习惯了使用导航的人，海马体（负责空间记忆的脑区）活跃度会降低，久而久之，他们会逐渐丧失方向感，甚至在自家小区门口也会迷路。

编程也是一样。

学习和成长的本质，发生在“挣扎”的过程中。

当你为了设计一个类结构而绞尽脑汁，当你为了修复一个“竞态条件”而彻夜排查，你的大脑正在构建复杂的神经连接，正在建立对系统的“心智模型”。

如果你跳过了这个“挣扎”的过程，直接向 AI 索要答案：

• AI 变成了“代笔者（Author）”：它替你构建了心智模型。
• 你变成了“消费者（Consumer）”：你只负责 Copy & Paste。

结果是：代码虽然跑通了，但你对系统组件之间的连接、潜在的边缘情况（Edge Cases）一无所知。你不再是代码的“作者”，你只是代码的“搬运工”。

一旦 AI 遇到它没见过的深水区，或者系统出现了一个隐蔽的 Bug，你会发现自己束手无策——因为你从未真正拥有过这段代码。

重构契约：把 AI 当做“磨刀石”，而非“枪手”

那么，我们要因噎废食，扔掉 AI 吗？当然不。

关键在于重构你与 AI 的协作契约。

核心原则只有一条：

Use AI as a Reviewer, a Rubber Duck, a Teacher. Not as an Author.
（把它当作审查者、橡胶鸭、导师。绝不要把它当作代笔者。）

如果 AI 在替你思考，你在退步；如果 AI 在逼迫你思考得更深，你在进步。

以下是基于这个原则的 4 个深度思考工作流：

1. 解释意图，而非索要实现

不要直接丢一句“帮我写个鉴权中间件”。

试着这样做： 你自己写出核心逻辑，然后对 AI 说：

“这是我写的鉴权逻辑。请解释我为什么在这里使用了 Context 传递用户信息？这种写法符合 Go 语言的惯用范式吗？有没有更好的风格？”

收益： 强迫自己理清思路，利用 AI 验证你的设计直觉。

2. 索要权衡(trade off)，而非标准答案

不要问“在这个场景下我该用 Redis 还是 Memcached？”

试着这样做：

“我倾向于使用 Redis，因为我们需要持久化。但在这个高并发场景下，使用 Redis 会带来哪些潜在的性能瓶颈或运维风险？请列出 Trade-offs。”

收益： AI 不再是给你喂饭，而是在陪你进行架构评审（Architecture Review）。

3. 寻找盲区，挑战假设

当你写完一段代码，觉得完美无缺时，把它扔给 AI：

“这段代码在什么极端输入下会崩溃（Edge Cases）？我是否遗漏了某些并发安全问题？请像一个最挑剔的 Tech Lead 一样 Review 它。”

收益： 利用 AI 广博的知识库，填补你的认知盲区。

4. 生成测试，而非生产代码

这是一个最高阶的玩法。你自己写业务代码，让 AI 写测试用例。

“这是我实现的订单状态机。请为它编写一套覆盖率 100% 的单元测试，特别是针对状态回滚的异常场景。”

收益： 如果 AI 生成的测试跑通了，说明你的逻辑是自洽的；如果跑不通，或者 AI 根本理解不了你的代码，说明你没想清楚。

小结：不要温和地走进那个良夜

在 AI 时代，能够熟练调用 API 生成代码的人多如牛毛。

但能够独立构建复杂系统心智模型，并能驾驭 AI 进行深度架构推演的人，将变得极度稀缺。

Writing code matters.

写代码的过程，强迫你思考，强迫你大脑建立连接，强迫你理解系统是如何像齿轮一样咬合的。

请继续亲自写下那些核心的、关键的代码。

把 AI 当作你的磨刀石，让你的思维在与它的碰撞中变得更加锋利，而不是让它锈蚀你的大脑。

深度实战：构建“以人为本”的 AI 工作流

道理大家都懂，但在高压的项目交付期，我们很容易滑向“让 AI 全自动生成”的舒适区。

如何建立一套强制性的工作流，既利用 AI 的效率，又保留人类的深度思考？

• 如何在 Spec 文档中通过“伪代码”保留思考过程？
• 如何配置 Claude Code，让它默认扮演 Reviewer 而不是 Coder？
• 如何利用 SDD (Spec-Driven Development) 迫使自己在 Coding 前先进行完整的思维推演？

如果你想掌握这套“不降智、反内卷”的高阶开发心法，欢迎关注我的极客时间专栏《AI原生开发工作流实战》。

在这个专栏里，我不教你如何偷懒，我教你如何进化。我们将一起探索，如何在 AI 的加持下，成为更强大的Software Engineer，而不是更快的Typist。

扫描下方卡片，开启你的认知升级之旅。

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/12/28/state-of-ai-vs-human-code-generation-report

大家好，我是Tony Bai。

“天下武功，唯快不破。但在软件工程里，‘快’可能是致命的诱惑。”

2025 年，AI 编码助手/智能体已经成为开发者的标配。它像蜜糖一样，让我们尝到了开发效率飙升的甜头：从自然语言一键生成函数，到自动补全繁琐的样板代码，甚至的整个项目的源码，功能交付周期从未如此之短。

然而，CodeRabbit 最新发布的《2025 年度 AI 与人类代码生成现状报告》却揭示了这层甜蜜糖衣下的残酷真相：Bug 激增、逻辑漏洞百出、安全隐患翻倍。

如果不加控制，这些由 AI 快速生成的劣质代码，很可能成为慢性发作的砒霜，最终毒害整个代码库的健康。这份报告用触目惊心的数据告诉我们：在享受 AI 带来的速度红利时，我们必须建立起更强大的免疫系统。

触目惊心的数字——AI 的“副作用”

CodeRabbit 分析了 470 个开源项目的 Pull Requests (PR)，其中 320 个由 AI 参与编写。结果显示，AI 并不是那个完美的“超级程序员”，它更像是一个高产但粗心的实习生。

问题总量激增 1.7 倍

这是最核心的发现。AI 参与的 PR 平均每 100 个包含 10.83 个问题，而人类纯手工编写的 PR 只有 6.45 个。这意味着，引入 AI 后，你的 Code Review 工作量不仅没有减少，反而可能翻倍。

逻辑错误暴涨 75%

这是最令人担忧的数据。AI 生成的代码在业务逻辑、依赖关系和控制流方面，错误率比人类高出 75%。

为什么？

因为 AI 只是在做“统计学上的模仿”，它并不真正理解你的业务规则。它能写出语法完美的代码，但却可能在转账逻辑里漏掉一个关键的校验。

安全漏洞增加 2.74 倍

AI 在处理敏感信息时表现堪忧。硬编码密码、不安全的对象引用等低级错误，在 AI 代码中出现的频率是人类的近 3 倍。AI 倾向于模仿它在训练数据中看到的“旧代码”，而那些旧代码中往往充满了过时的、不安全的模式。

可读性灾难：飙升 3 倍

虽然 AI 生成的代码乍一看很工整，但在命名规范、代码结构和上下文一致性上，它往往与现有代码库格格不入。这种“违和感”大大增加了后续维护者的认知负荷。

AI 为什么会犯错？——透视“黑盒”

报告不仅列出了数据，还深刻剖析了 AI 犯错的根本原因。为什么它这么快，却又这么容易错？

• 缺乏全局视野：AI 看不到你整个系统的架构图，也听不到资深工程师在茶水间的讨论。它只能根据局部的提示词生成代码，因此经常丢失业务上下文。
• “表面光鲜”：AI 擅长生成“看起来能跑”的代码。它会忽略边界检查、错误处理和异常路径，只为了尽快给出一个“正确答案”。
• 偏爱“简单”：AI 倾向于选择最简单的实现路径（例如，简单的循环、低效的 I/O），而忽略了性能优化和资源效率。

工程师的自救指南——如何驾驭 AI？

既然 AI 有这么多坑，我们是否应该因噎废食，放弃使用它？

当然不是。AI 依然是强大的加速器，前提是我们必须为它加上“护栏”。 未来的软件工程，不再是“写代码”，而是“设计系统来生成和验证代码”。

CodeRabbit 给出了几条务实的建议：

给 AI 喂“上下文”

不要只给 AI 一句简单的指令。把你的业务规则、架构约束、代码规范，甚至关键的配置文件，都作为上下文提供给它。让它在“懂行”的前提下写代码。

自动化“安检”

不要依赖人工 Review 去发现格式问题和低级错误。配置严格的 Linter（如 golangci-lint）、Formatter 和安全扫描工具，在代码进入人工视线之前，先由机器进行一轮清洗。

强化“正确性”护栏

针对 AI 在逻辑和错误处理上的弱点，强制要求：

• 重要逻辑必须有测试覆盖。
• 显式检查空值和类型。
• 标准化异常处理流程。

审查清单升级

Code Review 的重点需要转移。不要再纠结于语法细节，而要专门针对 AI 的弱点进行检查：

• 错误路径是否覆盖了？
• 并发原语是否正确使用？
• 配置项是否验证了？
• 有没有硬编码的凭证？

小结：质量不是自动的，它是设计出来的

这份报告给我们敲响了警钟：AI 不会自动带来高质量的代码。 相反，如果不加控制，它会以前所未有的速度制造技术债。

我们需要构建更强大的 CI/CD 流水线、更严格的自动化测试、以及更智能的 Code Review 流程，来承接 AI 带来的产能爆发。

只有当我们学会了如何像管理实习生一样管理 AI，我们才能真正享受到它带来的红利，而不是被它制造的 Bug 淹没。

如果你不想被“砒霜”毒害，就请先学会如何过滤“蜜糖”。

报告地址：https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

深度破局：用 Spec-Driven Development 扼杀 Bug 于摇篮

CodeRabbit 的报告虽然犀利地点出了问题，并建议“给 AI 提供上下文”，但它没有告诉我们具体该怎么做。

在实际工程中，仅仅靠零散的 Prompt 是无法约束 AI 狂野的想象力的。解决“质量砒霜”的终极解药，其实是彻底改变我们的开发范式——走向 SDD (Spec-Driven Development，规范驱动开发)。

与其让 AI 对着模糊的需求“猜”代码（然后我们去修 Bug），不如建立一套以规范为核心的流水线：先用 AI 辅助构建严谨的 Spec，在逻辑层面完成验证，再“驱动”AI 生成高质量代码。

这正是我的极客时间专栏《AI 原生开发工作流实战》的核心内容。

在这个专栏中，我将带你跳出“Prompt 调优”的低维竞争，掌握一套系统性的方法论：

• SDD 实战心法：如何实施“规范驱动开发”，把 80% 的逻辑错误拦截在写代码之前。
• 精准 Context 工程：如何构建结构化的上下文投喂机制，让 AI 真正“读懂”你的架构约束。
• 全链路重构：从需求分析到代码落地的全套 AI 协作 SOP。

不要只做 AI 的“质检员”，要做掌控 AI 的“架构师”。

扫描下方二维码，订阅《AI 原生开发工作流实战》，让我们一起重新定义 AI 时代的软件工程。

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/12/27/code-review-hell-in-ai-age

大家好，我是Tony Bai。

最近，在与几位架构师朋友的交流中，一个在 AI 编码时代下越来越普遍的“灵魂拷问”浮出水面。这不仅是一个问题，更是他们正在亲身经历的“代码审查地狱 (Code Review Hell)”。

想象一下这个场景：由 AI Agent 生成的代码正以前所未有的速度涌来，堆积如山；你花费心力给出的精辟修改意见，却被开发者转身当作新的 Prompt 重新喂给了 AI；片刻之后，一个全新的 PR 诞生了——它看起来解决了旧问题，却可能带着一堆你从未见过的新问题。你感觉自己深陷于“生成-审查-再生成”的无限循环中，身心俱疲。

这场危机并非危言耸听。在 Uber，每周有超过 65,000 个变更（相当于 PR）需要审查。当 AI 辅助编码成为常态，传统的 Code Review 流程已濒临崩溃。

但这究竟是末日，还是进化的前夜？答案是后者。这场危机，正催生一场深刻的变革——一方面，它要求架构师完成从“创作者”到“导演”的角色进化；另一方面，它也催生了像 Uber uReview 这样复杂的、系统化的 AI 审查平台。

本文将结合对当前危机的剖析与 Uber 的大规模工程实践，为各位小伙伴儿揭示这场变革的本质与破局之路。

危机的剖析：我们到底在审查什么？

要逃离地狱，必先理解地狱的构造。这场危机的根源，在于 AI 颠覆了代码的“创作”过程，从而动摇了 Code Review 的根基：

1. 思考过程“黑箱化”： 传统的 Code Review，我们审查的是代码，更是其背后开发者的思考路径。而 AI 的介入，将这个思考过程隐藏了起来。
2. 审查对象“降维”： 审查被迫从“这段设计是否优雅？”降维到了“这次 AI 输出是否碰巧正确？”。
3. 学习循环“断裂”： 开发者跳过了对 Review 意见最关键的“理解与吸收”环节，宝贵的经验传承被阻断。

天真地想用“AI 审查 AI”来解决问题，只会陷入更深的陷阱。正如 Uber 在其 uReview 项目初期所发现的，未经驯化的 LLM 会产生大量“幻觉”和“低价值的误报”，比如在非性能敏感的代码中挑剔性能问题。这些“噪音”会迅速侵蚀工程师对工具的信任，最终导致他们“调低音量并忽略它们”。

破局之路（上）：架构师的进化——从“创作者”到“代码导演”

面对危机，架构师和资深开发者的核心价值，必须从 Code Writer (代码创作者)，进化为 Code Director & Editor (代码导演与总编)。

“导演”不亲自扮演每个角色，但他定义了整部戏的基调、框架和最终质量。这份“代码导演”的实战手册，为我们指明了方向：

• 实践 1：审查“左移”，审查“剧本”而非“表演”
  在开发者大规模生成代码前，先审查其核心设计思路、任务分解和关键 Prompt。确保“剧本”是对的，再让 AI 这个高效的“演员”去表演。

• 实践 2：制定 AI 时代的 Code Review 新规

  • 明确标识 AI 代码，为审查者提供“警示”。
  • 强制开发者解释“为何接受”AI 方案，夺回思考的主动权。
  • 禁止“甩锅式再生成”，保护学习循环。

• 实践 3：定义“AI-Go”与“AI-No-Go”区域
  将 AI 的使用限制在单元测试、文档、模板代码等 AI-Go 区域，而在核心业务逻辑、安全代码等 AI-No-Go 区域保持高度警惕，让人类智慧主导。

破局之路（下）：Uber 的 uReview——“导演”的智能副驾

如果说“代码导演”模型描绘了架构师的“个人修炼心法”，那么 Uber 的 uReview 平台则展示了如何将这些理念，构建成一个大规模、系统化的工程解决方案。uReview 并非要取代人类，而是作为一个“智能副驾”或“第二审查员”，来增强人类的能力。

面对 AI 生成代码的洪水，Uber 没有让 uReview 直接进行审查，而是构建了一个精密的、多阶段的过滤管道，这与“导演”的思维方式不谋而合：

1. 预处理: 首先，系统会过滤掉配置文件、自动生成的代码等低价值目标，只聚焦于需要审查的核心代码。
2. 专业分工: uReview 并未使用单一的通用 AI，而是设计了多个“专家助理”：
   • Standard Assistant: 专注于逻辑缺陷、错误处理等 Bug。
   • Best Practices Assistant: 对照 Uber 内部的风格指南，检查代码是否符合规范。
   • AppSec Assistant: 专门寻找应用层的安全漏洞。
     这完美印证了“定义 AI-Go/No-Go 区域”的思想——让专业的 AI 干专业的事。
3. 严格品控: 这是 uReview 的核心，也是对“警惕 AI 幻觉”的最佳回应。它包含一个多层过滤过程：
   • 二次评估：另一个 AI（Review Grader）会对生成的每条评论进行打分，过滤掉低置信度的评论。
   • 语义去重：合并相似的建议。
   • 分类抑制：自动压制那些历史上被证明对开发者价值不大的评论类别。

Uber 的实践经验，为我们带来了几条宝贵的“场内教训”，这些教训与架构师的直觉高度一致：

• 精准比数量更重要: 充满噪音的建议会迅速摧毁信任。uReview 的核心策略就是“提供更少但更有用的评论”。
• 护栏与提示词同等重要: 优秀的系统架构和后处理流程，远比单纯的提示词工程更关键。
• 开发者讨厌文体说教: AI 提出的代码可读性、日志微调等建议，普遍不受欢迎。开发者更珍视对正确性、Bug 和最佳实践这种“高信噪比”的反馈。
• AI 善于抓虫，而非评估设计: 由于缺乏设计文档、业务背景等上下文，AI 无法评估系统设计的优劣。这再次强调了人类“导演”在宏观设计上不可替代的价值。

如今，uReview 在 Uber 内部取得了巨大成功：超过 75% 的 AI 评论被工程师标记为“有用”，每周节省约 1500 个工时，相当于每年近 39 个开发者年。

小结：拥抱人机协同的新未来

AI 带来的代码审查危机，实际上是一场深刻的产业升级。它迫使我们从对“代码”的微观审查，转向对“创作流程”的宏观把控。

“代码导演”模型为我们提供了战略指引，而 Uber 的 uReview 则展示了实现这一战略的工程蓝图。未来的 Code Review，不再是人与人的博弈，也不是人与 AI 的对抗，而是一种全新的“人机协同”模式：

架构师作为“导演”，定义设计、划定边界、把控最终质量；而像 uReview 这样的智能系统，则作为高效、精准、不知疲倦的“副驾驶”和“场务”，处理海量的细节检查，将人类从重复、繁琐的工作中解放出来。

最后，回到那个终极问题：谁来为质量负责？答案从未改变，也永远不会改变：永远是工程师自己。AI 是我们手中最强大的工具，但手握方向盘、对最终结果负责的，永远是我们自己。

资料链接：https://www.uber.com/blog/ureview/

聊聊你的“审查之痛”

AI 时代的 Code Review，正在成为每个技术团队的新挑战。在你所在的团队中，是否也遇到了 AI 代码带来的“审查地狱”？你们是如何应对的？ 是明令禁止，还是像 Uber 一样积极构建自动化防线？

欢迎在评论区分享你的真实经历和思考！ 让我们一起探索人机协同的最佳实践。

如果这篇文章对你有启发，别忘了点个【赞】和【在看】，并转发给你的架构师朋友，也许能帮他从“地狱”中解脱出来！

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.