现代软件工程师缓慢而安静的认知退化
作者认为 AI 依赖最突出的后果不是代码变差，而是认知退化：提示、接受、重复，中间少了审阅这一步，虚假的信任还会一环环往下传。他写了自己每天解一道编程题并录像讲题的对抗方法，以及一次亲手调试换来的踏实感。
中文
复制
过去几个月里，我读了很多关于 AI 依赖后果的文章，其中一个反复出现的发现是认知退化。换句话说，就是因为过度依赖 AI，技能在不知不觉中衰退。
这些反思大多指向不直接去解决问题。软件工程师会本能地先问 AI 该怎么做，而不是自己去想一个方案。这意味着跳过了思考这个关键过程。这主要也是我选上面那张题图的原因：老彼得·勃鲁盖尔的《盲人引盲》（1568）。
画里是一排盲人，由一个同样看不见的人领着走，最后一个个跌倒。这幅几百年前画的画，仍然映照着今天的世界。唯一的区别是，我们是在故意把自己弄瞎
提示 > 接受 > 重复
注意，这个流程里没有审阅这一步。这就是问题所在。你可能觉得这个工作流没问题，你可能会说_「只是个小改动，真没什么好担心的」_，直到你把这个过程一遍又一遍重复下去，这些 「小改动」 最终累积起来。把它拉长到长期来看，你会慢慢意识到，没有 AI 你已经 「写不动代码」 了。
我们在有意地不再去看一眼生成的代码。
AI 生成的代码干净，同时又在骗人。UI 看着不错，测试（也是它生成的）也过了。就好像代码库里的一切都是用彩虹和阳光做的。难怪工程师们只是接受改动，然后继续往前走。但我们不该只是这样。
技能退化并不是这个行业独有的。任何不经常使用的技能最终都会退化。_嘴上指挥_该怎么做，总是比自己_动手做这件事_更容易。而很多时候，指挥别人做一件事，跟真正去实现它并不是一回事。
自己动手执行任务会逼着你的大脑思考。你会找到真正的边界情况。你会更多地去考虑 UX。你会去想哪些测试才有意义。你会发现哪部分代码更重要。这就是亲自动手、把 AI 当作重复性任务的补充的价值所在。而当我们把全部思考都外包给 AI 时，就完全是另一回事了。
当然你可以说，人写的代码也不完美。我们大多数人并不是_天赋型程序员_。我们的代码里常常有_人的错误_。但这恰恰是它已经很有价值的主要原因。
它背后连着一个人。
已经有人对这个决定负责。已经有人要为它担责。已经有人掌握着上下文。出了错的时候，这个人已经有底子，不是从零开始。代码本来就是他建的，他也能修。挣扎、做出错误假设、最终找到正确的解法，这些正是真正理解的必经之路。下次再遇到同样的问题，他这次很可能能自己解决，效率也就更高了。
用 AI 来学习，并且故意让它暴露你的漏洞。质疑它、审视它。一边挑战它，一边验证它。这是一种健康得多的用 AI 的方式，不会把思考过程本身交出去。但如果你打算把所有工作都委托给它，那你不如直接宣布自己是替 AI 按 Tab 键的机器人。
盲目信任会引发多米诺效应
当未经审阅的 AI 生成代码被推上去做 PR 审阅时，多米诺骨牌就开始倒了。初级工程师信任 AI，高级工程师信任初级工程师，代码最终进了生产环境。这不仅造成认知退化，还会造出一种虚假的信任感。
我们是怎么让自己走到这一步的？
速度从来不是衡量代码质量的最好标准。代码库是脆弱的。它一直都很脆弱。一处错误的实现就能引发一连串错误。
AI 写出的代码完美地令人信服。作者看了一眼，就陷进「它能用」的错觉里，而没有真正理解它。这段新代码被推上去的那一刻，上下文就已经丢了。你是在赌它从一开始就能用，而不是靠_真的去看一眼_来刻意提高成功的概率。
高级工程师先想的可能不是这个改动好不好，而是初级工程师到底明不明白自己提交了什么（或者他到底有没有读过这段代码）。
谁喜欢读一千多行的垃圾？
读 AI 生成的代码是_会传染的_，传染到审阅者自己也懒了，不看就直接接受改动。
这毕竟是人的天性。如果一次引入的改动太多，质量检查就没法均匀地做下去。它诱惑审阅者草草翻完整个改动、只看重点部分，更糟的是，在此之上再依赖 AI 审阅 agent。这又添了一层不确定性。
AI 很好用，但只在它作为_补充_、而不是_替代品_的时候。它是一件要被正确、负责任地使用的工具。你没法强迫所有人都用这套工作流，但你总可以从自己开始。发出去之前先读，把 PR 弄明白，有意识地推送。
要点是让你的 PR_「准备好被审阅」。它不必完美。最重要的是_它是你的，审阅者一问，你就能立刻为它辩护。你能把代码的来龙去脉讲清楚，最终回答出那个问题：「为什么？」
下一步是让另一双眼睛看过你的代码，做一些润色，做一些小（或大）的修正，或者要求进一步重构。讨论改动这个过程本身，就是让上下文_自然地传递_给团队成员的方式。
做对了，别人最终会跟上。没做对，至少你把自己从认知退化里救了出来。
人的大脑需要被挑战
要对抗认知退化，我们必须想办法挑战自己的大脑。数据表明，现在的工作流并不够。我们需要锻炼自己的大脑。
就我个人而言，我每天至少解一道编程题，把它录下来，并且一步一步讲解自己的思路，就像在教别人怎么解。下面是我目前录的一批视频，只是对着镜头说话、展示屏幕。
它会暴露我的漏洞，而我喜欢这一点。每次回看录像，我都很容易注意到自己卡住的那些地方，以及在讲解中停顿的地方。错误和停顿总能把我拉回到当前真实水平的现实里。但这套做法最好的一点是，它给了我一个具体的、可以改进的东西，同时让我的大脑保持活跃，让它形成新的连接。
我看到了明显的进步。
拿我最早的那段录像和现在讲解的方式对比，我能看出自己更敏锐了，对正在用的语言和概念也有了更深的理解。它给了我一个真实的对照，而我个人更喜欢这样。就像打游戏一样，看到角色的数值随时间提升，我总会更有动力继续练下去。
除了编程题，我也一定会审视自己的作品，反复检查最佳实践和方法。我发现先去网上找文档、示例和不同的做法很有用。在形成_自己的想法_之后，我再用 AI 来补充这些知识，帮我把这个主题理解得更深。
也有几次，我抓到 AI 在推荐已经废弃的方法。
这种事，如果我没有事先自己下功夫研究这个主题，是不会注意到的。而我指出来之后，AI 的回答是什么？
「你说得完全对！」
对……就是那时候我意识到 AI 有多_不可靠_。
它时灵时不灵。如果你一开始对某个主题几乎一无所知，你就更可能漏掉问题。我的意思是，它们自己在我们打出提示词之前就已经告诉我们了。
但总的来说，这些是对我有效的做法，对你可能不一样。要紧的是，你一直在挑战自己的大脑，挑战到足以让它保持敏锐的程度。
认知退化会在你决定把思考外包出去的那一刻悄悄进来。只有当你发现自己_没有 AI 帮忙就没法像以前那样写代码_时，你才会意识到它。
自律是自尊的终极形式
是的，我不会虚伪地说我一次都没试过用 AI 生成的代码。我用过，而且我不喜欢。我打开 localhost，迎面而来的是好几个 bug。
让我烦躁的不是这些 bug 本身。真正的问题在于，我根本不知道该从哪里看起。
那种无助感、那种「这不是我的东西」的感觉，压得人喘不过气。
代码不是我写的，是 AI 写的。于是我继续，又试了一次提示。它给了我大概三到五个前置检查动作，我得先验证它们才能解决问题。_太累了。_那套工作流不适合我。等 bug 还是没修好，它又给了我一份新的前置检查和可能的修法，本质上就是一次又一次地重新生成另一个方案。
你可以说我还没有足够的经验，没有写对提示词，或者没有提供正确的 markdown 文件来描述架构和其他上下文。这话有道理。
但如果我们愿意费这么大劲去让 AI 的代码 「能用」，那我们不如自己把代码写了。
好吧，我自己来。于是我做了。
我花了大概 15 到 30 分钟：调试、反复琢磨、学习、修、弄坏、再修，然后做出了我需要的那个组件。过程中有挣扎，但那是一种你知道自己正在往前走的挣扎。那种体验像真的在爬梯子。挣扎是摸得着的。
更重要的是，我比以前懂得更多了。我的代码是我自己的。我的错误是我自己的。我的解法是我自己的。最后，我获得的理解是能留下来的。
在这套安排里，我唯一的敌人是我的自律。
我读过一句关于自律的话：「自律是自尊的终极形式。」 我读到它的那一刻它就留在我心里了，而我认为它用在这里恰如其分。
在一个生成代码一天比一天容易的世界里，能不偷工减料地学习，这种自律是一种_超能力_。基本功出现在我们所处的每一件事里。用真正的自律去投入基本功，你会由此赢得自尊，最终也赢得周围工程师的尊重。
睁开眼睛
解法很简单。
要对抗认知退化，我们应该更多地自己去想。我们越锻炼自己的大脑，就越能保住那些我们费了很大力气才建立的技能。
我不是说要彻底放弃 AI。那会浪费一个现成的资源。我说的是负责任地使用 AI。把它当作一件工具、一种补充，让我们的思考再上一个台阶，而不是取代它。
AI 很强，但没强到该接管构建软件过程中每一个决定的程度。那等于给自己开了一张直通认知退化的车票。记住，AI 会放大操作它的那名工程师身上好的做法，也会放大坏的做法。像任何工具一样，用得不对，产出最终就会走偏。
说到底，去做新一代软件工程师中的一员吧，仍然看重质量的那一代。它不必完美，也不必交付得飞快。重要的是它归你所有，你能为它辩护，出了问题你能修，而最终，你自己一直在进步。别让方便成为你把思考外包出去的理由。
所以睁开眼睛。
谢谢你读到这里。这篇比我预想的长。最后那张《复仇者联盟：毁灭日》预告片里的图是我最后一刻决定加的。我觉得它和结尾很搭。拜拜。