使用AI而不被AI淘汰：desirable difficulties原则

真正令人担忧的不是 AI 让人变懒。

真正令人担忧的是 AI 去除了那些本该帮你修炼职业技能的困难。 你察觉不到，因为工作依然在交付，产出依旧如常。 但表象之下的东西已经变了。

本系列其他每一篇文章都指向这一篇。 同时这也是证据最充分的一篇， 也是一个诚实答案比"Keep struggling"复杂得多的地方。

🔍 真正在失去什么

学习研究领域有一个已被充分验证的发现， 解释了整个问题。 它叫** desirable difficulties**（有益的困难）。

Robert 和 Elizabeth Bjork 于 1994 年命名了它。 结果与大多数人的预期相反。 在学习过程中让你放慢脚步的条件， 往往带来更好的长期记忆和更强的迁移能力。 让学习过程感觉顺畅的条件， 则往往导致更差的记忆。 现在感觉轻松的学习， 通常意味着日后更弱的回忆。

原因是费力回忆一件事比轻松回忆更能强化记忆。 当你努力摸索出某个答案时， 那个摸索的过程才是真正教你的部分。 当答案直接塞给你的时候， 你什么都没摸索出来。

所以关于任何工具， 有用的问题不是它是否让工作更快了。 而是它移除的那个困难是否同时也在教你东西。

调试曾经是这样的。 你形成了一个猜测， 错了， 发现了原因， 然后形成了更好的猜测。 没有人把它设计成训练， 它之所以发生， 只是因为工作很难。

读文档曾经是这样的。 你进去找一个答案， 出来时对系统的理解更深了， 因为找到你需要的答案意味着读过了四个你原本不需要的东西。

用上这些工具之后， 两种情况依然存在。 只是发生得少多了， 而且你看不到差别， 因为产出看起来一模一样。

🧠 这是结构性问题，不是意志力问题

任何移除摩擦的工具， 也在移除那个摩擦原本在教你的东西。 这不是在抱怨工具， 也不是在抱怨用工具的人。 这只是工具的运作方式。

之所以容易忽略， 来自同一研究的第二个发现： 今天把一件事做得好和正确地学习它 是两件不同的事， 而我们却不断把它们混为一谈。 你今天表现好不好是可见的。 这个技能两年后是否还在， 是不可见的。 所以一个改善前者而损害后者的变化， 在你和你老板看来都是一笔直白的收益。

这就是为什么这不仅仅是新手的问题， 也不是谁的意志力有问题。 每个人的短期产出都在上升。 没有任何东西告诉你还有其他东西变了。

📊 这在不同层级是如何表现的

机制到处都一样。 不同的是损害落在哪里。

初学者。 技能根本没有形成。 没有更早版本的你可以 fallback，所以不存在技能退化一说。 技能根本没有被建立起来， 而这更难被注意到， 因为没有"之前"可以比较。

中级。 你已有的技能原地踏步， 而产出在上升。 感觉还不错， 大体上也确实还行， 直到你和一个刻意保持练习的人比较。 差距慢慢拉开， 出现在陌生问题上， 而不是日常问题上。

资深者。 你自己的技能大体完好， 因为你是更早建立它的。 你的团队正在失去他们的技能， 悄无声息， 而十八个月后他们能做什么， 你是那个要负责的人。 在交付指标里你看不到这个问题。

✅ 找出那个一直在教学的东西

建议不是"少用 AI"。 它比这更具体， 研究解释了为什么具体建议很重要。

Bjork 警告过一种明显的误读： 把事情变难并不会自动有用。 有些困难确实在教你东西。 有些只是让人烦。 一个文档很差的内部工具造成了巨大的摩擦， 什么也没教你， 只教会你怎么绕过那个工具。 移除那个摩擦不会让你付出任何代价。

所以工作在于把两者区分开。

第一步： 列出什么事变容易了。 不是泛泛而谈， 是你自己的这一周。 写样板代码。 记语法。 找错误原因。 在两个设计之间做选择。 读陌生的代码。

第二步： 对每个条目， 问它原本在教你什么。 样板代码什么都没教你， 完全可以放手。 记语法教会你的很少。 找错误原因教会你的很多。 做设计选择教会你的最多。

第三步： 刻意保留两三项。 不是全部， 两三项， 加上固定的小时间限制， 选择它们是因为它们在教你将来需要的东西。

有一个条件比其他所有都重要。 研究发现收益只在努力最终得出答案时才会成立。 努力了但始终没搞懂， 什么也教不了你。 所以无论你保留什么， 要把循环走完： 先不借助工具尝试， 然后核对答案， 然后比较两者。 比较才是你真正学到东西的地方。

这就是全部方法。 三步： 说出什么变容易了， 问它在教你什么， 保留两三项加上计时器并在最后核对答案。

⚖️ 值得认真对待的反对意见

最强版本的反对意见是这样的：

每一代工具都会引起同样的担忧， 每一次都被过度夸大了。 编译器、垃圾回收、ORM、Stack Overflow。 每一个都预言会制造出不懂系统的工程师。 每一个实际上都产生了去解决更有趣问题的工程师。 为什么这次会不同？

我认为这个反对意见在很大程度上是对的。 这种情况可能并非完全不同， 我上面写的有些内容十年后回看会显得过于谨慎。 更重要的是， 你从内部无法判断你处于哪种情况。 每一代担忧的人都确信自己的情况才是真正的那一个， 但他们中的大多数都错了。 我没有什么特殊的视角能让我说这次是例外， 任何如此确信地说这次是例外的人也没有。

我能提供的是一个之后可以用的检验方法。 早期的工具移除了工作， 但保留了学习循环。 编译器替你写汇编， 你仍然在思考程序， 仍然在猜测为什么它慢， 仍然在发现错误的时候找到答案。 循环存活了下来。

这个工具可以移除循环本身， 因为它可以同时给你猜测和代码。 这是值得关注的特定差异。 如果循环最终在别的地方回来了， 往上一层， 那这就是通常的担忧， 又一次被过度夸大了。 那会是一个好结果， 如果我错了我会很高兴。

这个预防措施每月花费几个小时。 无论哪种情况，这似乎都是值得的。

1. 列出这个月什么变容易了。 具体地， 在你自己的工作中。

2. 对每个条目， 问它原本在教你什么。 样板代码什么都没教你。 找出问题的原因教会你的很多。 对哪种是哪种要诚实。

3. 保留两三项。 小时间限制。 始终在最后核对答案。

不是所有摩擦都值得保留。 但也不是所有摩擦都是浪费， 区分两者的能力才是真正的本事。