Karpathy谈Claude Fable 5：软件成本下降后，需求可能先暴涨

Simon Willison 引述了 Andrej Karpathy 对 Claude Fable 5 的一段推文评价。事实很窄：这不是长篇报道，也不是 Willison 自己提出的新理论。核心观点来自 Karpathy 的公开引文。

Karpathy 说，他感觉很多东西正在变化。随着“可运行软件越来越像从水龙头里流出来”，杰文斯悖论开始出现。他自己对软件的需求，反而明显变大了。

这句话有意思的地方，不在于又一次讨论“程序员会不会失业”。更值得看的是：当软件的获取成本降下来，软件会不会从稀缺交付物，变成一种按需消耗品。

Karpathy真正说的是：软件开始像临时工具一样被消费

Karpathy 列的例子很具体，不是泛泛地说“AI 会写代码”。

他提到的包括 explainers、visualizers、dashboards、一次性定制应用、为某个项目专门做的完整 wandb、把测试套件扩大 10 倍、自动优化代码，以及用定制 HTML 展示大型研究项目结果。

这些东西有一个共同点：过去很多时候不是做不了，而是不值得做。

写一个解释器，可能只服务一次讨论。做一个可视化页面，可能只用来检查一个实验结果。为单个项目搭一套仪表盘，正常排期下很难说服团队投入。

AI 编程工具改变的，正是这个“值不值得”的门槛。

这里的主线不是“软件被省掉”。恰恰相反，是软件被用得更多。

一个开发者以前可能只写主功能代码。现在他可能顺手生成解释页面、调试仪表盘、测试补丁和性能对照。一个研究团队以前只交一份表格。现在可能为每组实验生成一个独立 HTML 页面。

这就是需求扩张的起点。

杰文斯悖论放到AI编程上，意思不是省人，而是多做

杰文斯悖论说的是：效率提升可能扩大总需求，而不是减少使用。

经典例子是煤炭。煤炭使用效率提高后，单位成本下降，工业活动反而扩大，总消耗也可能上升。放到软件里，逻辑类似。

当一个小工具需要半天、一周、一个排期，它会被过滤掉。团队会问：这个需求值得立项吗？值得维护吗？值得占用工程师时间吗？

当它能被 AI 快速生成，问题就变了。

团队不再只问“值不值得正式开发”，而会先问“能不能先生成一个能跑的版本”。这一步很小，但会改变需求池的大小。

对软件开发者来说，动作会更具体：

• 少把 AI 只当代码补全器，多把它当临时工具生成器；
• 对测试、日志、可视化、脚手架这类低门槛需求，主动让 AI 先产出候选版本；
• 把精力从“手写每一段胶水代码”，挪到验证、集成、边界设计和代码审查上。

对 AI 产品和研发团队来说，变化也很现实：

• 内部工具不一定每个都立项，但可以先做轻量试作；
• 采购 AI 编程工具时，不能只看模型会不会写函数，还要看它能否接入仓库、测试、权限和团队流程；
• 研发管理要重新估算“临时软件”的价值，不然很多需求会继续被旧流程挡在门外。

我不太买账的是，把这件事直接讲成“软件工程师马上被替代”。证据不够，也不符合这些例子的性质。

Karpathy 说的更像是：软件的使用密度上升了。人不会因为水龙头更方便就不喝水，很多场景反而会开始用水。

限制也很清楚：能跑，不等于能进生产

把软件说成“从水龙头里流出来”，很有画面感。但它不能被过度理解。

原始信息只是一段引文。它没有提供 Claude Fable 5 的发布时间、价格、性能数据，也没有给出可验证的功能清单。这里能讨论的是 Karpathy 的判断，而不是替某个模型补一份测评。

更关键的是，AI 生成“能跑的软件”只是第一步。

权限怎么管？数据口径谁确认？依赖升级谁负责？出了安全问题谁背锅？这些不是演示视频能解决的事。

一次性软件和企业软件也不是同一种东西。

一个研究员为实验结果生成 HTML 页面，失败成本通常可控。一个团队把 AI 生成的仪表盘接入真实客户数据，风险就不一样。审计、合规、运维和权限治理都会进场。

所以这件事最可能先发生在两个地方。

一是开发者和研究人员自己的工作流。解释器、可视化、测试扩展、实验报告，这些需求成本低、收益快、失败也容易回滚。

二是技术团队的内部工具。它们不一定马上进入生产环境，但会先改变试作方式。过去要排期的东西，现在可能先由项目组生成一个版本，再决定要不要正规化。

接下来最该看的，不是某个 demo 又炫了多少。

要看这些 AI 生成的小工具能活多久。用完即弃，说明它们只是脚手架。进入团队长期工作流，才说明软件需求真的被放大了。

也要看企业会不会补上治理层：代码审查、权限边界、测试框架、日志追踪、数据隔离。如果这些没有跟上，水龙头开得再大，也只会把地板淹了。