本文永久链接 – https://tonybai.com/2026/06/15/google-ai-in-sre

大家好，我是Tony Bai。

整个软件工程界正在经历一场由生成式 AI 引发的“效率大爆炸”。

随着 GitHub Copilot、Claude Code、Codex 以及OpenClaw、Hermes等各类AI Agent 的普及，企业编写代码、构建功能并将其推向生产环境的速度，正在以 4 倍到 10 倍 的速度疯狂飙升。

然而，在这场高歌猛进的效率狂欢背后，软件工业最脆弱的防线——系统稳定性（SRE, Site Reliability Engineering），正在面临前所未有的毁灭性挑战。

传统由人类主导的 Code Review、基于静态监控指标的告警排查，在“机器以微秒级吞吐代码”的时代，已经彻底沦为杯水车薪。当代码提交量和部署频率暴涨 10 倍，意味着系统故障和未知黑盒技术债的涌入速度也暴涨了 10 倍。

为了应对这场“AI 带来的生产力过载危机”，谷歌 SRE 团队于近日发布了一份极具颠覆性的系统级白皮书：《AI in SRE: How Google is Engineering the Future of Reliable Operations》。

在这份白皮书中，谷歌首次向外界披露了其内部正在运转的、以 Agent 编排与闭环控制（Closed-loop Control）为核心的下一代自愈式运维系统。

今天，我们就来深度拆解这份代表着全球顶级运维水平的技术白皮书，看看谷歌是如何在 AI 时代，重新定义系统可靠性边界的。

为什么 AI 编码越快，运维死得越早？

谷歌 SRE 团队在白皮书的摘要中开门见山地指出：Site Reliability Engineering 正处于一场范式转移的阵痛中。

传统 SRE 的工作模式（SLO 定义、错误预算、消除琐碎工作）是建立在“人类编写代码的速度有限”这一物理前提下的。当 AI 充当了代码放大器，系统复杂度的膨胀速度已经远远超出了人类的阅读和心智承受极限。

谷歌提出了 AI 在运维系统中的 五个自治级别（SRE AI Autonomy Levels）：

在 L0 和 L1 阶段，人类还是绝对的“消防员”。但面对海量的机器代码，人类的响应时延（以分钟或小时计）在微秒级的故障蔓延面前毫无抵抗力。

谷歌认为，未来的 SRE 必须快速向 L3（高度自治）甚至 L4（完全自治）推进——即让 AI 智能体在无需人类确认的情况下，自主检测、诊断并安全地执行线上变更。

但问题是：谁来保证 AI 智能体本身不会“抽风”？ 一旦拥有自主执行权的 AI 智能体做出了错误的决策（例如在流量高峰期错误地清空了整个集群的负载），其造成的灾难（Blast Radius）将比人类操作失误大上千倍。

谷歌 SRE 的核武器：三大内部 AI 运维王牌组件

为了将 AI 安全地引入生产环境，谷歌在内部研发并上线了三套极具系统美学的底层 AI 平台。

1. IRM-Analyzer：将人类“救火轨迹”转化为黄金训练数据

AI 智能体要学会如何排障，首先需要向最优秀的人类 SRE 学习。但人类在排障时的行为是极其零散且非结构化的（躺在 Slack 聊天记录里、GVC 语音里、或者手动的命令行里）。

为此，谷歌开发了 IRM-Analyzer（事件分析平台）：

IRM-Analyzer 能够自动将零散的 Slack 聊天、日志报错、监控曲线，自动提炼并拼装成结构化、可复现的人类排障轨迹（Human Trajectory）。

IRM-Analyzer 利用大模型，能够将一场长达数小时、涉及数十人的混乱救火过程，自动解析、过滤、去噪并聚合成一条精确的时间线（Timeline），标明：什么时候观察到了 SLA 异常、什么时候执行了 canary 排水（Mitigation）、什么时候验证了服务恢复。

这条高纯度的时间线，成为了训练 AI Operator（智能体运维官）的 “黄金数据（Golden Data）”。

2. InvD（Investigation Dashboard）：一键生成的排障图谱

在发生线上故障时，人类 SRE 往往需要手忙脚乱地打开几十个 Grafana 仪表盘，手动过滤日志。

谷歌自研的 InvD（自动排障仪表盘，Investigation Dashboards） 彻底终结了这一状态。当收到告警时，InvD 会自动爬取相关的遥测数据，结合历史黄金数据进行推理，自动在网页上渲染出一张“自动故障拓扑图（Automated troubleshooting graph）”（如下图所示）。它能直接指出：这是由于某个新版本的二进制 Rollout 导致的 CPU 节流，并建议立即执行隔离。

数据表明，InvD 的上线，让谷歌受影响服务的平均缓解时间（MTTM）骤降了 44%！

3. Antigravity CLI：用 Go 编写的 AI 运维终端

我们在之前的文章中提到，Go 已经成为了 Google 内部智能体系统的通用语言。在 SRE 领域，这一趋势得到了最直接的印证：谷歌推出了基于 Go 开发的全新核心终端——Antigravity CLI。

通过集成标准的 MCP（Model Context Protocol）协议，Antigravity CLI 让 AI 智能体可以直接通过命令行与谷歌内部庞大的 Borg 系统、日志系统和 Bug 跟踪系统进行交互：

• 自动创建并分配故障单（Create/Assign Bugs）；
• 一键将事故复盘文档导出至 Google Docs；
• 执行底层的流量排干与扩容指令。

终极安全防线：决策与执行的“冷热解耦”

在白皮书中，谷歌提出了一个极其震撼且对所有企业都有借鉴意义的安全架构：“不要让做决策的 AI，直接去碰你的服务器。”

谷歌将这一安全哲学称为 The Safety Trifecta（安全三驾马车），并在底层通过 Actus（Actuation Agent，执行控制智能体） 实现了完美的“决策与执行解耦”：

1. 思考脑：AI Operator（决策智能体）

当系统报警时，AI Operator 会介入调查。在它的控制台（CoT, Chain of Thought）上，它会写下它的思考过程（例如：“检测到内存 OOM，怀疑是由于昨天部署的镜像导致的，建议将其副本数扩容 100% 以平摊压力”）。

2. 安全闸口：Actus（执行校验智能体）

AI Operator 拥有极高的智慧，但它在 Google 内部没有一丁点直接操作服务器的物理权限。

它提出的所有变更请求，必须提交给一个由确定性安全规则和零信任机制控制的物理控制平面——Actus。

• 强制 Dry-Run 支持：任何 AI 提出的 API 修改，Actus 会首先将其置于 dry_run=true 状态进行沙箱模拟，观察系统的报错。
• 智能体断路器（Agentic Circuit Breakers）：Actus 拥有最高级别的限流权限。如果发现某个 AI Agent 陷入了无限死循环、或者短时间内发起了超出 quota 的异常变更，断路器会瞬间切断其所有执行权限，并向人类 SRE 抛出报警。
• 零信任与最少特权：AI 智能体绝对不允许使用其开发者的个人凭证去登录服务器。它们拥有自己高度受控、双重强认证的 Agent Identities，且权限范围窄到极致（比如只允许在特定时间内调配流量，绝对不允许直接 ssh 运行原生 shell 脚本）。

这种将“会犯错的 AI 思考脑（LLM）”与“绝对遵守确定性安全规则的 Actus 控制面”进行冷热解耦的设计，是谷歌敢于将生产系统向 L3/L4 级别自治推进的终极底气。

范式革命：从“救火队员”到“安全架构师”的蜕变

当 AI 编排和 Actus 控制面接管了线上 90% 的基础告警和自动排水后，人类 SRE 应该去干什么？

谷歌给出的答案非常具有前瞻性：人类 SRE 正处于从“操作者（Operator）”向“安全架构师（Architect）”演进的关键节点。

过去，SRE 的价值体现在“手速”和“经验”上——谁能最快登录服务器找到那个坏死的配置，谁就是英雄。

现在，AI 的手速是人类的万倍。人类 SRE 的价值，转而体现在“定义安全边界和Actus策略（Defining Safeguards）”上：

• 设计高质量的 Evaluation Pipeline：设计更好的回归测试集，确保 AI 智能体在上线前不会退化。
• 架构高可用的渐进式发布（Progressive Rollouts）：针对 AI 10倍速的代码产出，设计更加敏感、能够自适应调整分流比例的“渐进式金丝雀发布”机制。

小结

大模型时代的到来，并没有像悲观主义者预言的那样带来软件工程的崩溃。相反，它正在强行将我们从枯燥、重复、高心智负担的“人肉运维”中解脱出来。

正如谷歌 SRE 团队在白皮书结尾所展现出的深邃洞察：

在机器以微秒级吞吐代码、部署服务的时代，人类工程师的价值，不再于手持水枪冲进火场，而在于设计出一套完美无瑕、能够自动防爆的自愈消防网。系统可靠性的终极边界，依然牢牢掌握在那些对生产环境心存敬畏、能够设计出严密安全闸口的系统架构师手中。

AI 负责疯狂奔跑，而我们，负责用优雅的系统工程，为它画出最安全的跑道。

资料链接：

• https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/
• https://cloud.google.com/blog/products/devops-sre/how-google-sre-is-using-agentic-ai-to-improve-operations

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/14/stop-saving-tokens-silicon-valley-consensus-waste-compute-shortcut

大家好，我是Tony Bai。

你是不是也曾在写 Prompt（提示词）时斤斤计较，为了省下那几元钱的 Token 而字斟句酌？你是不是也曾疯狂收藏各种“保姆级提示词教程”，试图摸索出调教大模型的“终极秘籍”？

快停下这种低效的行为吧。在真正的硅谷科技巨头和顶级创始人眼里，你这种抠抠搜搜的省钱方式，正在浪费你这辈子最昂贵的资源——时间。

在最新一期的硅谷教父 Naval and Nivi Podcast 闭门在线圆桌会议上，Naval 邀请了三位极其硬核的“前沿造物主”：

• Guillermo Rauch（Gumo）：前端圣经 Vercel 的创始人，正在致力于将 Vercel 打造为智能体时代的“AI 算力云”。
• Blake Scholl：Boom Supersonic 创始人，正在自己的工厂里手搓超音速客机和喷气式发动机。
• Max Hodak：脑机接口独角兽 Science 创始人（前 Neuralink 总裁），正在利用硅基芯片上培育活体神经元来恢复人类视力。

在这场几乎没有水分的对话中，大佬们抛出了一个在当今开发圈极具毁灭性、却又无比清醒的论点：

“别去学那些花里胡哨的提示词技巧了。扔掉预算表，直接用最粗暴的方式把 Claude、Gemini、Codex 砸向同一个问题。垃圾代码万岁，浪费 Token 才是大模型时代的唯一捷径。”

创作者的傲慢：大模型进化得比你快，别再研究“提示词技巧”了

现在的中英文互联网上，充斥着各种教你如何写“完美提示词”的收费课程。但在真正的硅谷巨头眼里，这些技巧无异于“刻舟求剑”。

“我完全无视了那些所谓的‘提示词技巧和框架’，”脑机接口巨头 Science 的创始人 Max Hodak 坦言。

“什么‘使用 Ralph Wigum 模式’、‘引入 OpenClaw’、‘配置这个脚手架’……我全都不管。我默认一个事实：大模型自身进化的速度，远远快于人类摸索提示词技巧的速度。它研究我怎么说话，绝对比我研究它怎么理解要快得多。”

Max 揭示了一个极其粗暴但无比爽快的底层策略：暴力破解（Brute Force）。

当他遇到一个复杂的系统工程问题时，他不会花三个小时去润色一条完美的 Prompt。他会选择直接写几句甚至带着语法错误的、大白话般的意图，然后同时塞给 Codex、Claude 和 Gemini。他不在乎 API 的账单，他只在乎谁先给出对的结果。

“词元（Token）再贵，也比人类的时间便宜。浪费词元，拯救时间，这就是全部的秘密。”

1000x 工程师的复活：软件开发已经变成了“造工厂”

在传统的研发团队中，说某个程序员是 “10x 程序员（十倍效能）”往往会引发极大的争议，因为它挑战了传统的“人人平等”观念。

但 Naval 指出，在数字和虚拟的世界里，人与人的差距从来就不是 10 倍，而是 100 倍、1000 倍甚至无限大。

“发明 JavaScript 的 Brendan Eich，写出 3D 引擎的 John Carmack，创立比特币的 Satoshi（中本聪）——这些都是 1000x 级别的神仙。”

而在 AI 编排引擎的加持下，这种“1000x 程序员”正在以一种全新的形态复活。

Vercel 创始人 Gumo 提出了一个颠覆性的论点：未来程序员的工作，不再是“交付具体的代码代码”，而是“建造生产代码的工厂”。

[传统工程师] ───> 编写 ───> [具体的业务代码 B] (低效，线性)

[1000x 工程师] ───> 建造 ───> [AI 软件工厂] ───> 自动化裂变 ───> [代码 B 到 Z] (指数级)

以前，衡量一个工程师的价值是：他写代码的速度有多快，交出的 Bug 有多低。

现在，衡量一个工程师的价值是：他能否构建起一个自动化、自省的 AI 开发流水线（The Software Factory），让这个工厂去自动产生从 B 到 Z 的无数代码。

在软件工厂（Software Factory）范式下，未来的开发不是写代码，而是设计生产代码的机器。平庸的、只会机械搬砖的程序员会迅速贬值；而那些具备高阶系统设计能力、超强架构直觉的 1000x 工程师，其生产力将被放大到令人颤抖的维度。

Vibe Coding（氛围编程）的本质：你其实一直都是个“氛围架构师”

近两年，硅谷流行起了一个新词——Vibe Coding（氛围编程）。很多人觉得这只是一个娱乐化的自媒体词汇，但 Naval 却一针见血地指出了它的物理本质：

“其实，一个优秀的研发总监或 CTO，在过去几十年的职业生涯里，一直都在进行‘Vibe Coding’。”

想想看，一个资深架构师或 CTO 每天在干嘛？他们并不亲自去写底层的每一行API/数据库调用。他们通过 飞书、Jira、设计文档，向团队传输他们的意志、设计哲学、业务直觉和品味（Taste & Judgment）。

他们给出边界和期望，然后让团队里的初级程序员们去补充细节、去踩坑、去实现。

“现在，人类只是把传递意志的对象，从‘初级程序员’换成了‘AI 智能体’。”

你把大方向和架构考量（比如：不要用 MongoDB，这里我们需要高强度的事务一致性，给我上 PostgreSQL）输入给 Agent，然后让它去疯狂搬砖。这正是最纯粹、最硬核的“氛围编程”。

AI 让所有具备“系统大局观”的人类，在瞬间拥有了数十个不知疲倦、随时待命的虚拟技术团队。

软件已死，积木永生？AI 时代真正的“护城河”在哪里？

如果代码生成已经变得如此廉价，那未来软件公司的“护城河（Moat）”到底在哪里？如果 AI 能够一键生成任何软件，那我们还需要构建底层的软件工程吗？

Gumo 和 Naval 探讨了 Mitchell Hashimoto 提出的 “积木经济（Building Block Economy）” 概念。

“我们绝对不能指望 AI 每次面临一个新任务时，都从第一性原理出发去重新发明一遍轮子。”

如果你的 AI Agent 需要发送一封邮件，它不应该去自己从底层协议重构一个邮件收发系统；它应该去调用已经存在的、在人类社会中经过千万次锤炼的安全积木——比如成熟的 Queue 系统、PostgreSQL 数据库。

大模型最核心的资产不是去搞无意义的“重复创造”，而是重用人类文明已经沉淀好的、高鲁棒性的“技术积木”。

因此，在 AI 时代，真正的壁垒将分化为两个极端：

1. 物理底座与前沿硬核（The Hard Tech）：比如 Max Hodak 正在做的脑机接口、Blake Scholl 正在造的超音速飞机。这些需要肉身与物理实体发生碰撞的领域，是 AI 无法轻松虚拟化的。
2. 极致、干净的高性能底层积木（High-quality Building Blocks）：那些被千万个 AI Agent 每天高频调用、绝对可靠、超高性能的底层中间件与运行时（比如 Redis、Vercel Serverless、甚至是 Go 的底层运行时）。

小结：一场纯粹创造力的解放

在这场硬核的围炉对话中，大佬们用最前沿的视角，为我们描绘了一个充满希望的未来。

Max 提到，他自己已经有 20 年不写代码了。但由于 AI 工具的爆发，他重新找回了年少时在电脑前废寝忘食、疯狂创造的快乐。在过去几个月里，他完全通过 Agent，为自己构建了数个每天都在高频使用的完整软件系统：

“在过去，你写代码时总会卡在某个愚蠢的依赖配置或编译报错里，一卡就是好几天，极其挫伤积极性。而现在，有了 Agent，你永远不会再卡住了（You just don’t get stuck anymore）。”

这是一场属于人类创造力的伟大解放。

当我们不再需要把生命浪费在无休止的“底层配置对齐”和“样板代码套娃”中，当我们学会大把大把地“浪费”廉价的 Token 去换取珍贵的时间，我们才真正夺回了作为“建造者（Builders）”的尊严。

我们不再是手持泥铲、在工地上砌砖的泥瓦匠；我们是坐在直升机上、挥洒着无尽算力、俯瞰整个数字新城拔地而起的巨擘。

资料链接：https://www.youtube.com/watch?v=aiyf-5jmYf0

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

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

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

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/13/linux-maintainer-greg-kh-switched-to-rust-after-35-years-of-c

大家好，我是Tony Bai。

在开源软件的宏大版图中，Linux 内核无疑是那座最古老、最庞大、也最不容有失的钢铁巨塔。它由数千万行 C 语言代码铸就，运行在世界上每一个数据中心、每一台智能手机，乃至公司的投影仪和麦克风里。

在这个由 C 语言统治了三十多年的“神圣领域”，任何关于引入新语言的提议，都曾被视为不可理喻的异端。

然而，巨变正在悄然发生。

在最新一期的 Rust in Production 播客中，两位行业殿堂级人物坐在一起，进行了一场载入 Linux 史册的对话，揭示了 Linux 内核史上最伟大的语言融合：

• Greg Kroah-Hartman：Linux 内核核心维护者，掌管着驱动核心（Driver Core）、USB、TTY 以及所有稳定版本（Stable Kernels）的发布，写了 35 年 C 语言的绝对骨灰级老炮。
• Alice Ryhl：Google Android Rust 团队成员，高并发异步运行时 Tokio 的维护者，将 Rust 引入 Linux 内核的主力军。

在这场深度对话中，Greg 坦言自己曾是一个坚定的“Rust 怀疑论者”，但现在，他不仅公开宣布 “Linux 引入 Rust 的实验已经结束，它已经是正式项目”，更说出了一句让无数技术人动容的话：

“Rust 让我觉得，写程序重新变得有趣了。”

为什么一个掌控着世界底层算力命脉的 C 语言守护神，会被 Rust 彻底征服？在 Linux 这个极致复杂的系统级工程里，Rust 究竟带来了怎样的化学反应？

信任的重构：代码可以出错，但我们必须信任你

在 Linux 内核这样不容许任何安全妥协的底层项目中，引入一门新语言，最大的挑战是什么？

Alice 和 Greg 给出了同一个反直觉的答案：最大的挑战不是技术，而是社会学（Social Challenge）。

“内核的运转，本质上是基于对‘人’的信任。”Greg 解释道。

在 Linux 社区，每天都有几千名开发者提交补丁。资深维护者们并不指望任何人写出完美无缺的代码，因为“我们都会犯错”。

“我们信任你，不是信任你的代码不会出错；而是信任当代码出错、系统崩溃时，你会守在电脑前把它修好。”

在过去的二十年里，有很多系统编程语言（比如 C++）曾试图叩开 Linux 内核的大门，但它们的倡导者写完代码就走了，没有人愿意留下来承担那份沉重、枯燥的长期维护责任。

而 Rust 社区的先驱们用了整整 8 年时间，在内核树外（Out of tree）默默编写驱动、完善基础设施，用实际行动向 Greg 这样的内核守门人证明：“我们不仅能写出安全的代码，而且我们做好了准备，会留在这里和你们一起修 Bug。”

正是这种长期主义的务实精神，建立起了难能可贵的信任（Trust）。

奇妙的化学反应：Rust 的到来，竟然让原有的 C 代码变好了！

当 Rust 真正开始深入内核的毛细血管时，发生了一个极其奇妙、甚至带有一丝讽刺意味的现象：即使你完全不碰 Rust 代码，原本的 C 语言代码也因为 Rust 的到来而变得更好了。

Alice 分享了她们在编写绑定（Bindings）时的技术细节。在 C 语言中，一个指针的定义往往是极其模糊的：

// C 语言中的经典指针返回
struct device *get_device_info(void);

这个指针返回后，调用者需要面对一系列拷问：

• 这个指针代表的是“所有权（Ownership）”的转移，还是仅仅是一次“借用（Borrow）”？
• 它指向的内存在生命周期结束时，是由我来释放，还是由系统释放？
• 它是可变的（Mutable）还是只读的？

在 C 语言的签名里，这些信息全部是缺失的，只能靠开发者查阅文档、或者在脑海里默默推理。

但当 Alice 试图为这段 C 代码编写 Rust 包装器（Wrapper）时，由于 Rust 编译器的强制要求，她们必须在 Rust 签名中明确定义：它是 Arc，是 Box，还是一个简单的引用（Reference）？

为了让 Rust 编译器满意，Rust 团队不得不去倒逼 C 语言维护者厘清这些指针的语义。

“在很多地方，写 Rust 绑定的开发者需要写几百行复杂的代码，就为了兼容某个极其难用的 C 语言接口。”Greg 笑着回忆道，“我看到后说：‘其实我们可以直接修改 C 语言代码，让它变得更简单。’ 那些写 Rust 的人惊呼：‘噢，原来还可以这样！’”

“即便 Rust 在今天突然消失，Linux 的 C 语言代码库也因为 Rust 曾经来过，而变得比以前安全、清晰、健壮得多。” 这是 Greg 给出的极高评价。这种跨语言的协同审视，正在洗礼整个 Linux 内核的工程素养。

纠正偏见：为什么写“驱动”比写“内核核心”难得多？

在很多开发者的刻板印象中，写底层的内核核心（如调度器、内存分配器）是最难的，而写外围的“驱动（Drivers）”是最简单的。

Greg 站出来彻底纠正了这个偏见：“在内核中，写驱动才是最难的。因为驱动虽然看起来是树叶，但它在疯狂地消费整棵树干的养分。”

Alice 在为 Android 编写 Rust 驱动时，深刻体会到了这一点。一个驱动为了运转，必须去调用内存分配（Alloc）、调用 I/O 模块、调用网络包分析、调用文件系统。这意味着，你要写一个 Rust 驱动，你就必须先把这所有涉及到的 C 语言核心模块，全部写出对应的 Rust 绑定。

1. 为什么不能用标准的 Rust 内存分配器？

很多人问，为什么不能直接用 Rust 标准库里的 alloc？

因为 Linux 内核的内存分配（malloc）绝非易事。它不是简单的“要一块内存”，而是充满了极其细微的上下文提示（Gfp flags）：

• “在中断上下文中，不能睡眠，请立刻给我内存”；
• “不要去触发 I/O 写入，直接从那个特定的 NUMA 节点上拿内存”；
• “从这个特定的内存池（Memory Bucket）里分一块给我”。

为了满足这些变态的底层硬件级要求，Rust 用户态标准库那一套内存分配器根本无法工作。Rust for Linux 团队不得不完全剥离了 std，甚至重写了适用于内核特性的定制版 alloc 库。

2. 极致的极客工具：Klint 与编译期“禁眠”检查

为了解决这些极其精细的内核场景，内核团队甚至编写了专属的编译器插件——Klint（Kernel Lint）。

在内核开发中，有一个铁律：在持有某些特定锁或处于中断上下文时，绝对不允许发生系统休眠（Sleep）。如果 C 程序员犯了这个错，系统往往会直接卡死、甚至死机，极难调试。

而 Klint 作为一个 Rust 编译器插件，能够利用编译期的类型系统，在编译时直接扫描整个代码路径，一旦发现你在不允许睡眠的上下文中调用了任何可能触发睡眠（Sleep）的函数，直接报编译错误！

这种在编译期就把低级内存与调度错误彻底掐灭的能力，是传统的 C 语言静态分析工具（如 Coccinelle）在不破坏代码可读性的前提下，永远无法企及的高度。

释怀：35 年 C 老炮被 Rust 治愈的瞬间

当主持人问及，C 程序员能从 Rust 身上学到什么时，Greg 的回答没有滔滔不绝的说教，反而充满了真诚与坦然。

“过去，当我写 C 语言时，如果要在两个模块间传递一个指针，我必须在脑海里进行高强度的思想斗争：这个指针是谁在持有？生命周期对不对？我有没有在别处释放它？”

“当我接触到 Rust 之后，我发现，Rust 帮我把这些繁琐、痛苦、容易出错的 meta-stuff（元认知开销）全部承担了。”

“编译器编译通过了，逻辑看起来也是对的。好了，我现在可以百分之百地把精力放在我的业务逻辑本身，而不需要去担心那些低级的内存越界和空指针问题。”

“写了 35 年的 C，Rust 让我重新觉得，编程是一件纯粹且快乐的事情。”

这或许是一个程序员，对一门新编程语言所能表达的最高敬意。

小结

在对话的最后，现场响起了经久不息的掌声。

Linux 的伟大，不在于它用了 30 多年的 C 语言，而在于它拥有一个极其开放、务实且充满活力的工程文化。当有更好的工具出现时，这些掌控着世界算力命脉的守护者们，没有抱残守缺，而是选择张开双臂，去拥抱改变。

从 Python 狂飙的 AI Agent 调度层，到 Go 统治的云原生 Agent编排底座，再到 Rust 正在接管的 Linux 内核最深处——无论上层的应用和模型如何演进，底层的系统工程（Systems Engineering）依然需要人类最顶尖的逻辑、同理心与工匠精神去雕琢。

我们有幸见证这场跨越语言与时代的融合，更有幸与这些伟大的建设者们同行。

资料链接：

• https://corrode.dev/podcast/s06e04-rust4linux/
• https://www.youtube.com/watch?v=HM-JM4DoYD4

今日开放讨论：

Greg 提到“Rust 绑定的过程，反过来倒逼并简化了 C 语言的原生接口”。在你的项目或日常重构中，是否也曾因为引入了更严苛的约束（如类型系统或静态检查），反而帮助你理清了原本混乱的业务逻辑？

欢迎在评论区分享你的跨语言协作与架构重构故事，我们一起聊聊代码的纯粹之美！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/12/zig-father-refuses-funding-bans-ai-why-no-1-0-in-a-decade

大家好，我是Tony Bai。

在技术圈，有一门名为 Zig 的系统级编程语言，它没有铺天盖地的营销，没有背后财大气粗的金主干爹，甚至它的代码仓库在 2025 年末从 GitHub 直接“硬核跑路”到了 Codeberg。

然而，在 JetBrains 发布的“最受敬仰编程语言”榜单中，它赫然位列 Top 5；Uber 用它的编译器解决 Go 的交叉编译难题；大热的 JavaScript 运行时 Bun 用它作为底层的胶水语言（注：近期Bun已经从Zig迁移为Rust实现）；金融级数据库 TigerBeetle 更是基于它实现了比传统方案快上千倍的性能。

为什么在拥有了 C++、Rust 和 Go 之后，世界依然需要 Zig？

最近，JetBrains 团队对 Zig 之父 Andrew Kelley 进行了一次深度专访。在长达一个多小时的访谈中，Andrew 展现出了极度“反主流”的极客态度：坚决抵制 AI 生成的代码（No-AI Policy）、宁可拿 67 万美元的非营利基金也不要上亿美元的投资、10 年不发布 1.0 版本。

今天，我们就来深度扒一扒，这位被称为“最硬核系统语言创造者”背后的狂人哲学。

缘起：“我能比 C++ 做得更好，我也能比 Rust 做得更好”

故事要从一个开发“数字音频工作站（DAW）”的失败尝试说起。

在 2015 年之前，Andrew 试图用各种现有的语言去开发一个专业的 DAW 软件。

• JavaScript？ “太高层了，根本接触不到计算机底层能力来做低延迟处理。”
• Go？ “和 C 库的交互极其痛苦（CGo），而且垃圾回收（GC）在实时音频处理中是致命的。哪怕卡顿一毫秒，在现场演出中都是灾难。”
• Rust（1.0 之前）？ “我为了让字体渲染工作花了一个月，被 Borrow Checker（借用检查器）折磨得生不如死。稍微改动一点代码，就会引发一连串的编译错误，让我彻底卡壳。”
• C++？ “刚开始感觉很高效，但很快，一个小拼写错误就导致了内存损坏（Memory Corruption），花了我几个星期去 Debug。这太慢了！”

即使退回到只用极简 C++（搭配 C 链接器），他依然在不断地“搬起石头砸自己的脚”。

那一刻，年轻的 Andrew 迸发出了极大的傲慢与决心：“我可以做得更好！我可以比 C++ 做得更好，比 Rust 做得更好，比 Go 做得更好！”

于是，Zig 诞生了。

为什么世界还需要 Zig？它凭什么挑战 C 和 Rust？

很多人会问：C 语言统治了底层 50 年，Rust 现在红得发紫，Zig 凭什么挤上牌桌？

Andrew 给出了一个极其精准的定位：“在 Zig 中，你不需要像在 Rust 中那样为了迎合编译器的‘类型理论’而去扭曲你的代码结构；在 Zig 中，你思考的是‘我希望 CPU 做什么’，然后你写出让它这么做的代码。”

1. 为什么它是更好的 C？

“想要替代 C，你不能放弃任何 C 拥有的能力。”Andrew 说道。

Go 放弃了底层的绝对控制权换取了并发的便利，所以 Go 永远无法替代 C 写操作系统内核。

但 Zig 做到了。在 Zig 中，一切都可以像 C 一样高效，但消除了 C 语言海量的“坑（Footguns）”。甚至在细节上，Zig 比 C 更像 C：C 语言只有溢出（Wraparound）的无符号整数，而 Zig 允许你精细控制整数的溢出行为和符号约束。

2. 为什么它不同于 Rust？

Rust 的核心是其宏大的类型系统和基于生命周期/借用的内存管理模型（类似 RAII）。

而 Zig 走的是“显式分配器（Explicit Allocators）”的路线。

在 Zig 中，没有隐式的内存分配，开发者经常针对特定应用使用 Arena Allocator（一次性分配，一次性销毁），以获得极低的延迟和极高的吞吐量。TigerBeetle 数据库就是利用这一点，在启动时预先分配好所有内存，此后运行时零动态分配（Zero Dynamic Allocation），从而实现了恐怖的高频交易性能。

3. 杀手锏：全宇宙最强的 Toolchain

如果你问一个开发者，在 C/C++ 项目里最痛苦的是什么？99% 的人会回答：配置构建环境（CMake、Makefile、装依赖）。

Zig 的杀手锏在于它的工具链：它没有任何外部依赖。 无论你在什么操作系统上，想要编译一个项目，永远只需要一句 zig build。不仅如此，Zig 甚至可以作为一个超级强大的 C/C++ 交叉编译器。Uber 就是用 zig cc 来解决 Go 语言中混合 C 代码在 ARM 架构上的交叉编译难题的。

“AI 代码全是垃圾”：为什么 Zig 坚决封杀 LLM 提交？

在这个“万物皆可 AI 编程（Vibe Coding）”的狂热时代，Andrew 和 Zig 社区制定了一项极其强硬的规则：严禁任何由大模型（LLM/AI）生成的 Issue 和 Pull Request。

为什么这么刚？Andrew 的回答充满了工程师的辛辣与无奈：

“因为那些贡献无一例外，全是垃圾（Invariably garbage）。”

Zig 的核心团队只有 5 个人，却要面对海量的社区贡献。开源项目接受 PR 的核心目的不仅仅是为了拿代码，更是为了“导师制（Mentorship）”——通过 Review 代码，培养出下一代的核心维护者。

但在 Andrew 看来，那些用 AI 批量生成代码然后扔过来的贡献者，不仅没有任何价值，还在疯狂消耗核心团队极其宝贵的 Review 时间。

“这就像是‘贡献者扑克（Contributor Poker）’。用 AI 的人永远只是路过，他们学不到任何东西，也永远不可能成为核心团队的一员。更可笑的是，他们往往只是把报错信息贴回 ChatGPT，然后假装自己修复了问题。这纯粹是在浪费所有人的时间。”

面对满天飞的“AI 编程神器”，Andrew 有着自己极其古典的软件信仰：

“我想要软件拥有‘绝不妥协的完美（Uncompromising perfection）’。我不想看到一个软件仅仅是因为‘出乎意料地没有 Bug’而沾沾自喜，那是一个糟糕透顶的质量标准。”

$670K 的独立基金与 $100M 的诱惑：为什么拒绝做大？

在科技圈，一个流行的开源项目很快就会被大厂收编，或者拿到顶级 VC 的上亿美元融资，然后迅速扩张。

但 Zig Software Foundation (ZSF) 走了一条截然不同的路。它是一个注册在美国的 501(c)(3) 非营利组织。2024 年，整个基金会的总收入只有区区 67 万美元（约合人民币 480 万）。

在这 67 万美元中，Andrew 为自己定下了 15.4 万美元的年薪（相当于纽约一个普通的资深程序员薪水），而剩下的资金的9成以上，全部用来支付另外几位兼职和全职的外包核心开发者。

当主持人犀利地问道：“如果一家大公司给你 1 亿美元的无条件赞助，你会要吗？”

Andrew 的回答展现出了极度的清醒：

“我会拿，但我会把它存进银行，确保我们未来 100 年都不需要再到处筹款。但我绝不会用这笔钱去扩张。我不想管理 100 个人的团队。”

他的逻辑极其自洽：保持一个极度精简、高效的微型组织，能够最大程度地抵御资本的腐蚀（Oxidation）。

“我们不是初创公司，我们没有投资人在背后催着我们变现。如果我们拿了大厂的钱，他们就会有控制权；现在，我们靠着多元化的小额赞助和少数企业的资助活着。如果哪天某个赞助商说‘你必须按我说的做’，我们可以硬气地回答：‘对不起，如果你撤资，我们依然能活下去。’”

这就是他宁可手写报税单，也要死守非营利基金的底层原因——他要为 Zig 争取“对世界说‘不’”的自由。

硬核的代价：离开 GitHub，以及那遥遥无期的 1.0

为了这份独立和自由，Andrew 付出了很多代价。

2022 年，他退出了 Reddit 和 Twitter。2025 年底，当发现 GitHub 的持续集成（CI）服务器对 Zig 极度不稳定时，他更是做出了一个惊世骇俗的决定：将 Zig 的主仓库从 GitHub 彻底搬迁到了一家德国非营利组织运营的平台 Codeberg。

这意味着他主动放弃了 GitHub 带来的巨大流量和打赏（Sponsors）收入。但他毫不在意：“我们是来写软件的。如果 CI 跑不通，我们就换一个能跑通的。Codeberg 是非营利组织，比那些为了下一个财报季奔波的创业公司靠谱多了。”

那么，被粉丝催了 10 年的 Zig 1.0 究竟什么时候出？

Andrew 坦言，1.0 本质上是一个“向后兼容的承诺”。像 Go 这种语言，1.0 之后很久没动过语法；而 Rust 虽早早发布 1.0，却靠着 Editions（版次）机制继续大改特改。

“我们不需要为了迎合风投的胃口，或者为了所谓的‘商业落地指标’去急匆匆地发布 1.0。当 Zig 1.0 发布的那一天，它必须是一份‘毫不妥协的热爱之作’。我们不需要为任何仓促的糟糕决定买单。”

不过，Andrew 也在采访中透露了一个彩蛋：他将全力冲刺即将到来的 0.16 版本 (注：截至发稿时，Zig官网已经发布了0.16.0版本)。在这个版本中，完全摆脱对 LLVM 依赖的自研 x86 后端将迎来爆发——百万级代码库的增量编译将低至恐怖的 50 毫秒！

小结：程序员的乌托邦

在访谈的最后，当被问及“未来 20 年人类还会写代码吗”，Andrew 的眼中闪烁着光芒：

“人们永远不会停止写代码，因为写代码真的太好玩了。”

在他看来，当今世界最好的软件，往往是开发者们在业余时间出于热爱而写的。而那些为了商业目的强加给用户的软件，总是充满了广告、诱导和恶意的参与度指标。

Zig 不仅仅是一门编程语言，它是 Andrew Kelley 献给世界的一份“无条件的礼物”。它在向所有热爱底层、渴望掌控计算机的极客们宣告：

在这个被大厂垄断、被 AI 噪音填满的世界里，我们依然可以凭借几百 K 的预算、五六个人的小团队，用对技术的极致纯粹，造出一把劈开混沌的利剑。

如果你也曾在这个庞大的系统工程世界里感到过疲惫与迷茫，不妨去试一试 Zig 吧。那是一片没有资本催促、没有 AI 噪音的，属于纯粹程序员的乌托邦。

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

✍️ 今日开放讨论

在这个几乎所有人都疯狂拥抱 AI 编程（Claude Code/ Codex /Antigravity Cli等）的时代，Zig 官方明确拒绝 AI 生成的 PR。你认为是 Andrew Kelley 过于“迂腐”，还是他在守护开源软件最核心的“导师制与高质量传承”？

欢迎在评论区留言，分享你对“AI 垃圾代码”以及系统编程语言发展趋势的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/11/writing-idiomatic-go-make-you-better

大家好，我是Tony Bai。

在技术圈里，Go 语言（Golang）一直扮演着一个特立独行、甚至有些“格格不入”的角色。

如果你去问一个写 Java、Python、TypeScript 或是 C++ 的程序员对 Go 的第一印象，得到的回答大概率是：“无聊”、“简陋”，以及无处不在的 “冗余样板代码（if err != nil）”。它没有优雅的异常捕获机制，早期坚决不引入泛型，更把面向对象最核心的“类继承”给无情斩断了。

然而，在技术社区 Reddit 的 r/golang 板块中，一个极其深刻的问题引发了全网热议：“写地道的 Go 语言（Idiomatic Go），是否让你成为了一个更好的整体开发者？”

令人惊讶的是，那些在业界摸爬滚打多年的大厂架构师、技术主管和多语言老兵们，几乎给出了高度一致的肯定回答。

Go，这门刻意在语法上“自我阉割”、拒绝一切魔法和花哨抽象的语言，究竟是如何反向输出、重新格式化一个程序员的底层智力结构的？在这篇文章中，我们就一起来盘点一下。

显式错误处理：从“假装看不见异常”到“直面毁灭的工程意识”

每个刚开始写 Go 的开发者，最难以忍受的就是地道 Go 语法里近乎强迫症的错误处理：

val, err := DoSomething()
if err != nil {
    return fmt.Errorf("failed to do: %w", err)
}

很多人抱怨：“为什么我非得在每一行可能出错的代码下面，写这三行废话？”

但在 Reddit 的高赞回复中，一个资深开发者从系统设计的层面一针见血地指出了真相：“基于异常（Exception-based）的语言，给我们制造了一种‘异常被完美控制’的幻觉。这其实是极不负责任的。”

在 Java 或 Python 中，当你调用一个可能失败的函数时，你的业务控制流是隐式的。你抛出一个异常，寄希望于上层某个魔妙的 try-catch 块能抓住它。

但实际情况往往是：开发者为了代码的“清爽”，假装看不见潜在的失败，直到生产环境爆出未捕获的运行时异常（Runtime Exception），导致系统崩溃。

而地道的 Go 语言通过返回 (Value, error) 的双元组，逼迫你和错误进行面对面的正面刚：

• 在每一个可能失败的节点，你都必须立刻、就地做出决定：是包装错误返回？是降级重试？还是优雅地熔断？
• 你开始把“失败（Failure）”视为系统运行的常规状态，而不是需要恐慌的意外。

许多开发者表示，在适应了 Go 的显式错误处理后，他们回去写 Python 或 TypeScript 时，再也不敢盲目依赖全局异常捕捉了。他们会主动用元组（Tuple）或类似 Result 的结构，在调用点显式解包。这种对错误的敬畏和就地处理的工程意识，是成为高级后端架构师的第一步。

拒绝抽象过载：Go 的“传染性极简”如何治好你的架构妄想症？

很多程序员在拥有了 3 到 5 年的开发经验后，极易患上一种名为“过度设计（Over-engineering）”的职业病：一看到业务需求，本能地就想套用几十种设计模式、建十几层继承树、引入各种高级的元编程和装饰器魔术。

而 Go，是这种“架构妄想症”的特效解毒药。

一位Reddit 用户分享了他的经历。在写了一段时期的 Go 之后，他回过头去写 Python：

“天啊，我突然发现有 5 种完全不同的方法去遍历和操作一个数组。我开始陷入无谓的选择困难和审美疲劳。我突然开始怀念 Go 那种‘只有一种最笨、最直接的写法’的无聊感。”

Go 语言在设计之初，就故意将语言特性压缩到了极致。它没有隐藏的控制流，没有神奇的操作符重载，没有复杂的类继承。

这种“无聊”逼迫你放弃在代码形式上炫技，转向思考最本质的问题：

• 这个逻辑能让一个新来的实习生在 30 秒内看懂吗？
• 这个复杂度真的有必要存在吗？
• 我的数据流向清晰吗？

写好地道的 Go 要求你学会“自我克制”。当你学会在编译器的安全网中，用最平铺直叙的代码去平复系统的复杂性时，你才真正跨过了从“写代码的泥瓦匠”到“管理复杂度的工程师”的门槛。

隐式接口与组合：告别深层继承树，解锁真正的松耦合

面向对象（OOP）的“多重继承”和“深层父子类”是无数中大型项目腐烂的温床。当你修改了一个顶层父类的方法时，你根本无法预知下面几十个子类会发生怎样灾难性的崩塌。

Go，彻底斩断了这条锁链。它创造性地采用了隐式接口（Structural Subtyping/鸭子类型）。

Go 社区有一句广为人知的黄金法则：“Accept interface, return struct.”（接受接口，返回结构体）。

这一原则在 Reddit 社区中被无数开发者奉为圭臬：

• 输入端轻量级解耦（Accept interface）：我的函数不关心你是什么“类”，我只关心你能不能干“读数据（Read）”这件事。
• 输出端具体、干净（Return struct）：我产生的是最具体、最实在的数据，把如何使用它的自由交还给调用者。

这种设计迫使你放弃设计复杂的“分类学（Taxonomy）”层级，转而像拼装乐高积木一样，用 “组合（Composition）” 的思路去重组系统。

在 Go 中，数据（Struct）和行为（Methods）是彻底分离的。没有 giant Class 树，只有扁平的、通过隐式接口拼装在一起的松耦合组件（Ports & Adapters）。这种“六边形架构”思维一旦融入你的脑海，你再去写任何其他语言，都会自然而然地写出极度清爽、极易重构的代码。

系统工程思维的蜕变：为什么“写最无聊的代码”是最高级的职业素养？

在 Reddit 讨论中，最让人产生共鸣的一句话是：

“Idiomatic Go was intentionally designed to make code easy to read for the next developer, not easy to write for the current one.”（地道的 Go，其设计的首要目标是让代码便于下一个开发者阅读，而不是为了让当前的开发者写得爽。）

很多年轻程序员总觉得“越精妙、越难懂、别人都看不懂的代码”才代表高水平。但当你真正经历过生产环境的毒打，半夜三点被报警电话叫醒去 debug 一个无人能懂的“聪明代码”时，你才会明白：可预测性（Predictability）和可读性（Readability）才是衡量一个程序员职业素养的终极指标。

Go 语言通过它的各种限制，强行把大家的代码拉到了同一个频道上。

它逼迫你交出在代码里展示智力优越感的方向盘，让你学会在业务逻辑的深度、数据的流向和工程的健壮性上去寻找真正的技术挑战。这种在软件工程层面的“祛魅”与成熟，正是地道的 Go 给予我们最珍贵的礼物。

小结

回到最初的问题：写地道的 Go 语言，是否能让你成为了一个更好的开发者？

答案是毫无疑问的。

Go 语言就像是一套高标准的“驾驶训练模拟器”。它通过在内存安全、并发模型、依赖管理和错误处理上的硬性规则，逼迫你戒掉所有在其他高级语言中惯出来的“坏毛病”。

它强迫你直面系统失败，强迫你用组合去代替继承，强迫你把简单和可维护性放在首位。

当你完成了这场认知洗礼，重新格式化了自己的大脑之后，你会发现，即便有一天你离开了 Go 去写 C++、Java 或 Python，你写出来的代码也变得比以前更干净、更清晰、更易重构。因为你已经学会了像一个真正的软件工程师一样去思考问题。

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

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/10/lets-encrypt-adopts-mtcs-preparing-for-post-quantum-security

大家好，我是Tony Bai。

当你在浏览器地址栏看到那把绿色的小锁，或是敲下 https:// 时，你正在被人类历史上最伟大的密码学基础设施——Web PKI（公钥基础设施）保护着。

长久以来，这套系统的基石是 RSA 和 ECDSA 签名算法。它们精巧、高效，扛住了互联网过去几十年的爆炸式增长。然而，一场风暴正在逼近。

随着量子计算机的发展，悬在所有密码学家头顶的“达摩克利斯之剑”——CRQC（密码学相关的量子计算机），其倒计时正在被各大科技巨头疯狂拨快。

近日，全球最大的免费 HTTPS 证书颁发机构 Let’s Encrypt 发布了一篇声明：《Let’s Encrypt 的后量子未来》。在这份声明中，Let’s Encrypt 不仅拉响了后量子时代的警报，更抛出了一个足以重塑整个互联网底层通信逻辑的终极杀手锏：MTCs（Merkle Tree Certificates，默克尔树证书）。

为什么传统的 RSA 和 ECDSA 会被淘汰？为什么直接换上标准的后量子算法会导致整个互联网“网速倒退”？今天，我们就来深度硬核拆解 Let’s Encrypt 这场惊心动魄的“后量子求生战”。

倒计时缩短：为什么认证（Authentication）的危机突然爆发了？

在讨论后量子密码学（Post-Quantum Cryptography, PQC）时，我们通常要区分两个概念：加密（Encryption / 密钥交换）和认证（Authentication / 签名）。

过去几年，业界对后量子“加密”极为焦虑。原因很简单：“现在收集，以后解密（Harvest now, decrypt later）”。攻击者现在就可以把你加密的流量存进硬盘，等 10 年后量子计算机成熟了，再拿出来暴力破解。因此，像 Google、Cloudflare 这样的巨头早已在各大浏览器和服务器中部署了混合后量子密钥交换算法（如 X25519MLKEM768）。

相比之下，“认证”似乎没那么紧迫。

因为证书签名的作用是证明“我是我”。要伪造一个服务器身份，量子计算机必须在 TLS 握手的几百毫秒内实时（in real time）伪造出一个签名，而不能“事后追溯”。因此，大家都觉得，只要 CRQC 还没造出来，签名就是安全的。

但这种安全感正在被撕裂。

1. 政策强制清退：美国国家安全局（NSA）的 CNSA 2.0 套件明确规定，必须在 2035 年之后全面禁用 RSA-2048 和 P-256。欧盟也出台了类似的路线图。由于各种底层依赖库、根证书的更替周期极长，生态系统实际上已经被逼到了悬崖边。
2. 巨头的极限施压：2026 年初，Google 震撼宣布，将在 2029 年之前全面迁移其服务；紧接着 Cloudflare 也做出了同样激进的承诺。Go 语言（1.27 版本）甚至直接将 NIST 标准化的后量子签名算法 ML-DSA 塞进了标准库。

警报拉响了，留给 Web PKI 生态转身的时间，已经从“未来某天”缩短到了“迫在眉睫”。

灾难推演：为什么直接换算法，会让互联网网速倒退？

面对量子威胁，最直接的思路就是：既然 RSA 和 ECDSA 不顶用了，咱们直接把它们替换成 NIST（美国国家标准与技术研究院）最新发布的后量子标准算法 ML-DSA 不就行了吗？

答案是：不行！因为太胖了。

Web PKI 是全球部署环境最复杂的系统之一。在一次典型的 TLS 握手（就是你建立 HTTPS 连接的那一瞬间）中，服务器需要向你的浏览器发送大概 5 个签名和 2 个公钥。

让我们来看看这场“体积灾难”的对比（参考官方给出的图表）：

• 目前的 ECDSA-P256：签名大小仅为 64 字节。公钥只有区区 64 字节。整个握手的认证数据大概只有几百字节。
• 后量子时代的 ML-DSA-44：哪怕是最小的规格，其一个签名的大小也高达 2,420 字节！公钥大小飙升至 1,312 字节！

如果我们在现有的 Web PKI 架构下，简单粗暴地把所有的 ECDSA 替换成 ML-DSA，那么单次 TLS 握手的数据量将直接突破 10 KB（10,000 字节）大关！

这会带来什么毁灭性的后果？

Cloudflare 的硬核研究表明，当 TLS 握手体积膨胀到这个规模时，由于 TCP 拥塞窗口机制和网络 MTU 的限制，大量真实世界的网络连接将直接失败（Fail），而幸存下来的连接也会遭遇严重的延迟。

试想一下，全球数十亿台低带宽的物联网设备、偏远地区的手机，在每一次发起 HTTPS 请求时都要被迫下载十几 KB 的“肥胖”证书。这种为了“防御一个尚未出现的威胁”而牺牲全人类网络体验的做法，在工程上是绝对不可接受的默认设定。

破局杀招：Let’s Encrypt 押注 MTCs（默克尔树证书）

在绝望之中，Let’s Encrypt 和一众硅谷巨头找到了一个极其优雅且疯狂的解法——Merkle Tree Certificates（MTCs）。

这个机制不仅解决了签名体积过大的问题，还顺手重塑了证书透明度（Certificate Transparency, CT）的底层逻辑。

1. 放弃“一人一签”，改用“批量打包”

在现有的 Web PKI 中，CA（证书颁发机构）在签发证书时，会对每一张证书单独进行一次签名。

而 MTCs 彻底颠覆了这个逻辑：

CA 不再对单个证书签名，而是把一段时间内（比如一个小时）要签发的所有证书，收集起来构建成一棵 Merkle Tree（默克尔树）。然后，CA 只需要用后量子算法（如 ML-DSA），对这棵树的树根（Root）进行一次唯一的签名。

2. 浏览器如何验证？

既然没有单独的签名了，你的浏览器怎么知道你访问的网站证书是合法的呢？

这里利用了默克尔树的密码学奇迹——包含证明（Inclusion Proof）。

浏览器（或客户端）会在后台定期更新 CA 发布的“树根”信息（被称为 Landmarks）。当浏览器访问服务器时，服务器只需要提供一条从自己这片“叶子”走到“树根”的路径（包含证明）。

因为哈希算法生成的包含证明（如 SHA-256）体积非常小（通常只有几百字节），所以在这种常见情况（Common Case）下，一次 TLS 握手的认证数据：

1 个短小精悍的包含证明 + 1 个公钥 + 0 个笨重的后量子签名！

在传统的 PQ（后量子）架构下，开销高达 7,260 字节；而采用了 MTCs 后，瞬间被压缩到了 736 字节，性能甚至直逼现有的传统算法。

这个体积甚至比今天基于 RSA/ECDSA 的传统握手还要小！这种从“胖子”变“瘦子”的降维打击，正是 MTCs 被奉为救星的根本原因。

3. 天生自带的“透明度”

现有的证书生态里，证书透明度（CT Logs）是一个事后缝合的“补丁”：CA 签发证书后，需要把它记录到一个单独的 append-only 日志系统中，并把签名附在握手数据里。

但在 MTCs 的世界里，“这棵默克尔树本身，就是那个追加日志（Append-only Tree）”！

由于每一张证书都必须存在于默克尔树中才能生效，这意味着没有任何一张 MTCs 证书可以脱离监控而秘密存在。CT 机制被完美、原生在地融入了底层协议中。

这对于 Let’s Encrypt 来说可谓是得心应手，因为他们自 2019 年以来就一直在维护基于底层树数据结构的 CT 日志，技术储备早已拉满。

路线图与影响：给开发者的终极指南

Let’s Encrypt 宣布，他们正计划在 2026 年末提供 MTCs 的测试环境（Staging），并在 2027 年正式推向生产环境（Production）。

这是 Web PKI 历史上一次规模浩大的“基础设施更换手术”。作为开发者和系统运维人员，这几个关键点你必须立刻了解：

1. 目前不用慌，但要保持关注：今天，你依然可以像以前一样，通过 Let’s Encrypt 免费、自动地续签你现有的 RSA/ECDSA 证书。
2. 底层协议正在疯狂博弈：IETF 的 PLANTS 工作组正在紧锣密鼓地制定 MTCs 的标准。如果你维护着类似于 certbot 这样的 ACME 客户端，或者负责底层的证书签发管道，现在是时候去查阅 mtcs@chromium.org 邮件列表并跟进 draft-ietf-tls-mldsa 草案了。
3. 不要忘了“加密”危机：虽然 Let’s Encrypt 正在通过 MTCs 解决“认证”问题，但文章结尾发出了严厉警告：后量子“加密（Encryption）”危机是当下最紧急的问题！

作为服务器的运营者，你现在必须立刻行动：检查你的 Web 服务器（如 Nginx, Envoy, Caddy等）和操作系统配置，确保已经开启了混合后量子密钥交换（如 X25519MLKEM768）。 所有的主流浏览器现在都已经支持它，这是你今天能做的 ROI 最高的安全升级！

小结：一场不计代价的世代更替

从 2013 年 Let’s Encrypt 创立至今，他们始终秉持着一个信念：安全应该是全球每个人都能平等获取的基础权利。

从推动全网 HTTPS 普及，到如今在量子威胁的阴影下，不惜重构庞大底层架构以推行 MTCs，这场无声的战役，不仅是算力与算法的博弈，更是人类为了守护数字世界的信任基石，所进行的一次史诗级防守反击。

达摩克利斯之剑已经落下，但得益于这些密码学极客的疯狂努力，当风暴真正来临的那一天，我们浏览器的左上角，那把绿色的小锁，依然会坚定地亮起。

资料链接：https://letsencrypt.org/2026/06/03/pq-certs

今日开放讨论：

当 MTCs（默克尔树证书）将证书透明度（CT）彻底融入底层结构时，你认为它会对现有的防火墙流量审计（如企业内网对 TLS 的中间人解密审计）带来哪些阻碍和变化？

欢迎在评论区分享你的安全架构洞察，我们一起探讨后量子时代的网络防线建设！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/10/the-story-of-cpp

大家好，我是Tony Bai。

如果将人类现代软件工业比作一部庞大的机器，那么支撑其运转的最核心骨架中，无疑很大一部分由C++支撑。从你手中的智能手机操作系统、每天刷的短视频推荐引擎、华尔街每秒百万次的高频交易系统，到驱动大语言模型（LLM）的底层算力矩阵，C++ 几乎无处不在。

在过去的 40 年里，这门语言一次次被宣布“濒临死亡”，却又一次次浴火重生。它被称为“弗兰肯斯坦的怪物”，被无数程序员诅咒过其令人发指的复杂性。但即便在如今 Rust 和 Go 等现代语言强势围剿的今天，C++ 依然稳坐系统级编程的王座。

近日，一部名为《The Story of C++: The World’s Most Consequential Programming Language》（C++ 官方纪录片）在 YouTube 上引起了巨大轰动。这部长达近两小时的纪录片，首次召集了包括 Bjarne Stroustrup（C++ 之父）、Alexander Stepanov（STL 之父）在内的一众 C++ 核心缔造者，向世人揭开了这门语言背后那些鲜为人知的妥协、背叛与权力斗争。

更精彩的是，在海外技术社区 Reddit 的 r/cpp 板块中，这部纪录片引发了无数大厂老炮和编译器极客的热烈讨论，通过将纪录片的官方叙事与社区的“野史”拼凑在一起，我们看到了一部远比代码本身更惊心动魄的技术史诗。

序章：从贝尔实验室逃出的“异类”

时间倒回 1979 年。彼时的贝尔实验室（Bell Labs）是全球计算机科学的“麦加圣地”，Ken Thompson和Dennis Ritchie 在这里创造了 C 语言和 Unix 系统。整个世界都沉浸在 C 语言那种贴近硬件、极致简洁的暴力美学中。

就在此时，一个名叫 Bjarne Stroustrup 的丹麦年轻人来到了贝尔实验室。他需要编写复杂的分布式系统模拟器，很快便发现，C 语言那套基于“函数与指针”的过程式编程，在面对巨大且复杂的系统时，就像是在用石器时代的工具建造摩天大楼——代码极易失控，且难以复用。

于是，他做了一个极具叛逆性的决定：他要在 C 语言的基础上，引入“类（Classes）”的概念。 这就是最初的“C with Classes”。

Bjarne 的初衷极其务实：他不想重新发明轮子，他只想让现有的 C 程序员能够稍微优雅一点地写代码。 因此，他定下了一条死命令：C++ 必须 100% 兼容 C 语言。

在 Reddit 的讨论中，一位资深 C++ 工程师指出：“C++ 之所以能在早期存活下来，唯一的理由就是它能够与海量的 C 语言头文件无缝对接。” 这条与 C 的“血脉绑定”，成为了 C++ 能够迅速占领企业级市场的最强杀手锏，但也为它日后的无底洞复杂性和编译期灾难埋下了最深远的隐患。

第一幕：STL 的救赎——从被群嘲到绝地反击

如果说 Bjarne 给了 C++ 骨架，那么真正赋予 C++ 灵魂的，是另一个极具争议的天才：Alexander Stepanov。

在 90 年代初，面向对象编程（OOP）如日中天。所有人都在沉迷于画继承树、搞多态。但 Stepanov 对此嗤之以鼻。他认为，将数据结构和算法强行绑定在对象里，是一种“极度低效且愚蠢的数学谬误”。

他提出了一种名为“泛型编程（Generic Programming）”的思想：算法应该独立于数据结构之外，通过一种叫“迭代器（Iterator）”的桥梁连接。

这就是后来名震天下的 STL（标准模板库）。

在纪录片中，最戏剧性的一幕发生在 1993 年的 C++ 标准委员会上。当 Stepanov 第一次将庞大且极其复杂的 STL 提案摆在委员会面前时，遭到了全场的群嘲与抵制。

“这太庞大了！这太疯狂了！这简直是在强奸编译器！”大佬们纷纷摇头。

此时的 C++ 委员会，正沉浸在由微软、IBM 等科技巨头把持的“门派斗争”中，没有人愿意为这种学术界的“屠龙术”买单。

在生死存亡之际，是 Bjarne 站了出来。为了让 STL 能够活下来，Bjarne 甚至不惜“扭断了自己亲生孩子的手臂”。

一位Reddit 用户分享了一段极其硬核的野史：“听到 Bjarne 承认为了让 STL 能在早期的 Cfront（C++ 编译器前置工具）上编译通过，他强行修改了 C++ 的语言规则，甚至导致了著名的 Cfront 2.0 bug，这简直太搞笑了！”

最终，在 Bjarne 的权力背书下，STL 以极其微弱的优势通过了委员会的投票。这一决定，彻底改变了现代软件工业的走向。没有 STL 提供的 Vector、Map 和极度优化的泛型算法，后来的谷歌、亚马逊和高频交易公司根本无法在 C++ 上构建起支撑亿万级流量的系统。

第二幕：巨头的绞杀——微软的野心与 Java 的入侵

正当 C++ 在系统底层攻城略地时，外部的绞杀战开始了。

2000 年前后，C++ 迎来了它生命中最黑暗的“冰河期”。在 Reddit 上，大厂老炮们对这段历史记忆犹新：

1. Java 的降维打击：Sun 公司推出的 Java 带着“Write Once, Run Anywhere（一次编写，到处运行）”和自带垃圾回收（GC）的承诺，瞬间摧毁了 C++ 在企业级开发层的统治地位。IBM 等巨头一夜之间倒戈。
2. 微软的背刺：为了对抗 Java，微软推出了自己的 .NET 战略和 C# 语言，并在很大程度上“冻结”了对原生 C++ 工具链的投入。

当时的 C++，就像是一个垂暮的老人：没有包管理器、跨平台编译像一场噩梦、ABI（应用程序二进制接口）地狱让人抓狂。甚至有人提到了一篇著名的早期新闻标题：“The Decline of C++?（C++ 的衰落？）”

更致命的是，C++ 标准委员会（WG21）在这个时期陷入了长达十年的“难产”。各大编译器厂商（尤其是微软的 MSVC）为了各自的商业利益互相扯皮。

在 Reddit 的帖子中，现任 MSVC STL 开发者的 STL 本尊亲自下场“辟谣”与爆料：

当时有很多开发者抱怨微软试图“破坏”STL（因为微软在 STL 里加入了极度拖慢性能的迭代器调试代码 _SECURE_SCL）。STL 大神解释道：“*微软并没有试图破坏 STL，这纯粹是出于对安全性的妥协，而在 2000 年代，由于编译器团队对 C++ 底层模板的理解不足，导致了糟糕的实现。*”

无论如何，在这漫长的十年里（C++98 到 C++11 之前），C++ 停滞不前。这段历史在官方纪录片中被轻描淡写地带过，但在社区看来，这是 C++ 被巨头资本裹挟、险些丧命的耻辱时代。

第三幕：现代 C++ 的绝地反击（C++11 至今）

就在所有人都以为 C++ 将退化为一门“只配用来写驱动”的边缘语言时，C++11 横空出世。

这绝对是编程语言史上最伟大的一次“续命”。C++11 引入了 auto、智能指针（Smart Pointers）、Lambda 表达式以及多线程支持。它仿佛将一辆生锈的老爷车，直接改装成了核动力飞船。

Reddit 上的一位开发者感叹道：“如果你没有经历过在 C++11 之前，仅仅是想要实现一个跨平台的多线程逻辑，就能触发各种未定义行为（UB）的时代，你就无法理解我们现在拥有的现代 C++ 有多么幸福。”

此时，硅谷的巨头们也终于醒悟。随着摩尔定律的逐渐放缓（单核 CPU 的免费午餐结束了），亚马逊、谷歌、Meta 以及高频交易巨头 Hudson River Trading（HRT）发现：要想在服务器账单上省下数千万美元，要想让延迟降低到微秒级，只有一条路可走——回归 C++。

从 C++11 开始，标准委员会终于恢复了活力，确立了每三年发布一个新标准（C++14, C++17, C++20…）的铁律。

纪录片中展示了今天 C++ 标准委员会的盛况：从最初的几十人，变成了现在动辄数百人的庞大机构。但这同时也带来了新的诅咒：过度设计与特征膨胀（Feature Bloat）。

终章：C++ 无法摆脱的诅咒与未来

纪录片以一种充满希望的基调收尾，特别提到了即将到来的 C++26 及其杀手级特性：静态反射（Static Reflection）。

但在 Hacker News 和 Reddit 上，那些每天深陷在 C++ 屎山代码中的一线架构师们，却显得远没有那么乐观。

1. 缺失的拼图：为什么官方不敢提 Boost？

眼尖的社区极客指出，这部宣称是“官方历史”的纪录片，竟然对 Boost 库 只字未提！要知道，在 C++ 停滞的十年里，是 Boost 库（包含大量实验性的元编程和现代特性）几乎凭借一己之力撑起了 C++ 的生态，并孵化了 C++11 的大部分新特性。社区猜测，这背后可能涉及到 Boost 基金会与 C++ 标准委员会之间复杂的权力斗争与未解恩怨。

2. 基础设施的荒漠：构建工具与包管理器之殇

在 Reddit 上，超过一半的火力集中在一个最朴素的痛点上：C++ 至今没有一个像样的官方包管理器。

当你用 Go 或 Rust 开发时，go get/install 或 cargo install 就能优雅地解决一切。但在 C++ 中，为了集成一个第三方库，你需要聘请一个拥有“博士学位”的 CMake 工程师，在 vcpkg、Conan、Bazel 之间痛苦挣扎，还要处理无穷无尽的 ABI（应用程序二进制接口）冲突。

一位大厂架构师绝望地写道：“标准化不应该强迫企业妥协，但现有的三大包管理器，导致了生态的极端割裂。C++ 真正的问题不在于语言层面，而在于其糟糕透顶的工程工具链体验。”

3. 碳（Carbon）与锈（Rust）的围剿

如今，谷歌推出了试图平替 C++ 的 Carbon 语言，而白宫甚至在安全报告中公开呼吁开发者放弃 C/C++，转向内存安全的 Rust。

面对如此巨大的压力，C++ 能够挺过下一轮大洗牌吗？

答案或许依然是肯定的。因为 C++ 早就超越了一门编程语言的范畴，它已经成为了人类数字文明的基础物理法则之一。 那些数以百亿计的遗留代码，那些经历了三十年实战检验的高频交易系统，那些与硬件深度绑定的 GPU 调度矩阵，是不可能在十年内被 Rust 或 Go 完全重写的。

《The Story of C++》不仅是一部纪录片，它是一面镜子。它照出了人类在构建庞大数字帝国时，那种充满妥协、混乱却又无比顽强的工程精神。

C++ 的世界里没有完美的乌托邦。正如 Bjarne Stroustrup 那句最著名的名言：

“世界上只有两种编程语言：一种是人们天天在抱怨的语言，另一种是根本没人用的语言。”

而 C++，无疑是被抱怨得最狠，却又永远无法被抛弃的那一个。

资料链接：

• https://www.youtube.com/watch?v=lI7tMxzSJ7w
• https://www.reddit.com/r/cpp/comments/1txhe5n/the_story_of_c_the_worlds_most_consequential/

今日开放讨论：

作为开发者，你认为 C++ 目前最大的痛点是由于它必须保持与 C 的后向兼容（Backwards Compatibility），还是因为它糟糕的构建和包管理工具？在 AI 和 Rust 崛起的时代，你会建议新人继续深入学习 C++ 吗？

欢迎在评论区留下你的观点，我们一起探讨系统级编程的未来！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/09/go-proposal-examples-to-support-arbitrary-function-signatures

大家好，我是Tony Bai。

在 Go 语言的开发日常中，编写 ExampleXxx 示例代码不仅是完善文档的必经之路，更是一门绝佳的“活文档”艺术。

通过在 “_test.go” 文件中编写以 Example 开头的函数，并在末尾加上 // Output: 注释，Go 官方的 go doc 和 pkgsite 就能在网页上直接渲染出可交互、可直接在浏览器中运行（Playable）的示例代码。

然而，在这个看似优雅的设计背后，却隐藏着一个让全球 Go 工程师如鲠在喉、折磨了大家近十年的“硬伤”：Go 官方对 Example 函数的签名有着极其死板的限制——它必须是无参、无返回值的空函数。

为了这个限制，我们在写文档示例时，不得不写出大量极度违背 Go 地道（Idiomatic）编程哲学的样板代码。

为了彻底拔掉这根刺，Go 编译器团队核心成员Damien Neil (neild)提交了一项被称为“大一统”的提案——Issue #79808：允许 Example 示例支持任意函数签名！

这项提案不仅终结了社区自 2017 年以来的长期争论（#21111 与 #64993），更用一种极其巧妙且务实的“解耦设计”，为 Go 语言的文档生态减负。

历史的疮疤：为了写好一个示例，我们被迫说了多少“废话”？

在真实的 Go 工程中，几乎所有的文件读写、网络调用都会返回 error。按照 Go 的地道写法，当我们调用一个可能失败的函数时，最自然的反应是直接将错误向上抛出：

// 我们真正希望在文档里向用户展示的地道写法
func ExampleReadFile() error {
    data, err := os.ReadFile("config.json")
    if err != nil {
        return err // 优雅直接
    }
    fmt.Println(string(data))
    return nil
}

但是，在目前的 Go 版本中，这行不通！ 因为 Example 函数不允许有任何返回值。

为了写出一个能通过 go test 验证的示例，你被迫在你的示例代码中写满各种“废话”：

// 迫于规则，我们不得不写出的妥协版本
func ExampleReadFile() {
    data, err := os.ReadFile("config.json")
    if err != nil {
        log.Fatal(err) // 或者使用更难看的 panic(err)
    }
    fmt.Println(string(data))
    // Output: { "port": 8080 }
}

这带来了一个极其糟糕的引导效应：新手在阅读官方文档时，会误以为在业务代码中遇到错误就应该直接 log.Fatal 或 panic。 示例代码不仅没能展示出 Go 语言优雅的错误处理哲学，反而成了不良编码习惯的传染源。

此外，当你在编写测试框架（Test Framework）或者使用 Go 新版引入的 synctest 虚拟时钟技术时，你必须拿到底层的 *testing.T 对象。但由于 Example 函数不能有入参，你根本无法写出一个可以传递 t *testing.T 对象的示例代码。

十年博弈：从 #21111 到 #64993 的宿命碰撞

为了解决这两个痛点，Go 社区实际上进行了两场旷日持久的战役：

战役 1：允许 Example 返回 error（#21111 – 始于 2017 年）

早在 2017 年，大牛 rogpeppe 就提出了这个想法。但当时官方为了等待 Go 2 的整体错误处理方案（Error Handling Draft）而将其无限期搁置。随着 Go 错误语法提案被无限期延迟，这个 hold 也终于在近年被拿掉。

战役 2：允许入参带上 *testing.T（#64993 – 始于 2024 年）

随着多智能体测试和 synctest（需要虚拟时间同步）等现代测试技术的发展，开发者越来越需要展示涉及 testing.T / testing.B / testing.F 的完整用例。但因为不支持入参，大家不得不写出复杂的 Stub（伪造类）去强行拼凑。

大一统方案 #79808：允许任意函数签名的 Example！

面对这两个互相纠缠、细节极其复杂的提案，Go 核心团队的 neild 指出，之前的讨论之所以陷入死胡同，是因为大家把 “文档如何展示示例（Rendering）” 与 “测试框架如何运行示例（Execution）” 混为一谈了。

如果我们彻底将这两者解耦呢？

在 Issue #79808 中，他提出了一个近乎完美的极简方案：对 Example 函数的签名彻底放开限制。

1. 规则大解放

只要你的函数命名符合 Example 或 ExampleXxx（且首字母大写），go doc 和 pkgsite 就会一律无条件地将其作为示例代码在网页上展示出来！

无论你的函数长成什么样：

package example_test

// 场景 A：优雅返回 error，不再需要 log.Fatal
func Example_returning_an_error() error {
    f, err := os.Open("testfile")
    if err != nil {
        return err
    }
    defer f.Close()
    return nil
}

// 场景 B：支持传入 testing.T，测试框架类的完美示范
func ExampleFunc_taking_a_t(t *testing.T) {
    if err := examplepackage.Func(t); err != nil {
        t.Fatal(err)
    }
}

// 场景 C：甚至可以带上输入输出参数
func Example_in_and_out(a, b int) string {
  return examplepackage.AddReturningString(a, b)
}

2. 完美的运行防线

如果放开了签名限制，go test 怎么运行它们？

• 对于有参数或返回值的 Example：testing 包一律不自动运行它们。这极大地简化了测试运行器的复杂度，避免了处理带有复杂入参的函数执行。
• 防止混淆：如果一个 Example 带有入参或返回值，但你却在末尾写了 // Output: 注释，go test 会直接抛出编译期错误，防止开发者产生误解。
• 如何跑测试？：如果你依然希望在测试中运行这些复杂的示例，非常简单，写一个伴随的 Test… 函数手动调用它即可：

func TestExample_returning_an_error(t *testing.T) {
  if err := Example_returning_an_error(); err != nil {
    t.Fatal(err)
  }
}

小结：让代码回归纯粹

从这个跨越十年的提案博弈中，我们能清晰地感受到 Go 团队的实用主义工程哲学：

他们没有为了解决问题而去创造一套复杂的、充满各种边界特例的编译器黑魔法，而是通过“将文档展示与执行引擎完全剥离”这一解耦思路，在不增加运行时负担的前提下，完美解决了长期折磨开发者的体验难题。

让文档回归原本纯粹的模样，让代码不再为古板的规则而妥协。这也是 Go 语言吸引系统工程师的魅力所在。

资料链接：

• https://github.com/golang/go/issues/21111
• https://github.com/golang/go/issues/64993
• https://github.com/golang/go/issues/79808

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/08/the-real-reason-big-tech-is-switching-to-go

大家好，我是Tony Bai。

在软件工程中，核心技术栈的迁移是一项高风险、高成本的决策。

然而，在近期的技术演进中，我们看到了一股明显的趋势：全球科技巨头与快速成长的 AI 独角兽们，正在不约而同地将核心系统向 Go 语言（Golang）收敛。

• 微软宣布将 TypeScript 核心编译器移植到 Go，构建速度暴涨 10 倍。
• Reddit将庞大的 Python 单体架构逐步解耦，核心数据模型全面改用 Go 重写。
• Lovable（前沿 AI 独角兽）将 4.2 万行 Python 代码移植为 Go，服务器实例直接从 200 个锐减到 10 个。
• Uber作为长期拥有最庞大 Go 代码库的企业之一，持续将后端服务从 Python、Node.js 收敛、统一至 Go 语言，以极低的算力成本承载海量并发。

这并非盲目的技术跟风，而是一场基于运行成本、高并发能力和工程维护性的理性重构。今天，我们就通过这些大厂的真实工程案例，深入拆解大厂重构核心系统时，集体投向 Go 的底层逻辑与技术启示。

微软的编译器移植：为什么 C# 之父不选 C# 和 Rust？

2025 年 3 月，微软宣布将 TypeScript 的编译器和工具链移植到 Go 语言。到了 2026 年 4 月，采用 Go 编译器底层的 TypeScript 7 Beta 正式发布。

令人瞩目的是，这个项目的操盘手正是 Anders Hejlsberg —— C# 语言的设计者与 TypeScript 的创造者。

这一决策在技术社区引发了深度探讨：为什么微软不用自家的 C#，也没有选择近年来大热的 Rust？这背后隐藏着极具启发性的工程权衡。

明确“移植（Port）”与“重写（Rewrite）”的边界

在工程决策中，这两者有着本质区别：

• 完全重写（Rewrite）：意味着抛弃旧代码，从零开始重新设计（New Design），风险极高。
• 代码移植（Port）：翻译现有代码，保持原有的代码结构和行为（Same behavior & structure），风险可控。

旧的 TypeScript 编译器是用函数式风格编写的，且重度依赖垃圾回收（GC）。

• 为什么不选 C#？C# 是典型的面向对象（OOP）语言。如果使用 C#，将很难平滑移植函数式风格的旧编译器，几乎等同于要推倒重写。
• 为什么不用 Rust？Rust 没有垃圾回收机制，要求开发者手动且极其严苛地管理内存。如果改用 Rust，团队必须彻底推翻并重新设计整套代码的内存生命周期，这直接背离了“平滑移植”的初衷。

Go 为什么是最佳折中方案？

Go 既支持原生编译，拥有极高的运行速度，同时还内置了高效的垃圾回收（GC）。

更关键的是，习惯写法的 Go 代码（Idiomatic Go）在结构上与 TypeScript 原有的编码模式有着天然的相似性。这使得原有团队在维护移植后的 Go 代码时，几乎没有认知摩擦。

移植后的性能收益：
* 编译构建速度直接提升了 10 倍。
* 编辑器加载时间从原来的 9.5 秒缩短至 1.2 秒。

微软用事实证明：Go 是在维持原有代码结构的前提下，实现性能跨越式提升的最短路径。

Reddit 的解耦之路：高并发压力下的“影子测试”

Reddit 曾长期使用 Python 单体（Monolith）架构。随着全球流量的爆发，单体架构的弊端逐渐显现：代码耦合严重、可靠性降低，系统维护成本极高。在高峰期，甚至连发帖、评论等基础操作都会遭遇严重的延迟。

为了解决高并发瓶颈，Reddit 决定对核心的四大基础特性（评论、账户、帖子、子社区）进行解耦，全部用 Go 语言重写为独立的微服务。

为什么选择 Go？

在高并发场景下，Go 内置的轻量级协程（Goroutine）和通道（Channel）调度模型，相比于 Python 的多线程/多进程，能够以更低的系统开销和更少的网络协调，抗住同等规模的流量。

零故障上线的“影子测试（Shadow Testing）”

系统重构最忌讳“一刀切”式的直接上线。Reddit 采用了一套精妙的过渡方案：

他们让 Python 旧单体与 Go 新服务在后台同时运行。对于每一次写入请求，两个系统都会收到相同的输入。Go 服务将数据写入一个隔离的测试数据库。

               ┌───────────────┐
               │  User Input   │
               └───────┬───────┘
                       │
             ┌─────────┴─────────┐
             ▼                   ▼
    ┌─────────────────┐ ┌─────────────────┐
    │ Python Monolith │ │   Go Services   │
    └────────┬────────┘ └────────┬────────┘
             ▼                   ▼
    ┌─────────────────┐ ┌─────────────────┐
    │  Production DB  │ │     Test DB     │
    └─────────────────┘ └─────────────────┘
             │                   │
             └─────────┬─────────┘
                       ▼
             Compare & Debug Output

通过在后台持续对比两个系统的输出结果，团队在不影响真实用户的前提下，排查并修复了新服务中的所有潜在 Bug。确认无误后，才 100% 将流量平滑切换到了 Go 服务。

重构后的收益：
* 关键写入操作的 P99 延迟直接砍半，系统高可用性大幅提升。

运行成本与算力优化：Lovable 与 Uber 的工程实践

对于快速成长的 AI 独角兽 Lovable 来说，技术栈的选择直接关系到服务器账单和业务存亡。

作为一个允许非技术用户通过 AI 构建应用的平台，Lovable 在核心链路上面临着极高并发的挑战。用户发送一条聊天指令，后台需要瞬间触发超过 50 个 HTTP 并发调用，分别去请求各大模型提供商、内部存储及周边服务。

Python 在这种高度并行的 IO 密集型场景下显得力不心。Lovable 团队果断将 4.2 万行 Python 代码重写为 Go。

无独有偶，Uber 作为长期拥有最庞大 Go 代码库的企业之一，也曾经历过从 Python、Node.js 向 Go 逐步收敛的过程。为了在单机上压榨出更高的并发能力，减少冗余的服务器开销，Uber 逐步在后端服务中停用了 Python，将核心服务统一收敛至 Go。

这两家公司，用 Go 实现了令人惊叹的算力优化：

小结：大厂系统重构释放的工程信号

这些大厂和独角兽们的集体实践，为我们释放了清晰的工程信号：

1. “运行成本”正成为系统重构的首要驱动力
   在项目初期，动态语言（如 Python、TypeScript）确实能提供极佳的开发爽感。但当业务规模扩大、高并发场景增加时，其带来的服务器硬件成本和维护开销将呈指数级上升。
2. Go 处于“开发效率”与“运行性能”的黄金分割点
   它不像 Rust 那样有着极其陡峭的内存管理和所有权学习曲线，能够让团队保持极高的开发效率；同时，它又拥有接近原生代码的执行速度，和冠绝群雄的轻量级并发模型。这使其成为了现代生产级后端服务的首选。

大厂的重构实践，为我们提炼了以下三条黄金工程铁律：

1. 分清“移植”与“重写”：在系统重构时，若想在保留原有业务逻辑的前提下快速提升性能，像微软那样进行代码级移植（Port）是风险最低、效率最高的路径。
2. 善用“影子测试（Shadow Testing）”：核心系统解耦和替换时，切忌盲目上线。采用双轨并行、对比输出的影子测试，是保障系统平滑过渡、零故障上线的最佳实践。
3. 高并发场景首选轻量并发模型：当系统面临大量并发 IO（如 AI 编排、多 API 协同调用）时，Go 语言的协程机制能够以极低的资源消耗提供极佳的吞吐量。

系统重构的本质，是在业务发展、团队认知和机器成本之间寻找最优解。而 Go，正是大厂在经历数次工程实践后，给出的最务实的答案。

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

今日开放讨论：

1. 微软不用 C# 也不用 Rust，而是选择 Go 来移植 TS 编译器，这个决策中的“移植 vs 重写”权衡是否启发了你？
2. Reddit 采用的“双轨制影子测试”非常稳健，你在实际的系统迁移或重构中，使用过类似的测试方案吗？
3. 从 Lovable 将 200 个实例缩减为 10 个，到 Uber 节省 97% 的算力，这些真实的性能与成本数据是否改变了你对后端技术选型的看法？

欢迎在评论区留下你的硬核观点，我们一起探讨系统重构与 Go 的工程之美！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/06/07/gaokao-in-the-age-of-ai-is-the-top-tier-degree-worthless

大家好，我是Tony Bai。

今天，2026年6月7日，千万名考生再次走向战场。

考场外，红色的横幅依然高悬，旗袍与鲜花依然簇拥。但在喧嚣之下，空气中却弥漫着一种前所未有的复杂情绪。

数据已经给出了最直观的反馈：在经历了2024年1342万人的历史峰值后，2025年和2026年的高考报名人数连续两年出现下滑。2026年全国高考报名人数仅为1290万人，比2025年的1335万人还减少45万人

生源的两连降，折射出的是无数家庭最深层的理性觉醒。在这个2026年的夏天，生成式AI、智能Agent和全自动工作流已经深度嵌入社会的每一个齿轮。

前阵子，一位本科毕业于某顶尖985高校、刚刚工作两年的程序员在社交平台上发帖：

“当年高考，我是全省前0.5%的做题家。辛辛苦苦在985卷了四年，以为拿到了中产阶级的入场券。结果工作不到两年，公司引入了AI 研发工作流。我现在每天90%的工作——写基础代码、debug、甚至写技术文档，AI两秒钟就能做得比我更好、更无懈可击。我开始怀疑，我那十二年的寒窗苦读，到底算什么？”

这条帖子瞬间引爆了全网的共鸣与焦虑。

今天的高考，我们还在为什么而战？如果连最顶尖的985、211学历，在AI面前都显得如此脆弱，我们付出的巨大代价，究竟在交换什么？

斯坦福的残酷研究：为什么我们的大学无法对抗AI的清算？

要回答“今天的高考还在为什么而战”，我们必须先看清一个长期被我们忽视的真相：我们的高等教育，正在让最聪明的年轻人“停止成长”。

斯坦福大学联合北京大学、清华大学、俄罗斯高等经济学院等全球顶尖机构，在《Nature Human Behaviour》（自然-人类行为）上发表了一篇具有里程碑意义的长期追踪研究。

研究团队对中国、美国、印度、俄罗斯数万名计算机和电子工程专业的学生进行了长达四年的标准化测试，得出了两个极具颠覆性的结论：

入学时，中国高考生是无可争议的“世界霸主”

在18岁踏入大学校门的那一天，中国大一新生的学术能力和数理基础处于全球同龄人的金字塔尖，其批判性思维（Critical Thinking）能力也与美国同龄人完全持平。

这证明，我们高强度的高考选拔，确实筛选出了这个星球上最聪明、最能吃苦、逻辑最严密的一批年轻人。

毕业时，我们的学生经历了残酷的“技能退化”

然而，追踪到大四毕业时，情况发生了戏剧性的逆转。

在大学四年里，美国学生的批判性思维能力实现了大幅度增长（约0.5个标准差）。而中国、印度和俄罗斯的学生，在四年里批判性思维几乎“零增长”，甚至在后两年出现了绝对值上的显著下降。

在数学和物理等专业学术能力上，中国学生在大一结束后，也出现了明显的、绝对的技能损失（下降约0.3标准差）。

这篇《Nature》论文揭示了一个近乎残酷的事实：中国的高考生在18岁那年达到了认知和技能的巅峰，然后，在大学四年里，他们被“严进宽出”的淘汰机制、陈旧的专业划分、以及重灌输轻思辨的教学模式，温水煮青蛙般地削弱了。

当这群大四毕业生拿着“高起点、低增值”的认知系统，一头撞上2026年已经进化到能够自我迭代的AI系统时，悲剧就发生了。

那些在大学里靠死记硬背应付考试拿下的GPA，在AI面前，连一秒钟的抵抗力都没有。

AI时代的清算：被替代的90%，到底是什么？

为什么那位985毕业生会感叹“AI替代了我90%的工作”？

因为在2026年的今天，AI首先消灭的，恰恰是那些“有明确标准、有套路可循、依赖信息检索和加工”的白领工作。

而这些工作，正是过去的大学教育最擅长培养、也是中产家庭最向往的就业方向：

• 初级程序员：AI自动编程工具已经能完成大部分基础代码的编写与测试。
• 翻译与文案策划：多模态大模型能够瞬间生成符合各种文化语境的译文和营销方案。
• 基础数据分析师：复杂的报表统计、趋势预测，AI可以在极短时间内完成可视化输出。
• … …

反思一下：这些被替代的工作，其核心特征不就是“做题”吗？

给出一个明确的需求（题目），寻找最优的算法或方案（标准答案）。

高考，是一场关于“寻找标准答案”的终极训练；而我们的大学，在过去很长一段时间里，只是这场训练的延续。

当“做题”的能力被AI彻底平替，我们十二年寒窗苦读积累的优势，在这一瞬间被抹平了。

2026年的质问：今天的高考，我们还在为什么而战？

既然如此，我们为什么还要支持孩子去考场？高考在今天，究竟还有什么意义？

如果我们依然把高考当成“通往高薪工作的自动售票机”，那我们一定会失望。因为那台售票机，已经坏了。

但如果我们换一个视角，高考在2026年，依然是一场不可替代的“成人礼”。我们今天在高考中战斗，是为了拿回三样AI永远无法夺走的东西：

1. 战的是“深度专注与抗挫折的底层神经元”

高考不仅考查知识，更是一场对意志力、抗压能力、多任务管理和长期深度专注力的极限训练。

在碎片化信息和即时反馈（如短视频、快餐娱乐）毁掉一代人脑前额叶的时代，能够为了一个长远目标，日复一日地进行深度学习、克服枯燥和焦虑——这种“深度专注的神经机制”，是你未来驾驭AI、不被AI深度娱乐化奴役的唯一底层硬件。

2. 战的是“在无标准答案世界里，寻找最优解的勇气”

很多人抱怨高考僵化，但高考恰恰教给普通人一件事：在规则极其明确的系统里，如何通过自我迭代，把自己的能力逼出极限。

这种“在给定约束条件下，调动一切资源求得最优解”的肌肉记忆，在走出考场后，可以无缝迁移到任何一个充满未知、没有标准答案的领域。

3. 战的是“改写自身命运的入场券”

尽管学历在贬值，但不可否认，高考依然是这个社会最公平、杂质最少的一次阶层跃迁和朋友圈重组的机会。

你考上的名校，它所能给你的最大价值，已经不再是课堂上的专业知识（那些网上都有），而是和你并肩站在一起的、同样经历过极限训练的同龄人群体，以及这个平台带给你的眼界和高维认知。

自救路径：考完之后，如何重塑你的“免裁系统”？

明天之后，高考生们将迎来人生中最长的一个暑假。但请记住，真正的分水岭，从交卷的那一刻才刚刚开始。

如果你不想在四年后成为那个被AI替代90%的“失业做题家”，你必须在大学第一天起，按照以下三步路径，重新设计自己的成长曲线：

步骤一：从“答题者”转变为“提问者”

未来的价值，不取决于你脑子里记了多少标准答案，而取决于你能否向AI、向世界提出最具洞察力的问题。在大学里，多去问“为什么（Why）”和“如果……会怎样（What if）”，而不是仅仅去背诵“是什么（What）”。

步骤二：建立你的“AI-Native”个人工作流

不要把AI当成作弊工具，而要把自己当成一个“AI团队的PM（项目经理）”。去学习如何编写结构化的Prompt，如何用多款AI工具协同完成一个研究报告、一个独立网站或一个创意视频。未来的竞争，不是人与AI的竞争，而是“掌握了AI的人”与“没掌握AI的人”的竞争。

步骤三：死守“人性的护城河”

去体验真实的生活，去和不同背景的人深度交流，去大自然中感受风、光与温度。去阅读那些不考的经典著作，去思考没有标准答案的伦理与道德。

人类特有的同理心、直觉、审美、物理世界的交互能力，以及在迷茫中坚守信仰的感性，是AI在很长一段时间里无法跨越的终极护城河。

小结

后天，当千万名考生走出考场，迎接他们的将是一个与他们父母辈完全不同的世界。

这个世界充满了不确定性，甚至有些冰冷。

但请不要害怕。高考从未保证过我们一生的无忧，它只是给了我们一次证明自己可以“为了梦想竭尽全力”的机会。

今天的高考，我们不为那张逐渐贬值的文凭而战，我们为那个在重压下历经淬炼、拥有无限自驱力、随时准备重塑自我的自己而战。

祝所有2026届考生，考场得意，金榜题名；更祝你们，在人生的下一场AI风暴中，乘风破浪。

资料链接：https://www.researchgate.net/publication/349707487_Skill_levels_and_gains_in_university_STEM_education_in_China_India_Russia_and_the_United_States

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

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

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

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.