“在 BOC 程序中，数据是共享的，但每个行为对数据拥有独特的时间所有权，从而无需通过锁来协调访问。对于 Python 程序员来说，这带来了诸多好处。行为通过装饰函数来实现，从程序员的角度看，这些函数的使用方式与普通函数无异。更重要的是，程序员的任务从解决并发数据访问问题转变为通过函数组织数据流。由此生成的程序更易于理解、更易于维护、更易于扩展，并且能够充分利用多核性能，因为可以高效地调度行为在多个进程中运行。”
它的全名是 Behavior-Oriented Concurrency in Python，核心目标是让程序员把注意力转移到有哪些行为要发生、这些行为依赖哪些数据、数据如何在行为之间流动这样的问题上，降低并发编程的难度。官网把它概括为一种适合 Python 的并发/并行新范式：让每个行为在某段时间内独占它需要的数据，从而减少手动协调共享数据的负担。
这套协议叫 MRC（Multipath Reliable Connection，多路径可靠连接），由 OpenAI 联合 AMD、博通、英特尔、微软、英伟达共同开发，通过 OCP（开放计算项目，业内最大的开源硬件标准组织）开放给全行业。AMD、博通、微软、英伟达同步发了配套博文。
训练大模型，几万到十几万张 GPU 要保持步调一致。一次训练步可能涉及几百万次数据传输，只要有一笔晚到，所有 GPU 都得干等。集群越大，链路抖动和故障越频繁。
传统网络的麻烦：一条链路挂了，整个训练任务可能崩掉，得回到上一个检查点重跑；交换机重新算路由要花好几秒甚至几十秒。OpenAI 在搭 Stargate（其大型算力基础设施项目）这种规模的集群时，遇到的第一个瓶颈就是网络。
过去一笔传输只走一条路径，MRC 改成把数据包拆散，同时分头走几百条路径，目的地再按内存地址重新拼起来。
链路出问题，微秒级就能绕开，不需要交换机重算路由表。OpenAI 还把动态路由协议(BGP)整个砍掉,改用 SRv6 源路由:发送方直接指定每个包走哪条路,交换机退化成"无脑"转发器,故障面大幅缩小。
网络结构因此简化。原本要 3 到 4 层交换机才能连起十几万张 GPU,MRC 的多平面设计 2 层就够,功耗、成本、故障点全降。
MRC 已经部署在 OpenAI 所有最大的英伟达 GB200 超算上,包括 Stargate 在德州 Abilene 与甲骨文合建的站点,以及微软 Fairwater 数据中心。多个 OpenAI 模型用它训练出来。
最直观的例子:最近一次前沿模型训练(服务 ChatGPT 和 Codex)期间,团队重启了 4 台核心交换机,不需要跟训练团队协调;每分钟还有多次链路抖动,对训练任务也没有可测量的影响。换以前,这种事故足以让整个任务崩溃。
AI 时代的算力竞赛已不再是单纯的晶体管缩减游戏，而是一场关于制程、封装、内存与散热的系统级集成战争。台积电的路线图揭示了一个事实：算力增长的本质是物理系统的规模化堆叠。
所有的 AI 魔法，底层都是极度沉重的物理系统。
台积电最新的技术路线图释放了一个很冷酷的信号：过去那种靠挤压晶体管尺寸来换取性能的“节点缩放”时代正在瓦解。现在的竞争维度变了，不再是比谁的芯片更聪明，而是比谁能把整个算力系统造出来。
有观点认为，AI 正在把半导体推回权力的中心。到 2030 年，HPC 和 AI 业务将占据半导体市场的半壁江山。这种增长不是波浪式的周期波动，而是结构性的跃迁。
制程的逻辑正在分化。像 A13 这种节点，追求的是经济上的明智，通过保持设计兼容来降低客户迁移 IP 的成本；而像 A16 这种节点，则是为了解决 AI 芯片由于电流密度过大带来的电源完整性问题，通过背面供电技术把电源和信号线分离开。这就像是在拥挤的城市里，不再只是盖更高的大楼，而是开始修地下供电管网。
更值得注意的是，算力的增长引擎已经转移到了封装层。CoWoS、SoIC 和 HBM 的组合，让性能的提升不再依赖单一芯片，而是依赖“系统封装规模”。当单颗芯片做不动时，就往里面堆更多的 HBM，甚至直接搞晶圆级系统（SoW）。
有网友提到，AI 正在从“理解世界”转向“参与世界”。当 AI 进入汽车和机器人领域，变成 Physical AI 时，对延迟和可靠性的要求会直接决定生死。
摩尔定律并没有消失，它只是从单纯的微缩，变成了复杂的系统工程。
提要：一项旨在资助学校开展“AI素养”教育的法案引发争议。批评者认为，这并非真正的素养教育，而是科技巨头通过教育系统进行的“用户预热”，旨在将学生培养成被动的使用者而非创造者。
在学校里，Chromebook 预装了 Gemini，学生写作文时，屏幕会跳出“帮我写”；做幻灯片时，它会问“帮我视觉化”。这些提示就像某种无处不在的系统中断，不断诱导孩子把认知工作外包给云端。
如果学习的目的是为了通过过程来获得经验，那直接跳过思考、只拿结果的行为，还叫学习吗？
有观点认为，这种所谓的“AI素养”教育，本质上是科技巨头在进行“用户入驻”。当法案定义的素养是“有效使用 AI”时，这更像是职业技能培训，而不是培养独立思考能力的公共教育。教育不该是为公司培养熟练的技术员，而应该教人如何批判性地审视世界。
有网友提到，这和当年学 Microsoft Office 的“IT 素养”很像，但性质完全不同。学 Office 是掌握一种通用的生产力工具，而学“如何写 Prompt”更像是学习如何向一个黑盒索要答案。
如果把学习比作构建底层架构，AI 应该是编译器或辅助工具，帮助我们更高效地运行逻辑；但现在的趋势似乎是，孩子们还没学会写代码，就先学会了如何直接运行别人的程序。
更有意思的冲突点在于：真正的 AI 素养，应该是理解系统的运作逻辑、谁在从中获利、以及如何识别它的幻觉。但如果教学大纲是由那些希望增加订阅用户的厂商来主导，我们得到的可能只是一套“如何更顺从地使用工具”的说明书。
当孩子习惯了“按一下按钮就得到答案”，他们可能会失去那种从零开始、在混乱中建立秩序的耐心。
如果一个工具让你变得更强大，那是赋能；如果一个工具让你变得不再需要思考，那是降维。
随着计算抽象层不断加深，开发者对底层逻辑的理解正在退化。AI 的介入进一步降低了门槛，让“看起来能用”的代码充斥市场，却掩盖了系统性风险与专业价值的流失。
现在的软件开发，越来越像是在用昂贵的精密仪器盖违章建筑。
以前写程序，得盯着内存、算着指令周期，那是跟机器“对话”。现在的开发者，更像是在玩一种名为“调用”的拼图游戏。大家导入各种库，写着看似高级的逻辑，却没人真的知道这些函数在底层是怎么转动的。这种抽象带来的自由是有代价的，它在解放生产力的同时，也把我们的理解力给“屏蔽”了。
有网友提到，这种现象在 AI 时代被无限放大。用 LLM 生成代码变得轻而易举，甚至能做出很漂亮的界面，但“好用”和“能用”之间隔着深渊。这就像是在阿里巴巴买了一堆看起来像钢材的东西，用来盖摩天大楼，这本身就是个危险的赌注。
这种趋势正在重塑整个行业的价值链。
过去，开发者的高薪某种程度上建立在“复杂性”之上——因为机器难懂，所以人才贵。但当 AI 能够通过非确定性的概率预测来模拟逻辑时，这种护城河正在坍塌。有观点认为，很多公司现在只想要快速交付的 Jira 工单，而不关心代码是否优雅、是否高效。他们更愿意支付更低的成本，去换取一个“勉强能跑”的结果。
这让那些真正理解底层原理、追求架构质量的专业人士感到一种深深的异化。在很多公司眼里，懂原理的人反而成了“阻碍进度”的负担。
有趣的是，这种“降级”不仅发生在软件领域。就像有人用房屋检查的例子类比：如果一个建筑师只看外观，却对地基的裂缝视而不见，那这栋房子迟早会出事。软件行业似乎正在进入一个“只要不崩，就先跑起来”的阶段。
但问题是，当所有的系统都建立在这些脆弱、松散、甚至带有随机性的抽象层之上时，我们该如何应对那次必然到来的、由于缺乏底层掌控力而引发的系统性崩溃？
本文回顾了从手动压缩包、锁定式管理到分布式协作的软件版本控制演进历程，探讨了 Git 如何在技术危机中诞生并凭借其底层架构逻辑确立了长达二十年的统治地位。
版本控制的历史，其实是一部不断试图解决“如何不丢代码”的斗争史。
在正式的系统出现前，开发者过得相当狼狈。那时候的“版本管理”大概就是把项目打包成 `project-2003-04-15.zip`，然后存进备份目录。大家在周一早晨讨论的不是逻辑，而是“上周二那个压缩包里是不是才是对的版本”。这种 ad-hoc 的方式本质上是极其低效且焦虑的。
后来出现了基于锁（Lock-based）的模式，比如 RCS。你想改文件？先把它锁住，别人就只能等着。这在单机时代没问题，但在协作时代简直是灾难。随后的 CVS 引入了并发编辑，虽然解决了“排队”问题，但它缺乏原子性。如果网络在中途断了，仓库就会处于一种谁也说不清的混乱状态。与此同时，微软系的 Visual SourceSafe 虽然在商业领域流行，却因为数据库频繁损坏，让“定期备份仓库”成了 IT 部门的必修课。
转折点发生在 2005 年 4 月。因为 BitKeeper 撤销了免费授权，Linus Torvalds 在十天内写出了 Git。
Git 的出现不是一种缓慢的演进，而是一次架构层面的降维打击。它把版本控制从“中央服务器”的桎梏中解放出来，变成了分布式模型。每一个 clone 都是一个完整的、拥有完整历史的仓库。这种基于内容寻址（Content-addressed）的存储结构，让数据损坏变得可检测，而不是静默发生。
有网友提到，GitHub 的成功在于它把 Git 的分布式特性包装成了社交化的 Pull Request 工作流，让协作变得“可见且可点击”。
即便在 2026 年，虽然出现了 Sapling 或 Jujutsu 等有趣的挑战者，但 Git 的核心数据模型依然稳如磐石。Git 并不完美，它复杂的指令集常让人抓狂，甚至偶尔也会因为误操作导致代码丢失。但它至少做到了：它把控制权还给了开发者，而不是让开发者去伺候平台。
现在的开发流程，究竟是在利用工具，还是在被工具的惯性裹挟？
