「AI 不是工具」——Rich Hickey 论 LLM 的本质是自动化

深度摘要

Clojure 之父 Rich Hickey 发表约 700 词短文，系统论证"AI 不是工具"：工具是你挥舞的东西（手持、力量、控制三要素），而不替你做事；LLM 缺乏可预测、可靠、确定性等工具属性，本质是"很少或无需直接人工控制自行运转"的自动化。用 LLM 等于把"与世界打交道"换成"为反复无常的机器人打工"，学到的细节一次更新即过时。

关键要点

• 工具的定义是"你挥舞的东西"：手持（控制与反馈）、力量（能量传递与方向）、控制（意图与持续引导）。
• 工具不替你做事；使用工具建立、回报并常常要求专业技能；好工具可预测、可靠、确定、功能有界、简单——这些 LLM 都缺乏。
• LLM 是 automation（很少或无需直接人工控制自行运转），如得来速之于做饭：你发出请求，它自行行动，没有你的能量或持续引导。
• 用自动化学到的是揣摩机器当日的细节（"在 voodoo.md 里填入恰当的咒语"），一次更新即过时；你用与世界打交道换来了为反复无常的机器人打工。
• "用它当工具读论文"是误用：是它读了论文，不是你；代价是错过学习写作、论证、细节、笑话与如何思考。
• 工具不会"失齐"、不会"叛变"；自动化与工具有本质区别，忽视其内在属性后果自负。

关键事实

LinkedIn Pulse 文章，作者 Rich Hickey（Clojure 语言创造者），发布于 2026-10-12；正文约 700 词、13 段，开篇注明是其常讲的一个 quip 的展开版。经浏览器任务免登录关闭弹窗后完整读取全文；页面显示 488 次回应、56 条评论。

作者观点

作者先给"工具"一个有区分度的定义：工具是你挥舞（wield）的东西，包含手持（控制与反馈、亲密感）、力量（能量传递与方向、杠杆）、控制（意图与对事件进程的持续引导）三要素。工具是你藉以做某事的器具，它们不替你做事；工具的使用建立、回报并常常要求专业技能。好工具具有 LLM 所缺乏的属性：可预测、可靠、确定性、功能有界、简单。核心论断：LLM 不是被驾驭的，它们是自动化（automation）——"以很少或无需直接人工控制自行运转的装置或过程"；得来速不是做饭的工具，而是"避免做饭"的自动化；LLM 不是你藉以写代码的工具，而是你藉以逃避写代码的自动化。使用自动化时你学到的不是世界的真理，而是揣摩某台反复无常的机器当日的细节，一次软件更新就可能过时。作者还批评"我只是用它当工具读论文"的说法：并没有像挥舞 Kindle 那样去读，是它读了论文，不是你；放弃亲自阅读的代价包括错过学习写作、论证、细节、笑话，以及学习如何思考。结尾：工具不会"失齐"、不会"叛变"、不会"逃出收容"；自动化与工具有本质区别，忽视其内在属性后果自负。

为什么重要

这是当前 AI 话语中最有分量的概念清理之一：它把"AI 只是工具"这句安抚性套话拆开，迫使每个使用者回答——你究竟是在 wield 它，还是在把它外包给它。对"如何用好 AI"的实践讨论（如下一篇的反驳）提供了共同的靶子。

编辑点评

这是"工具 vs 自动化"之辩的源头文本，也是本期最值得细读的一篇。Hickey 的锋利之处在于把定义问题前置：先用 wield 把"有用"和"是工具"切割开，再指出委托式使用的真正代价不是失业而是学习机会的流失（"是它读了论文，不是你"）。其弱点在于二分法可能过窄——正如下一篇 yyhh 的反驳，编译器和电子表格同样是"自动化"，我们照样 wield 它们。但即便接受反驳，Hickey 关于"揣摩机器当日的细节、一次更新即过时"的观察，依然是对 prompt 工程脆弱性的精准描述。

深度摘要

一篇对 Hickey 的逐条反驳：不可靠是工具好坏的维度而非成员资格（锯子也切不直）；编译器、电子表格同样是"自动化"，我们照样 wield 它们；程序员"解释→质疑→测试→拒绝→改写"的循环本身就是人类主导的反馈环。真正的区分是"熟练 wield"还是"无理解地委派"。

关键要点

• 不可预测、不可靠是评价工具好坏的维度，不是"是否为工具"的成员资格（锯子也切不直）。
• tool/automation 二分是伪命题：编译器、电子表格都是自动化的工具，照样通过指定输入、检查结果来 wield。
• 程序员的真实工作流是人类主导的反馈环：解释→质疑→查源码→测试→拒绝→改写请求。
• 用好 LLM 需要知道问什么、什么证据重要、何时答案是错的——这本身就是技能。
• 真正的区分是"熟练 wield" vs "无理解地委派"，而非宣布整类软件不是工具。

关键事实

yyhh.org 博客文章，发布于 2026-10-12；开篇即点名回应 Hickey 近日在 LinkedIn 发表的《'AI' is Not a Tool》。bin/read 提取 0 字符，改用 browser.open 完整获取全文。

作者观点

作者逐条反驳 Hickey。第一，不可预测、不可靠是评价工具好坏的维度，不是"是否为工具"的成员资格——锯子也切不直，没人因此说锯子不是工具。第二，Hickey 的 tool/automation 二分是伪命题：编译器、电子表格都是自动化的工具，我们照样通过指定输入、检查结果来 wield 它们；请求/自动化的循环也可以是挥舞，只要人保持在环路里。第三，作者描述程序员的真实工作流本身就是人类主导的反馈环：让 LLM 解释代码→质疑→查源码→测试→拒绝→改写请求，循环往复；用好它需要知道问什么、什么证据重要、何时答案是错的。真正的区分不是"工具 vs 自动化"，而是"熟练地 wield 工具" vs "无理解地委派"——后者的问题不在软件类别，而在使用者放弃了判断。

为什么重要

把"AI 是不是工具"从哲学定义之争拉回工程实践：问题不在于给软件贴标签，而在于使用者是否保持了判断环路。与 Hickey 原文对照读，是理解当前 AI 辅助编程争论全貌最省时间的一对文本。

编辑点评

罕见的同题正面交锋，且时效极强（Hickey 文发表 48 小时内即有系统反驳）。它的价值在于把辩论从本体论（"是不是工具"）拉回实践论（"如何 wield"）："wielding vs delegating"的区分比二选一更有工程指导意义，也与 Ars 研究的数据互文——review 环节正是 wield 发生的地方。未回应的缺口：Hickey 关于"放弃亲自阅读的学习代价"（错过学习写作与思考）的论点，反驳文中没有正面接招。两篇宜对照读。

深度摘要

哈佛研究人员基于 Jellyfish 的 3 亿条工程事件、700 余家公司数据发现：引入 AI 编码智能体后代码行数 +30%、PR +23%，但 Jira 需求解决率纹丝不动——因为 PR 平均审查时间膨胀 49%、要求返工的 PR 近乎翻倍。编码省下的时间，全被人类审查环节吃掉了；总雇佣人数则无显著变化。

关键要点

• 样本：Jellyfish 聚合数据，3 亿 work event、70 万+ 员工、700 余家软件公司，2021–2026.3，双重差分回归。
• 产出端：代码行数 +30%、commit +20%、PR +23%；但 Jira Issues/Epics 解决率无显著变化。
• 瓶颈端：PR 平均 review 时间 +49%、要求修改的 PR 占比近翻倍、每 PR 评论 +35%、参与 review 的员工 +14%。
• AI 参与审查仍边际：80% 公司已用 AI review，但 AI 只贡献 23.3% 的 review 评论、10.8% 的 PR。
• 就业：未发现 AI 导致总雇佣人数显著变化；95% 公司已引入 AI coding agents。

关键事实

Ars Technica 2026-10-12 报道哈佛大学研究人员 Fiona Chen 与 James Stratton 的研究。数据来自工程效能公司 Jellyfish 的聚合分析：3 亿个 work event（commit、PR 等）、70 万+ 员工、700 余家软件公司，覆盖 2021 年至 2026 年 3 月；用"双重差分"回归比较各公司引入 AI 工具前后的指标。关键数字：引入 AI coding agents 后，公司平均代码行数 +30%、commit 数 +20%、PR 数 +23%；Jira Issues/Epics 解决率无统计显著变化；PR 从提交到合并的平均 review 时间 +49%、要求修改的 PR 占比近乎翻倍、每 PR 评论数 +35%；参与 review 的员工占比 +14%；总雇佣人数无显著变化（Jellyfish 数据与 LinkedIn 交叉验证）。bin/read 全文读取（5642 字符）。

作者观点

研究者与报道的解读：编码阶段的效率提升被生产流程的下游约束吸收，人类代码审查成为整体效率的瓶颈；AI 辅助的审查目前影响边际（80% 公司已用某种 AI review，但 AI 只贡献 23.3% 的 review 评论和 10.8% 的 PR）；95% 的受访公司已引入 AI coding agents，但许多仍在学习何时、何处部署最合适，"编码时间 vs 审查时间"的权衡可能随经验改善。就目前而言，让 AI 写代码是双刃剑，值得怀疑其时间与金钱投入对多数公司是否划算。

为什么重要

这是"AI 提升生产力"叙事迄今最硬的一次企业级 falsification：瓶颈不在生成而在审查。它直接决定了 engineering org 该把钱投向哪里——不是更多的生成配额，而是审查产能与判别标准。

编辑点评

迄今关于 AI 编程工具企业级影响规模最大的实证研究之一，数字非常硬：+30% 代码行数、+49% review 时间、修改率近翻倍——"产出更多代码 ≠ 产出更多软件"是本期数据最扎实的论断。它与 Hickey 之辩形成互文：当 review 成本吞掉编码收益，价值恰恰沉淀在 wield 的反馈环（审查、质疑、测试）里。两个注意事项：数据截止 2026 年 3 月，agent 能力仍在快速迭代；Jellyfish 的客户样本可能偏向已具备工程度量意识的公司。

深度摘要

Meta 发布 Muse Wonder 系列前沿模型，主打个人与职业 agent 场景，自称在 agent、记忆、编程基准上 SOTA，提出 Active Memory（跨对话记忆）与 Active Focus（持续攻坚）两大能力，训练于吉瓦级 Prometheus 数据中心。其中用"分布内/外任务随推理算力扩展曲线"量化泛化能力的方法论，比分数本身更值得看。

关键要点

• 发布 Muse Wonder / Muse Wonder Full：个人与职业 agent 前沿模型，自称 agent、记忆、编程基准 SOTA。
• Active Memory：跨对话携带重要上下文并主动检索；Active Focus：持续攻坚、尝试替代路径、必要时澄清/确认。
• 评估含 Harvey 法律基准 LAB、FocusBench、SWE-Marathon（长周期软件工程）。
• 泛化实验：对比 Muse Spark 1.3，Wonder Full 在分布外任务上随 test-time compute 提升更快，归因于更强基座。
• 训练于 Prometheus 吉瓦级数据中心；安全自称迄今最强 CBRN/网络滥用防护，完整报告待发布。

关键事实

Meta research 官方博客 2026-10-12 发布 Muse Wonder 系列：Muse Wonder 与 Muse Wonder Full，定位个人与职业 agent 的前沿模型；自称在个人/职业 agent、记忆、编程基准上 SOTA；训练于 Prometheus 吉瓦级数据中心。Muse Wonder 经 Meta Model API 与 Muse Code 上线，Wonder Full 面向 Muse Code 订阅者；未来将驱动 Muse 内的体验与 artifact 生成。bin/read 全文读取（7273 字符）。

作者观点

官方主张：Muse Wonder 系列是"个人超级智能"之路的下一步，在个人/职业 agent、记忆、编程等关键基准上达到 SOTA；Active Memory（跨对话携带重要上下文、主动检索相关细节）与 Active Focus（持续攻坚、尝试替代路径、遇阻适应、必要时澄清与确认）是可用个人 agent 的关键能力；评估覆盖 Harvey 法律 agent 基准（LAB）、FocusBench、SWE-Marathon（长周期软件工程）等。关于泛化：对比 Muse Spark 1.3，Wonder Full 在分布外任务上随 test-time compute 提升更快，官方归因于"更强的基座使 post-training 增益更好地迁移到陌生任务"。安全方面自称迄今对齐最好、CBRN 与网络滥用防护最强，遵循 Meta Superintelligence Scaling Framework，完整安全报告"即将发布"。

为什么重要

Meta 在"个人超级智能"路线上的最新落子；其泛化实验的方法论（而非分数）是对 benchmaxxing 质疑的一次正面回应，值得做评测的人细读实验设计。注意：全部成绩为厂商自述。

编辑点评

标准的厂商发布，全部 benchmark 均为自述、未独立验证，阅读时应打折扣。但其中一节值得单拎出来看：官方用"分布内 vs 分布外任务随推理算力扩展的曲线"来量化回应 benchmaxxing 质疑——这是对"大模型味道"（big model smell）少见的量化尝试，方法论本身比分数更有信息量。另注意与本期落选的 GLM-Legal 的对照：法律 agent、harness 协同优化正在成为模型发布的标配叙事，领域 agent 是明确的主线。

深度摘要

一篇立场鲜明的长文：软件工程自始就是自动化别人的工作，工程师是"造织机的人"而非织工——而历史的讽刺是，造织机的人 50 年后自己也被去技能化替代，当时的反抗因被视为虚伪而熄火。在自动化轮到自己时才宣布"编程是无价艺术"，作者认为失体面（"No crying in the casino"）。

关键要点

• 软件工程自始就是自动化别人的工作：VisiCalc/簿记员、商业目录、排版公司、交易大厅跑腿员。
• 工程师不是卢德派织工，而是"造织机的人"；而造织机的技工 50 年后自己也被去技能化替代，反抗因被视为虚伪而熄火。
• 引《泰晤士报》评当时技工罢工："这些聪明工程师的哭喊，不过是手织工的哭喊——对不可避免的铁律的哭喊。"
• 技术乐观主义已不流行（气候、2008、社交媒体、科技领袖右转），作者自称不确定哪边正确。
• 结论：在自动化轮到自己时才宣布"编程是无价艺术"、"No crying in the casino"，是失体面的。

关键事实

seangoedecke.com 博客长文，发布于 2026-10-12；bin/read 全文读取（6838 字符）。文中提及的时事（Indianapolis 市议员住宅遭枪击、Sam Altman 住宅遭纵火）为作者所述，未独立核实。

作者观点

作者承认工程师对 AI 的愤怒可以理解，但指出工程师是"最后有资格抱怨的人"：软件工程自始就是自动化别人的工作（VisiCalc 让簿记员消失、商业目录、排版公司、交易大厅跑腿员）。工程师在这个类比里不是织工，而是"造织机的人"——而历史的讽刺在于，造织机的技工在 50 年后自己也被去技能化替代（"illegal men"），当时的反抗因被视为虚伪而迅速熄火（引《泰晤士报》："这些聪明工程师的哭喊，不过是手织工的哭喊"）。作者承认技术乐观主义已不流行（气候、2008、社交媒体、科技领袖右转），也不确定哪边正确；但工程师们用每一次 commit 都在为技术进步投票，现在轮到自己时才宣布"编程是无价艺术"，"No crying in the casino"（愿赌服输），是失体面的。

为什么重要

把"AI 抢饭碗"的讨论从受害者叙事扭向身份诚实：你一直在自动化别人的工作，现在轮到你了。与 Hickey 的"学习代价"论形成对照——一个谈失去，一个谈资格。

编辑点评

本期"人的位置"主题的第三块拼图：Hickey 谈工具本质、Ars 谈产出瓶颈，Goedecke 谈身份政治。其真正锋利处不在"工程师别抱怨"的姿态，而在双重位置的揭示——工程师既是自动化者又是被自动化者，而历史证明"造织机的人"的反抗同样会被视为虚伪。与 Hickey 的"学习代价"论对照读：一个谈你失去了什么（亲手做的机会），一个谈你没资格说什么（你一直在做的事）。