我最担心的工程师，不是那些正在为求职发愁的应届生。
而是那些已经做了十年工程师、加了AI工具、生产效率却跟18个月前差不多、最后得出结论说"AI有点用但没什么大不了"的资深工程师。
找不到工作的应届生至少清楚自己面对的是一个问题。到了高原期的资深工程师，往往连问题在哪里都意识不到。
1. 你其实已经经历过两次这种转变
大多数资深工程师，其实已经经历过这种结构性转变，而且不止一次。
第一次：从普通工程师变成 tech lead。你不再自己写每一行代码，而是开始指导其他工程师。产出倍增了——一个带着团队的 tech lead，能做到的事情远超任何一个单打独斗的人。但过渡期很难受，因为你感觉自己好像在"少做实际的事"。
第二次更隐晦：从 tech lead 逐渐往 manager 的方向走。更少的动手执行，更多的判断、架构方向把控和赋能身边的人。
AI 要求的，是第三次转变——而且结构跟前两次一模一样。
你不再是团队里代码写得最好的那个人。你是指挥 AI 来写代码的那个 manager，自己专注在 AI 做不到的事情上：判断、架构、产品感觉、组织上下文，以及让团队成长。
完成了这个转变的工程师，相当于拥有了一支无限扩张的团队。他们负责定义问题、设定标准、review 架构、把控执行方向。没完成这个转变的人，用 AI 做的是键盘升级——同样的工作，快一点，天花板还是一样。
你真正完成了哪次转变，答案可能跟你以为的不一样。
2. 同样的工具，两种结果
这件事我在自己团队里亲眼见过。
一位工程师，技术背景扎实，做事细致，十年经验。他接入AI的方式跟大多数资深工程师一样：code review、快速查资料、写文档。他能告诉你哪个工具适合哪类任务。产出确实有提升，但每天工作的基本样子没变。AI 让他更快地做了同样的事。
另一位工程师问了一个不同的问题。不是"AI能帮我更好地完成我现在的工作"，而是"如果从头重新设计这个工作流，应该是什么样子？"
结果是：他重建了整个新人入职流程。不只是文档——包括按天拆分的计划、环境配置指南、系统背景介绍、第一个月各阶段的检查节点。以前这些内容需要好几周的协调才能整理出来。新人上手时间缩短了一半。
这不是效率的小幅提升。这是工作方式的质变。
这两位工程师的差距，不在于工具更好或时间投入更多。在于他们用AI做的事情是不是本质上不同的事情。
3. 技术越强越容易踩的四个坑
资深工程师用AI时踩的坑有规律可循，而且不是随机的——它们几乎都来自让你变厉害的那些习惯。
坑一：给得太细
你花了多年时间，养成了动手之前先想清楚实现思路的习惯。所以交给AI的时候，你也这么做：想好方案、拆解问题、勾出架构，然后详细描述给AI。
结果：AI按你的规格生成了代码。你已经完成了大部分认知工作。你建造的，是一个高级打字机。
改变方式：给AI目标和约束，不给实现方案。让AI提出方案，你来判断方向。这让习惯于精准思考的工程师很不舒服——但这跟你第一次学会给别人授权时一模一样。
坑二：事无巨细地 review
AI 生成了400行代码。你把400行都读了一遍。
本能没错——你对上线的代码负责，你知道哪里可能出问题。但账算不过来。如果 review AI 的输出要花和自己写一样长的时间，你只是换了个瓶颈。
改变方式：分层 review。架构和关键接口认真看——这是 AI 最容易犯结构性错误的地方，一旦犯了会越滚越大。实现细节靠测试覆盖，不靠逐行阅读。这需要真正信任你的测试覆盖率，也就是说你需要把测试这件事投入方式改一改。大多数工程师跳过这一步，然后搞不明白为什么效率没提升。
坑三：自己把 bug 修了
AI 输出了有问题的代码。你发现了。本能：自己改掉。
但你刚刚把原本想委托出去的工作拿回来了。你也错过了一次验证：AI 在拿到明确反馈的情况下，能不能自己修复。
改变方式：当 AI 输出有问题的东西，把问题描述清楚，带着上下文还给它。明确说哪里错了，期望是什么。前几次会慢一点。从一个项目的维度来看，这能让你始终在对的抽象层次上工作。
坑四：被速度淹没
AI 太快，你同时开了三个任务。然后是五个。然后你在一堆没做完的事情之间来回切换，在还没想清楚要什么的情况下就开始 review 输出，产生了大量动作却没有一条清晰的主线。
处理得好的工程师，把 AI 的速度当成一个理由去在上游更用心——而不是更粗心。他们在 brainstorm 阶段投入更多，在执行开始前把要什么说清楚。AI 在跑的时候，他们在想下一个问题，不是在盯着这一个。
4. Agile 没有过时，它变得更强了
四个坑说的是工程师个人的工作习惯问题。但资深工程师还有一个系统性优势往往被低估：他们已经内化了工程方法论。
Agile 还是有效的。Sprint、用户故事、迭代交付、回顾会——这套框架，没有过时。如果说有什么变化，是 AI 让 Agile 每个环节都变得更有力量。
需求梳理：AI 可以帮你在一个用户故事里找出边界情况、模糊之处和隐含假设。以前需要两小时的 grooming 会，现在二十分钟就能做得更深。
技术设计：不再是一个架构师提一个方案，AI 可以同时生成三个架构方案，团队在真实选项之间做选择。决策质量更高，因为你在比较，而不是在接受一个初稿。
Code review：AI 先做一轮，过滤掉常见问题、风格违规和测试缺口。人来 review 真正重要的东西——架构意图、需要领域知识才能判断的边界情况。
迭代回顾：AI 可以跨 sprint 分析规律，把容易被当下忽略的反复出现的阻碍点浮出来。
已经把 Agile 内化了的资深工程师，在这里有结构性优势。 他们知道方法论的哪些环节有杠杆，也因此知道在哪里接入 AI。Junior 工程师还在学流程本身——还没完全搞懂的东西，没有能力去优化。
这是经验在 AI 时代创造不对称价值的最清晰例子之一。
5. 什么没有变
有一种关于 AI 的论调是：经验没有价值了，因为 AI 有所有信息。这是错的。
系统直觉。 你知道大规模系统怎么出故障——那些没有写在任何文档里的失效模式，因为你亲身经历过。AI 可以描述分布式系统应该怎么工作。但它无法告诉你：这个具体的服务在这个具体的负载模式下会出问题，因为三年前的一个架构决策。这些知识住在你身上。
工程思维。 AI 能生成通过测试的代码。但需要判断力才能知道：这段代码18个月后还能不能看懂，这层抽象值不值得它带来的复杂度，这个设计决策会不会在你还没遇到的场景里把你锁死。AI 可以测试你的品味，但替代不了它。
组织上下文。 AI 不知道你公司的历史技术债、团队的能力短板、某些决策背后不好明说的来龙去脉，也不知道 VP 那个需求背后真正的优先级是什么。能把这些整合进技术决策的工程师，是没有替代品的。
对团队的影响。 这是大多数资深工程师最容易低估的一点，也是 staff 级别和 senior 级别影响力最明显的分水岭。
原来的模型：你指导两三个 junior 工程师，他们负责执行，你的杠杆来自他们叠加起来的产出。
新的模型更复杂。你用 AI 来完成自己的执行工作。但你同时还需要帮助团队里的 junior 工程师建立同样的能力——因为一个只有你一个人用 AI 的团队，不叫乘数效应。
这意味着在团队层面重新设计工作流，让 AI 嵌入集体的开发过程，而不只是个人习惯。意味着定义团队在 code review、测试和设计中用 AI 的标准。意味着建立能让 AI 有效理解你们代码库的上下文文档——架构说明、编码规范、运维手册。也意味着主动带着 junior 工程师完成这个转变，而不是假设他们自己会摸索出来。
那位重建入职流程的工程师，不只是自己高效了。他改变了所有之后加入的工程师的结构性条件。这是只有资深工程师才能创造的团队层面的杠杆。
6. 一个可操作的框架
真正起作用的转变，可以拆成四个阶段：
Brainstorm（头脑风暴）。 需求还不清晰的时候，在执行开始前先跟 AI 深度交互。让它挑战你的假设，挖出你还没考虑到的方案，找你初步想法里的漏洞。这是你的判断最重要的阶段——你知道该问什么问题，知道哪些答案要推回去。
Implement（实现）。 方向清楚之后，写一份完整的上下文文档：要做什么、有哪些约束、完成的标准是什么、什么不能碰。然后放手让 AI 去做。不要坐在那里看它写代码。去想下一个问题。
让自己从主动实现里抽出来，是大多数资深工程师最难做到的一步。感觉上不负责任。实际上，坐在那里看 AI 写代码的时间，几乎总是可以用在更值钱的地方。
Audit（检查）。 在关键节点回来：架构是不是你想要的？边界情况覆盖到了吗？团队成员能不能维护这段代码？这是你标准发挥作用的地方——不是逐行 reviewer，而是判断整体输出有没有达到标准的人。
Iterate（迭代）。 AI 压缩了"能跑"和"还不错"之间的距离。把它还回来的时间，用来填上"还不错"和"很好"之间的差距——以前这个差距总是因为要上线而被牺牲掉。在这个阶段认真投入的资深工程师，往往会拉开差距。只是更快发版的人，停留在同一水平。
7. 真正值得问的问题
用来区分两种资深工程师，最清楚的一张表：
| 维度 | 只是更快了 | 真正升了维 |
|---|---|---|
| 如何用AI | 辅助单个任务（review / 查资料 / 写文档） | 重新设计工作流，系统性接入 |
| 遇到bug | 自己改掉 | 带上下文还给AI，保持抽象层次 |
| review方式 | 逐行检查输出 | 分层review：架构看，细节靠测试 |
| 对团队 | 个人效率小幅提升 | 带团队完成转型，改变结构性条件 |
| 衡量标准 | 比以前快了多少 | 现在能做什么以前根本做不到的事 |
我接触的大多数资深工程师都在用 AI。这已经不是门槛了。
真正值得问的是：我是在一个不同的层次上工作，还是用更好的工具做同样的事情？
真正完成了转变的工程师，能具体说出来现在能做什么以前做不到的事——不是更快，而是真的做不到。如果这个描述说不出口，大概值得认真想一想为什么。
你目前是怎么用AI的？工作方式有没有发生质变？或者作为工程师，你们团队在推广AI方面踩过什么坑？欢迎在评论区聊聊。
这是关于AI时代各工程角色系列的第四篇。前三篇：AI 时代，Junior 工程师没有未来了吗？一个资深工程师的观察与判断、AI 时代的软件开发经理：我是怎么把管理杂务缩减到三分之一的、AI时代，运维工程师如何不被淘汰？从 Ops 到 Platform Engineer 的思维跃迁。
