52 名工程师接到同一个任务：用一个没碰过的 Python 库 Trio，写一段能跑的程序。一半人的编辑器侧边栏里挂着 AI 助手，另一半人只能翻文档。
实验设计很干净。先用 10 分钟热身，再做 35 分钟任务，紧接着 25 分钟测验。只有那 35 分钟里，AI 组能用助手。
结果有点冷。用 AI 的那组，测验平均分低了 17%，差不多两个字母等级。差距最大的是调试题。知乎
速度上，AI 组只快了两分钟，统计上不显著。有人花了 11 分钟，写了 15 条提示词，才把任务推下去。
同一批用 AI 的人里，差距也拉开了：把 AI 当解释器、追问概念的人，测验分能到 65% 以上；把活直接外包出去的人，掉到 40% 以下。知乎
这不是「AI 有没有用」的问题。它能把熟悉的活干得很快，但在学新东西时，它把最该由你走的那段路，替你走了。
METR 的实验更扎心。16 名资深开源开发者，246 个真实 issue。用 AI 之后，平均慢了 19%。实验前他们估计自己能快 24%，做完之后仍然觉得快了 20%。知乎专栏知乎
慢了 19%，觉得快了 20%。两个数字摆在一起。工具没坏，是人很难察觉时间去了哪：写提示词、等生成、读代码、发现不对、再改提示词。这些碎片加起来，比手写还长。
这件事可以换个说法：AI 没有拿走你的知识，它拿走的是你忍受「不知道」的能力。它把「不知道」从一种正常状态，改判成一种需要立刻消除的故障。知乎
可基本功偏偏长在这段故障里。第一次设计缓存，你只想着怎么查得快；直到线上出现脏数据，顺着更新链路追了一下午，才真正明白一致性难在哪。知乎
第一次做异步消息，你只想着怎么投递；直到重复消费、消费者异常退出、任务状态对不上，才理解幂等不是八股。
这些时刻没有产出，也不好受，但它们会在脑子里留下一张图。下次看到嵌套事务，你会本能地皱眉。
一个写了十几年 TDD 的开源开发者，停用 AI 一个月后复盘：原本 20 分钟能写完的功能，review 要花两天；一个小任务烧掉 30 美元 token，卡了半小时没输出。小红书
最让他后背发凉的是，他提交的测试用例没覆盖对应场景，自己没看出来。
他说，你慢慢会接受一些以前绝对不会接受的烂代码，因为你已经判断不出它为什么烂了。小红书
我不是劝人把 AI 关掉。重复的 CRUD、脚手架、迁移脚本、单测骨架，交给它没问题，这些活练一百遍也不会让判断力变好。
要留的是另一部分。首席架构师 Carlos Kelkboom 的做法是：项目开始前自己花 20 分钟到 1 小时搭骨架，定目录、关键文件、函数签名。36氪
主 Agent 不许直接改文件，只负责把需求聊清楚；生成的东西看不懂，就整段扔掉重来。36氪
这套做法不神秘，核心只有一句：让 AI 干实现，别让它替你决定。
个人能做的更简单。下次卡住，先别急着把报错贴给 AI，给自己十分钟，哪怕只是把问题重新描述一遍。每周挑一个做过的任务，关掉 AI 从零重写，再和它的版本对 diff。差距集中的地方，就是你真实的水位。
AI 把「从想法到能跑」从三个月压到三天，这是好事。被压掉的那段路里，有一部分东西长在人身上。它压不掉，只能长，或者不长。
所以真正的问题不是「AI 会不会写代码」，是没网的那天，你还能不能坐下来，把一个问题想明白。
