别卷“AI能做的事“，去练“AI做不了的事“

最近我们公司在推AI Coding工具不管产品还是研发、测试 人手一个账号 用来提升自身的工作效率。大家挖掘其中的用法 一段时间后确实有部分人反馈非常好用研发用来生成代码、找bug、优化性能等测试用来根据接口生成用例 直接写调试脚本。但同时又产生了新的焦虑——AI提升了工作效率做事比人又快后面真能抢自己的饭碗还有效率的提升 也代表着后面会被分配更多的活。说实话现在有互联网公司正在用AI代替前端人员很多外包前端都被毕业也不得不逼我们深思继续下去后端会不会也完全替代。去年有个项目做数据迁移我用 AI 工具试了一下给它源表和目标表结构、字段映射关系二十分钟出了四十多个脚本跑起来基本没问题。这事要是我自己干至少得一个下午。还有一段时间刷技术社区满屏都是AI 写代码比人快、某某工具一键生成微服务看得人确实心里发毛。如果这种活它都能干那我攒了这么多年的经验到底值钱在哪我们焦虑的到底是 AI 太强还是我们自己都没搞清楚到底什么才算有能力我在之前的文章《当新人用了AI不再啃屎山代码未来的高级工程师从哪来》中也提到过AI给技术人员成长过程中带来的问题。很多人觉得 AI 焦虑是技术问题其实不是。大家怕的不是 AI 本身而是自己这些年干的活本质上跟 AI 干的没什么区别。普通的CRUD、接口对接、数据格式转换、单元测试生成——这些有明确输入、固定规则、可验证输出的事情AI 干得又快又稳还不加班不要年终奖。如果你的日常工作可以被写成一份足够详细的 SOP先做 A 再做 B 遇到 C 走分支 D那这部分工作确实早晚不属于你。以前是人写脚本自动化现在是 AI 把写脚本这件事也自动化了。但你有没有想过过去一年里让你真正头疼的那些事有几件是照着文档做就行的需求是模糊的利益是冲突的历史包袱是甩不掉的上线风险是算不准的。你要在信息不全的时候拍板要在两边都有理的时候取舍要在出了事的时候站出来扛。说白了AI 能搞定的全是有标准答案的事。可真实工作里大部分问题根本没有标准答案。公司有个同学参与系统从 Eureka 迁 Nacos方案他写的灰度计划也排好了。结果切到第三天出了事——新注册中心跨网段 Raft 选举卡死服务发现全挂下游十几个微服务拿不到地址整个链路雪崩。而且那天是周五下午四点。运维说回滚吧他说先别动。因为他清楚 Eureka 那套集群的证书上个月刚过期回滚了还得搞证书搞不好又是一两个小时。他做了个决定不回滚直接在 Nacos 侧把跨网段的三个节点临时摘掉先用同网段的撑着同时手动刷新客户端缓存。二十分钟服务恢复了。如此场景你让 AI 来做这个决定试试。它不知道该不该回滚因为它不知道 Eureka 证书过期了。它不知道跨网段节点该摘哪几个因为它不知道机房拓扑。它也不知道周五下午四点这个时间点意味着什么。还有个事更有意思。组内有个后端同学负责一个内部公共组件一直运行稳定。有天下午好几个项目同时报空指针查下来是某个项目组调方法传了个 null 进来组件没做校验。十分钟就修好了。结果复盘会上对方负责人说公共组件健壮性不足防御性编程是基本功文档约束不等于技术约束。他急了说你们传 null 是你们的问题吧对方不慌不忙回了一句你是 Owner你做最后兜底。后来他把组件所有公开方法全加了校验异常信息也做了优化空指针变成了明确的参数异常还加上了调用方的类名和方法名方便定位。他跟我说下次再炸日志里直接告诉他是他传错了省得再甩锅给我。 这个事之前在《被罚了500后整个人都变老实了》文章中也提过。这种被人甩过锅之后长出来的防御意识你觉得 AI 的训练数据里有吗有时候夜深人静我也会想这十年到底攒了什么。不是某个框架的 API 熟练度那玩意三年一换。不是某种语言的特性掌握写多了谁都会。甚至不是架构设计的方法论看书看博客也能学个七七八八。真正攒下来的是踩坑的记忆。你知道 Nacos 选举在跨网段的时候可能卡死不是因为你看过论文是你真的遇到过排查了三天才定位到。你知道 Eureka 的自我保护机制在生产环境不能随便关因为你关过一次网络抖动的时候服务全挂了。你知道 RabbitMQ 重启之后消费者重连要加退避策略因为你被雪崩式重连坑过凌晨两点被电话叫醒的那种经历忘不掉的。这些记忆没法被文档化也没法被谁学到。它长在你脑子里下次做方案的时候会自动跳出来提醒你——这条路走过是死胡同。除了踩坑的记忆还有担责的勇气。你背过锅被骂过经历过凌晨的故障和客户的投诉。但第二天你还是来了下次做决定的时候你还是敢拍板。这种勇气不是天生的是一次次事故和复盘磨出来的。很多人只注重代码能力忽略了判断力、取舍力、担责力。但实际上公司需要的不是会写代码的程序员而是能在混乱中把事推进下去的人。高级工程师的高级从来不是代码写得漂亮。是敢在一团乱麻里做决定也敢为选错的后果买单。它首先是一种判断力。方案 A 性能好但维护成本高方案 B 开发快但扩展性差方案 C 什么都好但团队没人用过。没有哪个方案是错的但你得选一个。而且是在需求还没完全定、排期已经压到极限、老板还在旁边说能不能两个都做的时候选。然后是一种取舍力。我见过不少技术很强的人栽在同一个地方在不需要完美的地方死磕。一个内部运营工具日活不超过二十人他非要用最流行的架构、做完整的领域建模、写全套的集成测试。活干得漂不漂亮漂亮。但耽误了三周上线业务方差点投诉。知道什么时候该追求完美什么时候能用就先上这个分寸感不是看书能学会的。残酷的现实是什么普通开发的产出增速在下降因为 AI 把正确地做事的门槛拉低了。但能处理不确定性的人价值在持续走高。差距在于你是熟练生产的还是处理不确定性的。有个说法我觉得挺对的你的不可替代性等于你能处理的不确定性总量。AI 没有踩过你的坑所以它不知道理论最优解和能落地的解之间隔着多大的鸿沟。AI 也不会背锅所以它永远无法理解一个看似普通的技术决策背后有多少妥协。如果你还在焦虑AI 会不会取代我先问自己几个问题。你写代码的时候有多少比例是在执行已知方案有多少比例是在面对未知做判断如果大部分是前者那确实需要警惕。如果后者不少那你焦虑的方向就搞错了。你这十年攒下来的东西到底是熟练度还是判断力如果只是前者AI 确实比你快。但如果是后者它比不了。你有没有遇到过那种只有你能搞定的局面如果有那个局面里AI 能帮上多少忙AI 不是来抢你饭碗的是来帮你照清楚——你碗里装的到底是什么。我觉得 AI 是一个巨大的机会——它把熟练工的门槛拉平了反而逼着我们往更高的地方走。别卷那些 AI 能做的事了去练那些 AI 够不到的东西在混乱中做判断在压力下做取舍在不确定中把事情推进下去。说到底机器负责正确地做事人负责做正确的事。中间那条模糊的线就是你的价值所在。