Martin Fowler

Fragments: October 4

7.5内容质量

TL;DR · AI 摘要

文章用电影隐喻揭示LLM开发的伦理风险,强调从‘建造’到‘培养’的范式转变,需重新思考技术治理方式。

核心要点

  • LLM开发需从‘建造’思维转向‘培养’思维,接受不可控性
  • 推断型系统的错误修复难度比传统软件高两个数量级
  • 《禁忌行星》的Krell文明隐喻警示AI失控风险

结构提纲

按章节快速跳转。

  1. 用电影《禁忌行星》隐喻AI开发的伦理困境

  2. 对比桥梁建造与LLM培养在确定性层面的本质区别

  3. ›Krell文明的现代启示

    分析LLM失控风险与电影中Krell命运的因果关联

  4. 探讨推断系统错误修复的特殊性与复杂性

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • LLM开发范式转变
    • 核心隐喻
      • 《禁忌行星》Krell文明
    • 技术对比
      • 建造思维
      • 培养思维
    • 治理挑战
      • 错误修复难度
      • 伦理风险

金句 / Highlights

值得收藏与分享的关键句。

#LLM#AI伦理#软件开发#技术哲学
打开原文

碎片:10月4日

Martin Fowler

2026年10月4日

针对我上一篇碎片(可能是指我们担忧LLM是否具有意识,而非应该思考为何它们没有道德感的部分),"Metalanguage"回复道:

我们发布了本我,却忘记了超我。经典的软件生命周期。

我不知道他们当时在想什么,但他们的帖子让我立刻想到了1956年的经典科幻电影《禁忌星球》。许多科幻作品和其他文学作品都探讨过人类创造技术时产生的非预期行为,至少可以追溯到玛丽·雪莱。但这部电影对科幻电影制作产生了深远影响,其核心故事正是关于当我们将一个思考机器培养出来时会发生什么。

我在这里特意使用了"培养"这个词。我们常说构建软件,但"构建"暗示着一定程度的决定论。当我们建造一座桥或一列火车时,我们期望它们以可控且被充分理解的方式运行。这与我们在花园里培育植物或培养幼儿的方式存在程度上的差异。与这些系统合作的挑战之一在于理解从构建计算系统到培养推理系统的转变中发生了什么变化,以及我们的流程需要如何随之调整。

确定性构建会产生非预期行为:一些桥梁曾坍塌,我们的计算系统也经常存在漏洞。但一个关键区别在于,当我们发现计算系统中的漏洞时,通常可以修复它。即使无法修复,我们通常也能禁用某个组件以防止漏洞造成进一步损害。然而对于推理型LLM来说,却没有这样简单的修复或禁用方式,这可能使我们走向克雷尔的命运。

(如果你还没看过《禁忌星球》,强烈推荐观看。是的,它展现了1950年代的特色——特效、音乐、表演和当时的时代风貌。但故事本身非常扎实,其核心主题对我们在生成式AI时代构建的未来具有重要参考价值。不过建议不要提前了解剧情,沉浸式体验故事会更有意思——尽管我对那次经历的记忆已经有些模糊了。)

--- --- --- --- ---

根据其律师发布的信息,Bini被一辆车上四名自称是移民局官员的人拦截。随后,他被带往移民局办公室,但没有收到任何进一步的信息或相关主管部门的正式命令。在那里,官员告诉Bini他的签证已被撤销,但并未出示任何支持文件。Bini的辩护团队已提出人身保护令,以保障其自由并阻止其被驱逐出境。然而,厄瓜多尔当局坚称,这位开发者对公共安全和国家结构构成威胁或风险,必须离开该国。驱逐的依据是一份据称声称Bini曾对厄瓜多尔安全实施过行为的秘密报告,而辩护方无法接触该报告内容。

我一度非常担心,因为不清楚他将被驱逐到哪里。但他在瑞典发推文,所以我对此感到庆幸。但这只是部分缓解。Ola在厄瓜多尔生活了十三年,这里已成为他的家。被毫无理由地驱逐出家门是一件沉重的事情,而实施这一行为的官员已犯下严重过错。

DDD Europe发布了Gien Verschatse在六月会议上采访Eric Evans和我的视频。我们首先谈论了20世纪90年代末期我们如何因概念建模而建立联系。随后对话迅速转向AI领域,我们指出无法预测这种重大变革将如何发展。我们预计这将促使我们以不同方式思考工作,但这种变革可能带来解放,它重新激发了Eric对编程的热爱。

人们可能会对[这种新的软件思维方式]感到非常沮丧……但当你克服这种情绪后,会有一种大脑被释放的奇妙感觉。

我们在敏捷规划方面的背景有助于应对不确定性,因为我们习惯于采取小步骤并关注反馈。我们思考写作与思考之间的互动,无论是散文还是代码,这都是一种探索与完善交织的迭代过程——与我们与LLM对话时的情况如出一辙。

不要错过Eric重要的最后建议。

Paul Graham:

有很多事情之所以能运作,是因为人类操作速度存在限制。我们即将发现所有这些限制,因为它们即将失效。

关于阅读代码是否会在软件开发者的未来扮演角色,这一猜测仍在继续。Geoffrey Huntley表示:

人们仍在大声疾呼,认为代码应具有可读性以便人类理解。但我现在不再认为这是目标。

有趣的是,他的例子让LLM通过将其转换为Python来解释一个Haskell函数定义……这在我看来表明代码仍有一定作用,只是LLM无需以与呈现给读者相同的形式存储代码。这本质上与投影编辑(projectional editing)的概念相同,该概念认为软件的可编辑表示形式不必与其存储表示形式相同。

Sam Ruby在思考Rails World主题演讲时提到了这一点。他引用DHH的话:

目前Rust是一个很好的提示编译目标,C++也是如此。很快将是汇编语言,然后是微码。短视地认为我们会让智能代理钻头停止,直到它触及计算的底层。

他的回应是:

这篇文章留下了一个未被提出的问题:钻头的顶端是什么?我们保留、编辑并信任什么作为真相的来源?

他进行了查看一些 Rails 软件的练习。用 Ruby/Rails 表示,大约有 60,000 个标记。将其编译为 C 后,变为 4,000,000 个标记。这种标记数量的增加会对 LLM 造成阻碍,因为 LLM 仍然需要将其放入上下文窗口中,即使它能够容纳,也难以确定注意力应聚焦在哪里。Sam 指出,即使没有人类阅读代码,用高级语言表示程序也是有道理的。

当代理编写代码时,Rails 变成了什么:无论最终编译成什么,它都是最紧凑、精确且常规的 Web 应用程序规范。让钻头尽可能深入,只需在顶部保持符号表示。

所有这些都让我想起了 Unmesh Joshi 的观点:代码服务于“两个截然不同但相互关联的目的”:给机器的指令,以及问题领域概念模型。在探索这些如何随着 LLM 变化后,他得出结论:

编码的角色并未消失,但正在发生变化。随着 LLM 使代码生成更加廉价,编写指令的机械行为变得不再核心。更重要的是明确概念模型,发现合适的词汇,并通过迭代、领域专业知识和反馈来完善这些词汇。这也是为什么编程语言仍然至关重要。我们并不是要被动地审查生成的代码。编写代码本身是我们思考的一部分。代码仍然是对机器的指令。但它也是理解的模型。在 LLM 时代,这一角色变得更加重要。编码的未来不仅仅是更快地编写更多代码。它是在构建更好的概念模型、更好的词汇和更好的基础,让人类和 LLM 都能在此基础上协作。

在后续的一篇文章中,Sam 思考了人们如何谈论代理能力的方式,这让人联想到“盲人摸象”的寓言。我们每个人对这个对象及其发展方向都只有部分了解。我们所有人共同的主题是:

实用的问题不是代理是否优秀。而是:对于你本周面临的任务,信息将从哪里来?什么会验证结果?

《经济学人》对投资者担忧 AI 公司产品风险的简洁总结:

很难庆祝一个导致“最终公开处决”的首次公开募股。

关于 Google 最新模型的新闻很有趣:

Gemini 4 Argon 在人工分析上的幻觉率极低,仅为 15%。Grok 4.7 为 29%。GPT-6 Astra 为 45%。Opus 5.5 为 59%。Fable 5.1 为 69%。低于它的模型几乎无法回答任何问题。它们的正确率都不超过 15%。在最大情况下,它的正确率甚至比 Opus 5.5 低,50% 对比 66%。但当它不知道答案时,它会如实说明,而不是编造内容。

在牺牲部分正确率的前提下,更清晰地表明自己不知道的内容,这显然是我更倾向于接受的权衡。

最新片段:

10 月 4 日

上一篇:

9 月 29 日

所有片段 /think