夜雨聆风
一、两个工程师，一个任务，两种结果
Spring MVC 迁移到 Spring Boot 3.x，同时修复几个隐藏多年的 NPE bug。时间紧，历史代码又臭又长，注释比都市传说还不可信。我把任务分给了两个工程师：小A（三年经验，重度AI用户） 和 小B（五年经验，坚持“代码必须自己写”）。同一个项目，同一个截止日期，结果让我彻底刷新了认知。
小A的操作：把整个模块的代码丢给 Claude 做架构分析，然后带着 AI 生成的迁移方案和风险清单来找我对齐。中途遇到一个
Optional 链式调用引发的空指针，他直接写了一个 Prompt 让 AI 做了 5 种修复方案的对比，选了最优解。整个过程，他像在指挥一个高效的副手。小B的操作：打开 IDE，从第一行代码开始读，边读边骂“这谁写的”。遇到 NPE 就自己画调用链路图，遇到配置变更就去翻 Spring 官方文档。三天后他告诉我：“老大，这个模块太烂了，我需要重写。”——而小A在第二天就已经提了 PR，测试覆盖率 85%，新增代码行数不到小B预估的十分之一。
差距？不是三倍，是五到十倍。 而且不是速度的差距，是 思考方式 的差距。
二、AI 不是替代你的手，是替代你的“找”和“试”
AI 最擅长的不是创造，而是 检索、匹配、组合。这三件事恰好是工程师日常花时间最多的：
- 检索
：查 API 文档、翻 StackOverflow、翻历史代码——AI 一秒搞定。 - 匹配
：“我这个场景是不是有现成的设计模式？”——AI 能列出 5 个候选并解释优劣。 - 组合
：把 A 库的认证逻辑和 B 库的缓存策略拼到一起——AI 帮你搭好脚手架，你只需要验证和微调。
我自己的真实经历：去年接手一个
Kubernetes Operator 的维护，代码用 Go + controller-runtime，我之前没写过 Operator。给我两周熟悉，我花了一周痛苦地读文档、看示例、调试，进展很慢。后来我换了个思路：把问题抛给 AI。我把整个 Operator 的代码结构粘贴进去，然后问：“这个 Operator 的核心 reconcile 逻辑是什么？如果我要加一个自定义资源的 watch，代码应该改哪里？依赖的库版本有哪些坑？”
AI 十分钟内给我画了一张完整的架构图（Mermaid），列出了 6 个关键代码位置和 3 个已知的
controller-runtime 版本兼容性问题。我按它的指引去验证，80% 是对的，剩下的 20% 属于它过度理想化（比如没考虑限流和重试的细节）。但至少我第一天就有了全局理解，而不是在代码大海里乱游。不会用 AI 的工程师，是在用蛮力对抗复杂度；会用的，是在借力拆解复杂度。 你省下来的不是“写代码”的时间，而是“理解代码”“寻找答案”“试错”的时间。
二、一个反常识的结论：AI 反而提高了“代码质量”的门槛
因为 AI 可以帮你快速生成“可以运行”的代码，但验证、调试、优化、以及判断“这个方案是否适合当前业务”——这些 真正体现工程能力 的部分，AI 做不了，也没法做。
我举两个场景对比：
第一个工程师在“低价值重复”上花的时间多，第二个工程师在高价值判断上花的时间多。同样的产出，后者学到了更多，成长更快。
四、我的判断：AI 是“能力放大器”，不是“能力替代器”
为什么？因为糟糕的工程师缺乏 判断力。AI 给你 10 个方案，你不知道哪个好，选了最差的那个，出了 bug 还怪 AI。优秀的工程师能快速从 10 个方案里挑出最优的，或者把 3 个方案组合成一个更好的，还能预判 AI 没考虑到的边界情况。
所以差距在哪？不在写代码的速度，在于“拆解问题”和“判断方案”的能力。 不会用 AI 的工程师，手速再快也快不过 AI；会用 AI 的工程师，能把 AI 变成自己的思维外挂，一个打十个。
我甚至觉得，未来两年，“会不会用 AI 辅助编程”会像“会不会用 Git”一样，成为工程师的基本门槛。 不是可选项，是必选项。不会用 Git 的工程师你不敢合作，不会用 AI 的工程师，效率差距大到团队没法平衡。
五、小结（带着立场）
我的答案是：当前是 3-5 倍的效率差距，一年后会拉大到 10 倍以上。 因为 AI 工具本身也在进化，会用的人会越来越强，不会用的人连追赶的机会都会越来越渺茫。
别把 AI 当敌人，也别当保姆。把它当成一个永远有耐心、永远不累、永远愿意给你 10 个版本的 junior 工程师。 你是那个 senior，你来审它的活儿，你来拍板，你来负责。
工具摆在这了，用不用是你的事。反正我团队现在招人，面试最后一问一定是：“如果给你一个你完全没接触过的框架，你打算怎么用 AI 帮你一周内上手？”
回答“我不用 AI”的，我直接 pass。不是偏见，是团队拖不起这个效率差。
自己掂量。