在过去的几个月里，我读了很多关于AI依赖后果的文章，其中一个突出的发现是认知萎缩。换句话说，这是因为过度依赖AI而导致的技能逐渐退化。
大多数认识到的问题在于直接解决问题。软件工程师下意识地先问AI该怎么做，而不是自己思考解决方案。这意味着跳过了至关重要的思考过程。这也是我选择上面横幅的主要原因：《盲人领盲人》（1568），作者是Pieter Bruegel the Elder。
它描绘了一排盲人被另一个盲人领着，直到他们最终绊倒摔落。这幅几百年前的画作仍然映射出当今世界发生的事情。唯一的区别是，我们正在故意让自己变得盲目
提示 > 接受 > 重复
注意这里没有审查步骤。这就是问题所在。你可能觉得这个工作流没问题。你可能会说「这只是个小改动，根本不用担心」，直到你一次又一次地重复这个过程，这些「小改动」最终会积累。放长时间来看，你会慢慢意识到，没有AI你已经无法「编码」了。
我们现在故意不再查看生成的代码。
AI生成的代码看起来既整洁又具有欺骗性。界面看起来很好，而且它自己生成的测试也能通过。就像代码库里的一切都是彩虹和阳光构成的。难怪工程师们只是接受更改然后继续前进。但我们不仅仅是这样。
技能退化并非此行业独有。任何长期不使用的技能最终都会退化。在你自己动手完成任务之前，指定 要做什么总是更容易。实际上，仅仅下达指令往往与真正执行任务不同。
亲自执行任务会迫使你的大脑去思考。你会找到正确的边界情况。你会更多地考虑用户体验。你会思考哪些测试有意义。你会发现哪些代码更重要。这就是亲自动手并将AI用作重复任务的补充的美妙之处。当我们把所有思考都外包给AI时，情况就完全不同了。
当然你可以争论说人写的代码并不完美。我们中的大多数人都不是天赋异禀的程序员。我们的代码经常会出现人为错误。但正是这一点使它已经具有价值。
有人对它负责。
有人已经对这个决定负责。有人已经承担起责任。有人已经掌握了上下文。当出现错误时，那个人已经有了基础，他们不是从零开始。他们最初构建了这段代码，也能够修复它。挣扎、做出错误的假设，最终找到正确的解决方案，是获得真正理解的关键步骤。下次他们遇到同样的问题时，他们独自解决它的可能性很大，从而提高效率。
利用 AI 学习，并让它有意识地暴露你的不足。提出质疑，仔细审视它。同时挑战和验证它。这是一种更健康的使用 AI 的方式，而不放弃思考过程本身。但如果你打算把所有工作都交给它，你不如直接宣布自己是 AI 的按键机器人。
盲目信任会产生多米诺骨牌效应
当未经审查的 AI 生成代码被推送到 PR 审查时，多米诺骨牌开始倒下。初级开发者信任 AI，高级开发者信任初级开发者，最终代码进入生产环境。这不仅会导致认知萎缩，还会产生错误的信任感。
我们是如何让事情发展到这一步的？
速度从来都不是衡量代码质量的最佳标准。代码库本身就很脆弱。它一直都是这样。一个错误的实现可能会导致众多错误。
AI 会写出看似完美且令人信服的代码。作者看到后会陷入一种幻觉，认为它能运行而无需真正理解。在这段新代码被推送的瞬间，上下文已经丢失。你是在赌它能从一开始就工作，而不是通过实际查看它来有意提高成功的概率。
高级开发者不再首先问这是否是一个好的改动，而是可能先怀疑初级开发者是否真的理解他们发送的内容（或者说他们是否甚至没有阅读过代码）。
谁会喜欢阅读超过 1000 行的垃圾代码呢？
阅读 AI 生成的代码具有传染性，以至于审查者也可能变得懒惰，直接接受更改而不进行审查。
毕竟这是人的本性。如果一次引入太多变更，质量检查就不会得到统一实施。这会诱使审阅者跳过整个变更，只浏览重要部分，甚至更糟的是依赖 AI 审查代理。这会增加更多不确定性。
AI 很好，但前提是作为 补充 而非 替代 使用。它是一种需要正确、负责任地使用的工具。你不能强迫所有人都采用这一工作流，但你总可以从自己开始。发送前先阅读，理解 PR，有意识地推送。
重点在于让你的 PR 处于 「可供审查」 状态。它不必完美。最重要的是 它是你的，当审阅者询问时，你能够迅速为其辩护。你可以解释代码的方方面面，最终回答 「为什么？」 这个问题。
接下来的一步是让另一双眼睛审视你的代码，进行一些润色，修复一些小的（或大的）问题，或提出额外的重构需求。讨论这些变更正是导致上下文 自然地 传递给团队成员的原因。
如果做得对，人们最终会跟随。如果不然，至少你已经避免了自己陷入 认知萎缩。
人类的思维需要被挑战
为了对抗认知萎缩，我们必须寻找挑战思维的方法。数据表明，当前的工作流程还不够。我们需要锻炼大脑。
就我个人而言，我每天都会至少解决一个编程挑战，记录下自己的过程，并像在教别人解题一样，一步步解释我的思路。下面是我目前的视频合集，只是对着镜头说话并展示我的屏幕。
这能暴露我的不足，我也很喜欢。每次我回顾录像时，都能轻松记下我在哪些地方遇到困难，以及在解释过程中哪些地方会停顿。错误和停顿总能让我回到当前技能水平的现实。但这种设置最好的地方在于，它让我拥有可具体改进的东西，同时保持大脑活跃，促进新连接的形成。
我看到了明显的进步。
当我把最初的录音与我现在的讲解方式相比时，我能感觉到自己思考更敏捷，对所使用的语言和概念也有了更深入的理解。这给我提供了一个真实的对比，我个人更倾向于这种方式。就像在视频游戏里，看到角色属性随时间提升时，我总会被激励去多练习。
除了编码挑战，我也会通过复查最佳实践和方法来仔细审查自己的工作。我发现先在互联网上搜索文档、示例和不同的思路很有用。在形成自己的自己的想法之后，我会使用 AI 来补充这些知识，帮助我更深入地理解主题。
也有的时候，我发现 AI 给出了已被废弃的方法。
如果我事先没有通过自行学习来做好功课，我是不会注意到这一点的。而在我指出这个问题后，AI 的回答是什么？
"你说得对！"
嗯……那就是我意识到 AI 有多不可靠的时候。
这其实是 hit or miss——有时准有时偏。如果你对该主题几乎没有任何知识，就更容易遗漏东西。我的意思是，他们自己在我们输入提示之前就已经在告诉我们这一点。
总的来说，这些是对我有效的活动，但对你可能不同。重要的是你要不断地以适度的方式挑战自己的思维，以保持敏锐。
认知退化会在你决定将思维外包的那一刻悄然爬上来。只有当你发现自己在没有 AI 帮助的情况下，难以像以前那样编码时，你才会意识到这一点。
自律是自我尊重的终极形式
是的，我不会假装自己从未尝试过使用 AI 生成的代码，而实际上我尝试过，而且我不喜欢它。我打开了本地主机，迎接我的却是多个错误。这些错误本身并不是让我感到沮丧的原因。我不知道该从哪里着手，这就是问题所在。
无助感和缺乏所有权感让我感到压倒性的困扰。
我并没有编写这段代码，是 AI 生成的。于是我继续尝试，再次进行提示。它给出了大约三到五个我需要先验证的预检查步骤来解决问题。这让我精疲力尽。 这种工作流程并不适合我。当错误仍未得到修复时，它又给出了一份新的预检查列表和可能的修复方案，基本上生成了另一个解决方案，就这样一遍又一遍。
有人可能会说我还没有足够的经验，也没有正确的提示词，或者我缺少用于描述架构和额外上下文的正确 Markdown 文件。这话也有道理。
但如果我们愿意走这么远，只是为了让 AI 生成能 "能工作" 的代码，那么我们不如亲自动手写代码。
好吧，我自己来。于是我就这样做了。
我花了大约 15-30 分钟来调试、重复、研究、修复、再次出错、再次修复，最终完成了我需要的组件。过程中有艰难，但我知道自己在前进。这种感觉就像在亲身攀爬梯子，挣扎是真实可感的。
更重要的是，我比以前掌握了更多知识。我的代码是我自己的。我的错误是我自己的。我的解决方案也是我自己的。最终，我获得的理解是持久的。
在这个设置中，我的唯一敌人就是自律。
我曾读到一句关于自律的名言：“自律是自尊的最高形式”。这句话在我读到的那一刻就深深印在脑中，我认为它在这里完全适用。
在代码生成日益简便的世界里，坚持不走捷径、靠自律去学习是一种 超能力。基本功始终贯穿于我们所从事的每一项工作。通过正确的自律投入基本功，潜在地赢得了自尊，最终也会赢得周围工程师的尊重。
睁开眼睛
解决方案很简单。
为了对抗认知退化，我们应该多自己动脑。我们动脑越多，就越能保留那些我们辛苦建立起来的技能。
我并不是说我们应该完全放弃 AI。那样会浪费一个可用的资源。我的意思是要负责任地使用 AI。把它当作一种工具和补充，能够进一步提升我们的思考，而不是取代它。
AI 虽然强大，但不应到它接管软件开发中每一个决策的程度。那样只会直接导致认知退化。请记住，AI 会放大工程师所控制的积极和消极的做法。就像任何其他工具一样，如果使用不当，其输出最终会偏离预期。
到了一天的尽头，加入一代仍然看重质量的软件工程师。它不必完美，也不必交付得很快。重要的是，你要对它负责，能够为它辩护，出问题时能够修复它，最终，你会不断自我提升。不要让便利成为你外包思考的理由。
所以，睁开你的眼睛。
感谢阅读。这篇文章比我预期要长。我临时决定加入这张《复仇者联盟：毁灭日》预告片的史诗图片。我认为它与结尾非常契合。拜拜。
