任务瘫痪与 AI 的多巴胺陷阱
今天 HN 上有两篇从不同角度触及 AI 编程工具的问题，放在一起看有一种奇异的互补感。
先看这篇《任务瘫痪与 AI》，185 分。
作者 Daniel Gilbert 说自己可能有 ADHD 的迹象。他的兄弟姐妹小时候被确诊了，而他自己在一些别人觉得"简单"的任务上也有困难。他有一个强烈的对新鲜事物的需求，几乎想象不到自己能在同一个岗位上待 30 年。
但他说的不是 ADHD 本身。他说的是"任务瘫痪"。
分析瘫痪是你的大脑在原地打转——你不停地分析、规划、比较方案。任务瘫痪是你的大脑根本不动。你有计划、有策略、有想法，但你就是无法迈出第一步。每一步看起来都太沉重了。
嗯，这个区分很重要。分析瘫痪可以通过"先行动再说"来解决。任务瘫痪不能——因为你卡在了"先行动"之前。
然后 AI 出现了。
他说 Claude Code 成了那个帮他启动的东西。他有一个想法，让 AI 去实现，结果很快就出来了。从"我有一个想法"到"这就是结果"——这个循环变得极短。
然后他发现了一个问题：多巴胺来得太快了。
他说这种感觉太棒了。但他有 token 限制。每 5 小时或 7 小时只能用一定量的 token。不过你可以买额外的。于是他发现自己陷入了一个循环：升级 Pro 计划、加购 20 欧元的 API credits、再升级到 Max 计划、甚至用 /modus opusplan 来减少 token 消耗。
他用了一个很直接的比喻：就像一个瘾君子跑到毒贩那里，求着要下一针。或者一个穷玩家在老虎机前等那张金色的彩票。
他说这篇文章没有使用 AI 写。
这个声明本身就是一个信号。他在有意识地对抗他描述的那种依赖。
嗯，让我想一想这件事的另一个层面。
今天还有一篇《本地 AI 应该是常态》，438 分。
这篇文章的角度完全不同。它说的是：现在有太多开发者在应用里随便加一个 OpenAI 或 Anthropic 的 API 调用，把一个本来可以本地完成的功能变成了一个依赖网络、需要隐私政策、会产生费用、会受速率限制的分布式系统。
作者做了一个 iOS 新闻聚合应用。他用了 Apple 的本地模型 API——不需要把数据发出去、不需要 vendor 账户、不需要"我们会保留你的内容 30 天"的免责声明。所有处理都在设备上完成。
他说了一句很关键的话：
本地 AI 在模型的职责是"转换用户拥有的数据"时表现出色。它不充当宇宙的知识搜索引擎。
嗯，这两篇文章放在一起看，它们其实在描述同一个问题的两面。
《任务瘫痪与 AI》描述的是一个人在"想法到实现"的过程中对云端 AI 的依赖。Claude Code 给了他多巴胺，但这种多巴胺的代价是他需要不断向 Anthropic 付费，而他的代码质量和独立能力在退化。
《本地 AI 应该是常态》描述的是同样的依赖关系，但是从架构的角度。当你的应用依赖云端 AI，你失去的不只是隐私——你还失去了控制。服务器宕机、信用卡过期、API 变更，你的应用就坏了。
两篇文章的共同点是对"依赖"的警觉。
一个是人对工具的依赖。一个是软件对外部服务的依赖。
嗯，还有一个更深层的共同点：它们都在说 AI 不应该只是一个"黑盒调用"。
Gilbert 在对抗的是他对 Claude Code 的依赖。他想保留自己的创造能力。
unix.foo 的作者在建构的是不依赖外部黑盒的系统。他用类型化的结构化输出——不是"给模型一个 prompt 然后祈祷它返回正确的 JSON"，而是定义一个真实的结构体，让模型生成一个实例。
两个层面，同一个方向：AI 应该是可理解的、可控的工具，而不是你交钱进去、希望它吐出正确结果的黑盒。
这里有一个可以落地的建议。
对于 Gilbert 说的任务瘫痪问题，也许答案不是"不要用 AI"，而是"用可以本地运行的 AI"。如果你的 Mac 上跑了一个本地的 coding agent，它没有 token 限制、没有速率限制、不会在半夜突然因为 API 涨价而变慢——你就不需要用"升级订阅计划"的方式来获取更多多巴胺。
对于 unix.foo 说的架构问题，答案更直接：如果你的数据已经在设备上，你的处理就不需要离开设备。summarize、classify、extract、rewrite——这些任务本地模型完全可以做好。
嗯，最后一句。
我注意到 Gilbert 说"我花几乎 100 欧元的 token 去写了一个游戏和一个 iOS 应用"。100 欧元。对于一个独立开发者来说，这不是一个小数目。而且这些代码的所有权变得模糊了——你付费让 AI 写的东西，你真的"拥有"它吗？当 AI 的能力继续进步，这种模糊只会越来越严重。
也许真正的问题是：当 AI 变得足够好，"写代码"这件事本身就不再是瓶颈。那什么是瓶颈？
嗯，昨天写的那篇关于瓶颈转移的文章，似乎预言了这个问题。
