Rich Hickey 论 AI：为何它不是工具？

引言：当 Clojure 之父谈论 AI

在技术圈，Rich Hickey 的名字几乎与“简单性”和“深思熟虑”画上等号。作为 Clojure 语言的创造者，他极少对技术热点发表即兴评论，但每一次发声都值得仔细咀嚼。近期，他在 Hacker News 上引发讨论的观点——“AI 不是工具”——乍看像一句博眼球的断言，实则触及了当下 AI 讨论中一个被反复混淆的根本问题：我们究竟在用什么框架来理解这项技术？

（当前 Hacker News 原帖仅提供标题与少量元数据，本文基于该观点在技术社区中的典型讨论方向进行分析与阐释。）

“工具”这个词，可能从一开始就错了

Hickey 的核心论点并不复杂：工具是被动、可预测、可完全掌控的。一把锤子不会在你不知情时改变自己的形状，一个编译器不会突然决定用另一种方式解释你的代码。工具的本质是延伸人的意图，而不是拥有自己的意图。

问题在于，当我们把 AI 称为“工具”时，实际上是在暗示它可以被无缝嵌入现有的工程与管理框架中——像调用一个 API 那样简单。但 Hickey 暗示，AI 系统的行为具有涌现性、非确定性和难以完全解释的特征，这些特征与“工具”的经典定义存在张力。你用锤子，锤子不会给你一个“大概正确”的钉子。

从 Clojure 哲学看 AI 的“非工具性”

理解 Hickey 的立场，需要回到他毕生倡导的设计哲学。Clojure 强调不可变数据、纯函数和显式状态管理——核心目标是让系统的行为可推理、可预测。在这个框架下，一个理想的工具应该具备确定性：给定相同输入，必然产生相同输出。

而当前主流的 AI 系统，尤其是大语言模型，恰恰在这一点上站在了对立面。相同的提示可能产生不同的回答；模型的内部决策过程难以逐层追踪；其能力边界随规模扩大而“涌现”，而非由设计者逐条规定。Hickey 的批评并非否定 AI 的价值，而是在提醒：用“工具”的隐喻去管理 AI，会导致错误的期望、错误的治理方式和错误的责任分配。

工程管理上的后果

如果 AI 不是工具，那么“购买 AI 工具”这种采购思维就值得警惕。工具可以按规格验收，AI 系统却不能。你无法像测试一把扳手那样测试一个模型——你只能评估它在特定分布上的统计表现，而分布之外的失败模式往往不可预知。这对软件工程的管理流程、质量保证和风险评估都提出了全新要求。

分布外失败（Out-of-Distribution Failure） 是 AI 系统特有的风险模式：模型在训练数据覆盖的分布内表现良好，但一旦遇到训练中罕见的输入，行为可能急剧退化，且这种退化往往毫无预警。相比之下，传统软件在边界条件外通常表现为崩溃或报错——至少是可检测的失败。AI 的失败却常常是“自信地给出错误答案”，这在医疗、法律、金融等高风险场景中尤为危险。这解释了为什么 Hickey 强调“AI 不是工具”：工具的失效模式可以被枚举和防御，而 AI 的失效模式只能被统计性地估计和管理。

责任归属上的后果

工具出错，责任在使用者。但如果 AI 的行为具有不可完全预测的自主性，“谁该负责”就变得模糊。Hickey 的观点间接指向一个更深的问题：当我们把 AI 当作工具来部署时，是否在无意中回避了对系统自主行为的伦理与法律考量？

涌现性（Emergence） 在这里指的是：系统的宏观能力并非由设计者逐条编程规定，而是由大量简单组件的交互在规模扩大后自发产生。以大型语言模型为例，翻译、推理、代码生成等能力并非被显式写入代码，而是在训练过程中从海量数据里“长”出来。这意味着这些能力的边界无法通过阅读源代码来推断，只能通过经验性测试来探测。对工程实践而言，这直接冲击了传统的“规格—实现—验证”流程：如果一个系统的行为不能被完整规定，那么验收标准本身就失去了确定性基础。

非确定性（Nondeterminism） 在软件工程中通常被视为缺陷——同一输入产生不同输出，意味着系统不可复现、不可调试。但大语言模型的非确定性并非 bug，而是其工作机制的一部分：采样策略（如 temperature 参数）让模型在概率分布上选择输出，从而获得创造性和多样性。这对质量保证提出了根本挑战：传统的单元测试假设固定输入对应固定输出，而 AI 系统的测试只能建立在统计评估之上，需要大量样本、置信区间和分布外检测。理解这一点，是理解 Hickey 批评的关键前提。

社区分歧：这是深刻的警告，还是语义游戏？

Hacker News 上的讨论呈现出两种典型立场。

支持者认为，Hickey 抓住了当前 AI 话语中最危险的简化。把 AI 称为工具，就像把互联网称为“信息高速公路”——听起来无害，却掩盖了复杂的系统效应。这种命名方式直接影响政策制定、企业战略和公众预期。

质疑者则认为，这不过是语义上的较真。人类历史上几乎所有强大技术最初都被称为“工具”，后来才逐渐发展出独立的治理框架。说 AI 不是工具，并没有给出替代性框架，因此实践意义有限。

两种观点都有道理，但 Hickey 的独特之处在于，他不是在玩概念游戏，而是在从系统设计的角度指出隐喻的实践后果。一个错误的隐喻，会导致一整套错误的工程决策。

如果 AI 不是工具，那它是什么？

Hickey 本人并未在简短发言中给出完整答案，但沿着他的思路可以推演几种可能。

一种理解是，AI 更像一个协作对象或参与者，而非被动器械。这意味着交互模式应是对话式的、迭代的，而非命令式的。另一种理解是，AI 是一种环境或基础设施，像电力或网络一样渗透到系统各处，其行为需要被监控和治理，而非被“使用”。

无论哪种理解，都指向同一个结论：现有的“工具”心智模型不足以支撑 AI 时代的工程实践。 我们需要新的词汇、新的管理方法和新的责任框架。

结语：命名的力量

Rich Hickey 的观点之所以在 Hacker News 上引发共鸣，不是因为它提供了答案，而是因为它提出了一个正确的问题。在 AI 能力快速演进的当下，我们习惯于用旧框架套新技术，以求心理上的安全感。“AI 是工具”就是这种安全感的典型产物。

但如果这个框架本身就是错的，那么建立在其上的一切——产品设计、团队组织、监管政策——都可能需要重新审视。Hickey 的提醒是克制的，却足够尖锐：在讨论 AI 能做什么之前，先想清楚我们把它当成了什么。