最近我们公司在推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 够不到的东西：在混乱中做判断，在压力下做取舍，在不确定中把事情推进下去。
说到底，机器负责正确地做事，人负责做正确的事。中间那条模糊的线，就是你的价值所在。