在AI时代避免技能退化
摘要
如何在使用AI编码助手的同时，避免让你辛苦获得的工程技能逐渐衰退。
AI助手在编码领域的崛起引发了一个悖论：我们可能正在提高生产力，但如果不小心，就有可能因技能退化而失去优势。技能退化是指由于缺乏使用或练习，技能随时间推移而下降或丧失。
如果没有AI，你会完全陷入困境吗？
每个开发者都知道将繁琐任务交给机器处理的吸引力。当AI可以按需提供答案时，为什么还要记住文档或翻阅教程呢？这种认知卸载——依赖外部工具来处理心智任务——有很多先例。想想GPS导航如何侵蚀了我们的寻路能力：一位工程师承认，在多年盲目跟随Google地图后，他的道路导航技能"已经退化"。同样，AI驱动的自动补全和代码生成器可能会诱使我们在日常编码任务中**"关闭大脑"**。（向Dmitry Mazin致敬，那位忘记如何导航的工程师，他的博客文章也谈到了如何在不失去技能的情况下使用LLM）
卸载机械性工作本身并不坏。事实上，我们许多人正在经历一场文艺复兴，让我们能够尝试原本不太可能处理的项目。正如资深开发者Simon Willison所说，"在我们这个奇怪的AI增强现实中，最让我兴奋的是它让我能够在项目上更有雄心"。有了AI处理样板代码和快速原型，曾经需要数天的想法现在似乎在一个下午就能实现。速度和生产力的提升是真实的——取决于你想要构建什么。危险在于在哪里划清界限，区分健康的自动化和有害的核心技能退化。
批判性思维正在成为牺牲品吗？
最近的研究正在敲响警钟，我们的批判性思维和解决问题的能力可能正在悄悄恶化。微软和卡内基梅隆大学研究人员的一项2025年研究发现，人们越依赖AI工具，参与的批判性思维就越少，这使得在需要时更难调动这些技能。
本质上，对AI能力的高度信心导致人们在心理上退居二线——"放开方向盘"——尤其是在简单任务上。当任务感觉简单时，人类本能地放松，但随着时间推移，这种**"长期依赖"可能导致"独立解决问题能力的减弱"**。研究甚至指出，有AI辅助的工作者对同一问题产生的解决方案多样性较低，因为AI倾向于基于其训练数据提供同质化的答案。用研究人员的话说，这种一致性本身可以被视为*"批判性思维的恶化"*。
批判性思维存在几个障碍：
意识障碍（过度依赖AI，尤其是在日常任务中）
动机障碍（时间压力、工作范围限制）
能力障碍（难以验证或改进AI响应）
这在日常编码中是什么样子？它开始得很微妙。一位工程师承认，在12年的编程生涯后，AI的即时帮助让他*"在自己的技艺上变得更差"*。他描述了一种逐渐的衰退：首先，他停止阅读文档——当LLM可以立即解释时，为什么还要费心呢？
然后调试技能减弱——堆栈跟踪和错误消息感觉令人生畏，所以他只是将它们复制粘贴到AI中寻求修复。"我已经成为一个人类剪贴板"他感叹道，盲目地将错误传递给AI，然后将解决方案传回代码。每个错误曾经教会他一些新东西；现在解决方案神奇地出现，他什么也学不到。即时答案的多巴胺冲击取代了来之不易的理解所带来的满足感。
随着时间推移，这个循环加深。他指出深度理解是下一个消失的——他不再花几个小时真正理解一个问题，而是实现AI建议的任何东西。如果不起作用，他就调整提示词再问一次，进入*"日益依赖的循环"*。甚至开发的情感回路也发生了变化：曾经解决棘手bug的喜悦，现在变成了如果AI在5分钟内没有给出解决方案的挫败感。
简而言之，通过将思考外包给LLM，他正在用短期便利换取长期掌握。*"我们不是通过AI成为10倍开发者——我们正在成为10倍依赖AI"*他观察到。"每次我们让AI解决一个我们本可以自己解决的问题，我们就是在用长期理解换取短期生产力"。
你的技能正在退化的微妙迹象
这不仅仅是假设——有一些明显的迹象表明，对AI的依赖可能正在侵蚀你在软件开发中的工艺：
调试绝望： 你是否跳过调试器，直接向AI求助处理每个异常？如果现在阅读堆栈跟踪或逐步执行代码感觉艰难，请留意这项技能。在AI之前的时代，与bug搏斗是一个学习的熔炉；现在很容易将这种努力外包出去。一位开发者承认，他甚至不再完整阅读错误消息——他只是将它们发送给AI。结果是：当AI不可用或困惑时，他不知道如何用老式方法诊断问题。
盲目复制粘贴编码： 让AI编写样板代码是可以的，但你理解它给你的代码为什么有效吗？如果你发现自己粘贴的代码是你无法自己实现或解释的，要小心。年轻开发者特别报告说，使用AI比以往更快地交付代码，但当被问到为什么选择某个解决方案或它如何处理边缘情况时，他们一片茫然。通过探索替代方案而来的基础知识就是……缺失的。
架构和全局思维： 复杂的系统设计无法通过单个提示解决。如果你已经习惯于用AI解决小问题，你可能会注意到在没有它的情况下不愿意处理更高层次的架构规划。AI可以建议设计模式或模式，但它不会掌握你独特系统的完整上下文。过度依赖可能意味着你没有练习在心理上将组件拼凑在一起。例如，你可能接受AI建议的组件，而不考虑它如何适应更广泛的性能、安全性或可维护性图景——这是经验丰富的工程师通过来之不易的直觉所做的事情。如果这些系统级思维肌肉没有得到锻炼，它们可能会减弱。
记忆和回忆能力减弱： 基本的API调用或语言习语是否从你的记忆中溜走？忘记很少使用的细节是正常的，但如果日常语法或概念现在逃离你，因为AI自动补全总是填充它，你可能正在经历技能衰退。你不想成为依赖计算器的学生，忘记了如何手工做算术。
值得注意的是，随着时间推移，一些技能损失是自然的，有时是可以接受的。
我们都放弃了过时的技能（你上次在汇编中手动管理内存，或在没有计算器的情况下做长除法是什么时候？）。有些人认为，担心"技能退化"只是在抵制进步——毕竟，我们很乐意让老一辈的技能如手写信件或地图阅读消失，为新技能腾出空间。
关键是区分哪些技能可以安全外包，哪些是必须保持敏锐的。失去手动内存管理的诀窍是一回事；因为你只是跟随AI的引导而失去在紧急情况下调试实时系统的能力是另一回事。
速度与知识的权衡：AI提供快速答案（高速度，低学习），而旧方法（Stack Overflow、文档）较慢但建立了更深的理解
在追求即时解决方案的过程中，我们冒着浏览表面并错过构建真正专业知识的上下文的风险。
过度依赖的长期风险
如果这种趋势继续不受控制会发生什么？首先，你可能会在职业生涯中遇到**"批判性思维危机"**。如果AI一直在为你思考，当工具不足时，你可能会发现自己无法处理新问题或紧急问题。
正如一位评论员直言不讳地说："你使用AI越多，你使用大脑就越少……所以当你遇到AI无法解决的问题时，你会有技能自己解决吗？"。这是一个发人深省的问题。我们已经看到了小危机：开发者在AI编码助手中断期间恐慌，因为他们的工作流程陷入停顿。
过度依赖也可能成为自我实现的预言。微软研究作者警告说，如果你担心AI会抢走你的工作，但你*"不加批判地使用它"*，你可能会有效地将自己降级为无关紧要。在团队环境中，这可能会产生连锁反应。今天跳过"艰难道路"的初级开发者可能会早早停滞，缺乏成长为明天高级工程师的深度。
如果整整一代程序员*"从未知道真正独立解决问题的满足感"，"从未体验到"*与bug搏斗数小时带来的深刻理解，我们最终可能会得到一支只能在AI指导下运作的按钮推手队伍。他们会擅长向AI提出正确的问题，但不会真正理解答案。当AI出错时（它经常以微妙的方式出错），这些开发者可能不会发现——这是bug和安全漏洞溜进代码的配方。
还有团队动态和文化影响需要考虑。如果每个人都埋头使用他们的AI配对程序员，指导和通过渗透学习可能会受到影响。如果初级开发者习惯于询问AI而不是他们的同事，高级工程师可能会发现更难传递知识。
如果这些初级开发者没有建立坚实的基础，高级开发者将花更多时间修复训练有素的人类会发现的AI生成的错误。从长远来看，团队可能会变得不如其各部分之和——一群个体，每个人都悄悄依赖他们的AI拐杖，共享的强大实践较少。公交车因素（在项目崩溃之前需要多少人被公交车撞）可能实际上包括"如果AI服务宕机，我们的开发是否会陷入停顿？"
这一切并不是说我们应该回到烛光下编码。相反，这是呼吁明智地使用这些强大的工具，以免我们**"不仅外包工作本身，还[外包我们的]批判性参与"**）。目标是在不掏空你的技能集的情况下获得AI的好处。
将AI用作协作者，而非拐杖
我们如何享受AI编码助手的生产力提升，同时保持头脑敏锐？关键是有意识的参与。将AI视为协作者——一个初级配对程序员或一个随时可用的橡皮鸭——而不是一个无懈可击的神谕或问题的倾倒场。以下是一些需要考虑的具体策略：
实践"AI卫生"——始终验证和理解。 不要仅仅因为看起来合理就接受AI输出是正确的。养成_红队_AI建议的习惯：积极寻找其代码中的错误或边缘情况。如果它生成一个函数，用棘手的输入测试它。问自己，"为什么这个解决方案有效？它的局限性是什么？"通过询问AI逐行解释代码或提供替代方法，将AI用作学习工具。通过质疑AI的输出，你将被动的答案变成主动的课程。
基础知识不用AI——有时，挣扎是好的。 故意在一周中保留一部分时间进行"手动模式"编码。一位经验丰富的开发者设立了**"无AI日"**：每周一天，他从头开始编写代码，完整阅读错误，并使用实际文档而不是AI。起初很令人沮丧（"我感觉更慢、更笨"他承认），但就像一次艰难的锻炼，它重建了他的信心并加深了他的理解。你不必完全戒掉AI，但定期在没有它的情况下编码可以防止你的基本技能熵增。把它想象成为你的编码大脑进行交叉训练。
在询问AI之前，始终自己尝试解决问题。 这是经典的"开卷考试"规则——你会通过先挣扎一点来学到更多。在让AI填空之前，制定一个方法，即使只是伪代码或猜测。如果你在bug上卡住了，花15-30分钟自己调查（使用打印调试、控制台日志，或只是推理代码）。这确保你锻炼了解决问题的肌肉。之后，咨询AI并不可耻——但现在你可以将它的答案与你自己的思考进行比较，并真正从任何差异中学习。
使用AI来增强，而不是替代代码审查。 当你得到AI生成的代码片段时，像审查人类同事编写的代码一样审查它。更好的是，对AI贡献也进行人工代码审查。这使团队知识保持在循环中，并捕获单个开发者在信任AI时可能错过的问题。在文化上，鼓励*"AI可以起草，但我们拥有它"*的态度——意味着团队负责理解和维护存储库中的所有代码，无论谁（或什么）最初编写了它。
参与主动学习：跟进和迭代。 如果AI解决方案有效，不要只是继续前进。花点时间巩固这些知识。例如，如果你使用AI实现了一个复杂的正则表达式或算法，之后尝试用简单的英语解释它（对自己或队友）。或者问AI为什么那个正则表达式需要那些特定的标记。对话式地使用AI来加深你的理解，而不仅仅是复制粘贴答案。一位开发者描述使用ChatGPT生成代码然后用后续问题和"为什么不用另一种方式？"来轰炸它——类似于拥有一个无限耐心的导师。这将AI变成了导师而不仅仅是代码分配器。
保持学习日志或"AI辅助"列表。 跟踪你经常向AI寻求帮助的事情——这可能是你想要弥补的知识差距的标志。如果你注意到你多次要求AI帮助在CSS中居中div或优化SQL查询，记下来真正学习那个主题。你甚至可以根据AI解决方案为自己制作抽认卡或练习（拥抱我们知道对记忆力很好的检索练习）。下次你面对类似问题时，挑战自己在没有AI的情况下解决它，看看你是否记得如何做。将AI用作后备，而不是重复任务的第一站。
与AI配对编程。 不要将AI视为你向其提供查询的API，而是尝试配对编程的心态。例如，你编写一个函数，让AI建议改进或捕获错误。或者反过来：让AI编写草稿，你来完善它。保持持续对话："好的，那个函数有效，但你能帮我重构它以提高清晰度吗？"——这让你保持在驾驶座上。你不仅仅是在消费答案；你在实时策划和指导AI的贡献。一些开发者发现，使用AI感觉就像有一个擅长繁重工作但需要监督的初级开发者——你是循环中的高级开发者，负责最终结果。
通过整合这样的习惯，你确保使用AI仍然是净正面的：你获得了加速和便利，而不会慢慢失去独立编码的能力。事实上，这些实践中的许多可以将AI变成磨练你技能的工具。例如，使用AI解释不熟悉的代码可以加深你的知识，尝试用棘手的案例难倒AI可以增强你的测试思维。区别在于保持积极参与而不是被动依赖。
结论：保持敏锐
软件行业正在AI引领代码生成的情况下快速前进，这个精灵无法放回瓶子里。拥抱这些工具不仅是不可避免的；它通常是有益的。但当我们将AI整合到工作流程中时，我们每个人都必须*"走一条细线"*，决定我们愿意向机器让步什么。
如果你热爱编码，这不仅仅是更快地输出功能——它还关乎保护最初让你进入这个领域的工艺和解决问题的乐趣。
使用AI来放大你的能力，而不是取代它们。让它把你从繁重的工作中解放出来，这样你就可以专注于创造性和复杂的方面——但不要让那些基础技能因不使用而退化。对事物如何以及为什么工作保持好奇。即使AI给你一条捷径，也要继续磨练你的调试直觉和系统思维。简而言之，让AI成为你的协作者，而不是你的拐杖。
那些茁壮成长的开发者将是那些将他们的人类直觉和经验与AI的超能力配对的人——那些可以在有和没有自动驾驶的情况下导航代码库的人。通过有意识地练习和挑战自己，你确保当花哨的工具不足或出现真正新颖的问题时，你仍然会在方向盘后面，敏锐并准备好解决。不要担心AI会取代你；担心不培养使你不可替代的技能。正如谚语所说（带有现代转折）："AI给予的，工程师的头脑仍然必须理解。" 保持那个头脑参与，你就会驾驭AI浪潮而不会翻车。
额外提示： 下次当你想让AI编写整个功能而你只是观看时，把这当作你的提醒，卷起袖子自己写一点。你可能会惊讶于你记得多少——以及再次锻炼那些心智肌肉的感觉有多好。不要让AI辅助开发的未来让你在智力上闲置。使用AI来提升你的生产力，但永远不要停止积极练习你的技艺。
明天最好的开发者将是那些没有让今天的AI让他们忘记如何 思考的人。
我很高兴分享我正在与O'Reilly合作撰写一本新的AI辅助工程书籍。如果你喜欢我在这里的写作，你可能会有兴趣查看它。
