机器翻译 Avoiding Skill Atrophy in the Age of AI 避免人工智能时代的技能萎缩
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.
人工智能助手在编程领域的兴起引发了一个悖论：我们或许正在提高生产力，但如果不小心，技能萎缩也有可能让我们失去优势。技能萎缩是指由于缺乏使用或练习，技能随着时间的推移而下降或丧失。
Would you be completely stuck if AI wasn’t available?
如果没有人工智能，你会陷入困境吗？
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)
每位开发者都深知将繁琐的任务交给机器的吸引力。既然人工智能可以按需提供答案，何必死记硬背文档或费力地翻阅教程呢？这种认知卸载 ——依靠外部工具来处理脑力任务——已有诸多先例。想想 GPS 导航是如何侵蚀我们寻路能力的：一位工程师承认，在多年盲目跟随谷歌地图后，他的道路导航技能“已经退化”。同样，人工智能驱动的自动完成和代码生成器也会诱使我们在日常编码任务中 “关闭大脑” 。（向那位忘记导航的工程师 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.
卸下死记硬背的工作本身并不坏。事实上，我们许多人都在经历一场复兴，这让我们可以尝试一些原本可能不会处理的项目。正如资深开发人员 Simon Willison 打趣道 ， “在我们这个奇怪的新人工智能增强现实中最让我兴奋的是，它让我能够对我的项目更有野心” 。借助人工智能处理样板文件和快速原型设计，曾经需要几天时间才能实现的想法现在似乎可以在一个下午就能实现。速度和生产力的提升是实实在在的——取决于你想要构建什么。危险在于如何在健康的自动化和核心技能的有害萎缩之间划清界限 。
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 年进行的一项研究发现，人们越依赖人工智能工具， 批判性思维就越少 ，这使得在需要的时候更难运用这些技能。
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.
从本质上讲，对人工智能能力的高度信任导致人们在精神上处于次要地位——“放手不管”——尤其是在处理简单任务时。当任务感觉简单时，放松是人类的天性，但随着时间的推移，这种 “长期依赖”会导致“独立解决问题的能力下降” 。研究甚至指出，在人工智能的帮助下，工作者对同一问题的解决方案缺乏多样性 ，因为人工智能倾向于根据其训练数据提供同质化的答案。用研究人员的话来说，这种一致性本身可以被视为 “批判性思维的退化” 。
There are a few barriers to critical thinking:
批判性思维存在一些障碍：
Awareness barriers (over-reliance on AI, especially for routine tasks)
意识障碍（过度依赖人工智能，尤其是在日常任务中）
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 年后，人工智能的即时帮助让他 “自己的技术变得更糟了” 。他描述了一种逐渐衰退的过程： 首先，他不再阅读文档 ——既然法学硕士都能立即解释清楚，那还有什么必要费心阅读呢？
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.
后来， 他的调试技能逐渐衰退 ——堆栈跟踪和错误消息让他望而生畏，于是他干脆把它们复制粘贴到人工智能里去修复。“我成了一个人体剪贴板，”他感叹道，盲目地把错误传给人工智能，再把解决方案传回代码。以前，每个错误都能让他学到新东西；现在， 解决方案却像变魔术一样出现，他却什么也没学到 。瞬间得到答案带来的多巴胺冲动取代了来之不易的理解带来的满足感。
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.
随着时间的推移，这个循环不断加深。他指出， 接下来要做的事情就是深入理解 ——他不再花费数小时真正理解一个问题，而是执行人工智能给出的任何建议。如果不起作用，他会调整提示，然后再次询问，进入一个 “依赖性不断增强的循环” 。甚至连开发的情感回路也发生了变化：过去解决一个棘手问题的喜悦，现在变成了如果人工智能在 5 分钟内没有给出解决方案的沮丧。
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”.
简而言之，通过将思考外包给法学硕士，他放弃了长期的精通，换取了短期的便利。 “我们并没有因为人工智能而成为 10 倍的开发者——而是对人工智能的依赖程度增加了 10 倍，” 他观察到。 “每当我们让人工智能解决一个我们自己就能解决的问题时，我们就是在用长期的理解来换取短期的生产力 。 ”
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:
这不仅仅是假设——有迹象表明对人工智能的依赖可能会削弱软件开发方面的工艺：
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.
调试无望： 遇到每个异常时，你是否都会跳过调试器，直接使用人工智能？如果现在阅读堆栈跟踪或单步执行代码让你感到费力 ，不妨留意一下这项技能。在人工智能出现之前，与错误搏斗是一场学习的熔炉；而现在，人们很容易将这种努力卸下来。一位开发人员承认，他甚至不再完整地阅读错误信息，而是直接将它们发送给人工智能。结果：当人工智能不可用或遇到难题时，他就不知道该如何用传统方法诊断问题了。
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.
架构与全局思维： 复杂的系统设计无法仅凭一己之力解决。如果您已经习惯于使用人工智能解决小型问题，您可能会注意到，在没有人工智能的情况下，您不愿处理更高层次的架构规划。人工智能可以建议设计模式或架构，但它无法掌握您独特系统的完整背景。过度依赖人工智能可能意味着您缺乏在脑海中将组件拼凑在一起的实践经验。例如，您可能会接受人工智能建议的组件，而没有考虑它如何融入更广泛的性能、安全性或可维护性图景——而经验丰富的工程师则凭借来之不易的直觉来做到这一点。如果这些系统级思维能力得不到锻炼，它们可能会变得脆弱。
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.
关键在于区分哪些技能可以安全地卸下， 哪些技能必须保持敏锐 。失去手动内存管理的诀窍是一回事；因为一直只听从人工智能的指引而失去在紧急情况下调试实时系统的能力又是另一回事。
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
速度与知识的权衡：人工智能提供快速答案（高速，低学习），而旧方法（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.
如果这种趋势持续下去，会发生什么？首先，你可能会在职业生涯中遭遇 “批判性思维危机” 。如果人工智能一直在替你思考，你可能会发现自己在工具失效时无力应对新问题或紧急事务。
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.
过度依赖也可能成为一种自我实现的预言 。微软研究的作者警告说，如果你担心人工智能会抢走你的工作，却又 “不加批判地使用它”， 那么你可能会让自己变得技能低下，变得无关紧要。在团队环境中，这可能会产生连锁反应。今天的初级开发人员如果跳过了“艰难的道路”，可能会过早地进入瓶颈期，缺乏成长为未来高级工程师所需的深度。
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.
如果整整一代程序员 “永远无法体会到真正独立解决问题的满足感” ，也 “永远无法体会到”花数小时与错误搏斗所带来的深刻理解 ，那么我们最终可能会拥有一支只能在人工智能的指导下运作的“按钮驱动型”员工队伍。他们擅长向人工智能提出正确的问题，但却无法真正掌握答案 。而当人工智能出错时（通常以微妙的方式出现），这些开发人员可能无法发现——这会导致代码中潜藏错误和安全漏洞。
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.
这并不是说我们应该回到烛光下编程的时代。相反，这是在呼吁我们明智地使用这些强大的工具 ，以免 “不仅外包工作本身，还将我们与工作的关键互动也外包出去” 。我们的目标是在享受人工智能带来的好处的同时， 不至于在这个过程中掏空你的技能。
Using AI as a collaborator, not a crutch
将人工智能作为合作者，而不是拐杖
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:
我们如何才能既享受人工智能编程助手带来的生产力提升， 又保持思维敏捷呢？关键在于用心参与。将人工智能视为合作伙伴——初级结对程序员或随时待命的“小黄鸭”，而不是一个可靠的预言家或问题的倾倒场。以下是一些可供参考的具体策略：
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.
使用人工智能来增强代码审查，而不是取代它。 当你收到人工智能生成的代码片段时，要像人类同事编写一样进行审查。更好的做法是，也对人工智能的贡献进行人工代码审查。这可以让团队保持知识的循环，并发现单个开发人员在信任人工智能时可能忽略的问题。在文化方面，要鼓励 “人工智能可以起草，但我们拥有它” 的态度 ——这意味着团队有责任理解和维护存储库中的所有代码，无论最初是谁（或什么）编写的。
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.
积极学习：跟进并不断迭代。 如果一个人工智能解决方案有效，不要只是放弃。花点时间巩固这些知识。例如，如果你使用人工智能实现了一个复杂的正则表达式或算法，之后试着用通俗易懂的英语解释它（向你自己或队友）。或者问问人工智能为什么这个正则表达式需要那些特定的标记。与人工智能进行对话，加深你的理解，而不是简单地复制粘贴答案。一位开发者描述了他使用 ChatGPT 生成代码 ，然后不断提出后续问题，例如“为什么不这样做呢？”——就像拥有一位无限耐心的导师。这使得人工智能成为了一位导师，而不仅仅是一个代码分发者。
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.
与人工智能结对编程 。 与其将人工智能视为一个你输入查询的 API，不如尝试结对编程的思维模式。例如，你编写一个函数，让人工智能提出改进建议或捕捉错误。或者反之亦然：让人工智能写出草稿，你再进行完善。保持持续的对话： “好吧，这个函数可以运行，但你能帮我重构一下让它更清晰吗？” ——这能让你掌控全局。你不仅仅是在获取答案，还在实时管理和指导人工智能的贡献。一些开发者发现，使用人工智能就像拥有一个擅长繁重工作但需要监督的初级开发者——你是资深的负责人，对最终结果负责。
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.
通过养成这些习惯，你就能确保使用人工智能始终保持积极的一面 ：你既能获得加速和便利，又不会逐渐丧失独立编程的能力。事实上，许多这样的做法可以将人工智能变成提升技能的工具。例如，使用人工智能解释不熟悉的代码可以加深你的知识，而尝试用棘手的案例来难倒人工智能则可以提升你的测试思维。区别在于，你需要积极参与，而不是被动依赖。
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）掌控代码生成，飞速发展，而且这种魔力已无法遏制。拥抱这些工具不仅是必然趋势，而且往往大有裨益。然而，当我们将人工智能融入工作流程时，每个人都必须 “谨慎行事”， 权衡我们愿意向机器做出哪些让步。
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.
用人工智能来增强你的能力，而不是取代它们。让它把你从繁重的工作中解放出来，让你专注于创造性和复杂的领域——但不要让这些基础技能因为废弃而萎缩。保持对事物运作方式和原因的好奇心。即使人工智能为你提供了捷径，也要不断磨练你的调试本能和系统思维。简而言之，让人工智能成为你的合作伙伴，而不是你的拐杖 。
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.
蓬勃发展的开发者将是那些将人类直觉和经验与人工智能超能力相结合的人——无论是否借助自动驾驶仪，他们都能驾驭代码库。通过有意识地练习和挑战自己，你可以确保当花哨的工具失效或出现真正新颖的问题时，你仍然能够掌控方向盘，保持敏锐，随时准备解决问题 。不必担心人工智能会取代你；而要担心的是没有培养出让你无可替代的技能。正如一句现代谚语所说： “人工智能提供的东西， 工程师的头脑必须能够理解。” 保持这种思维活跃，你就能乘着人工智能的浪潮而不被淘汰。
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.
未来最优秀的开发人员将是那些没有让今天的人工智能让他们忘记如何思考的人 。
