GitHub Copilot 正式上线两年多了，你用 AI 写代码用了多久？我自己的体验是一年半。每天上班打开 IDE，Copilot 就已经弹出来了，敲几个字母，它就把剩下的给你补全了。有时候它比我想得还快，比如我要写一个异常处理的分支，它先我一步把 try-catch 写好了，格式还比我工整。
这种感觉挺奇怪的。你每天还是在写代码，但你开始不确定这段代码到底是你写的还是 AI 写的。更微妙的是，你开始懒得去想某些实现细节了——反正 AI 会给你补上。这种"懒得想"的冲动很危险，我见过不少人就是这样慢慢把自己的思考能力外包出去了，而且外包得心安理得。
这篇文章不聊 AI 有多强。网上那些文章已经写得够多了，什么"AI 一天写了十万行代码"、“大模型通过了 LeetCode 满分”，听起来吓人，但跟你每天坐在工位上写业务代码没什么关系。我想聊的是：AI 变强之后，你作为一个有 1 到 3 年经验的工程师，到底还要练什么。
一、先承认现实：哪些工作 AI 真的能干了
我先说几个我自己用下来，AI 确实干得不错的场景。
重复性 CRUD。你接手一个新项目，产品说要加一个用户表的增删改查接口。你打开 IDE，Copilot 直接给你把 Controller、Service、Mapper 一套都生成出来了，字段映射都给你写好了，命名规范跟你项目里的风格一致。这种活以前要花你半天，现在十分钟就搞定，而且生成的代码比你手写的还整洁。
API 文档注释。以前写 JSDoc 或者 Python docstring 是真烦人，经常写完代码之后懒得补，或者随便糊两行。AI 不嫌这个活烦，直接给你把参数说明、返回值描述、异常情况都补上了，还带使用示例。这种机械性的文档工作，AI 已经做得比大多数工程师认真了。
代码翻译。比如你之前用 Python 写了一个数据处理脚本，产品那边技术栈是 JavaScript，研发团队让你翻译一份。扔给 Claude 或者 GPT，七八成的翻译是对的，类型转换、异步处理这些细节它也能照顾到。你要做的只是通读一遍，把明显不对的地方改掉。这活以前要花你一天，现在两个小时够了。
简单 bug 定位。线上报了一个空指针异常，堆栈扔给 AI，它能快速告诉你问题大概出在哪个文件的哪一行。有时候还能帮你把问题原因分析清楚，比如"这里因为集合未初始化导致遍历时报错"。当然仅限于简单场景，复杂的我后面会说。
一个需要直面的事实是：AI 做的是"把 60 分的活干掉"，而不是替代所有工程师。那些靠堆时间、堆重复劳动生存的岗位，确实受到冲击了。但如果你只会写 AI 能写的那种代码，你本来也没什么护城河。这个话说得不好听，但这是现实。
二、真实情况：哪些它还是干不了
AI 能干的事情说完了，我们来说说它干不了的。这部分比上面的重要得多，因为它决定了你的价值在哪里。
理解业务逻辑。我举个例子。你公司有个订单系统，用户下单之后有个"超时取消"的逻辑，代码里写了个定时任务，每五分钟扫一次，把超过三十分钟未支付的订单取消掉。产品有一天找到你说，这个定时任务能不能改成用户下单时直接压一个延迟消息，到点了自动取消。你看了看代码，说可以，但有个问题：如果用户在第二十九分钟的时候点击了支付，支付成功的同时取消消息也刚好投出来，这两个操作的时序问题怎么处理？AI 能给你写出来这个延迟消息的实现，但它不知道你需要考虑这个时序问题，因为这是业务层面的判断，不是代码层面的实现。
系统设计。我见过一个真实的案例。某个创业公司的后端工程师想让 AI 帮他设计一个秒杀系统，AI 给出了一套看起来非常标准的方案：Redis 缓存库存、MQ 异步下单、数据库乐观锁。听起来都对。但上线第一天就崩了——因为没有考虑 Redis 和数据库之间的数据一致性，也没有考虑 MQ 消费失败之后的重试策略，更没有考虑热点数据对 Redis 本身的压力。这些问题 AI 没有主动提，因为它不知道你的业务量级，不知道你的团队技术储备，不知道你用的中间件版本有没有已知的坑。系统设计本质上是一种权衡，权衡就需要判断，判断就需要经验。
调试复杂问题。线上偶发性的问题最难搞。比如某个接口每天有那么一两次响应时间突然变长，监控曲线看起来毫无规律，堆栈信息又不完整。这种问题扔给 AI，它能帮你分析几种可能性，但每种可能性的概率它没法告诉你，因为它没有线上环境的感知能力。你只能靠自己去查日志、去复现、去排除。我之前处理过一个 MySQL 死锁问题，AI 给了我好几个可能的原因，但到底是哪个，要靠我自己逐个排查，最后发现是一个长事务持有锁的时间太长导致的，这个细节跟具体业务逻辑强相关，AI 给不了答案。
和人沟通。这个其实才是大多数工程师低估了的价值。产品经理跟你说了一个需求，听起来很简单，但你在评审会上问了一句"这个功能上线之后，如果用户量涨十倍，现有的缓存策略还撑得住吗"，然后整个方案就变了。这种在沟通中挖掘出来的风险，靠的是你对业务的理解和对系统的判断，不是靠写代码的速度。AI 听不懂产品经理的弦外之音，也听不懂技术评审会上某个人说话时眼神飘向了哪里。
一个越来越清晰的趋势：AI 越强，"知道要做什么"这件事就越值钱。因为 AI 能把"怎么做"做得越来越快，但"做什么"和"为什么做"永远是人的责任。你能问出正确的问题，比你能写出正确的代码更重要。这个判断在接下来几年会越来越准确。
三、程序员应该重点练的三件事
这一节是全文最核心的部分。我不会给你列一个能力清单然后让你去打勾，我只说三件事，这三件事如果你练好了，AI 再强也替代不了你。
第一件事：理解业务的能力
很多人以为写代码就是写代码，跟业务关系不大。这是一种非常危险的误解。
我带过一个实习生，代码写得挺规范的，变量命名也清楚，但每次问他这个接口是给谁用的、日活多少、极端情况怎么处理，他都答不上来。有一次他写了个批量查询接口，没有加限制查询条数的逻辑，测试的时候没问题，上线之后被运营一个查询请求把数据库打爆了。他写的代码本身没错，但不知道业务边界在哪里，这就是理解业务的能力缺失。
AI 能写出语法正确的代码，但它不知道这段代码在解决什么问题，更不知道这个问题背后有什么隐含的约束。你要能回答：这个接口是给哪类用户用的，日均调用量大概多少，有没有可能有人恶意刷接口，如果有的话怎么处理。这些判断不能靠 AI，只能靠你对业务的了解。
练习方式很简单：每次接需求，在打开 IDE 之前，先把业务流程画出来。画完之后给产品和测试讲一遍，看他们有没有要补充的。如果你能把一个需求用五分钟讲清楚产品价值和边界约束，那你对这个需求的理解就到位了。
第二件事：判断 AI 输出的能力
这个能力是被大多数人忽视的，而且刚入行的工程师最容易在这里踩坑。
我见过一个真实的例子。有个同事让 AI 帮他写一个算法，用来计算一组数的滑动窗口最大值。他的代码跑通了，测试用例也过了，于是直接提交了。过了一段时间发现生产环境有个 bug，一查日志，发现是滑动窗口边界处理有问题——当窗口大小为 1 的时候，他的代码和 AI 生成的代码行为不一致。他回头去看了 AI 生成的代码，发现 AI 对边界情况的处理是错的，但他没有 review，直接信任了 AI 的输出。
这就是问题所在：AI 会一本正经地给你写一个完全错误的解法，而且它不会告诉你"这个解法我不太确定，你最好检查一下"。它永远很有信心，哪怕答案是错的。
你得能看出来：这段代码在干嘛，时间复杂度对不对，空间复杂度对不对，边界条件考虑了没有，数据类型转换有没有问题。这些判断需要你有足够的代码经验才能做出来。
练习方式同样很简单：AI 给的代码，每个函数都读一遍，想清楚这个函数在做什么，然后跟自己写的对比一下。你觉得你能写得比它更好还是它写得比你好？这个判断过程本身就是你在练的东西。不要直接复制粘贴运行通过就完事了。
刚入行的工程师最容易被 AI 坑，因为他们的代码跑通了，但不知道跑通的是什么。AI 输出的东西对于有经验的人来说是好东西，对于没有经验的人来说是一个危险的捷径。
第三件事：系统级思维
单函数单文件，AI 已经很强了。但涉及多个模块、多个服务的整体设计，AI 还是业余水平。
我举个例子。产品说要加一个实时通知功能，让你去设计这个子系统。AI 能帮你生成一个大概的架构：Kafka 接收事件、WebSocket 推送、Redis 做在线状态管理。听起来都对。但等你开始设计的时候，问题就来了：推送失败怎么办，是重试还是落库；用户不在线的时候消息怎么存；推送量大的时候怎么削峰；怎么避免消息重复投递。这些不是单点问题，是系统协作问题，AI 给不了你一个现成的答案。
什么是好的系统设计？接口边界怎么定、数据库选什么、缓存放哪层、服务之间怎么通信。每一个决策背后都是权衡，没有标准答案。你的经验决定了你能看到多少权衡点，你的判断力决定了你能做出多优的权衡。
练习方式我自己的经验是：读完别人的系统设计文章或者方案之后，合上文章，自己从头设计一遍，然后再对比看看自己漏了什么。这个过程比单纯读十篇文章有用得多。
四、那些技能没那么重要了
下面我说几个可能有点争议的观点。
背诵语言细节没那么重要了。Python 装饰器原理是什么、Java GC 分代是怎么工作的、JavaScript 事件循环机制是什么。面试会问，但实际工作中遇到这些底层问题，你查一下文档或者让 AI 给你解释一下，效率比你硬背高得多。这些知识重要，但不需要你花大量时间去背，需要的时候能查、能理解就行了。
手写复杂 SQL 查询没那么重要了。我不是说不要学 SQL，SQL 基础你肯定要会，能看懂、能写基本的增删改查。但那种嵌套三层、带窗口函数的复杂查询，你能写出来当然好，写不出来让 AI 帮你写，然后你 review 一遍，这个效率更高。关键是看懂，而不是能默写。
记住所有命令行参数没那么重要了。Linux 的 top、ps、netstat 这些命令的参数很多，你不需要全部记住。man 查一下或者让 AI 帮你写一个命令，比你背下来效率高得多。我自己的习惯是需要什么参数当场查，查几次自然就记住了，没必要专门花时间去背。
一个核心观点：记忆力不再是核心竞争力，判断力才是。你知道某个知识点在哪里，比你能背诵这个知识点更有价值。这个变化很多人还没适应，尤其是从学生时代过来的工程师，习惯了"记住就能考高分"的模式。但在工程领域，记住不等于会用，会用不等于能用对。
五、具体怎么练：可操作的建议
说完了认知层面的东西，最后给几个可以落地的建议。
每周至少写一次没有 AI 参与的代码。不是为了返璞归真，是为了保持手感。我自己这么做了半年，发现一件有意思的事：我用 AI 写代码写得越久，我不用 AI 写代码的能力反而在退化。有些我以前能轻松写出来的逻辑，现在要停顿一下才能想起来怎么写。这个感觉就像你天天用导航开车，突然有一天要自己找路，发现路痴了。每周给自己留一块不插电的工作时间，专门用来写一些有挑战性的代码，保持自己的基础能力不退化。
定期重构自己半年前写的代码。找一天时间，把你半年前写的代码翻出来看看，然后问自己：如果我现在重写，会怎么写。如果你觉得当时写的挺好的，恭喜你，你进步不大。如果你觉得当时写的简直没法看，那说明你在进步，而且进步得挺快。我用这个方法检验自己，发现大概每半年就会觉得半年前的自己是个笨蛋。这个感觉很好，说明你在往前走。
读优秀的开源项目，不是 GitHub Trending。GitHub Trending 上的项目通常是新的、热的，但不一定适合学习。你要找的是那种 star 数量稳定、维护了很多年的老项目，比如 Python 的 requests、Go 的 golang/go、Kubernetes。这些项目经过了大量用户的检验，它们的代码里藏着无数真实场景下踩过的坑。看人家怎么处理边界条件、怎么处理并发、怎么处理错误，这些经验比任何教材都有价值。
学会用 AI 做工具，而不是被 AI 当工具用。Copilot、Claude Code、Cursor 各有优劣，没有一个 AI 是全能的。Copilot 补全代码快，Claude Code 上下文理解深，Cursor 的多文件编辑体验好。你要把它们当成不同的工具，针对不同的场景选择最合适的那个。这就像你不可能用一把锤子拧螺丝，用对了工具效率才能最大化。
把 AI 当成你的徒弟，不是你的替代者。徒弟干什么？徒弟执行你的指令，你在关键节点把关。你告诉 AI 要做什么，它去执行，你 review 它的输出，决定哪些接受哪些修改。这个模式意味着你需要有能力判断它干得对不对。如果你没有这个判断力，你就成了被 AI 使用的工具，而不是你使用 AI 的工具。
六、面试还会问什么
有人可能会问：既然 AI 都能写代码了，那面试怎么面？问算法题还有意义吗？
先说算法题。算法题不会消失，但考核的重点在变。以前考算法题可能考核的是"你能不能写出来"，现在考核的是"你能不能在 AI 辅助下高效地做出来并且做对"。同一个算法题，你查题解和 AI 给你提示然后做出来，成本是不一样的。面试官会越来越多地考察你对算法思路的理解深度，而不只是你能不我能写出正确答案。
原理类问题没有消失，反而更重要了。HashMap 怎么实现的、HTTP 握手过程是什么、MySQL 索引为什么用 B+ 树。这些问题 AI 能回答，但你能判断 AI 回答得对不对。面试官问这些，不是要考你的背诵能力，是要考你的理解深度。如果你依赖 AI 回答这些问题但没有真正理解，你迟早会在实际工作中吃亏。
系统设计题变难了。以前系统设计题是考察知识面，看你知道多少种方案。现在不仅要考察知识面，还要考察你怎么在 AI 辅助下做权衡。你能不能快速评估 AI 给出的方案有什么问题，能不能问出关键的限制条件，这本身就比单纯背方案要难得多。
项目经历问得更深了。以前面试问项目经历，通常问的是"你做了什么"。现在更倾向于问"你做的那段 AI 干不了的判断是什么"。你能不能讲清楚你在项目里的一个关键决策点是什么，你为什么做了这个选择而不是另一个选择，你是怎么权衡的。这种问题没有标准答案，AI 也帮不了你，因为它只属于你自己的经验。
写在最后
AI 不会让你失业，但会用 AI 的程序员会让不会用的程序员失业。
这句话听起来像废话，但我见过太多人把它理解错了。意思不是"你要学会用 Copilot"，而是"你要成为一个能用 AI 放大自己能力的人，而不是一个被 AI 替代了还没反应过来的人"。
你的竞争优势不在于"能写代码"，而在于"知道写什么代码、为什么写、写成什么样"。这个判断力，AI 还没学会。它能帮你把代码写得更快，但它不知道这段代码值不值得写。
练好理解业务的能力，你就能回答"写什么"；练好判断 AI 输出的能力，你就能保证写对；练好系统级思维，你就能写出值得写的代码。这三件事不需要 AI，AI 也替代不了你。
剩下的，就是时间问题了。