在编程领域，人工智能助手的兴起带来了一个矛盾现象：我们的工作效率可能提高了，但如果不小心，可能会面临技能萎缩，从而失去自身优势。所谓技能萎缩，就是指由于长期不使用或缺乏练习，技能随着时间慢慢衰退甚至丧失。
我想起了我们公司最近的政策：每个季度的绩效评定必须有一项是 AI 提效，每个月必须填写一项 AI 提效的实际措施以及绩效占比，想想头都大了。
要是没有人工智能，你会不会就完全不知所措了呢？
每个开发者都懂的：把那些繁琐的任务交给机器去做，这是多么诱人的事。既然人工智能能按需给出答案，何必去费劲记忆文档内容，或者在众多教程里苦苦查找呢？
这种依靠外部工具来处理思维任务的做法，也就是认知外包，其实早有不少先例。
想想高德导航吧，它是如何不知不觉削弱了我们的认路能力的：现在大多数有车的小伙伴，多年来去陌生的地方都是跟着高德地图走，自己的路感已经几乎没有了，可能没有导航的情况下，连高速路口都找不到。
同样，人工智能驱动的自动补全和代码生成功能，也很容易让我们在做日常编程任务时 “放松大脑”。
把那些重复性的机械工作外包出去，这本身并非坏事——这也正是现代社会进步的原因之一。事实上，我们很多人正迎来编程生涯的 “小春天”，有机会尝试一些以前可能不会涉足的项目。就像资深开发者西蒙·威利森调侃的那样：“在我们这个人工智能加持的新奇世界里，最让我兴奋的就是，我可以对自己的项目野心更大一些啦 ！” 有了人工智能帮忙处理样板代码和快速搭建原型，过去可能需要好几天才能实现的想法，现在一个下午似乎就能搞定。速度和效率确实有了显著提升——当然，具体还是要看你打算开发什么项目。不过问题在于，要把握好平衡，在合理利用自动化的同时，避免核心技能因为过度依赖而退化。
批判性思维会 “受伤” 吗？
近期的研究给我们敲响了警钟：我们的批判性思维和解决问题的能力，可能正在悄然退步。微软和卡内基梅隆大学的研究人员在2025年开展的一项研究发现，人们越依赖人工智能工具，批判性思维运用得就越少，等到真正需要运用这些技能的时候，反而感觉力不从心了。
本质上来说，对人工智能的过度信任，会让人们在思维上 “偷懒”，就好比开车时 “松了方向盘”（emmm，这里我不是针对某个车企关于智驾的宣传），尤其是在处理简单任务的时候。这也符合人的天性，毕竟任务简单的时候，大家都会放松些。但长此以往，这种 “长期依赖” 可能导致 “独立解决问题的能力下降”。研究还指出，在人工智能辅助下工作的人，针对同一个问题给出的解决方案往往比较单一，因为人工智能给出的答案通常基于它的训练数据，难免千篇一律。大家伙儿在用某些绘图 AI 的时候，有这种感觉吗？用研究人员的话来说，这种一致性本身就反映出 “批判性思维在退化”。
批判性思维面临着这几方面的 “阻碍”：
- 认知阻碍：对人工智能过度依赖，特别是在处理常规任务时
- 动力阻碍：时间紧迫，工作范围受限
- 能力阻碍：难以验证或完善人工智能给出的答案
这种现象在日常编程中是如何显现的呢？初始阶段可能不太明显。有小伙伴跟我抱怨，做了12年编程工作后，发现人工智能提供的即时帮助让他 “在自己擅长的领域反而表现不如从前”，也就是“越来越懒”了。他描述了一个逐渐 “退步” 的过程：先是不再仔细阅读文档，反正有大语言模型能快速解释，何必多此一举呢？
接着，调试技能也慢慢变弱了。看到堆栈跟踪信息和错误提示就觉得头疼，于是直接把这些问题复制粘贴给人工智能，等着它出解决方案。“我感觉自己快变成一个只会复制粘贴的工具人了。” 他无奈地感慨道，只是盲目地把错误丢给人工智能，再把得到的解决方案原封不动地放回代码里。以前，每个错误都能让他学到新东西；如今，解决方案来得太过容易，自己反倒什么都学不到。迅速得到答案带来的短暂快感，取代了曾经辛苦钻研后获得理解的那种成就感。
随着时间的推移，这个 “恶性循环” 愈发严重。他发现自己对问题的深度理解能力也在下降——不再愿意花几个小时去真正理解一个问题，而是直接按照人工智能的建议行事。如果行不通，就调整一下问题再问，逐渐陷入 “越来越依赖” 的怪圈。就连对编程的情绪也发生了变化：以前成功解决一个难题会让人满心欢喜，现在要是人工智能在5分钟内没能给出答案，就会让人很沮丧。我老家有句古话：没米吃怪筲箕。
简单来说，把思考工作外包给大语言模型，其实是用长期的技能提升，换取了短期的便利。他总结道：“有了人工智能，我们并没有变成10倍高效的开发者，反而对它产生了10倍的依赖 ！”，“每次让人工智能解决本应由自己处理的问题，都是在用长期的理解和掌握，换取短期的生产力。”
技能衰退的微妙信号
这可不只是理论上的担忧，实际上有很多迹象表明，对人工智能的依赖可能正在蚕食你在软件开发方面的精湛技艺：
-
调试困境：每次遇到异常情况，你是不是直接跳过调试环节，第一时间求助于人工智能？老实说，Android Studio 在 LogCat 中提供的 Ask Gemini 确实很方便。如果现在看堆栈跟踪信息或者一步步分析代码让你觉得很费劲，那就要留意这项技能了。在没有人工智能的日子里，与程序错误作斗争可是积累经验的好机会；现在，人们却总想着偷懒逃避。有开发者承认，他现在连错误信息都懒得完整看完，直接丢给人工智能。结果就是，一旦人工智能出问题或也束手无策，他完全不知道该怎么用传统方法去诊断问题了。这也让我想起了我们公司新招进来的小伙儿，基本就是通义灵码，Github Copilot 一把梭哈，AI不会的他也不会，让他做个需求真是急死人了。
-
盲目复制粘贴式编程：让人工智能编写样板代码倒也没问题，但你真的理解这些代码背后的原理吗？要是发现自己只是一味地复制粘贴，对代码的实现和解释毫无头绪，那可就得小心了。年轻开发者尤其如此，借助人工智能，他们发布代码的速度比以往更快。可是当被问到为什么选择某种方案，或者如何处理边界情况时，他们往往一脸茫然。本应在探索不同实现方式过程中积累的基础知识，就这样不知不觉地缺失了。这我深有体会，希望写一点 Android 的样板代码，结果 Gradle 的配置不知道是几年前的，还得重新开始配置。
-
架构与整体思维能力减弱：复杂系统设计可不是简单的指令就能完成的任务。如果习惯了让人工智能帮忙解决一个个小问题，在没有它的辅助时，你可能会发现自己不太愿意去处理高层次的架构规划工作。尽管人工智能能提供一些设计模式或架构方案的建议，但它无法全面理解你独特系统的具体情况。过度依赖人工智能，可能意味着你没有锻炼自己在脑海中整合各个组件的能力。比如，你可能直接接受了人工智能推荐的某个组件，却没有考虑它对整个系统性能、安全以及可维护性的影响，而经验丰富的工程师凭借多年积累的直觉，通常都会考虑这些因素。如果长期不锻炼这种系统级的思维能力，它们就会逐渐变弱。
-
记忆与知识调用能力下降：你有没有发现自己对一些基本的 API 调用方法或编程语言惯用法开始记忆模糊了？偶尔忘记不太常用的细节是正常的，但如果连日常的语法和概念都经常想不起来，只是因为人工智能的自动补全功能帮你处理了，那你可能正在经历技能衰退。可别像那种离了计算器就不会做算术的学生一样，我们可不能让编程技能也这样 “溜走” 了。但我不得不承认，一路按 Tab 确实太爽了，我甚至觉得以后键盘厂商可能只需要出一个4配列的键盘，Ctrl + C + V + Tab，对吧！
需要注意的是，随着时间流逝，一些技能出现些许衰退是正常现象，有时也是可以接受的。
毕竟，我们也不是机器人，我们都或多或少放弃过一些过时的技能。（你上一次用 C 语言手动管理内存，或者不用计算器做长除法，是什么时候的事了？）有人认为，担心 “技能萎缩” 只是在抗拒进步——毕竟，我们很自然地就让手写书信、看地图找路这些老技能退出了舞台，为新技能腾出空间。
关键在于，要分清哪些技能托付出去无妨，哪些技能则必须保持敏锐。失去手动管理内存的技巧是一回事，但要是因为一味依赖人工智能，在紧急情况下无法调试实时运行的系统，那就严重了。也就是说，自己依然要保留解决问题的能力。
速度与知识的平衡
人工智能提供答案迅速（速度快，但学习效果可能有限），而传统方法（比如在 Stack Overflow 上查找答案、查阅文档）虽然慢些，但能让你对知识有更深入的理解。
如果一味追求即时解决方案，我们很可能只是浅尝辄止，错过构建真正专业知识的重要环节。
过度依赖的长期风险
如果这种趋势不加控制地持续下去，会发生什么呢？首先，在职业生涯中，你可能会遭遇 “批判性思维危机”。如果一直依赖人工智能替你思考，当它无法应对新问题或紧急情况时，你会发现自己毫无办法。
我直言不讳的问你个问题：“你越依赖人工智能，自己动脑子就越少…… 那么，当遇到人工智能解决不了的问题时，你有能力自己解决吗？”
这确实让人深思。我们已经见过一些小麻烦了：当人工智能编程辅助工具出现故障时，有些开发者会惊慌失措，因为他们的工作流程完全停滞了。
过度依赖还可能成为一种自我实现的预言。微软的研究人员警告说，如果一方面担心人工智能抢走自己的工作，另一方面又不加思考地使用它，很可能会逐渐削弱自己的技能，最终变得无足轻重（很可惜，我看到的现在大多数开发者都在经历这样的事情，甚至公司也逼迫他们这样做，作为公司来讲，他们当然希望AI能替代人工）。在团队环境中，这种影响更为深远。如今的初级开发者如果跳过积累经验的 “艰苦之路”，可能过早地达到职业瓶颈，缺乏进一步成长为资深工程师的 “深度储备”。
如果整整一代程序员 “从未体验过独自解决问题的满足感”，也 “从未从数小时与程序错误的斗争中获得深刻理解”，那么最终我们可能培养出一群只会听从人工智能指挥的 “按钮操作员” 。他们可能善于向人工智能提出正确的问题，但并不真正理解答案背后的深意。而且，当人工智能给出错误答案（这种情况常常很隐蔽）时，这些开发者可能浑然不觉——这无疑为代码中的错误和安全漏洞埋下了隐患。
此外，团队的活力和文化氛围也会受到影响。如果大家都只顾埋头和自己的人工智能编程搭档合作，导师传授经验和团队成员潜移默化学习的机会就会减少。如果初级开发者总是习惯向人工智能求助，而不是向同事请教，资深工程师可能会觉得传授知识变得更加困难。
而且，如果初级开发者没有扎实的基础知识，资深工程师就得花更多时间去修正人工智能产生的错误，而这些错误原本一个训练有素的开发者是能够避免的。从长远来看，团队的整体实力可能会小于成员个体能力之和——每个人都悄悄依赖着人工智能这根 “拐杖”，共同进行严格审查和自我提升的机会寥寥无几。“关键人物流失风险” （也就是需要多少核心人员离职，项目才会崩溃） 实际上可能需要考虑 “如果人工智能服务停止，我们的开发工作是否会陷入停滞？”
但这绝非说我们要回到过去 “烛光编程” 的时代。相反，这是在提醒我们，要明智地使用这些强大的工具，避免 “不仅外包了工作，还外包了思考和钻研的过程”。我们的目标是在享受人工智能带来的便利的同时，确保自身技能不会因此而荒废。
把人工智能当成协作伙伴，而不是拐杖
我们如何既能享受人工智能编程助手带来的生产力提升，又能保持思维敏锐呢？关键在于有意识地与之互动。把人工智能当作一个协作伙伴——类似于初级结对程序员，或者随时能帮忙的 “解惑小能手”，而不是一个绝对正确的 “全能大师”，或者问题的 “垃圾桶” 。以下是一些具体的策略供你参考：
-
践行“人工智能使用规范”（我刚发明的这个词）：始终对人工智能给出的结果进行验证和理解。不要仅仅因为看起来合理，就轻易接受它的输出。养成对其建议进行 “挑刺” 的习惯：主动在生成的代码中寻找错误或边界情况。例如，如果它生成了一个函数，用复杂的输入值进行测试。问问自己：“这个解决方案为什么有效？它有哪些局限性？” 把人工智能当成学习工具，让它逐行解释代码，或者提供其他替代方案。通过这样的探索，你可以将被动获得的答案转化为主动学习的课程。
-
基础学习避免依赖人工智能：有时候，多自己动手是有益的。每周可以预留一些时间，尝试 “手动模式” 编程。大家可以给自己设立 “无人工智能日”：每周选一天，完全不借助人工智能，从头开始编写代码，认真查看错误信息，并依据实际文档解决问题 。一开始，你可能觉得这个过程很煎熬（感觉自己“又慢又笨”），但就像经历一场艰苦的训练，慢慢地，你的信心得到了恢复，对知识的理解也更加深入了。你不必完全摒弃人工智能，但定期脱离它进行编程，可以防止基础技能生疏。不妨将其视为对编程思维的交叉训练。
-
向人工智能求助前先尝试独立解决：这就如同 “开卷考试” 的策略——先自己努力思考一下，会学到更多东西。在向人工智能寻求帮助之前，先构思一个解决方案，哪怕只是伪代码或简单的思路。如果在调试过程中遇到问题，先花 15 - 30 分钟自行排查（可以使用打印调试信息、控制台日志记录，或者简单分析代码逻辑）。这样可以锻炼解决问题的能力。之后再向人工智能咨询也并不丢人——此时将其答案与自己的思路进行对比，你就能从差异中真正收获知识。
-
利用人工智能优化而非替代代码审查：当收到人工智能生成的代码片段时，要像审查同事编写的代码一样严谨对待。更好的做法是，对人工智能提供的内容，也安排人工代码审查。这有助于确保团队知识的持续传承，并发现单独依靠开发者个人，因信任人工智能而可能忽略的问题。在团队文化中，提倡 “AI可起草，但我们负责掌握” 的态度，这意味着团队成员有责任理解和维护代码库中的所有代码，无论最初的编写者是谁或是什么工具。
-
积极学习，持续跟进与迭代：如果人工智能提供的解决方案有效，先别急着往前走，花点时间巩固知识。例如，使用人工智能实现了一个复杂的正则表达式或算法后，试着用平实的语言向自己或者同事解释一下。或者询问人工智能为什么这个正则表达式需要特定的字符。以交流的方式使用人工智能，深化理解，而不只是单纯地复制粘贴答案。我给大家分享一个类似做法：使用 DeepSeek 生成代码后，接连提出后续问题，像是 “为什么不选另一种方法呢？” 、“为什么这种方法更搞笑”等。这就如同有一个耐心无限的导师在身边——通过这样的方式，人工智能不再只是代码生成器，而转变为学习过程中的指导者。
我最近在人工智能上有一次非常好的体验。我碰到一个想优化的问题，我在设计一个 API 的时候，返回的是一个不可变数组——Compose 中的PersistentList。但是我的数据是有变化的，也就是会在不定的时候删除元素，添加元素。PersistentList提供了add和remove方法，不过该方法并不是在原列表上进行修改，而是返回一个新的PersistentList，我担心这个操作会对性能有影响（毕竟，添加一个元素就需要创建一个新的列表，这种操作开销也太大了），就问 DeepSeek 有没有什么更好的方案，结果，它告诉我PersistentList效率并没有那么低，他比我们想象的效率要好，Compose 在这个列表上做了很好的优化，后面我仔细看源码，才发现我多虑了。
你看，AI 也确实能拓宽我们的视野，不是吗？ -
记录学习过程与 “人工智能辅助事项”：记录下经常向人工智能求助的问题——这可能揭示了你想要弥补的知识缺口。比如，发现自己多次询问人工智能如何在 CSS 中使
div元素居中，或者优化SQL查询，那就把这些问题记录下来并深入学习。你甚至可以依据人工智能给出的解决方案，为自己制作练习题（我们都知道，通过这种复习实践有助于增强记忆）。下次遇到类似问题时，试着不借助人工智能解决，看看是否还记得方法。反复出现的任务，可以将依赖人工智能作为最后手段，而不是首选 。 -
与人工智能进行结对编程：不要仅把人工智能当成接受指令的应用程序编程接口，尝试采用结对编程的思路。例如，你编写一个函数，让人工智能提出改进建议或者找出错误；或者反过来，让人工智能给出初稿，你来进行优化；我最喜欢的就是提供单元测试代码，它能帮助你生成一系列的测试代码和测试数据。保持持续的沟通交流：“这个函数能正常运行，不过能帮我再重构一下，让逻辑更清晰吗？” 这样，你始终掌握主动权。你并非仅仅是接收答案，而是实时引导人工智能的贡献。有些开发者觉得使用人工智能如同有一个擅长基础工作，但需要指导的初级开发者伙伴——在这个过程中，你作为资深角色，对最终结果负责。
通过养成这些习惯，你可以确保使用人工智能带来的总体是积极影响：在享受效率提升与便利的同时，不至于逐渐丧失独立编码的能力。实际上，这些方法中的许多都能将人工智能转化为提升技能的工具。比如，让人工智能解释陌生代码，能加深知识储备；用复杂情况考它，能增强测试思维能力。关键在于主动参与，而非被动依赖。
结论：保持敏锐
在人工智能引领代码生成潮流的当下，软件行业正飞速发展，这是不可逆的趋势。拥抱这些工具不仅不可避免，而且往往益处多多。然而，当我们把人工智能融入工作流程时，每个人都得拿捏好分寸，明确哪些工作可以交给机器。
如果你热爱编程，那么重点不仅是更快地实现功能——还要守护最初让你踏入这个领域的那份技艺，以及解决问题带来的乐趣。
用人工智能提升能力，而不是替代自己的能力。让它把你从繁琐的工作中解放出来，专注于创意和复杂的部分，但千万别让那些基础知识和技能因长期闲置而生锈。保持对事物运作方式和背后原理的好奇心。即使人工智能为你提供捷径，也要不断磨砺调试直觉和系统思维能力。简而言之，让人工智能成为你的协作伙伴，而非拐杖。
未来那些优秀的开发者，是能够将人类的直觉和经验与人工智能强大能力相结合的人——他们既能借助自动导航（人工智能），也能在没有辅助的情况下应对代码库。通过有意识地练习和挑战自己，你可以确保当先进工具失效，或者面对全新的问题时，你依然能掌控局面，思维清晰，随时准备解决难题。别担心人工智能会取代你，更应该担心的是没有培养出让自己无可替代的技能。就像一句与时俱进的俗语所说：“人工智能给出答案，但工程师的头脑必须理解其中道理。” 保持这份思考，你就能在人工智能的浪潮中乘风破浪，避免被淘汰。
额外提醒
下次当你想看着人工智能编写整个功能模块时，不妨把这当作一个提醒，自己动手写一些。你可能会惊讶地发现，曾经的知识并没有遗忘——再次锻炼这些思维能力的感觉真好。不要让人工智能辅助开发的未来，让你的思维 “变懒” 。借助人工智能提升生产力，但永远不要停止积极提升自己的编程技能。
未来最出色的开发者，将是那些不会因今日的人工智能而忘却思考的人。
