1.谷歌工程主管Addy Osmani博客探讨了AI时代开发工程师如何避免技能萎缩的问题。
2.过度依赖AI可能导致人类习惯性地规避主动思考，付出潜在的认知代价。
3.由于AI倾向于基于训练数据提供高度同质化、缺乏创新性的答案，批判性思维和解决问题的能力正在成为过度依赖AI的“牺牲品”。
4.然而，避免AI时代的技能萎缩，最简单的就是保持对代码原理敏锐的好奇心，投入精力去构建和强化那些AI难以替代的核心能力。
以上内容由腾讯混元大模型生成，仅供参考
家人们，不知道有没有人与我一样，在日常工作中已经全力倚仗 AI 工作了！
难的、复杂的，我需要 AI 多帮帮我，简单的、容易的，那 AI 一定干的又快又好我也可以全权委托。
表面上看（实际上也是）极大地提升了我的工作效率，而且“解放”了双手 ～ 但是，非常矛盾的是，我分明察觉到自己的思维似乎变得迟钝了！
不仅难以快速进入深度思考状态，而且在遇到障碍时，第一反应总是寻求 AI 的帮助，这种对 AI 工具的过度依赖似乎导致我出现认知能力“钝化”的现象。
很巧的是！这周末，小鹿刷到了谷歌工程主管 Addy Osmani 的博客，就是讲开发工程师如何避免 AI 时代的技能萎缩，非常有意思，和大家一起分享下 ～
认知分担会带来技能退缩
今天，几乎所有人都意识到—将重复性任务委托给 AI 是非常有效的，AI 的即时响应减少了对详细文档、教程进行人工记忆和检索的必要性和耗时。
用了 AI，直接一键搞定！
将认知负担转移给外部工具，这种做法被称为“认知分担”。这并非一个新现象，最早的例子之一便是 GPS 导航取代传统的寻路方式。而随着 GPS 导航的普及，许多人的独立寻路能力确实随之下降。
通过将认知负担转移给 AI，自动化处理样板代码和加速原型验证等重复性任务，AI 极大地解放了开发工程师，大幅提升了效率与生产力，使他们得以专注于更具价值和挑战性的工作。
然而，这种便利的另一面是，它可能导致人类习惯性地规避主动思考，付出潜在的认知代价。
除了对专业技能和整体认知能力的影响，批判性思维和解决问题的能力也正在成为过度依赖 AI 的“牺牲品”。
由微软与卡内基梅隆大学共同发表的论文提出：研究人员发现，使用者对 AI 工具的依赖度越高，其主动进行批判性思考的频率越低，这直接导致他们在实际需要时，更难有效地调动和运用这些关键能力。
论文链接：
https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf
现象出现原因研究人员也做出了解答：
对 AI 能力的过分信任往往导致个体在心理上“退居二线”，尤其是在处理看似简单的任务时—形象地说，就是“松开了思考的方向盘”。
尽管在任务轻松时放松警惕符合人之常情，但长期过度依赖工具，会显著削弱个体独立分析和解决问题的能力。
此外，研究人员还观察到：在 AI 的辅助下，人们针对同一问题提出的解决方案数量显著减少，这是因为 AI 倾向于基于训练数据提供高度同质化、缺乏创新性的答案，而这样的实验已经证明了批判性思维正在“恶化”。
已经有人发现自己在退步了
一位拥有十二年编程经验的工程师老哥坦承：
AI 的即时辅助反而让我感到自己在“手艺上变差了”。
他描述了一个“悄无声息”的退步过程：
起初只是不再主动查阅官方文档：有了 AI 帮助检索收集知识，何苦还自己费力读呢？ 后来，调试能力也开始减弱：面对堆栈跟踪信息和 Bug 提示不再深入分析，而是直接丢给 AI，让 AI 来提供解决方案。
这老哥的自嘲说的还挺到位的：“我变成了一个人类剪贴板”
在过去的工作中，每一个 Bug 带来的其实也是一次学习过去忽视到的问题的机会；但是现在，解决方案都不用查验、思考，直接喂给你，除了即时得到答案带来的轻松，什么也没真的进入脑子里，完全丢失了通过艰辛努力获得深刻理解的知识。
非常可怕但是又真实的是，这个循环正成为我们日复一日的日常。
老哥还发现，不止解决问题的能力没了，他发现解决问题的需求也没了！
他不再愿意花费数小时去透彻分析一个难题的根源，而是将自己完成的思考工作外包给 AI。如果 AI 的建议不起作用，那就接着修改提示词再问，直到 AI 的方案能解决这个问题。
这样就陷入一个“越来越依赖”的死循环：“未能成为借助 AI 将效率提升十倍的开发者，反而正在变成一个十倍依赖于 AI 的开发者。”
怎么样确诊技能正在萎缩？
随着技术的不断更新迭代，一些不再常用技能、技术和语言的逐渐淡忘，是正常且有时必要的现象。淘汰过时技术是必然趋势，比如，技术迭代后，我们已经不再手动管理汇编内存，也不再依赖计算器进行复杂运算了。
但是，其实仔细想想，遗忘汇编内存管理与因 AI 依赖而丧失独立诊断能力，还不是一回事，AI 提供的是即时结果（快但可能浅显），而通过传统途径（如查文档、搜社区）解决问题，虽耗时，却能带来更全面的认知。
过度追求快速答案的风险，在于可能停留在表面，丢失深厚专业知识所需的背景和洞察能力。
那怎么样“确诊”你的技能已经开始萎缩呢 ～
目前具体迹象有：
调试能力减弱： 倾向将错误直接丢给 AI 而非使用调试器，回避阅读堆栈跟踪。这导致一旦 AI 失效，缺乏独立诊断能力。 对生成代码缺乏理解： 快速粘贴 AI 代码，但在无 AI 辅助时无法重现或解释其逻辑和边界处理。 宏观视野受限： 习惯依赖 AI 解决局部问题，导致处理更高级别系统架构设计时感到困难或逃避。 基础知识淡忘： 即使日常常用的 API 调用或核心概念，也因 AI 自动补全代劳而变得生疏。
将 AI 当作协作者而不是拐杖
Addy Osmani 认为，问题解决的关键有意识地调整工作方式，将 AI 视为增强工具而非替代品，从性质上做一个区分，比如：
不盲从： 将 AI 输出视为建议，始终质疑、测试、探究原理。 强制独立： 定期安排无 AI 编码时间，刻意练习基础技能。 先己后 AI： 遇问题先独立思考和尝试解决，再借助 AI 比对学习。 人工把关： 将 AI 生成代码纳入代码评审，确保理解和质量。 追问究竟： 不止步于 AI 的答案，深入理解方案原理、替代 AI 得答案。 找准痛点： 常常记录常依赖 AI 的领域，有针对性地学习强化。 主导协作： 将 AI 视为受你指导的初级伙伴，而非指令执行者。
最终是被动地接受，还是主动地学习和驾驭，选择权在我们手中。
结语
Keep sharp，保持敏锐！
AI 在开发领域的地位已不可逆转，带来了真实的效率提升。但是，在读完这篇博客的分析后，小鹿意识到，此前确实没有充分思考，或对此保持足够的警惕，关于如何保留并维系我们人类开发工程师的专业优势。
编程的价值，不全在于快，更在于对技术本身的深入理解。
避免 AI 时代的技能萎缩，最简单的就是保持对代码原理敏锐的好奇心——“为什么是这样？”，哪怕 AI 给了答案，也不能全盘依赖，而是投入精力去构建和强化那些 AI 难以替代的核心能力。究其原因，代码的最终悟透，终究离不开人类工程师的主动认知投入。