Levix's zone

编程中 AI 助手的兴起引发了一个悖论：我们可能在提高生产力的同时，若不谨慎行事，将面临技能退化的风险。技能退化指的是由于缺乏使用或练习，技能随时间推移而下降或丧失。

如果 AI 不可用，你会完全束手无策吗？

每位开发者都清楚将繁琐任务交给机器的吸引力。既然 AI 能按需提供答案，何必记忆文档或筛选教程？这种认知卸载 —— 依赖外部工具处理脑力任务 —— 早有先例。想想 GPS 导航如何削弱了我们寻路的本领：一位工程师坦承，多年盲目跟随谷歌地图后，他的道路导航技能 “已经退化”。同样，AI 驱动的自动补全和代码生成器可能诱使我们在常规编码任务中 “关闭大脑”。（向那位忘记如何导航的工程师 Dmitry Mazin 致敬，他的博文也提到了如何在不丧失技能的情况下使用 LLM）

将机械性工作外包并非本质上的坏事。实际上，我们许多人正经历一场复兴，得以尝试那些原本可能不会着手进行的项目。正如资深开发者西蒙・威利森所言：“在这个被 AI 增强的奇异新现实中，最让我兴奋的是它让我能够对项目抱有更大野心。” 随着 AI 处理样板代码和快速原型设计，曾经需要数天的想法如今一个下午就能实现。速度和效率的提升是真实的 —— 取决于你想构建什么。危险在于如何划清健康自动化与核心技能有害退化之间的界限。

批判性思维正在成为牺牲品吗？

最新研究敲响警钟：我们的批判性思维和问题解决能力可能在悄然退化。微软与卡内基梅隆大学研究人员 2025 年的一项研究发现，人们越依赖 AI 工具，其批判性思维运用就越少，导致需要时更难调动这些技能。

本质上，对 AI 能力的高度自信会让人在心理上产生依赖 ——"松开方向盘"，尤其是在简单任务上。当任务感觉简单时，人类天性会放松警惕，但久而久之这种 "长期依赖" 可能导致 "独立解决问题能力的退化"。研究甚至指出，在 AI 协助下，工作者针对同一问题提出的解决方案多样性降低，因为 AI 倾向于根据其训练数据提供同质化答案。用研究者的话说，这种一致性可被视为 "批判性思维本身的退化"。

批判性思维存在几大障碍：

• 认知障碍（过度依赖 AI，尤其是处理常规任务时）
• 动机障碍（时间压力、工作范围限制）
• 能力障碍（难以验证或改进 AI 的响应）

这在日常编码中是什么样子？起初很微妙。一位工程师坦言，在编程 12 年后，AI 的即时帮助让他 “在自己的手艺上变得更糟”。他描述了一种逐渐的退化：首先，他不再阅读文档 —— 既然 LLM 能即时解释，何必费心？

随后，调试技能逐渐退化 —— 堆栈跟踪和错误信息让人望而生畏，于是他干脆将它们复制粘贴到 AI 中寻求修复。“我变成了一个人肉剪贴板，” 他哀叹道，盲目地将错误传送给 AI，又将解决方案传回代码。过去，每个错误都能教会他新东西；如今解决方案神奇地出现，他却一无所获。即时答案带来的多巴胺快感取代了来之不易的理解所带来的满足感。

随着时间的推移，这种循环不断加深。他指出，深度理解能力是接下来丧失的 —— 他不再花数小时真正理解一个问题，而是直接实施 AI 给出的任何建议。如果方案无效，他就调整提示词再次询问，陷入 “依赖性不断增强的循环”。甚至开发过程中的情感回路也发生了变化：曾经解决棘手漏洞的喜悦，如今变成了若 AI 五分钟内未能给出解决方案便感到沮丧。

简而言之，通过将思考外包给 LLM，他正在用长期精通换取短期便利。“我们并没有因为 AI 成为 10 倍效率的开发者 —— 而是变得 10 倍依赖 AI，” 他指出。“每次让 AI 解决本可自行解决的问题，我们都在用长期理解力换取短期生产力”。

你的技能正在退化的微妙迹象

这并非仅是假设 —— 有迹象表明，过度依赖 AI 可能正在侵蚀你在软件开发中的工艺水平：

• 调试绝望：你是否跳过调试器，直接向 AI 求助每一个异常？如果现在阅读堆栈跟踪或逐步执行代码让你感到吃力，那就要警惕这项技能的退化。在 AI 出现之前，与 bug 搏斗是学习的熔炉；如今却很容易将这份努力外包出去。一位开发者坦言，他甚至不再完整阅读错误信息 —— 直接丢给 AI 处理。结果就是：当 AI 无法使用或束手无策时，他对如何用传统方法诊断问题一筹莫展。

• 盲目复制粘贴编程：让 AI 编写样板代码是可以的，但你是否理解它给出的代码为何有效？如果你发现自己粘贴的代码无法独立实现或解释，那就需要小心了。尤其是年轻开发者们报告称，借助 AI 他们能比以往更快地交付代码，但当被问及为何选择特定解决方案或如何处理边缘情况时，他们却哑口无言。那种通过反复尝试不同方案而积累的基础知识…… 就这样缺失了。

• 架构与全局思维：复杂系统设计无法通过单一提示解决。如果你已习惯用 AI 处理零散问题，可能会发现自己不愿在没有 AI 的情况下进行更高层次的架构规划。AI 能推荐设计模式或方案，但无法理解你独特系统的完整背景。过度依赖可能导致你缺乏在脑海中整合组件的练习。例如，你可能直接采纳 AI 推荐的组件，却未考虑它如何融入整体性能、安全性或可维护性 —— 这正是资深工程师通过长期实践形成的直觉所擅长的。若长期缺乏这类系统级思考的锻炼，相关能力便会退化。

• 记忆力与回忆能力下降：基本的 API 调用或语言习惯是否开始从你的记忆中溜走？忘记不常用的细节是正常的，但如果因为 AI 自动补全总是代劳，导致日常语法或概念现在对你来说变得陌生，你可能正在经历技能退化。你肯定不想变成那种依赖计算器、连手算都忘了的学生。

值得注意的是，随着时间的推移，某些技能的丧失是自然的，有时也是可以接受的。

我们都已摒弃了过时的技能（你上一次手动用汇编语言管理内存，或是不用计算器做长除法是什么时候？）。有人认为担忧 “技能退化” 只是在抗拒进步 —— 毕竟，我们欣然让老一辈的技能如手写信件或阅读地图逐渐淡出，为新技能腾出空间。

关键在于区分哪些技能可以放心外包，哪些必须保持熟练。失去手动内存管理的技巧是一回事；因为只跟随 AI 的指引而在紧急情况下失去调试实时系统的能力，则是另一回事。

速度与知识的权衡：AI 提供快速答案（高速度，低学习），而传统方法（Stack Overflow、文档）速度较慢但能建立更深层次的理解

在追求即时解决方案的匆忙中，我们可能只触及表面，而错失了构建真正专业知识的背景。

过度依赖的长期风险

如果这一趋势不加遏制地持续下去会怎样？首先，你的职业生涯可能会遭遇一场 “批判性思维危机”。如果一直依赖 AI 替你思考，当工具失灵时，你可能会发现自己无力应对新问题或紧急状况。

正如一位评论者直言不讳所说：“你越多使用 AI，就越少动用自己的大脑…… 所以当你遇到 AI 无法解决的问题时，你自己是否具备解决的能力？” 这是个发人深省的问题。我们已经目睹了一些小规模危机：当 AI 编程助手宕机时，开发者因工作流程陷入停滞而惊慌失措。

过度依赖也可能成为一种自我实现的预言。微软研究报告的作者警告称，如果你担心 AI 会取代你的工作，却又 "不加批判地使用它"，实际上可能会让自己技能退化，变得无足轻重。在团队环境中，这会产生连锁反应。如今那些跳过 "困难方式" 的初级开发者，未来可能因缺乏深度而早早停滞，难以成长为高级工程师。

如果整整一代程序员 “从未体验过真正独立解决问题的满足感”，也 “从未通过数小时与漏洞搏斗获得深刻理解”，我们最终可能培养出一批只会按按钮、依赖 AI 指导才能工作的劳动力。他们将擅长向 AI 提出正确问题，却无法真正理解答案。而当 AI 出错时（它经常以微妙的方式犯错），这些开发者可能无法察觉 —— 这将成为代码中潜伏漏洞和安全风险的温床。

此外，还需考虑团队动态和文化影响。如果每个人都埋头与 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 辅助工程书籍。如果你喜欢我在这里的写作，可能会有兴趣了解一下。

原文链接：

https://addyo.substack.com/p/avoiding-skill-atrophy-in-the-age