关注「索引目录」公众号，获取更多干货。
上个月，METR 发布了一项研究，这项研究应该会让所有开发者感到不安。
他们挑选了 16 位经验丰富的开源开发者——他们对自己的代码库了如指掌——并随机分配任务，让他们使用或不使用 AI 工具来完成。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
我使用人工智能编码工具已经将近一年了。当我读到那篇研究报告时，我的第一反应是“嗯，那些开发者肯定是哪里做错了”。我的第二个反应是：这不正是那篇研究报告警告的那种思维方式吗？
认知差距才是真正的发现
速度数据固然引人注目，但我认为最重要的发现是感知上的差距。我们感觉速度更快，是因为人工智能处理了那些枯燥乏味的部分——样板代码、语法，以及那些看似繁琐实则并非真正难点的部分。与此同时，真正困难的部分却变得更加棘手：理解人工智能修改了什么、验证其正确性、以及记住那些并非自己编写的代码。
Simon Willison——Datasette 的创始人，也是我所知的最多产的 AI 辅助开发者之一——写下的一段话让我印象深刻：
“我对我的项目能做什么以及它们是如何运作的，已经没有清晰的认识了。”
这位开发者已经利用人工智能辅助开发了 80 多个工具。如果他在理解思维模型方面遇到困难，那么问题可能并不在于经验水平。
注意力才是真正的瓶颈
我现在是这样想的：
Before AI: Think → Write → Test → Debug
With AI: Describe → Review → Verify → Debug AI → Debug your understanding编写代码的成本降低了，其他所有环节的成本都增加了。“审查自己没写过的代码”在认知上比“编写自己能理解的代码”要难得多——任何做过代码审查的人都知道这一点。
“人工智能把我们都变成了杰夫·贝佐斯——自动化了简单的工作，留下了所有艰难的决策。”——史蒂夫·耶格
METR 的研究基本上证实了我们很多人一直以来的感受，但却不愿承认：人工智能编码工具并不能节省时间。充其量，它们只是重新分配了你的注意力。最糟糕的是，它们营造了一种生产力提高的假象，而实际上却增加了认知负荷。
我实际改变的
我不再追求速度，而是开始问自己：“我的注意力都集中在哪里？”
1. 我预先思考，而不是预先提示。
在使用任何人工智能工具之前，我都会先用纯文本写下我想要什么、为什么想要以及“完成”的标准是什么。这不是给人工智能看的，而是给我自己看的。这需要5到10分钟，但却是我一天中最有意义的事情，因为它迫使我在生成结果之前先思考。
肯特·贝克将此称为“增强型编码”和“直觉型编码”之间的区别。后者是指寄希望于人工智能能生成可运行的代码。前者是指在人工智能编写代码之前，就已经知道可运行的代码应该是什么样子。
2. 我把验证当作真正的工作。
我以前总觉得代码审查是完成真正工作之后才做的苦差事。现在，它本身就是真正的工作。StrongDM 团队把这种理念发挥到了极致——他们的“黑暗工厂”模式完全不进行人工代码审查。所有投入都用于测试、工具和模拟。人类负责定义什么是正确的代码，其他一切都由机器完成。
我还没达到目标，但方向很明确：我的价值不在于编写代码，而在于定义“正确”在我的特定语境下意味着什么。
3. 我不再以产出来衡量生产力。
代码行数越多，生产力并不高。提交的 PR 越多，生产力也不高。Harness 2025 的调查发现，67% 的开发者花费在调试 AI 生成的代码上的时间比他们自己编写代码的时间还要多。如果你也是其中之一，那么更快地生成更多代码只会让情况变得更糟，而不是更好。
我现在最关心的指标是：我把多少精力放在了只有我才能做的决策上？架构选择、面向用户的权衡取舍、“我们到底要不要开发这个”——这些都是人工智能做不到的。至于其他的一切，我希望自动化，不是因为这样速度更快，而是因为这样可以腾出精力去解决真正棘手的问题。
令人不安的暗示
如果 METR 的研究是正确的——如果人工智能工具实际上并不能为经验丰富的开发人员在熟悉的代码库上节省时间——那么人工智能编码的价值主张就不是“10 倍生产力”。它还有更微妙之处：
如果你有足够的自律性，就能将注意力集中在更有影响力的工作上。
这比“更快地编写代码”更难让人接受。它要求你知道高影响力工作是什么样的，并且能够抵制住观看人工智能在 3 秒钟内生成 200 行代码所带来的多巴胺刺激。
我还没完全弄明白。有时候我还是会凭感觉写代码，然后因为编译通过就假装输出结果很好。METR 研究的认知差距不仅仅存在于他们的参与者身上——它存在于我们所有人身上。
但至少现在，当我感觉自己利用人工智能提高了工作效率时，我会停下来问自己：我真的提高了工作效率吗？还是只是感觉如此？
关注「索引目录」公众号，获取更多干货。