GitHub Copilot 正式上线两年多了你用 AI 写代码用了多久我自己的体验是一年半。每天上班打开 IDECopilot 就已经弹出来了敲几个字母它就把剩下的给你补全了。有时候它比我想得还快比如我要写一个异常处理的分支它先我一步把 try-catch 写好了格式还比我工整。这种感觉挺奇怪的。你每天还是在写代码但你开始不确定这段代码到底是你写的还是 AI 写的。更微妙的是你开始懒得去想某些实现细节了——反正 AI 会给你补上。这种懒得想的冲动很危险我见过不少人就是这样慢慢把自己的思考能力外包出去了而且外包得心安理得。这篇文章不聊 AI 有多强。网上那些文章已经写得够多了什么AI 一天写了十万行代码、“大模型通过了 LeetCode 满分”听起来吓人但跟你每天坐在工位上写业务代码没什么关系。我想聊的是AI 变强之后你作为一个有 1 到 3 年经验的工程师到底还要练什么。一、先承认现实哪些工作 AI 真的能干了我先说几个我自己用下来AI 确实干得不错的场景。重复性 CRUD。你接手一个新项目产品说要加一个用户表的增删改查接口。你打开 IDECopilot 直接给你把 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 查询没那么重要了。我不是说不要学 SQLSQL 基础你肯定要会能看懂、能写基本的增删改查。但那种嵌套三层、带窗口函数的复杂查询你能写出来当然好写不出来让 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 输出的能力你就能保证写对练好系统级思维你就能写出值得写的代码。这三件事不需要 AIAI 也替代不了你。剩下的就是时间问题了。