2026-05-03 07:08:15
本文永久链接 – https://tonybai.com/2026/05/03/flask-creator-pi-author-on-ai-coding-the-cruel-truth
大家好，我是Tony Bai。
过去的一年，我们见证了 AI 工具从“玩具”到“神器”的进化。从 Copilot 到 Claude Code，再到OpenClaw和Hermes等，整个技术圈都沉浸在一种“效率无限提升”的乐观主义狂欢之中。
但就在前几天，两位在开源世界里的大神——Flask 框架之父 Armin Ronacher 和 Pi (OpenClaw的agent runtime) 的创造者 Mario Zechner——进行了一场极其深刻、甚至有些“悲观”的对话。
他们没有去鼓吹 AI 带来了多高的效率，反而用一种极其冷静的视角，对当下这场“AI 狂欢”提出了拷问。这场对话，值得我们每一个身处其中的技术人，暂停手中飞速生成的代码，静下心来，一字一句地读完。
故事的开端，源于两位大神对 AI 的“第一印象”。
作为 Flask 的作者，Armin Ronacher 最初对 Copilot 的出现充满了警惕。他做的第一件事，就是去“钓鱼执法”，诱导 Copilot 复现那段著名的《雷神之锤III》中的快速平方根倒数算法，并发现 AI 果然在没有正确署名的情况下，吐出了 GPL 协议的代码。
而 Mario Zechner，这位同样拥有数十年开发经验的老炮，则是在厌倦了 Claude Code 越来越臃肿、越来越不可控之后，愤然决定自己动手，从零打造一个极简的编码智能体——Pi。
两位大神殊途同归，最终都成了 AI Agent 的重度用户。但他们发现，这场看似美好的“生产力革命”，正在把我们引向一个危险的深渊。
访谈中，Mario 提出了一个极其深刻的洞见：AI Agent 正在用“无痛”的方式，批量制造“屎山（Slop）”。
“人类是有痛感的。当你写了一段极其恶心的代码，你会感到痛苦。为了避免这种痛苦，你会花时间去重构，去梳理架构。痛苦，逼着人类去学习和进化。”
“但 Agent 呢？它是一台没有感情的打字机。它可以在几分钟内生成两万行代码。如果其中包含了一个微小的设计缺陷，它不会感到痛苦。相反，它会在你看不见的地方，将这个缺陷以成百上千倍的速度复利式地放大。”
Armin 对此深有同感。他把 AI 生成的代码，比作一个“涌现式状态机（Emergence State Machine）”。
“我们曾经重构过一个游戏的撮合系统，里面有 16 个布尔值标志位，理论上只有 6 个有效状态，但实际上却能组合出几何级爆炸的可能状态。AI 生成的代码就是这样，它为了处理各种异常，会不断地添加 catch 和默认值，让你的系统在不知不觉中，变得比人类手写的屎山还要复杂。”
更可怕的是，这些屎山一旦形成，连 AI 自己都救不了。因为当代码库膨胀到一定程度后，Agent 极其有限的上下文窗口，让它只能基于局部的视野（Local View）去做决策，最终在“修复”的过程中，制造出更多的垃圾。
在这场对话中，Armin 提出了一个极其反直觉、却又极具哲学思辨的观点：一个好的工程系统，需要被刻意地注入“摩擦力（Friction）”。
“在最好的工程团队里，为了让服务更成熟，你需要定义 SLO，你需要做 Code Review，你需要让架构委员会审批。这些看似‘官僚’的流程，其实是在故意减慢速度，逼着你去思考：我真的需要做这个改动吗？”
“但现在，所有人都想把这些‘摩擦力’去掉，好让 Agent 能更自主地运行。结果就是，我们失去了刹车。”
这个观点，完美地解释了为什么软件质量正在全面倒退。
当一个产品经理、甚至市场部员工，都能用 AI 在几分钟内生成一个看似可行的功能并提交 PR 时，整个工程的“质检防线”就被彻底冲垮了。
对话中，两位大神还深入探讨了当前 Agent 工具链的两种路线之争：MCP（模型上下文协议） vs CLI（命令行界面）。
Armin 认为，MCP 在企业级的 Auth（认证） 场景下有其价值，但在“组合性（Composability）”上却是一场灾难。
“MCP 就像是给 AI 一堆独立的、互不相关的玩具。而 CLI，给了 AI 一整套乐高积木和管道。当 AI 拿到 curl、grep、sort 这些工具时，它能自发地创造出你从未预料到的、极其强大的工作流。”
Mario 对此完全赞同，并补充道，Pi 的核心哲学，就是将一切能力都封装成 CLI 工具，然后通过“自修改”的方式，让 AI 自己去扩展自己的工具集。
“Pi 没有 MCP 支持，但用户可以自己教 Pi 去构建一个 MCP Server。Pi 本身，是可以自我进化的。”
在这场充满悲观与反思的对话中，两位大神依然为我们这些身处其中的人类工程师，指明了一条生路。
第一，夺回“说不”的权力。
Mario：“一个好的工程师，是那个经常说‘不’的人。这能让系统的复杂性保持在最低。但当你用 Agent 时，你会忍不住说‘是、是、是’，因为你不需要自己打字了。”
第二，从“代码编写者”进化为“代码品鉴师”。
Armin：“我不再享受‘把一个函数写得天衣无缝’的快感了。因为机器能做得更好。我的乐趣，转移到了‘理解整个系统’上。因为在‘雕琢细节’这件事上，我们已经失去了杠杆。”
第三，拥抱“慢思考”与“主动重构”。
Mario：“我会有意地放慢速度。我强迫自己去重构那些 AI 生成的代码，因为只有通过重构，我才能真正理解系统的脉络，重新找回那种‘人剑合一’的感觉。”
AI 正在剥夺我们“感受痛苦”的权利，而这，恰恰是我们作为人类工程师最宝贵的财富。
这场持续了一个多小时的对话，没有给出任何关于“如何写 Prompt”的答案。
但这两位穿越了数个技术周期的智者，用他们的人生经验，为我们揭示了 AI 这场史无前例的巨浪中，唯一能抓住的几块礁石：
机器可以写下每一行代码，但只有你，才能为这堆代码注入灵魂，并为它的最终结果，承担责任。
资料链接：https://www.youtube.com/watch?v=n5f51gtuGHE
今日互动探讨：
在使用 AI 编程后，你是否也像 Armin Ronacher 一样，感觉失去了那种“雕琢代码”的快感？在 AI 时代，你认为“故意注入摩擦力”的架构哲学，是开倒车，还是真正的远见？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-02 07:48:52
本文永久链接 – https://tonybai.com/2026/05/02/from-vibe-coding-to-agentic-engineering-karpathy-survival-guide
大家好，我是Tony Bai。
过去的一年，我们中的许多人，都经历了一种全新的、令人上瘾的编码体验，它被前特斯拉 AI 总监 Andrej Karpathy 戏称为 “Vibe-Coding（氛围编码）”。
我们不再逐行挣扎，而是凭着“感觉”，用模糊的自然语言指挥 AI，看着代码在屏幕上如瀑布般涌现。
这种“氛围感”，让编程的门槛被前所未有地夷为平地。但它也像一剂甜蜜的毒药，正在麻痹我们的工程知觉。
就在前几天，在红杉资本组织的 AI Ascent 2026 顶级峰会上，Karpathy 再次发声，为这场狂欢踩下了“刹车”。
他警告说，如果我们仅仅停留在“Vibe-Coding”的舒适区，我们将很快被时代淘汰。真正的未来，属于一种更严谨、更具工程化思维的全新范式——“Agentic Engineering（智能体工程）”。
今天，我们就来深度拆解 Karpathy 的这场最新演讲，看看从“Vibe-Coding”到“Agentic Engineering”，到底隔着怎样一条鸿沟，以及我们作为普通开发者，该如何掌握这套 AI 时代的终极“生存法则”。
Karpathy 在演讲中，清晰地描绘了两种截然不同的开发者画像。
第一种：Vibe Coder（氛围感编码者）
这是 AI 时代的“新手村玩家”。他们是 AI 生成代码的“消费者”。
他们的典型特征是：
- 对 AI 有着近乎“盲目”的信任。
- 将 AI 视为一个能解决一切问题的“黑盒许愿池”。
- 当 AI 犯错时，他们无法理解错误的根源，只能通过不断调整 Prompt 来“玄学 Debug”。
Karpathy 坦言，自从去年 12 月大模型能力发生“突变”后，他自己也曾沉迷于 Vibe-Coding。
“我只是不停地要求更多，而它（AI）输出的总是对的。我记不清我上一次纠正它是什么时候了。”
但这种“顺滑”的体验，恰恰是最危险的。
第二种：Agentic Engineer（智能体工程师）
这是 AI 时代的“高阶玩家”。他们是 AI Agent 的“指挥家”和“架构师”。
他们深刻理解 AI 的能力边界，并将 AI 视为一个强大但不稳定、需要被严格约束的“实习生”。
他们的核心工作，不再是“写代码”，而是：
Karpathy 总结道：
“Vibe-Coding 是在提升所有人的下限。而 Agentic Engineering，是在探索质量与效率的上限。”
从“Vibe Coder”进化为“Agentic Engineer”的第一步，是彻底放弃对 AI“无所不能”的幻想，深刻理解其“参差不齐的智能（Jagged Intelligence）”。
Karpathy 提出了一个经典的“卡帕西难题”：
“为什么 Claude Opus 4.7 能够在一瞬间重构十万行代码、发现 0-day 漏洞，但当你问它‘我想到 50 米外的洗车店洗车，我该开车还是走路？’时，它却会一本正经地告诉你应该走路？”
这种“时而天才，时而智障”的诡异表现，源于 AI 的训练机制。大模型的能力，高度依赖于“可验证性（Verifiability）”和“数据分布（Data Distribution）”。
作为一个智能体工程师，你必须像一个经验丰富的老猎人，清晰地知道你面前这头“猛兽”的狩猎范围。在它擅长的领域，大胆授权；在它不擅长的领域，寸步不让。
当 AI 接管了“How（如何实现）”之后，人类工程师的唯一护城河，就只剩下了“What（做什么）”和“Why（为什么做）”。
Karpathy 举了他自己写的 MenuGen 项目的例子。AI 生成了一个版本，试图用 email 地址去关联 Stripe 支付和 Google 登录。
“这是一个极其愚蠢的错误。因为用户完全可能用不同的邮箱。但 AI 不知道。这种判断力、这种对业务的审美（Taste），是 AI 暂时无法拥有的。”
停止在代码的细枝末节上与 AI 较劲。把你的时间，投入到更高维度的抽象工作中去——梳理业务逻辑、定义系统边界、规划数据流转。
AI 可以帮你画出每一块砖，但只有你，才能画出整座教堂的蓝图。
这是 Karpathy 在整场演讲中，提出的最核心、也最具有哲学思辨的一条法则。
“最近有一条推文让我非常震撼：你可以外包你的思考，但你无法外包你的理解（You can outsource your thinking but you can’t outsource your understanding）。”
AI 可以替你思考如何用一个高效的算法来解决问题，它可以替你思考如何组织代码的结构。
但它无法替你理解这个系统为何而建，无法替你理解你的用户真实的需求，更无法替你理解一个微小的改动可能对整个系统带来的长远影响。
把 AI 当作一个无限算力的“外部大脑”，去帮你探索、试错、执行。但最终，所有的信息都必须回流到你自己的“内部大脑”中，由你来完成最关键的“理解”与“决策”闭环。
你，才是系统的最终责任人。
在演讲的结尾，Karpathy 描绘了一幅极其遥远、甚至有些科幻的未来图景。
他认为，我们正在从“经典计算机”时代，重新回归到上世纪 50 年代那个“神经计算机”与“图灵机”分道扬镳的历史岔路口。
“未来，神经网络可能会成为‘主处理器’，而我们现在的 CPU，则降级为处理确定性任务的‘协处理器’。”
在这个被他称为“软件 3.0”的时代，软件的形态将被彻底重塑。我们将不再编写传统的 UI 界面，而是直接将摄像头采集的原始视频流，喂给一个巨大的神经网络，由它通过扩散模型（Diffusion），实时地为你“画”出一个独一无二的界面。
我们作为工程师的角色，将变成定义这个世界的“传感器（Sensors）”和“执行器（Actuators）”，并为 Agent Native（智能体原生）的世界，重写所有的基础设施。
Andrej Karpathy 的这场演讲，没有给出任何一行代码，却比任何一篇技术教程都更令人震撼。
他用一种极其诚实、甚至有些残酷的方式，为我们揭示了从“Vibe-Coding”到“Agentic Engineering”的进化路径。
AI 正在用它的“参差不齐”，逼迫我们放弃对“编码”这项体力劳动的迷恋，转而去拥抱那些更高级、更接近本质的人类智慧——理解、品味、与判断。
“你可以外包你的思考，但你无法外包你的理解。”
这或许是对 AI 时代，我们这些“数字工匠”最深刻、也最充满希望的生存箴言。
资料链接：https://www.youtube.com/watch?v=96jN2OCOfLs
今日互动探讨：
听完 Karpathy 的分享，你认为自己目前更接近于一个“Vibe Coder”还是“Agentic Engineer”？你认为“你可以外包思考，但无法外包理解”这句话，是对的，还是错的？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-05-01 07:46:25
本文永久链接 – https://tonybai.com/2026/05/01/open-source-civil-war-bun-founder-predicts-ban-on-human-contributions
大家好，我是Tony Bai。
过去的一年，AI 编程的浪潮席卷了整个技术圈。但在这片繁荣之下，一场关于“开源精神与 AI 伦理”的深刻裂痕，正在悄然扩大。
就在前几天，这场裂痕，以一种极其戏剧性的方式，被彻底引爆了。
事件的导火索，来自当红 JavaScript 运行时 Bun 的一则看似平平无奇的技术更新：Bun 团队 fork 了 Zig 语言的编译器，通过引入并行分析等优化，将自己的调试构建速度提升了 4 倍。
但真正引爆全网的，是 Bun 官方账号在 X 平台发布的一条补充说明：
“我们目前不打算将这些改进提交回上游（Zig 社区），因为 Zig 有一条严格的禁令：禁止任何由 LLM（大模型）创作的贡献。”
这条推文，像一根火柴，瞬间点燃了整个开源社区的火药桶。
Bun 的创始人 Jarred Sumner 更是亲自下场，抛出了一个极其激进、甚至有些“疯狂”的预言：
“我预感开源社区会走向另一个极端：未来将不再允许人类贡献代码。人类写的垃圾代码（Slop），将成为 2025 和 2026 年的怀旧遗物。”
一边是 Zig 社区对 AI 的严防死守，另一边是 Bun 创始人对“纯 AI 开发”的狂热鼓吹。这场突如其来的“内战”，引来了包括网景创始人 Marc Andreessen、开源运动领袖 Eric S. Raymond 等一众硅谷大佬的围观和站队。
今天，我们就来复盘这场神仙打架，看看在这场关于“Pro-AI”与“Anti-AI”的论战背后，到底隐藏着怎样的技术哲学、利益博弈与生存法则。
Zig 社区为什么要禁止 AI 贡献？
这背后，是传统开源精神对“贡献”二字的捍卫。在他们看来，一个 Pull Request 不仅仅是一段代码，它更代表了贡献者投入的心血、思考、以及对社区文化的认同。
而由 AI 生成的、未经深入理解的“垃圾代码（Slop）”，正在无情地摧毁这种信任契约，将 Code Review 的沉重负担，转嫁给那些用爱发电的维护者。
但 Bun 的创始人 Jarred Sumner 显然不这么认为。他坚信，AI 将彻底重塑生产关系。
在他的设想中，未来的开源协作将是这样的：
“和人类不同，AI 会严格遵守你的代码风格指南，并在几分钟内完成你提出的每一个修改。它们会编写详尽的测试和文档。它们会研究竞争对手的实现方案。它们会不知疲倦地进行迭代，直到通过所有第三方的一致性测试。”
在这场辩论中，著名浏览器 Ladybird 的作者 Andreas Kling，给出了一个更宏大、也更令人不安的预言：
“我的猜测是，开源社区将分裂成两个阵营：Pro-AI（亲 AI）和 Anti-AI（反 AI）。
1. Pro-AI 阵营的项目，将以惊人的速度超越 Anti-AI 阵营。
2. 那些被 Anti-AI 项目拖慢了脚步的 Pro-AI 开发者，最终会选择 fork 或者重写这些项目。”
Bun 对 Zig 的这次 fork，似乎正是这个预言的第一次应验。
这场论战迅速升级，引来了各路神仙的围观。
传奇投资人、a16z 联合创始人 Marc Andreessen，用一个简单的“+1”表情，旗帜鲜明地站在了 Jarred Sumner 的“未来无人类”阵营。
开源运动的“教父级”人物、《大教堂与集市》的作者 Eric S. Raymond，也对“Anti-AI”派发起了无情的嘲讽：
“我发现了一个规律。在开源社区里，那些反对 AI 的人，和之前被‘Woke Mind Virus’（觉醒文化病毒）完全俘获的，是同一批人。他们是白痴。 这是我作为创始人的肺腑之言。”
当然，也有大量的资深开发者对 Jarred 的观点嗤之以鼻。
一名游戏引擎开发者直接发问：
“在保持高质量标准的前提下，‘超越’的证据在哪里？还是说你认为质量对于客户来说已经不重要了？”
Gary Marcus（著名 AI 评论家）更是引用了一句名言来讽刺 AI 的不可靠：
“当你不了解一个主题时，AI 看起来最令人印象深刻。一旦你对某个领域了如指掌，你就会发现它说的全是废话。”
这场争论的背后，其实隐藏着一个更深层次的权力问题：当 AI 能够生成 90% 的代码时，谁来定义剩下的 10% 的“质量”？
Bun 创始人 Jarred Sumner 的答案是：Agent。
他认为，未来的代码质量将由自动化的测试、严格的类型系统和不知疲倦的 Agent 来保证，人类的角色将被无限削弱。
但反对者认为，这是一种极其天真的“技术幻想”。
Darren Shepherd（Rancher 联合创始人）在评论中指出：
“所有迹象都表明，未来由 AI 辅助生成的代码，其质量将远高于纯人类编写和维护的代码。”
这场辩论最终走向了一个无法调和的哲学分歧：
作为身处一线的工程师，我们不必陷入这种非黑即白的“信仰之争”。
无论是 Pro-AI 还是 Anti-AI，在这场混乱的辩论中，我们依然能找到几条极其清晰的生存法则。
第一，警惕“立场先行”，回归“工程现实”。
无论是 Bun 还是 Zig，他们的选择，都是基于自身项目所处的特定工程阶段和社区文化。
你的项目，更像 Zig，还是更像 Bun？这个问题，比单纯地喊“AI 万岁”或“AI 垃圾”要有意义得多。
第二，不要成为“AI 的传声筒”，要做“AI 的驾驭者”。
即使在 Pro-AI 阵营内部，大佬们也普遍承认一个事实：无脑地让 AI “Vibe-Coding”，结果就是灾难。
你需要为 AI 构建强大的“护栏（Guardrails）”，你需要设计精密的“评测体系（Evals）”，你需要像一个真正的架构师一样，去定义系统的边界和验收标准。
AI 正在把开发者的能力，从“写代码”，向上推到“设计系统”和“定义规则”。
第三，拥抱“阵营分裂”的未来。
Andreas Kling 的预言，大概率会成为现实。
未来的开源世界，将不再是一个“其乐融融”的大家庭。它会分裂成：
* Anti-AI 社区：坚守人类智慧的最后防线，可能会变得更加封闭、审核更严，成为“小而美”的精英俱乐部。
* Pro-AI 社区：以惊人的速度进行迭代和演进，可能会涌现出大量创新，但同时也伴随着巨大的混乱和泡沫。
作为开发者，你需要提前思考：你的价值观和职业规划，更适合哪一个“宇宙”？
Bun 与 Zig 的这次“决裂”，可能只是未来十年开源社区大分裂的第一次预演。
当 Jarred Sumner 喊出“未来将禁止人类贡献”时，他开启了一场极其危险的“社会实验”。这背后，是资本对“效率”的无限渴求，是对“开源社区协作成本”的极度不耐烦。
而 Zig 社区的坚守，则是对“人类智慧不可替代性”的最后捍卫。
这场战争，没有对错，只有选择。
但无论你选择哪条路，请记住：工具终将过时，但工程的智慧与审美的品味，永不褪色。
资料链接：https://x.com/i/trending/2048470411793563936
今日互动探讨：
你更认同 Bun 的“Pro-AI”哲学，还是 Zig 的“Anti-AI”哲学？在你的日常工作中，是否也曾因为“AI 生成的代码质量”问题，而与同事发生过争执？
欢迎在评论区分享你的站队和理由！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-30 07:20:36
本文永久链接 – https://tonybai.com/2026/04/30/ghostty-creator-leads-github-exodus-cto-apology-go-fix
大家好，我是Tony Bai。
在程序员的江湖里，GitHub 从来不仅仅是一个代码托管平台。它是开源精神的麦加，是数千万开发者的“赛博故乡”，是这个行业赖以运转的、最坚实的“基础设施”。
但就在近几个月，这座我们无比信赖的“圣城”，似乎正在走向“崩塌”。
4 月 28 日，Github 的第1299位用户，在自己的推特与博客上发表了一篇极其悲伤的“分手信”，标题是：《Ghostty Is Leaving GitHub》（Ghostty 正在离开 GitHub）。
这位用户，不是别人，正是 HashiCorp 的联合创始人、一手缔造了 Terraform、Vagrant、Vault、Consul 等一系列云原生和 Devops 神器的“教父级”人物——Mitchell Hashimoto。而 Ghostty，正是他当下倾注心血的、备受期待的新一代终端项目。
他在这封信中，用一种近乎“心碎”的口吻写道：
“写下这些让我感到莫名的悲伤。我从 2008 年 2 月开始使用 GitHub，至今已超过 18 年，横跨了我半个人生。……我曾深爱着 GitHub，胜过一个人应该去爱一个东西。但现在，我受够了。18 年了，我得走了。”
是什么，让这位曾经的“ GitHub骨灰粉”毅然决然地带着自己的“亲儿子”项目“出走”呢？
答案简单得令人窒息：GitHub 正在变得越来越不可用。
“在过去的一个月里，我用日记记录了每一次 GitHub 宕机对我工作的影响。几乎每一天，旁边都画着一个‘X’。就在我写下这些文字的时候，GitHub Actions 又挂了 2 个小时。……如果一个平台每天都要瘫痪几个小时，那它就不再是一个适合严肃工作的地方。”
Mitchell 的这封“分手信”，像一颗炸弹，瞬间引爆了整个技术圈。
就在文章发布的几个小时后，GitHub 的 CTO Vlad Fedorov 紧急发表了一篇官方博客，标题同样沉重：《An update on GitHub availability》（关于 GitHub 可用性的更新）。
在这篇近乎“道歉信”的回应中，GitHub 官方不仅承认了问题的严重性，更罕见地揭示了这场“可用性雪崩”背后的真正罪魁祸首，以及他们正在秘密进行的“技术自救”——其中，Go 语言扮演了至关重要的“救火队长”角色。
今天，就让我们来复盘一下这场由“分手信”引发的技术公案。
GitHub 到底怎么了？
在官方的回应中，CTO Vlad Fedorov 给我们展示了一张极其恐怖的增长曲线图：“Record Acceleration”（创纪录的加速）。
自 2025 年下半年以来，随着 AI Agent（智能体）编程工作流的急剧加速，GitHub 的各项核心指标都呈现出近乎垂直的指数级增长：
GitHub 官方坦言：
“这种指数级的增长，不是只对一个系统造成压力。一个 PR 会触及 Git 存储、合并检查、分支保护、GitHub Actions、搜索、通知、权限、API、后台任务、缓存和数据库。在巨大的规模下，微小的低效会被无限放大。”
队列加深、缓存击穿、索引落后……这些经典的分布式系统“并发症”，在 AI 制造的流量洪峰面前，被彻底引爆了。
Mitchell Hashimoto 的“出走”，只不过是压垮骆驼的最后一根稻草。
面对这场史无前例的“流量洪水”，GitHub 的工程师们正在进行一场惊心动魄的“架构自救”。
在官方博客的What we’re doing一小节中，我们看到了一个熟悉的身影——Go 语言。
“我们加速了将性能或规模敏感的代码，从 Ruby 单体应用中迁移到 Go 语言的过程。”
这短短的一句话，信息量巨大。它揭示了 GitHub 这座“上古神殿”最核心的技术债之一：一些庞大、沉重、且难以扩展的 Ruby 单体应用。
在过去，当我们需要提升性能时，可能会选择更深入地优化 Ruby 代码，或者在前面加更多的缓存。
但在 AI 时代，这种“小修小补”可能已经毫无意义了。面对 10 倍甚至 30 倍的流量增长预期，唯一的出路，就是对系统进行“外科手术式”的重构。
为什么选择 Go 来“救火”？
因为 Go 语言几乎是为这种“救火”场景量身定制的：
我们可以想象，在 GitHub 内部，正有无数个由 Go 语言编写的、小而美的微服务，像一支支训练有素的“消防队”，正在冲入火场，小心翼翼地从那个庞大的 Ruby 巨人身上，一块块地切下那些已经“燃烧”的性能瓶颈模块（如 Webhooks、认证授权、Git 操作等）。
Go 语言，正在成为 GitHub 这艘巨轮在 AI 洪流中，避免沉没的“压舱石”。
Mitchell 的“分手信”，之所以能在社区引发如此巨大的共鸣，不仅仅是因为他的技术地位，更在于信中那份令人动容的“爱之深，责之切”。
他坦言，自己 20 岁时创建 Vagrant 这个成名作，很大程度上就是为了能获得一份在 GitHub 的工作。
“GitHub 是我的梦想。那里的工程师令人难以置信，产品令人难以置信。在过去的 18 年里，我每天都在呼吸着它的空气。”
“当我的感情经历挫折时，我把自己沉浸在 GitHub 的开源世界里；当我在大学里通宵时，我会在凌晨 4 点偷偷提交一个 commit；甚至在我的蜜月期间，我都会趁着妻子还在睡觉时，打开 GitHub。”
但正是这份深沉的爱，让 GitHub 的每一次宕机，都像一把刀子，刺在他的心上。
“这对我来说是私人的。我对 GitHub 的爱，超过了一个人应该对一个东西的爱。所以我对它感到愤怒。”
在文章的最后，他给所有“Git 是分布式的，你怕什么”的言论，给出了最沉重的回击：
“问题不在于 Git，而在于我们围绕它建立的、赖以为生的基础设施：Issues, PRs, Actions……如果它每天都要让你停工几个小时，那它就不再是一个适合严肃工作的地方。”
Mitchell Hashimoto 的“出走”，和 GitHub 官方的“道歉”，共同为我们揭示了 AI 时代一个极其深刻的现实：
当生产力工具的效率被提升 10 倍、100 倍时，它对底层基础设施稳定性的要求，也将被以同样指数级的规模放大。
我们曾经以为像水和电一样“理所当然”的 GitHub，正在成为整个行业发展的瓶颈。
这场危机，对 GitHub 来说是“生死存亡”的挑战，但对我们这些身处其中的技术人来说，又何尝不是一次“机遇”？
它告诉我们：
旧神正在踉跄，新王尚未诞生。
在这场由 AI 引发的、史无前例的“基础设施大迁徙”中，你，准备好你的船票了吗？
资料链接：
今日互动探讨：
在过去几个月里，你是否也曾被 GitHub 的频繁宕机所困扰？你认为 GitHub 这次“中年危机”的根源，真的是 AI 吗？还是其自身技术债的必然爆发？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-29 08:16:43
本文永久链接 – https://tonybai.com/2026/04/29/go-1-27-default-simd-for-amd64-portable-simd-proposal
大家好，我是Tony Bai。
过去十年，Go 语言以其惊人的简洁和强大的并发能力，席卷了整个云原生领域。但在这片繁荣之下，一个尴尬的“阿喀琉斯之踵”，始终困扰着所有追求极致性能的 Gopher：
Go 语言，无法像 C++ 或 Rust 那样，原生且优雅地利用现代 CPU 的 SIMD（单指令多数据流）能力。
当你需要处理海量数据（如向量计算、图像处理、加解密）时，手写 Go 代码的性能，往往会被隔壁 C++/Rust 的 SIMD 优化版本，拉开数倍甚至数十倍的差距。为了榨干 CPU 的最后一滴性能，我们不得不去手写那些极其晦涩、难以维护、且无法被 GC 优雅调度的 Go 汇编。
但就在今年年初发布的Go 1.26版本中，这场长达十年的“性能怨念”，终于迎来了终结的曙光。Go 1.26以实验特性形式在AMD64架构上提供了SIMD的支持。
近期，Go 核心团队在官方 GitHub 仓库中，又密集地抛出了一系列重磅提案（#78902, #78979等）。这些提案不仅宣告了在 Go 1.26 中实验性加入的 SIMD 功能大获成功，更进一步宣布： 在即将到来的 Go 1.27 中，simd/archsimd 包将默认开启！同时，一个早已规划好的、架构无关的“可移植（Portable）”SIMD API 也已正式提案！
Go 团队试图用一种极其“Go-like”的优雅方式，为我们揭开 SIMD 这头性能怪兽的封印。
今天，就让我们来拆解这场 Go 语言的“性能下半场”革命，看看 Go 团队到底在下一盘怎样的大棋。
要理解 Go 的 SIMD 设计，我们必须先看懂官方在 Issue #73787 中提出的核心哲学——“两层模型（Two-level approach）”。
Go 团队清醒地认识到，SIMD 的世界充满了矛盾：
如何调和这个矛盾？Go 团队从标准库中 syscall 和 os 包的关系里，找到了灵感。
第一层：simd/archsimd —— 你的“syscall”
这一层，是架构绑定的、低级别的。它将 CPU 的 SIMD 指令，近乎一对一地封装成 Go 的函数。比如 VPADDD 指令，就对应着 Uint32x4.Add()。
这一层追求的是极致的表达力和与硬件的零距离。它就是为那些需要手写汇编的“性能狂人”准备的。如果你想调用某个 AVX512 的独有指令，来这里就对了。
第二层：simd —— 你的“os”
这一层，将是架构无关的、高级别的。它会定义一套通用的、不依赖特定向量宽度的向量类型（如 simd.Float32s），以及一套通用的操作（如 Add, Mul）。
当你写下 a.Add(b) 时，编译器会根据你当前的编译目标（GOARCH），自动将其翻译成最高效的底层 archsimd 指令。
这一层追求的是极致的可移植性和易用性。对于 99% 的开发者来说，你只需要和这一层打交道。
在 Go 1.26 的 GOEXPERIMENT=simd 实验成功后，Go 团队在 Issue #78979 中正式提案，将 simd/archsimd for AMD64 在 Go 1.27 中默认开启！
让我们来一睹这把“屠龙刀”的真容：
1. 强类型的向量定义
告别 unsafe.Pointer 和丑陋的字节数组！archsimd 为不同位宽和数据类型，定义了极其清晰的结构体：
// 128位，4个 uint32
type Uint32x4 struct { a0, a1, a2, a3 uint32 }
// 256位，8个 float32
type Float32x8 struct { /* ... */ }
2. 易于理解的方法链
所有的 SIMD 操作，都被设计成了易于阅读和链式调用的方法。注释里甚至贴心地标出了对应的汇编指令。
// Add each element of two vectors.
//
// Equivalent to x86 instruction VPADDD.
func (Uint32x4) Add(Uint32x4) Uint32x4
3. 抽象的掩码（Mask）类型
如何处理不同架构下千奇百怪的掩码，是 SIMD API 设计中最头疼的问题。Go 团队选择了用一个不透明的 Mask 类型来屏蔽底层差异，让编译器自己去选择最高效的实现（K-register 还是 Vector-register）。
如果说 archsimd 只是让 Go “追平”了 C++/Rust，那么 Issue #78902 中提出的高级 simd 包，则真正展现了 Go 语言的“野心”——在可移植性上，超越所有前辈。
在这个提案中，dr2chase 描绘了一个极其诱人的未来。你将可以这样写代码：
// 一个 inner product 示例
func ip(x, y []float32) float32 {
var a simd.Float32s // 注意！这里没有指定位宽！
var i int
// a.Len() 会在运行时自动返回当前 CPU 支持的最佳向量宽度
for i = 0; i < len(x)-a.Len()+1; i += a.Len() {
u := simd.LoadFloat32Slice(x[i : i+a.Len()])
v := simd.LoadFloat32Slice(y[i : i+a.Len()])
a = a.Add(u.Mul(v))
}
// ... 处理剩余的尾部数据
return sum(a) // 水平求和
}
sum函数在amd64平台的具体实现：
//go:build amd64
package main
import (
"simd"
"simd/archsimd"
)
func sum(x simd.Float32s) float32 {
switch a := x.ToArch().(type) {
case archsimd.Float32x8:
a = a.AddPairsGrouped(a)
a = a.AddPairsGrouped(a)
return a.GetLo().GetElem(0) + a.GetHi().GetElem(0)
case archsimd.Float32x16:
s := make([]float32, a.Len())
a.StoreSlice(s)
var r float32
for _, e := range s {
r += e
}
return r
case archsimd.Float32x4:
s := make([]float32, a.Len())
a.StoreSlice(s)
var r float32
for _, e := range s {
r += e
}
return r
}
panic("not a known type")
}
看懂了吗？
你只需要写一份代码，把它扔到一台只支持 AVX2 的机器上，a.Len() 会返回 8；把它扔到一台支持 AVX512 的机器上，a.Len() 会自动变成 16！
编译器会自动为你生成多个版本的代码，并在运行时动态选择最优路径。这彻底将开发者从“为不同 CPU 手写不同优化版本”的地狱中解放了出来。
在 Issue #73787 的评论区，一场关于 SIMD 函数命名哲学的“神仙打架”，精彩绝伦。
以 Ian Lance Taylor 为首的“专家派”认为：
“应该直接使用 VPADDD 这样的汇编指令名。这对于专家来说更友好，他们不需要在脑子里多做一次‘Go 风格名称’到‘Intel 手册名称’的翻译。”
以 Cherry Mui 为首的“可读性派”则坚决反对：
“代码的读者，远比代码的作者多。一个普通开发者能轻易猜出 Add 的意思，但绝对猜不出 VPADDD 是什么鬼。我们应该为读者优化，而不是为专家。”
最终，“可读性派”胜出。这也再次印证了 Go 语言一以贯之的设计哲学：明确性与可读性，永远高于一切。
SIMD 的正式入场，标志着 Go 语言的演进，正在进入一个全新的阶段。
如果说过去十年，Go 靠着“并发”和“简洁”赢得了云原生的上半场；那么在未来十年，它将靠着这套兼具“优雅可移植”与“极致性能”的 SIMD 工具链，去硬刚 AI、数据科学、游戏引擎这些性能深水区（如果后续新版本的 AI 学会了如何使用这些新增SIMD特性）。
Go 团队没有选择像 C++ 那样直接暴露几百个晦涩的 Intrinsics，也没有像 Rust 那样在稳定性和表达力之间反复纠结。
它用一套极其深思熟虑的“两层模型”，试图在这场性能的终局之战中，走出一条属于自己的路。
Go 1.27，将是我们所有 Gopher 重新认识这门语言的开始。
那扇通往极致性能的大门，正在被缓缓推开。你，准备好了吗？
资料链接：
今日互动探讨：
在你的日常工作中，有哪些场景是目前 Go 语言性能的瓶颈，让你极其渴望 SIMD 的加持？对于 Go 团队设计的这套“两层 SIMD API”，你是更看好它的“可移植性”还是“性能潜力”？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
