2026-05-04 06:39:16
本文永久链接 – https://tonybai.com/2026/05/04/the-ai-layoff-trap
大家好，我是Tony Bai。
过去的一年，AI 带来的“裁员恐慌”几乎席卷了整个科技行业。
今年 2 月，Jack Dorsey 的 Block 公司裁掉了近一半的员工，他直言不讳：“因为 AI 让很多岗位变得没必要了。”
Salesforce 用 AI 替换了 4000 名客服，Cognition 的 AI 程序员 Devin 让一个资深工程师能干五个人的活。
我们似乎正处在一场由 AI 引发的“效率革命”之中。管理者们为“降本增效”而欢呼，而我们这些打工人，则在瑟瑟发抖，担心自己的饭碗随时可能被一个看不见的 Agent 抢走。
但如果我今天告诉你，这场看似“零和博弈”的裁员狂潮，最终的结局可能不是“资本家赢，打工人输”，而是“所有人一起输”呢？
就在今年3月份，宾夕法尼亚大学和波士顿大学的两位学者，发布了一篇极其硬核、甚至有些惊悚的经济学论文——《The AI Layoff Trap》（AI 裁员陷阱）。
这篇论文用极其严密的数学模型，推演出一个令人脊背发凉的结论：
在充分竞争的市场中，所有理性的公司都会陷入一场疯狂的“自动化军备竞赛”。它们会不断地用 AI 裁掉员工，直到把整个市场的消费需求彻底摧毁，最终导致企业利润和员工收入双双崩溃。
今天，我们就来拆解一下这篇堪称“末日预言”的论文，看看我们是如何一步步，心甘情愿地跳进这个“双输”陷阱的。
论文的核心，建立在一个极其简单的经济学常识之上：被裁掉的员工，同时也是消费者。当他们失去收入，整个市场的购买力就会下降。
既然这个道理连街边卖菜的大妈都懂，为什么那些拥有无数顶尖经济学家的巨头公司，还会朝着“零需求”的悬崖狂奔呢？
答案，就在于一个经典的博弈论模型：囚徒困境。
论文构建了一个简单的竞争市场模型：
现在，让我们站在其中一家公司 CEO 的视角来做决策：
场景一：如果其他公司都选择不裁员
这时，如果我选择裁员，我能独享 AI 带来的全部成本降低（利润增加），而裁员导致的市场需求下降，则是由所有 N 家公司共同分摊的。
对我来说，裁员是绝对的最优策略。
场景二：如果其他公司都在疯狂裁员
这时，市场的总需求已经在萎缩了。如果我选择不裁员，我不仅要和他们一起承受市场萎缩的痛苦，还无法享受到 AI 带来的成本优势，我的市场份额会被迅速蚕食。
为了活下去，我唯一的选择就是：比他们裁得更狠。
看懂了吗？
无论竞争对手怎么做，对我自己来说，“最大化自动化（裁员）”永远是我的最优解（严格优势策略）。
而当市场上的每一家公司都这么想、都这么做的时候，整个系统就陷入了一场无法回头的“死亡螺旋”。下面这张图通过三组二维图，直观地展示了随着市场竞争者数量（Number of firms N）的增加，“过度自动化”的阴影面积（代表双输的程度）是如何变得越来越大、越来越黑的。
每家公司都做出了对自己最理性的决策，但最终却导致了一个对集体而言最坏的结果。 这就是“AI 裁员陷阱”的本质。
有人可能会乐观地认为：“没关系，只要 AI 的生产力足够高，它创造出的新财富，总能填补被裁员工的消费窟窿。”
但这篇论文给出了一个更令人绝望的推论：“更好”的 AI，不仅不会缓解这个问题，反而会加速毁灭的进程。
因为一个生产力更高的 AI，会给率先采用它的公司带来更大的“市场份额增益”的幻觉。这会进一步刺激所有公司，更疯狂地投入到这场军备竞赛中。
这就像《爱丽丝梦游仙境》里的“红色皇后效应”：你必须用尽全力奔跑，才能勉强留在原地。
最终，在所有人（包括 AI）都跑得气喘吁吁的均衡状态下，没有任何一家公司真正获得了额外的市场份额，整个系统只是以更快的速度，冲向了那个“零需求”的悬崖。
面对这个残酷的困境，社会上流传着几种看似美好的“解药”。但这篇论文用数学模型，一一戳破了它们的虚幻。
结论：完全无效。
因为 UBI 和资本税，作用的是企业的“利润水平”，而不是那个驱动裁员的“边际决策”。
只要用 AI 替换一个员工的成本，依然低于这个员工的工资，那么无论你给这家公司发多少补贴、或者收多少税，它裁员的动机都不会改变。
结论：部分有效，但无法根治。
让被裁的员工通过再培训，找到收入更高的工作，或者让他们持有公司股票，分享自动化带来的利润，确实能够部分地“回收”损失的消费需求。
但这篇论文指出，这个“回收”过程，永远无法 100% 抵消最初的损失。因为信息和资本的流动总有摩擦，只要存在一点点的“需求外溢（Demand Externality）”，那个驱使大家走向悬崖的魔鬼，就依然存在。
在排除了所有看似美好的“市场化”解决方案后，论文最终指向了一个极其古典、也极其具有争议的“终极武器”——庇古税（Pigouvian Tax）。
这个概念由经济学家阿瑟·庇古在 1920 年提出，它的核心思想是：对产生负外部性的行为，直接征税。
比如，一家工厂每排放一吨废气，对社会造成了 100 元的环境损失，那就对它征收 100 元的“排污税”。
在这篇论文的模型里，这个“税”被具体化为“自动化税（Automation Tax）”。
每当一家公司用 AI 替换掉一个人类岗位时，它就必须为这个“自动化行为”本身，支付一笔税。这笔税的金额，应该精确地等于这次裁员对整个社会造成的“消费需求损失”。
只有这样，才能将那个被企业“外部化”的社会成本，重新“内化”回它自己的决策模型中，从而逼迫它在裁员时，三思而后行。
当然，作者也承认，征收“自动化税”在现实中面临着巨大的挑战：如何精确计量？如何防止企业将生产转移到海外？
但他们强调，这是在理论上，唯一能够从根源上踩下“裁员军备竞赛”刹车的政策工具。
这篇论文，虽然是用经济学的语言写就，但它探讨的，却是我们每一个技术人都在亲身参与和塑造的未来。
它像一面镜子，照出了我们在追求“技术最优解”时的认知盲区。
我们痴迷于用 AI Agent 替换掉客服、用 AI Coder 替换掉初级程序员，我们为每一次“降本增效”的成功而欢呼。但我们很少去想，当这些被我们亲手“优化”掉的人，失去消费能力时，我们亲手构建的商业大厦，地基又在哪里？
这篇论文的价值，不在于给出了一个完美的答案，而在于它提出了一个更高维度的问题：
当“个体理性”与“集体理性”发生冲突时，我们作为系统的构建者，应该扮演怎样的角色？
是继续蒙眼狂奔，加速这场“双输”的游戏？
还是停下来，去思考如何从架构层面，引入那些能够平衡“效率”与“公平”的、更具人文关怀的“新规则”？
这其实已经超出经济学问题范畴，更像是是一个深刻的“架构伦理”问题了。
资料链接：https://arxiv.org/abs/2603.20617
今日互动探讨：
看完这篇论文的推演，你是否也对 AI 的未来感到一丝寒意？你认为“自动化税”是一个可行的方案，还是一个乌托邦式的幻想？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
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. 版权所有.
