半年前团队来了个应届生，挺机灵的。入职第三天，他拿Cursor写了个完整的CRUD模块，接口、校验、异常处理，一应俱全。代码贴出来，格式规整，命名规范。
我盯着屏幕看了几秒，说实话，心里咯噔了一下。
十年前我干这事，得翻文档、查Stack Overflow、对着IDE一行行敲，少说大半天。他二十分钟搞定了。
那天晚上我骑车回家，风灌进领口，脑子里一直转一个问题：如果经验和知识可以被一个工具在几分钟内补齐，那我多出来的这十年，到底值什么？
知识这条护城河，确实塌了
我不想装。
以前带新人，我最有底气的就是"你这个问题我见过"。Spring事务传播机制的坑、JVM的GC调优、分布式锁的边界case……这些东西靠踩坑攒出来的，新人要追上来，得熬。
现在呢？他问AI，三秒钟，不光给你答案，还给你三种方案对比，顺便告诉你各自的适用场景。
我花了三年才真正理解的"为什么这里要用ConcurrentHashMap而不是synchronized"，他可能花三分钟就"理解"了。当然，他那种理解和我的理解不是一回事，但表面上，那个信息差没了。
承认这一点，其实挺难受的。
但有些东西，AI给不了你答案
转折发生在大概两个月前。
线上一个订单系统出了个诡异的bug：高峰期大概万分之一的订单会重复扣款。日志看着没问题，链路追踪也完整，该幂等的地方也做了幂等。
新人用AI分析了半天，AI给了一堆可能性：网络重试、消息队列重复消费、缓存不一致……都对，但都太泛了。等于把教科书上"分布式事务常见问题"列了一遍。
我坐在那儿没急着动手。我在想的是另一件事：这个bug只在高峰期出现，而且只出现在某个特定的支付渠道。那说明它大概率不是通用的并发问题，而是跟那个渠道的回调机制有关。
顺着这个方向去查，果然，那个渠道的异步回调在网络抖动时会发两次，而我们的幂等键用的是订单号，没用渠道流水号。改一个字段的事。
你看，AI能给你一百种可能性。但决定你先排查哪一个的，是你对系统的"体感"。是你对这个业务链路的熟悉程度，是你脑子里那张不是画在文档里、而是长在直觉里的架构图。
这种东西，不是"知识"。是十年里无数次半夜被电话叫醒、无数次对着监控面板发呆、无数次在"为什么"和"到底是什么"之间反复横跳之后，长出来的一个东西。
我后来想，真正的差距是"怎么想"
我现在带新人，越来越不关心一个人知不知道某个API、某个框架的某个特性。那些东西，说实话，我也记不全，我也得查。
我关心的是另一件事。
需求评审的时候，产品丢过来一个功能。有人接过去就开始想"怎么实现"，脑子里已经在拼技术方案了。但有人会先停一下，问一句：这个问题，本质上是在解决什么？有没有可能根本不该用这个方案？
这就是拆解问题的思维。不是"怎么做"，是先想清楚"做什么"和"为什么做"。
再比如架构设计。初级工程师想的是"我要用微服务"、"我要上消息队列"。但做过几年、真正被坑过的人想的是：这个系统的读多还是写多？数据一致性要求到什么程度？未来半年最可能的变更方向是什么？我能不能先用一个更简单的方案扛住，把复杂度推迟？
这是架构思维。它不是一条规则，是一种"在约束条件下做取舍"的直觉。而取舍，AI替你做不了，因为取舍背后是你对业务上下文、对团队能力、对时间窗口的综合判断。
还有一个我特别在意的：抽象能力。
代码写多了你会发现，很多看起来完全不同的问题，底下是同一个模式。你见过足够多的"具体"之后，慢慢能提炼出"一般"。这个能力让你在面对新问题时，不是从零开始，而是能迅速归类："哦，这本质上是个生产者-消费者问题"、"这其实是个状态机"。
AI可以帮你写出具体的实现，但"这个问题本质上是什么"这个判断，是你自己做的。
我也焦虑过，现在好一些了
说完全不焦虑是假的。
去年有段时间，我反复想：如果AI再进化两年，是不是连"怎么想"它也能模拟了？是不是我引以为傲的那些"直觉"、"体感"，本质上也不过是足够多的pattern matching，只不过跑在我脑子里而不是GPU上？
想了很久，没有确切答案。但我后来跟自己和解了，原因很朴素：
就算AI有一天真能模拟这些思维方式，在真实的工程场景里做决策的那个"主体"，还是得是人。你要跟产品吵，要跟业务方确认需求边界，要在凌晨三点判断这个bug要不要回滚、回滚的代价是什么、不修的风险是什么。这些决策不只是技术问题，是责任问题。AI没有"担责"这个概念。
而且，怎么说呢，写代码这件事对我而言，早就不只是谋生了。我享受那种把一坨混乱的需求理成清晰结构的快感，享受那种"啊原来如此"的debug瞬间。这些东西AI替代不了，不是因为AI不够强，是因为它没有"我"。它不会在解决一个问题之后，坐在工位上愣两秒，然后轻轻笑一下。
写在最后
我今年三十七了。头发比十年前少了一些，颈椎也不太行，加班到十一点第二天就缓不过来。
但我不太想回到二十五岁了。
二十五岁的我知道很多API，能背很多八股文，手速快，能肝。但我那时候看一个系统，看到的是一堆零件。现在我看一个系统，看到的是零件之间的关系，是力，是流动，是哪里会先撑不住。
这个视角，是时间给的。是那些bug、那些故障、那些"卧槽怎么会这样"的深夜给的。
AI把"知道"这件事变得廉价了。这其实是好事。它逼着我们去想一个以前可以含糊过去的问题：除了知道，你到底还会什么？
而那个答案，往往是你怎么思考，怎么拆解，怎么在混乱中找到结构，怎么在不确定中做判断。
这些东西没有快捷键，没有Skill模板。
它们是你。
所以如果你也是一个写了很多年代码的人，你最近也在焦虑 AI 会不会让你变得不再被需要
我想了很久，我的答案是：你那些真正痛苦地"想"过的东西，谁也拿不走。
别慌。
你的护城河从来不是你知道什么。
是你怎么想。
写于一个普通的周六下午，代码写不动了，就写点别的。如果你也是个写了几年代码的人，希望这篇能让你觉得，这些年没白熬。
数据仓库中的全维度宽表：复用利器还是治理陷阱？
DWS 宽表和 ADS 宽表，不是一回事
组里只有一行有值，却要填给所有行？——分组「稀疏值回填」的窗口函数范式
Doris LATERAL VIEW explode_split 实战：优雅实现“一行转多行”
数据链路重构复盘：新模型上线，如何优雅的兼容旧模型？
数据治理：如何做计算存储治理？
面试问：如果业务需求突然增加一个“7天未激活用户”的标签，落在DWS层，你会从哪层开始设计？
面试问：DS中数仓分层调度策略是怎样的？是所有的任务都写到一个WF中吗？
面试问：数仓中跨域是放在哪一层？跨域整合和联邦查询有什么区别？
游戏数仓 : 用户行为属性大表整合【宽表设计】
