The rise of AI assistants in coding has sparked a paradox: we may be increasing productivity, but at risk of losing our edge to skill atrophy if we’re not careful. Skill atrophy refers to the decline or loss of skills over time due to lack of use or practice.
编程中 AI 助手的兴起引发了一个悖论：我们可能在提高生产力的同时，若不谨慎行事，将面临技能退化的风险。技能退化指的是由于缺乏使用或练习，技能随时间推移而下降或丧失。
Would you be completely stuck if AI wasn’t available?
如果 AI 不可用，你会完全束手无策吗？
Every developer knows the appeal of offloading tedious tasks to machines. Why memorize docs or sift through tutorials when AI can serve up answers on demand? This cognitive offloading - relying on external tools to handle mental tasks - has plenty of precedents. Think of how GPS navigation eroded our knack for wayfinding: one engineer admits his road navigation skills “have atrophied” after years of blindly following Google Maps. Similarly, AI-powered autocomplete and code generators can tempt us to “turn off our brain” for routine coding tasks. (Shout out to Dmitry Mazin, that engineer who forgot how to navigate, whose blog post also touched on ways to use LLM without losing your skills)
每位开发者都清楚将繁琐任务交给机器的吸引力。既然 AI 能按需提供答案，何必记忆文档或筛选教程？这种认知卸载 —— 依赖外部工具处理脑力任务 —— 早有先例。想想 GPS 导航如何削弱了我们寻路的本领：一位工程师坦承，多年盲目跟随谷歌地图后，他的道路导航技能 “已经退化”。同样，AI 驱动的自动补全和代码生成器可能诱使我们在常规编码任务中 “关闭大脑”。（向那位忘记如何导航的工程师 Dmitry Mazin 致敬，他的博文也提到了如何在不丧失技能的情况下使用 LLM）
Offloading rote work isn’t inherently bad. In fact, many of us are experiencing a renaissance that lets us attempt projects we’d likely not tackle otherwise. As veteran developer Simon Willison quipped, “the thing I’m most excited about in our weird new AI-enhanced reality is the way it allows me to be more ambitious with my projects”. With AI handling boilerplate and rapid prototyping, ideas that once took days now seem viable in an afternoon. The boost in speed and productivity is real - depending on what you’re trying to build. The danger lies in where to draw the line between healthy automation and harmful atrophy of core skills.
将机械性工作外包并非本质上的坏事。实际上，我们许多人正经历一场复兴，得以尝试那些原本可能不会着手进行的项目。正如资深开发者西蒙・威利森所言：“在这个被 AI 增强的奇异新现实中，最让我兴奋的是它让我能够对项目抱有更大野心。” 随着 AI 处理样板代码和快速原型设计，曾经需要数天的想法如今一个下午就能实现。速度和效率的提升是真实的 —— 取决于你想构建什么。危险在于如何划清健康自动化与核心技能有害退化之间的界限。
Is Critical Thinking becoming a casualty?
批判性思维正在成为牺牲品吗？
Recent research is sounding the alarm that our critical thinking and problem-solving muscles may be quietly deteriorating. A 2025 study by Microsoft and Carnegie Mellon researchers found that the more people leaned on AI tools, the less critical thinking they engaged in, making it harder to summon those skills when needed.
最新研究敲响警钟：我们的批判性思维和问题解决能力可能在悄然退化。微软与卡内基梅隆大学研究人员 2025 年的一项研究发现，人们越依赖 AI 工具，其批判性思维运用就越少，导致需要时更难调动这些技能。
Essentially, high confidence in an AI’s abilities led people to take a mental backseat - “letting their hands off the wheel” - especially on easy tasks It’s human nature to relax when a task feels simple, but over time this “long-term reliance” can lead to “diminished independent problem-solving”. The study even noted that workers with AI assistance produced a less diverse set of solutions for the same problem, since AI tends to deliver homogenized answers based on its training data. In the researchers’ words, this uniformity could be seen as a “deterioration of critical thinking” itself.
本质上，对 AI 能力的高度自信会让人在心理上产生依赖 ——"松开方向盘"，尤其是在简单任务上。当任务感觉简单时，人类天性会放松警惕，但久而久之这种 "长期依赖" 可能导致 "独立解决问题能力的退化"。研究甚至指出，在 AI 协助下，工作者针对同一问题提出的解决方案多样性降低，因为 AI 倾向于根据其训练数据提供同质化答案。用研究者的话说，这种一致性可被视为 "批判性思维本身的退化"。
There are a few barriers to critical thinking:
批判性思维存在几大障碍：
-
Awareness barriers (over-reliance on AI, especially for routine tasks)
认知障碍（过度依赖 AI，尤其是处理常规任务时） -
Motivation barriers (time pressure, job scope limitations)
动机障碍（时间压力、工作范围限制） -
Ability barriers (difficulty verifying or improving AI responses)
能力障碍（难以验证或改进 AI 的响应）
What does this look like in day-to-day coding? It starts subtle. One engineer confessed that after 12 years of programming, AI’s instant help made him “worse at [his] own craft”. He describes a creeping decay: First, he stopped reading documentation – why bother when an LLM can explain it instantly?
这在日常编码中是什么样子？起初很微妙。一位工程师坦言，在编程 12 年后，AI 的即时帮助让他 “在自己的手艺上变得更糟”。他描述了一种逐渐的退化：首先，他不再阅读文档 —— 既然 LLM 能即时解释，何必费心？
Then debugging skills waned – stack traces and error messages felt daunting, so he just copy-pasted them into AI for a fix. “I’ve become a human clipboard” he laments, blindly shuttling errors to the AI and solutions back to code. Each error used to teach him something new; now the solution appears magically and he learns nothing. The dopamine rush of an instant answer replaced the satisfaction of hard-won understanding.
随后，调试技能逐渐退化 —— 堆栈跟踪和错误信息让人望而生畏，于是他干脆将它们复制粘贴到 AI 中寻求修复。“我变成了一个人肉剪贴板，” 他哀叹道，盲目地将错误传送给 AI，又将解决方案传回代码。过去，每个错误都能教会他新东西；如今解决方案神奇地出现，他却一无所获。即时答案带来的多巴胺快感取代了来之不易的理解所带来的满足感。
Over time, this cycle deepens. He notes that deep comprehension was the next to go – instead of spending hours truly understanding a problem, he now implements whatever the AI suggests. If it doesn’t work, he tweaks the prompt and asks again, entering a “cycle of increasing dependency”. Even the emotional circuitry of development changed: what used to be the joy of solving a tough bug is now frustration if the AI doesn’t cough up a solution in 5 minutes.
随着时间的推移，这种循环不断加深。他指出，深度理解能力是接下来丧失的 —— 他不再花数小时真正理解一个问题，而是直接实施 AI 给出的任何建议。如果方案无效，他就调整提示词再次询问，陷入 “依赖性不断增强的循环”。甚至开发过程中的情感回路也发生了变化：曾经解决棘手漏洞的喜悦，如今变成了若 AI 五分钟内未能给出解决方案便感到沮丧。
In short, by outsourcing the thinking to an LLM, he was trading away long-term mastery for short-term convenience. “We’re not becoming 10× developers with AI – we’re becoming 10× dependent on AI” he observes. “Every time we let AI solve a problem we could’ve solved ourselves, we’re trading long-term understanding for short-term productivity”.
简而言之，通过将思考外包给 LLM，他正在用长期精通换取短期便利。“我们并没有因为 AI 成为 10 倍效率的开发者 —— 而是变得 10 倍依赖 AI，” 他指出。“每次让 AI 解决本可自行解决的问题，我们都在用长期理解力换取短期生产力”。
Subtle signs your skills are atrophying
你的技能正在退化的微妙迹象
It’s not just hypothetical - there are telltale signs that reliance on AI might be eroding your craftsmanship in software development:
这并非仅是假设 —— 有迹象表明，过度依赖 AI 可能正在侵蚀你在软件开发中的工艺水平：
-
Debugging despair: Are you skipping the debugger and going straight to AI for every exception? If reading a stacktrace or stepping through code feels arduous now, keep an eye on this skill. In the pre-AI days, wrestling with a bug was a learning crucible; now it’s tempting to offload that effort. One developer admitted he no longer even reads error messages fully - he just sends them to the AI. The result: when the AI isn’t available or stumped, he’s at a loss on how to diagnose issues the old-fashioned way.
调试绝望：你是否跳过调试器，直接向 AI 求助每一个异常？如果现在阅读堆栈跟踪或逐步执行代码让你感到吃力，那就要警惕这项技能的退化。在 AI 出现之前，与 bug 搏斗是学习的熔炉；如今却很容易将这份努力外包出去。一位开发者坦言，他甚至不再完整阅读错误信息 —— 直接丢给 AI 处理。结果就是：当 AI 无法使用或束手无策时，他对如何用传统方法诊断问题一筹莫展。 -
Blind Copy-Paste coding: It’s fine to have AI write boilerplate, but do you understand why the code it gave you works? If you find yourself pasting in code that you couldn’t implement or explain on your own, be careful. Young devs especially report shipping code faster than ever with AI, yet when asked why a certain solution is chosen or how it handles edge cases, they draw blanks. The foundational knowledge that comes from struggling through alternatives is just… missing.
盲目复制粘贴编程：让 AI 编写样板代码是可以的，但你是否理解它给出的代码为何有效？如果你发现自己粘贴的代码无法独立实现或解释，那就需要小心了。尤其是年轻开发者们报告称，借助 AI 他们能比以往更快地交付代码，但当被问及为何选择特定解决方案或如何处理边缘情况时，他们却哑口无言。那种通过反复尝试不同方案而积累的基础知识…… 就这样缺失了。 -
Architecture and big-picture thinking: Complex system design can’t be solved by a single prompt. If you’ve grown accustomed to solving bite-sized problems with AI, you might notice a reluctance to tackle higher-level architectural planning without it. The AI can suggest design patterns or schemas, but it won’t grasp the full context of your unique system. Over-reliance might mean you haven’t practiced piecing components together mentally. For instance, you might accept an AI-suggested component without considering how it fits into the broader performance, security, or maintainability picture - something experienced engineers do via hard-earned intuition. If those system-level thinking muscles aren’t flexed, they can weaken.
架构与全局思维：复杂系统设计无法通过单一提示解决。如果你已习惯用 AI 处理零散问题，可能会发现自己不愿在没有 AI 的情况下进行更高层次的架构规划。AI 能推荐设计模式或方案，但无法理解你独特系统的完整背景。过度依赖可能导致你缺乏在脑海中整合组件的练习。例如，你可能直接采纳 AI 推荐的组件，却未考虑它如何融入整体性能、安全性或可维护性 —— 这正是资深工程师通过长期实践形成的直觉所擅长的。若长期缺乏这类系统级思考的锻炼，相关能力便会退化。 -
Diminished memory & recall: Are basic API calls or language idioms slipping from your memory? It’s normal to forget rarely-used details, but if everyday syntax or concepts now escape you because the AI autocomplete always fills it in, you might be experiencing skill fade. You don’t want to become the equivalent of a calculator-dependent student who’s forgotten how to do arithmetic by hand.
记忆力与回忆能力下降：基本的 API 调用或语言习惯是否开始从你的记忆中溜走？忘记不常用的细节是正常的，但如果因为 AI 自动补全总是代劳，导致日常语法或概念现在对你来说变得陌生，你可能正在经历技能退化。你肯定不想变成那种依赖计算器、连手算都忘了的学生。
It’s worth noting that some skill loss over time is natural and sometimes acceptable.
值得注意的是，随着时间的推移，某些技能的丧失是自然的，有时也是可以接受的。
We’ve all let go of obsolete skills (when’s the last time you manually managed memory in assembly, or did long division without a calculator?). Some argue that worrying about “skill atrophy” is just resisting progress - after all, we gladly let old-timers’ skills like handwritten letter writing or map-reading fade to make room for new ones.
我们都已摒弃了过时的技能（你上一次手动用汇编语言管理内存，或是不用计算器做长除法是什么时候？）。有人认为担忧 “技能退化” 只是在抗拒进步 —— 毕竟，我们欣然让老一辈的技能如手写信件或阅读地图逐渐淡出，为新技能腾出空间。
The key is distinguishing which skills are safe to offload and which are essential to keep sharp. Losing the knack for manual memory management is one thing; losing the ability to debug a live system in an emergency because you’ve only ever followed AI’s lead is another.
关键在于区分哪些技能可以放心外包，哪些必须保持熟练。失去手动内存管理的技巧是一回事；因为只跟随 AI 的指引而在紧急情况下失去调试实时系统的能力，则是另一回事。
Speed vs. Knowledge trade-off: AI offers quick answers (high speed, low learning), whereas older methods (Stack Overflow, documentation) were slower but built deeper understanding
速度与知识的权衡：AI 提供快速答案（高速度，低学习），而传统方法（Stack Overflow、文档）速度较慢但能建立更深层次的理解
In the rush for instant solutions, we risk skimming the surface and missing the context that builds true expertise.
在追求即时解决方案的匆忙中，我们可能只触及表面，而错失了构建真正专业知识的背景。
The Long-term risks of over-reliance
过度依赖的长期风险
What happens if this trend continues unchecked? For one, you might hit a “critical thinking crisis” in your career. If an AI has been doing your thinking for you, you could find yourself unequipped to handle novel problems or urgent issues when the tool falls short.
如果这一趋势不加遏制地持续下去会怎样？首先，你的职业生涯可能会遭遇一场 “批判性思维危机”。如果一直依赖 AI 替你思考，当工具失灵时，你可能会发现自己无力应对新问题或紧急状况。
As one commentator bluntly put it: “The more you use AI, the less you use your brain… So when you run across a problem AI can’t solve, will you have the skills to do so yourself?”. It’s a sobering question. We’ve already seen minor crises: developers panicking during an outage of an AI coding assistant because their workflow ground to a halt.
正如一位评论者直言不讳所说：“你越多使用 AI，就越少动用自己的大脑…… 所以当你遇到 AI 无法解决的问题时，你自己是否具备解决的能力？” 这是个发人深省的问题。我们已经目睹了一些小规模危机：当 AI 编程助手宕机时，开发者因工作流程陷入停滞而惊慌失措。
Over-reliance can also become a self-fulfilling prophecy. The Microsoft study authors warned that if you’re worried about AI taking your job and yet you “use it uncritically” you might effectively deskill yourself into irrelevance. In a team setting, this can have ripple effects. Today’s junior devs who skip the “hard way” may plateau early, lacking the depth to grow into senior engineers tomorrow.
过度依赖也可能成为一种自我实现的预言。微软研究报告的作者警告称，如果你担心 AI 会取代你的工作，却又 "不加批判地使用它"，实际上可能会让自己技能退化，变得无足轻重。在团队环境中，这会产生连锁反应。如今那些跳过 "困难方式" 的初级开发者，未来可能因缺乏深度而早早停滞，难以成长为高级工程师。
If a whole generation of programmers “never know the satisfaction of solving problems truly on their own” and “never experience the deep understanding” from wrestling with a bug for hours, we could end up with a workforce of button-pushers who can only function with an AI’s guidance. They’ll be great at asking AI the right questions, but won’t truly grasp the answers. And when the AI is wrong (which it often is in subtle ways), these developers might not catch it – a recipe for bugs and security vulnerabilities slipping into code.
如果整整一代程序员 “从未体验过真正独立解决问题的满足感”，也 “从未通过数小时与漏洞搏斗获得深刻理解”，我们最终可能培养出一批只会按按钮、依赖 AI 指导才能工作的劳动力。他们将擅长向 AI 提出正确问题，却无法真正理解答案。而当 AI 出错时（它经常以微妙的方式犯错），这些开发者可能无法察觉 —— 这将成为代码中潜伏漏洞和安全风险的温床。
There’s also the team dynamic and cultural impact to consider. Mentorship and learning by osmosis might suffer if everyone is heads-down with their AI pair programmer. Senior engineers may find it harder to pass on knowledge if juniors are accustomed to asking AI instead of their colleagues.
此外，还需考虑团队动态和文化影响。如果每个人都埋头与 AI 结对编程，师徒关系和潜移默化的学习可能会受到影响。如果初级工程师习惯于向 AI 而非同事请教，资深工程师传授知识可能会变得更加困难。
And if those juniors haven’t built a strong foundation, seniors will spend more time fixing AI-generated mistakes that a well-trained human would have caught. In the long run, teams could become less than the sum of their parts – a collection of individuals each quietly reliant on their AI crutch, with fewer robust shared practices of critical review. The bus factor (how many people need to get hit by a bus before a project collapses) might effectively include “if the AI service goes down, does our development grind to a halt?”
如果这些初级员工没有打下坚实的基础，高级员工将花费更多时间修正 AI 生成的错误，而这些错误本应由训练有素的人类发现。长远来看，团队的整体效能可能低于个体之和 —— 每个人都默默依赖 AI 辅助，缺乏强有力的集体批判性审查实践。巴士因子（项目崩溃前需要多少人被巴士撞到）实际上可能还要考虑 “如果 AI 服务宕机，我们的开发是否会陷入停滞？”
None of this is to say we should revert to coding by candlelight. Rather, it’s a call to use these powerful tools wisely, lest we “outsource not just the work itself, but [our] critical engagement with it”). The goal is to reap AI’s benefits without hollowing out your skill set in the process.
这并不是说我们应该回到烛光下编程的时代。相反，这是在呼吁明智地使用这些强大工具，以免我们 “不仅外包了工作本身，还外包了对其的批判性参与”。目标是在享受 AI 带来的好处的同时，不在此过程中削弱自身的技能储备。
Using AI as a collaborator, not a crutch
将 AI 作为协作者，而非拐杖
How can we enjoy the productivity gains of AI coding assistants and still keep our minds sharp? The key is mindful engagement. Treat the AI as a collaborator – a junior pair programmer or an always-available rubber duck – rather than an infallible oracle or a dumping ground for problems. Here are some concrete strategies to consider:
我们如何才能在享受 AI 编程助手带来的生产力提升的同时，保持思维敏锐？关键在于有意识地参与。将 AI 视为协作者 —— 一个初级的结对编程伙伴或随时可用的橡皮鸭，而非绝对正确的预言家或问题的倾倒场。以下是一些值得考虑的具体策略：
-
Practice “AI hygiene” – always verify and understand. Don’t accept AI output as correct just because it looks plausible. Get in the habit of red-teaming the AI’s suggestions: actively look for errors or edge cases in its code. If it generates a function, test it with tricky inputs. Ask yourself, “why does this solution work? what are its limitations?” Use the AI as a learning tool by asking it to explain the code line-by-line or to offer alternative approaches. By interrogating the AI’s output, you turn a passive answer into an active lesson.
践行 “AI 卫生”—— 始终验证并理解。不要仅仅因为 AI 的输出看起来合理就接受其正确性。养成对 AI 建议进行红队测试的习惯：主动寻找其代码中的错误或边缘案例。如果它生成了一个函数，就用棘手的输入进行测试。问问自己：“为什么这个解决方案有效？它的局限性是什么？” 通过要求 AI 逐行解释代码或提供替代方法，将其作为学习工具。通过质疑 AI 的输出，你将被动接受的答案转化为主动学习的课程。 -
No AI for fundamentals – sometimes, struggle is good. Deliberately reserve part of your week for “manual mode” coding. One experienced dev instituted “No-AI Days”: one day a week where he writes code from scratch, reads errors fully, and uses actual documentation instead of AI. It was frustrating at first (“I feel slower, dumber” he admitted), but like a difficult workout, it rebuilt his confidence and deepened his understanding. You don’t have to go cold turkey on AI, but regularly coding without it keeps your base skills from entropy. Think of it as cross-training for your coder brain.
基础不靠 AI—— 有时，挣扎是好事。刻意留出一周中的部分时间进行 “手动模式” 编码。一位经验丰富的开发者设立了 “无 AI 日”：每周有一天，他从零开始编写代码，完整阅读错误信息，并使用实际文档而非 AI。起初这令人沮丧（他承认 “感觉更慢、更笨”），但如同艰难的锻炼，它重建了他的信心并加深了理解。你不必完全戒除 AI，但定期无 AI 编码能防止基础技能退化。将其视为程序员大脑的交叉训练。 -
Always attempt a problem yourself before asking the AI. This is classic “open book exam” rules – you’ll learn more by struggling a bit first. Formulate an approach, even if it’s just pseudocode or a guess, before you have the AI fill in the blanks. If you get stuck on a bug, spend 15-30 minutes investigating on your own (use print debugging, console logs, or just reasoning through the code). This ensures you exercise your problem-solving muscles. After that, there’s no shame in consulting the AI – but now you can compare its answer with your own thinking and truly learn from any differences.
在向 AI 求助之前，始终先尝试自己解决问题。这是经典的 “开卷考试” 原则 —— 通过先自己挣扎一番，你会学到更多。在让 AI 填补空白之前，先形成一个解决思路，哪怕是伪代码或猜测也好。如果遇到 bug 卡壳了，花 15-30 分钟自行排查（使用打印调试、控制台日志或单纯通过代码逻辑推理）。这能确保你锻炼自己的问题解决能力。之后，再向 AI 咨询就没什么可羞愧的了 —— 但此时你可以将它的答案与自己的思路对比，真正从差异中学习。 -
Use AI to augment, not replace, code review. When you get an AI-generated snippet, review it as if a human colleague wrote it. Better yet, have human code reviews for AI contributions too. This keeps team knowledge in the loop and catches issues that a lone developer might miss when trusting AI. Culturally, encourage an attitude of “AI can draft it, but we own it” – meaning the team is responsible for understanding and maintaining all code in the repository, no matter who (or what) originally wrote it.
利用 AI 增强而非取代代码审查。当收到 AI 生成的代码片段时，应像对待人类同事编写的代码一样进行审查。更理想的做法是，对 AI 贡献的代码也进行人工审查。这能确保团队知识得以循环利用，并发现单独开发者过度依赖 AI 时可能遗漏的问题。在文化层面，应倡导 “AI 可起草，但代码归属我们” 的态度 —— 即团队有责任理解并维护代码库中的所有代码，无论其最初由谁（或什么）编写。 -
Engage in active learning: follow up and iterate. If an AI solution works, don’t just move on. Take a moment to solidify that knowledge. For example, if you used AI to implement a complex regex or algorithm, afterwards try to explain it in plain English (to yourself or a teammate). Or ask the AI why that regex needs those specific tokens. Use the AI conversationally to deepen your understanding, not just to copy-paste answers. One developer described using ChatGPT to generate code and then peppering it with follow-up questions and “why not this other way?” - akin to having an infinite patience tutor. This turns AI into a mentor rather than a mere code dispenser.
积极参与主动学习：跟进并迭代。如果 AI 解决方案有效，不要就此止步。花点时间巩固所学知识。例如，若你借助 AI 实现了复杂的正则表达式或算法，之后尝试用简单英语（对自己或队友）解释它。或者询问 AI 为何该正则表达式需要那些特定标记。以对话方式利用 AI 深化理解，而非仅复制粘贴答案。一位开发者描述道，他先用 ChatGPT 生成代码，随后用一系列后续问题和 “为何不采用另一种方式？” 来追问 —— 如同拥有一位无限耐心的导师。这使 AI 转变为导师角色，而非单纯的代码生成器。 -
Keep a learning journal or list of “AI assists.” Track the things you frequently ask AI help for – it could be a sign of a knowledge gap you want to close. If you notice you’ve asked the AI to center a div in CSS or optimize an SQL query multiple times, make a note to truly learn that topic. You can even make flashcards or exercises for yourself based on AI solutions (embracing that retrieval practice we know is great for retention). The next time you face a similar problem, challenge yourself to solve it without AI and see if you remember how. Use AI as a backstop, not the first stop, for recurring tasks.
保持学习日志或记录 “AI 辅助” 清单。追踪你经常向 AI 寻求帮助的事项 —— 这可能表明你想填补的知识空白。如果你发现自己多次让 AI 帮忙居中 CSS 中的 div 或优化 SQL 查询，那就记下来真正去学习那个主题。你甚至可以根据 AI 提供的解决方案为自己制作闪卡或练习（利用我们已知对记忆有益的检索练习）。下次遇到类似问题时，挑战自己不用 AI 解决，看看是否还记得方法。对于重复性任务，将 AI 作为后备方案，而非首选方案。 -
Pair program with the AI. Instead of treating the AI like an API you feed queries to, try a pair programming mindset. For example, you write a function and let the AI suggest improvements or catch mistakes. Or vice versa: let the AI write a draft and you refine it. Maintain an ongoing dialog: “Alright, that function works, but can you help me refactor it for clarity?” – this keeps you in the driver’s seat. You’re not just consuming answers; you’re curating and directing the AI’s contributions in real-time. Some developers find that using AI feels like having a junior dev who’s great at grunt work but needs supervision – you are the senior in the loop, responsible for the final outcome.
与 AI 结对编程。不要将 AI 视为仅接收查询的 API，而是尝试采用结对编程的思维方式。例如，你编写一个函数，让 AI 提出改进建议或捕捉错误；或者反过来：让 AI 起草代码，你来优化。保持持续对话：“好的，这个函数能运行，但你能帮我重构以提升可读性吗？”—— 这样你始终掌握主导权。你不是在被动接受答案，而是在实时指导和筛选 AI 的贡献。一些开发者发现，使用 AI 的感觉就像带一个擅长基础工作但需要监督的初级开发人员 —— 你是闭环中的高级开发者，对最终结果负责。
By integrating habits like these, you ensure that using AI remains a net positive: you get the acceleration and convenience without slowly losing your ability to code unaided. In fact, many of these practices can turn AI into a tool for sharpening your skills. For instance, using AI to explain unfamiliar code can deepen your knowledge, and trying to stump the AI with tricky cases can enhance your testing mindset. The difference is in staying actively involved rather than passively reliant.
通过整合这些习惯，你可以确保使用 AI 始终是一种净收益：既获得加速和便利，又不会逐渐丧失独立编码的能力。实际上，许多这类实践能将 AI 转化为磨砺技能的工具。例如，利用 AI 解释陌生代码可以加深你的理解，而尝试用复杂案例难倒 AI 则能增强你的测试思维。关键在于保持主动参与，而非被动依赖。
Conclusion: Stay sharp 结论：保持敏锐
The software industry is hurtling forward with AI at the helm of code generation, and there’s no putting that genie back in the bottle. Embracing these tools is not only inevitable; it’s often beneficial. But as we integrate AI into our workflow, we each have to “walk a fine line” on what we’re willing to cede to the machine.
软件行业正以 AI 为代码生成的核心飞速前进，这一趋势已无法逆转。接纳这些工具不仅不可避免，而且往往大有裨益。但在将 AI 融入工作流程的过程中，我们每个人都必须在 "愿意让机器接管什么" 这一问题上 "谨慎权衡"。
If you love coding, it’s not just about outputting features faster - it’s also about preserving the craft and joy of problem-solving that got you into this field in the first place.
如果你热爱编程，那么这不仅关乎更快地输出功能 —— 还关乎保留最初让你进入这个领域的解决问题的技艺与乐趣。
Use AI it to amplify your abilities, not replace them. Let it free you from drudge work so you can focus on creative and complex aspects - but don’t let those foundational skills atrophy from disuse. Stay curious about how and why things work. Keep honing your debugging instincts and system thinking even if an AI gives you a shortcut. In short, make AI your collaborator, not your crutch.
利用 AI 来增强你的能力，而非取代它们。让它将你从枯燥工作中解放出来，从而专注于创意与复杂领域 —— 但别让那些基础技能因闲置而退化。保持对事物运作原理的好奇心。即使 AI 为你提供了捷径，也要持续磨练调试直觉和系统思维。简而言之，让 AI 成为你的协作者，而非拐杖。
The developers who thrive will be those who pair their human intuition and experience with AI’s superpowers – who can navigate a codebase both with and without the autopilot. By consciously practicing and challenging yourself, you ensure that when the fancy tools fall short or when a truly novel problem arises, you’ll still be behind the wheel, sharp and ready to solve. Don’t worry about AI replacing you; worry about not cultivating the skills that make you irreplaceable. As the saying goes (with a modern twist): “What the AI gives, the engineer’s mind must still understand.” Keep that mind engaged, and you’ll ride the AI wave without wiping out.
那些蓬勃发展的开发者，将是那些将人类直觉经验与 AI 超能力相结合的人 —— 他们能在自动驾驶辅助下或独立驾驭代码库。通过有意识地练习与自我挑战，你确保当花哨工具失灵或真正新颖的问题出现时，仍能稳握方向盘，敏锐且随时准备解决。别担心 AI 取代你；该担心的是未能培养让自己不可替代的技能。正如现代版谚语所言："AI 所予，工程师之心仍需明辨。" 保持思维活跃，你就能驾驭 AI 浪潮而不被吞没。
Bonus: The next time you’re tempted to have AI code an entire feature while you watch, consider this your nudge to roll up your sleeves and write a bit of it yourself. You might be surprised at how much you remember – and how good it feels to flex those mental muscles again. Don’t let the future of AI-assisted development leave you intellectually idle. Use AI to boost your productivity, but never cease to actively practice your craft.
额外建议：下次当你忍不住想让 AI 编写整个功能而你袖手旁观时，不妨把这视为一个提醒，挽起袖子亲自动手写一部分代码。你可能会惊讶于自己还记得多少 —— 以及重新调动这些脑力时的美妙感觉。别让 AI 辅助开发的未来使你陷入思维惰性。利用 AI 提升效率，但永远不要停止主动磨练你的技艺。
The best developers of tomorrow will be those who didn’t let today’s AI make them forget how to think.
未来的顶尖开发者将是那些不让今天的 AI 使他们忘记如何思考的人。
I’m excited to share I’m writing a new AI-assisted engineering book with O’Reilly. If you’ve enjoyed my writing here you may be interested in checking it out.
我很高兴地宣布，我正在与 O’Reilly 合作撰写一本新的 AI 辅助工程书籍。如果你喜欢我在这里的写作，可能会有兴趣了解一下。
原文链接：
https://addyo.substack.com/p/avoiding-skill-atrophy-in-the-age