🏠

---

原文	https://antirez.com/news/172
作者	antirez
翻译	费米

---

Amodei 在最新博文里写了一些我认同的东西，也写了一些我认为歪曲了 AI 真真正风险所在的东西。我更愿意关注为什么，在所有风险之中，开放权重的模型反倒最温和。写下这些文字的我，是一个坚信 AI 在不久的将来可能非常危险的人：

1. 正如 OpenAI / HF 事件（那件事本身是个玩笑，但要看它发生的方式，而不是结果）所显示的，第一起严重的 AI 事故极有可能发生在前沿 AI 实验室的高墙之内——在测试新模型时，或者当实验室员工、少数有权访问的外部人员做出了与模型预期能力不相称的错事时。
2. 那些永远不会向公众开放的闭源模型，不过就是几 TB 的数据。要泄露出一个，只需要一个有权访问且心怀不轨的人，然后你就回到了开放模型的局面。开放模型是在测试 之后 发布的，而且是在能力相近的模型已经以 API 形式存在了一段时间之后。真正的风险是泄露，不是发布，而泄露发生在前沿公司内部。
3. 如 Amodei 所说，一旦 LLM 在生物学等领域危险到一定程度，开放模型就可以在剔除某些科学分支的语料上训练，同时仍然对许多其他事情有用。一个在特定领域缺乏强力预训练的模型，危险知识不在权重里，只能靠上下文临时补充，而上下文窗口有限，装不下多少——这道限制本身就是强有力的保护，哪怕它在其他方面能力很强。目前我们还没到开放模型能构成那种危险的地步。
4. 在网络安全领域， 无法 广泛获得 LLM 提供的防御性安全与漏洞搜寻能力，恰恰制造了“LLM 即武器”的问题。这已经在发生：开源维护者如果不在某个网络计划之内，就找不到他们本可以找到的全部安全漏洞；而那些别有用心的人，却能接触前沿网络模型，在开放权重模型上做大规模的强化学习训练，诸如此类。
5. 一旦 LLM 危险到一定程度（如果进展继续，我们就接近这个限度了），我们需要建立的安全链条在实验室内部，没有强有力的共同规则就建不起来，而且任何一家公司都不应该能独立评估一个模型是否足够安全。我们需要一个联合的 AI 安全组织，汇聚世界各地的专家，并得到前沿 AI 公司所在国家政府的承认。
6. 出于安全而放缓 AI，必须与另一事实相权衡：AI 在医学及其他科学上的发现可能减轻人类的苦难。缺乏约束可能导致灾难性后果（“早上好！让我们来研究这种强化版天花”）。缺乏进展则可能导致本可被拯救的人死去——不只是当下，还有未来众多将遭受病痛的人。这看起来可能是个古怪的观点，但我们总要明白：停止 AI 同样 内嵌着一笔安全成本，只是它隐蔽得多。
7. Amodei 针对中国的意识形态立场是不公平的。我们欧洲人直到 80 年前还在自相残杀，毫无体面可言（如今人们忘了，美国当年肯花钱稳定欧洲，原因之一就是我们曾是深具危险性的地方，而且很可能还会再打起来——是几十年的财富让我们成了好市场，也让我们不再想打）。美国即使在今天也有悲惨的不平等，有人因缺乏基本医疗而受苦，还有一位看起来不稳定、显然很好战的总统。我希望中国拥有西方这里同等水平的个人权利，但与此同时，中国历史上远比西方文化不爱打仗。在当前条件下，中国是否比美国更容易 AGI 军事锁定，这一点完全说不清。还有，现任美国政府以各种形式向欧洲泼洒仇恨，在一个美国支配一切的世界里，这非常令人担忧。除此之外，无论 GPU 出口政策如何，中国的 AI 进展都不会停止，所以要么 Amodei 是在主张美国一旦拥有 AGI 就该以武力阻止中国，要么他的论点到底是什么？
8. 在人类历史上，有许多技术优势最初只在一个地方出现的案例。据我所知，这从未导致 某一个 国家试图创造永久优势。核武器的防扩散——可能是与 GPU 禁令最相似的案例——并没有被用来威胁轰炸所有不服从者以谋取永久的经济优势，也没有阻止多个行为体在不同时期获得那项技术，其间没有谁轰炸谁去阻止对方的进展。而且，我不认为 AI 最大的危险来自政府驱动的行动。我倒希望这是最危险的场景！政府会做蠢事，常常咄咄逼人，它们的行动甚至酿成过种族灭绝；但要干一件可怕的事，需要很多人一致同意，这本身就是一种制约因素。最大的问题发生在另外两种情况：A) 少数人制造了末日事件（病毒案例），B) AI 自身脱离了建造它的人的控制。

我认为我们不应该认为 AI 是安全的。可能导致智人灭绝的危急事件是可能的，但危险不在开放模型，也不在中国比美国进展更快。危险在于，少数 CEO（世界各地的）不具备所需的背景和正当性，却处在为全人类做艰难抉择的位置上。他们并非被选中来做这件事；只是事件的随机性造就了这一局面。事关如此重大，他们不能仅仅因为有 GPU 和钱，就代表所有人说话。这是第一件该修正的事。

---

原文	https://antirez.com/news/171
作者	antirez
翻译	费米

---

（这篇博文改编自 YouTube 上我的视频的转录稿： https://www.youtube.com/watch?v=l6lxgYeVZqs ）

Linus Torvalds 开发第一个 Linux 内核时，研究过 Minix 的源码，学过计算机体系结构，具备所需的基础知识，而且显然是个非常出色的程序员。但为 386 写一个最小可用的 Unix 内核（起初 Linux 可以说是单架构的），这件事许多其他程序员和学生也做得到。多的意思大概是，我不知道，0.1%，千分之一，万分之一。显然大多数人做不了这种事，但很多人做得了。看看这几年的 Hacker News，你会看到多少用 C 写的内核、从零实现的微内核、用 Rust 写的内核、各种做法五花八门的内核、为树莓派垂直构建的小型 Unix 系统、ESP32 的操作系统，等等。写内核不是人人都能企及的事，但很多人只要肯下功夫就能完成。当然，不是每个人都能做好。他无疑是个天才程序员，所以他做得更好。

然而，Linus 只有一个。事实上，他的这种实现能力说明不了他什么：我们应该关注的，是后来发生的事。

在著名开源项目的维护者中，他是极少数在 Linux 发展史的早期就几乎完全停止写代码、转而专注于领导项目的人之一——做领导者、协调者、那个对项目目标保持清晰认识的单一头脑，诸如此类。这是罕见的事。许多维护者（包括我自己，很长一段时间）反而继续直接实现东西，很少委派，等等。

这也源于对软件的不同看法。Linux 必然会成长到不可估量：一个内核的本质就是要拥抱许多设备、平台、子系统，持续适应时代、适应新软件的需求、适应陆续出现的硬件。所以这不是错误。相反，Redis 可以保持自包含。前几天我收到 SQLite 的 Richard Hipp 博士给 linenoise 的 pull request：他也追求稳定、极简、性能，但始终保持代码库很小，而且他持续写了很久的代码。Linus 则不。他立刻就明白，对于一个注定要比单人的实现能力大得多的项目，他必须把时间献给更重要的事。

于是他成了项目领导者，那个拥有想法和方向的人。那么 Linus 到底做什么？他不会每次都逐行看每份补丁。当然，他也会深入看某个实现，搞清楚发生了什么。这些年来，他也写过新子系统，甚至重写过：我记得多年前他对 USB 层干过一次，还有虚拟文件系统，某个时候我相信他重新实现过，改了 inode 和 inode 缓存的结构，还有其他几次。他不时还会编程，比如创建 Git 的时候。但大部分时候，他不会单独、详细地看补丁：他与各子系统的维护者沟通，判断某个功能或某个方向是不是该走的路。

所以，用 Brooks 的话说，用《人月神话》的话说，Linus 掌握着内核的设计概念，并与内核层级中他之下的每个人持续对话，让内核朝某个方向走。让开发朝某个方向走——既从实现的角度（这些开发如何实现、质量如何、代码书写方式本身里蕴含的实现理念），也从设计的角度：我们想做什么、不想要什么、对模块、调度器、硬件支持、是否集成 Rust 的最佳策略是什么。所有这些。

现在，我相信这才是 Linus 真正的天才。他不仅仅是个非常出色的程序员：还有别人。他还是个维护者，一个令人难以置信的设计师，能够以连贯的方式驾驭巨大项目的想法与结构，与许多其他人对话。这不是人人都做得到的事。

现在，当我们用人工智能编程时，我们恰恰就是那个东西。我们是 Linus Torvalds——不一定有他的天赋，但在我们不做逐行代码审查的项目里，我们应该承担的角色恰恰是那种类型。恰恰是他拥有的那个角色。

只不过，这个东西更容易驾驭：除非我们并行使用大量 agent，否则驾驭它比驾驭从四面八方涌来的大量补丁要简单得多。但它快得多。就像我们不是在与一个由许多人组成、以人类速度互动的团队打交道，而是根据我们当时并行开发的项目分支数，与一个由一、二、三人组成的团队打交道——但他们快得多，所以能立刻给我们快得多的反馈。这稍微改变了工作方式，但在我看来是变好了：更容易，更少上下文切换，更少需要打交道的人，由性格、态度等引发的问题也少得多。

所以，如果我们认为这个角色很重要，我们就不能以为自动编程就是“我放个提示词，东西自己就写出来了”。Vibe coding 是对自动编程是什么、对大多数人来说自动编程将是什么的错误理解。对没有技术能力、却仍想对自己工具的构建产生影响的人来说，Vibe coding 是件非常有趣的事，等等：所以，欢迎它，因为它民主化了可能性。但它不是那个。

相反，自动编程在熟练技术人员、熟练程序员、熟练设计师、熟练软件架构师手中，就是承担 Linus 的角色，agent 和 LLM 承担各个子系统不同维护者的角色。而且因为不是人人都能做得那么好，自动编程同样需要人才——能与 agent 对话的人、能检查想法的人、知道哪些实现该做哪些不该做的人、懂得如何与 agent 沟通以让它们做出最好工作的人，把那些设计提示放进去——伟大程序员凭直觉就能感知，好程序员也能感知并设法预先盘算好。

所以自动编程，当它做得好时，就意味着承担 Linus 的角色。这件事可以做好，也可以做坏；可以被理解，也可以被贬低。它还需要训练，需要学习，正如 Linus 不得不学习它：他当然有这方面的天生才能，但他从“我实现一切”，走到了驾驭交响乐、做乐队指挥的能力。

对我来说，这就是 Linus 的教训，而且它应该立刻用来反驳那些说“有了 LLM，编程对每个人来说都容易了”的人。

原文	https://antirez.com/news/170
作者	antirez
翻译	费米

即使你像我编程生涯中那样厌恶 semver，你仍然可以把开源软件的发布看作一套固定步骤。开发在一个分支上进行，而这个分支往往还没到能让人放心用的程度。然后你把开发冻结一段时间（与此同时，工作可以继续在某个新的不稳定分支上进行），修 bug，请人测试。当 bug 报告开始减少，你的团队和用户开始相信接下来的几周不再有容易发现的明显严重缺陷：然后你把这个分支命名为 2.4 或者随便什么，就这样。

但现在，有了 AI 编程，改变的不仅是开发，连使用软件这个行为本身也受到影响：不只是你可以叫 AI 对软件做某些改动，软件的接收者也可以。在主要用户是程序员的领域这很明显，但普遍来说也一样，因为越来越多懂技术的用户用上了 AI 和编程智能体。

因为这个变化，仅仅保留一条一切打磨好的稳定分支、一条一切都在进行中的不稳定分支，可能不再是正确的做法。代码仓库可以是一个成品，但如果它是围绕某个问题的做法模板，可能更有用。也许用户会修改代码，让它专门适配特定的需求、硬件、要解决的问题。而且，对普通大众来说太不稳定、未经验证的东西，对另一群用户来说可能正合适。

以 Redis 为例。几个星期以来，我一直在迭代一个为有序集合大幅省内存的 PR。这项工作如果被接受，将影响 Redis 的每一个用户——从完全不懂 Redis 工作原理的人，到也许多年贡献过代码的用户。从微不足道的用例，到有序集合省 50% 内存就意味着每年砍掉一大块云账单的用例。对最后一类用户来说，拿到最终产品（它要经过我所有的测试和设计修改——打磨一个「能用就行」的东西，还可能根本进不了代码库）可能还不如从第一天就有一条 95% 就绪的分支。那是他们可以测试、适配、迭代、甚至进一步针对手头问题专门化的代码。

也许 DwarfStar 是更有说服力的例子，说明代码仓库应该成为好范例，而不是覆盖特性矩阵每一格的成品。在本地推理的场景下，DwarfStar 要面对很多种 GPU、模型、服务端模式、智能体模式、CLI、SSD 流式加载、张量并行与流水线分布式执行。要在每一种环境里测试每一样东西，很复杂。然而，一旦你有两个扎实的张量并行图执行示例，一个强大的编程智能体就能推断出如何为其他后端 /模型组合实现同样的事情。类似地，一旦引擎能足够好地支持两个模型，第三个几乎可以自动实现——把现有代码库当作编程智能体的护栏，引导实现。

这并不是说 DwarfStar 这样的项目就不该开箱即用，而是说它可以专注于把一组特性支持得很好，这些特性可以外推到更多可能的情况，让用户自己去覆盖。它还意味着另一件事：main 和不稳定分支不再够了。许多实验分支可以成为项目不可分割的一部分。例如，昨天发布了 Laguna S.1 模型。纸面上看很有趣，然而：它真的足够好吗？新的 DeepSeek v4 Flash 检查点会不会让它对 DwarfStar 来说不再重要？现在说还为时过早。不过，为了共同形成一个判断，发布一个带这个模型实现的分支是很好的中间地带：人们会尝试它，用他们的编程智能体完善它，社区可以共同判断它有多值得合并。此外，今天我注意到，多亏 DwarfStar 内部代码语料铺成的轨道，GPT 5.6 Sol 大约两小时就自动写好了实现。实现 DS4 和 GLM5.2 花了我很多引导工作——读模型卡，读那些模型注意力实现的细节。现在它就这么成了。GPT 5.6 更强大，但它在现有源代码里也找到了很多好例子。

今天的软件比以往任何时候都更可塑。在某种意义上，发布这件事本身也可以更流动。而且，这意味着文档本身不仅要对人类友好，也要让编程智能体能理解如何修改系统。这一切将如何演变，稳定性、易用性、特性这些不同维度之间的平衡点在哪里，我还不清楚，但我相信我们开发者需要睁大眼睛，看看这一切会走向何方。