开幕雷击。
有一说一，这个还真不算是玩梗。
八月份的时候，我把开发了两年左右的 Rust 异步原语项目捐赠给了 Apache 软件基金会，由于西语系老哥说原来的名字有些神秘的联想，于是我们几个开发者鬼脑发动，合计完最后采用了 Asyncband 作为项目名称。
然后就是项目合伙人 @PragmaTwice 开了一个乐队主题的 Logo 提案。可惜由于人均艺术细菌不足，暂时搁置，也欢迎各位反馈或投稿。
言归正传，本文写于下周我即将在 Scotland Glasgow 做演讲之前，内容与演讲主题相同，即讨论 AI 冲击下的开源范式进化和社群格局演变。一言以蔽之，就是作为一个朴素的软件工程师，在下一个时代还值得参与开源，加入建设开源社群吗？
“AI 可以替你做一切，唯独不能替你坐牢。”
这个名梗表明，即使越来越多的生产代码已经不再由人类工程师手写完成，而是由智能体（Agent）根据指令大规模生成，但是智能体从社会属性上并不能对它自己生成的代码负责，一旦代码在生产环境造成问题，或者需要对代码做审计，仍然需要一个对应的 Code Owner 来负责。
早在二十年前，经典著作《程序员修炼之道》开篇就讲了一个有关“我的源码被猫吃了”的寓言故事：最好的软件项目也不可避免地会遇到推迟交付，或出现未曾预料的技术问题。一旦问题出现，Code Owner 就需要承担责任，依靠自己的专业去解决问题。书中写到：
责任意味着你对某事积极认同。你保证事情能够搞定，并为之做出承诺，但你不必直接掌握事情的每个方面。除了个人尽力做好，你必须分析超出你控制范围的风险情况。
……不要把问题归咎于别人或其他什么事情上，也不要寻找借口。不要把所有问题都归咎于供应商、编程语言、管理或是同事。这些因素都可能是问题的一部分。它们的确会解决方案造成影响，但不是给你的接口。
在智能体编程（Agentic Coding）时代，把“智能体”插入到上面“供应商、编程语言、管理或是同事”当中毫无违和感。所谓“我的源码被猫吃了”，书中指的是如果项目源码只有一份，而你丢失了且没有备份，这就是你的责任，推卸说“我的源码被猫吃了”无助于事。对应到智能体编程场景，也就是一旦线上出现问题，推脱说这是 AI 写出来的 BUG 并不能撇清你作为 Code Owner 应该承担的责任。
本文以“代码上道（Code Soundness）”为题，首先简述智能体编程的优势，然后说明人在智能体编程的循环中如何发挥自身价值，从而可靠地交付智能体编程所产生的代码。
Soundness 通常翻译为“可靠”或“稳固”。这里根据其发音和出自《是，大臣》的梗，将其翻译为“上道”，既是指代码的可靠性，也意指代码如行车上道一样，部署到生产环境稳定运行。
我有一个朋友讲过，如果大模型能力的边界超过你日常工作的基线，你就会进入一个生产力井喷的状态（并开始发表一系列暴论）。
去年底的时候，我还能共情 Linux 内核开发老哥：
而当今年初 Codex App 发布并日渐完善，GPT 5.5 到现在 5.6 的模型逐渐能够相对可靠地交付我需要它交付的内容之后，我不得不承认，GPT 5.6 Sol Max 的能力边界已经达到我日常工作的基线。所以，我也要发表 Code Is Cheap 的暴论了。
开宗明义，只有当模型能力覆盖你的日常工作需求的时候，你才或许能跟现在的我共情。
反面例子比如，目前 AI 写作还远远达不到我的要求，我试过 AI Gen 文章，但是最后这篇文章还是得我手写才对味。调整 AI Gen 的文章比我自己手写都心累。Codex App 和 GPT 5.5 模型出来之前，模型产生的结果往往充斥着我无法忍受的部分，且无法通过进一步 Prompt 改善。这种情况在下面的案例里还会出现。
现在开始介绍我通过使用 Coding Agent 大幅降低软件开发成本，提升生产力的案例。出于分享方便起见，我主要讨论我在开源社群相关的工作，但是其实日常 ScopeDB 内核、平台和运维也已经全面经过了 AI 的加持。
本文成型于今年我在国内几所高校所做分享的同名 PPT 材料，主要以时间为线索介绍了我从接触开源世界到开源成为生活的一部分，或者叫“如呼吸般自然”的过程。
内容包括但不限于：我是如何接触开源软件并参与到开源社群协作的，如何在开源社群中成长，开源工作的可持续性，还有当下不可避免谈到生成式人工智能如何改变了开源的典型模式。
本文结合我近期 Agentic Coding 的经验，讨论这一范式在实践当中可能遇到的问题。
首先说明，以目前 LLM AI 的能力，能够针对任意通用任务生成疑似正确（Plausible）的方案、流程或代码等，是完全可以做到的，但是以此为由声称“某某领域已死”则大可不必。因为从生成似是而非的原型，到实际经得起考验的产品，仍然存在 AI 不能覆盖的鸿沟。不过，如果你的需求并不复杂，似是而非的结果已经可以满足需求，那也很好。
例如在发扬 LLM Writes Plausible Code 的这篇文章里，作者抨击了一个号称 LLM-driven 用 Rust 重写的 SQLite 性能不行，所举的例子是一个简单任务 SQLite 原版花了 0.09 毫秒，但是重写版花了 1815.43 毫秒，也就是上万倍的差距。但是就这个简单任务而言，它也就花了一秒上下。如果你的需求就到这了，难道你会觉得一秒完成任务的这个 Rust 重写的版本有什么不好吗？
去年底读到一篇题为《配置管理：被忽视的技术债务》（下面简称《配置管理》）的文章，文章作者从产品研发的视角出发吐槽了配置管理的一系列问题：
.env 文件管理配置缺乏一致性和安全性同时，文章作者提出了配置分类的几个维度，以及设计配置项时应该考虑的几个问题。
我于是发现，配置系统的设计和不同业务的配置管理问题，确实缺乏讨论。很少有开发者认真思考过配置系统是如何工作的，好像应用程序天然就能自己加载到正确的配置。一旦应用加载到错误的配置，开发者则往往很难说出问题出在哪里。要么怪罪配置有多个来源造成混乱，要么反思配置项的设计不够合理，要么指责配置管理职责不明，莫衷一是。
我有幸在某公司工作时看到过完整流畅的配置系统和管理方案。本文将综合业务研发和配置系统研发两种角度，首先给配置下一个定义，进而为市面上的配置软件做一个分类，最后再针对上面引用的文章提到的问题做逐一评论。
如题，一个常见的问题。正好近期针对问题和相关的议题，我有几个浓缩的观点，写出来以作分享。
一直以来，资本市场常以药品研发来类比软件研发：两者都需要在前期投入巨大的不确定成本研发新品，一旦研发成功，通过专利授权和垄断销售带来的利润，不仅可以覆盖之前投入的研发成本，甚至还有巨大的盈利空间。
其中，新品药物盈利的关键就在于专利保护和垄断生产。一旦配方公开并且允许仿制药流通，药品的价格就会显著下降。由于药品的公益特性，一般而言药品专利会有时间上限，超过时间上限后即成为公共知识可以仿制生产销售。在专利期内，药品研发公司通过前述手段收回成本保持盈利。
商业软件的研发类比大抵相同。企业雇佣开发者做出专有软件之后推向市场，通过收取垄断的授权费和维护费用收回成本实现盈利。目前，没有专门的法律规定软件发布后一定时间内必须公开源码，允许任何人使用。然而，软件开源即扮演了这样的角色：向所有人公开软件源码，允许任何人出于任何目的使用、修改和发布修改后的版本。
药品专利的盈利模式会受到仿制药的直接挑战，同样地，软件专利的盈利模式也会受到开源决策的直接影响。
本文对应我在今年 RustChinaConf 2025 & Rust Global China 大会上的演讲，原标题《最速传说：四个月内基于 Rust 开发服务全球云数据库 ScopeDB》。由于近期我写的另一篇文章也使用了“最速传说”的字样，出于个人写作习惯，我把标题做了改动。
云原生技术方兴未艾已十余年，但是，云上的数据方案大多还只是将基于裸金属集群构建的系统几乎原样的搬到了云上，没能充分利用云上弹性调度的能力，以及云厂商提供的廉价对象存储。
我在开发者的未来：基于云服务构建数据基础设施一文中已经说明为何简单照搬原有架构行不通。
ScopeDB 的出现，既是为了压榨出云资源的所有优势，也是为了压缩大数据时代叠床架屋的数据流水线方案，将分析的能力带给每一个业务团队。
Rust 已经成为新时代基础软件开发的首选。基于可靠的 Rust 语言和繁荣的 Rust 生态，我们在四个月内从无到有开发出了云数据库 ScopeDB 并在全球多个可用区内上线服务客户需求。
在此过程中，我们也将自己对 Rust 生态的需求和改进持续反馈到上游项目社群，并将研发过程中衍生的独立模块以开源库的方式共享出来。
Apache 软件基金会官方已发布新闻稿，宣布 The ASF 的新徽标 “橡树叶”正式启用。本文按照我对新闻稿的理解进行翻译，非逐字翻译。
去年，Apache® 软件基金会（The ASF）宣布，为了更好地体现基金会“社群重于代码”的一贯理念，我们将更新组织徽标（Logo）和品牌体系。今天，我们荣幸地宣布推出全新的 ASF 徽标：橡树叶（Oak Leaf）。
关于 2024 年的相关公告，请参见：