前阵子 The Pragmatic Engineer 发了一份观察清单，总结他在整个软件行业看到的几个趋势。七条内容条条砸在工程师和测试工程师的日常上。有的和我们这一年用 AI 工具的感受完全吻合，有的则反直觉，值得逐条拆开看。清单作者 Gergely Orosz 长期跟踪工程组织话题。这些判断更接近一线观察，而不是行业预测。下面把这七个变化逐个展开：它们底下到底发生了什么，又对写代码、做测试的我们意味着什么。
IDE 正在退居二线
IDE 没有消失，只是被打开的次数越来越少。Claude Code、Cline 这类编程 Agent 进入终端、CI 和 issue 跟踪器。写代码的重心跟着转移：从在编辑器里逐行敲，变成把意图描述清楚、再验收结果。现在典型的一天是这样的：早上打开终端把任务交给 Agent，中午审查它提交的几个 PR。下午为了一个线上疑难问题，才终于打开熟悉的编辑器。很多人的 IDE 实际已经退化成两个用途：文件浏览器和 diff 查看器。当然 IDE 没死，断点调试、读源码、做性能剖析还离不开它。变的是位置：从主工作台变成辅助屏幕。这个切换来得非常突然，比多数人预期的快。对测试工程师来说，对应的问题是：代码在终端和批量生成中诞生时，验证面应该建在哪里？这个变化也重新定义了会用工具的含义。快捷键熟不熟越来越不重要，能把任务说清楚、能把产出验明白才重要。
tokenmaxxing 没人再提了
tokenmaxxing 是社区造的词，指把上下文塞满、把输出量拉满，用 token 消耗量来衡量 AI 用得好不好。一年前它还是经验贴里的常客。今年就像 The Pragmatic Engineer 调侃的那样：tokenmaxxing？什么 tokenmaxxing？降温的原因不难猜。模型的上下文管理和 Agent 编排成熟之后，越来越多的人发现：堆 token 不等于堆产出。真正决定产出质量的，是输入里有没有正确的约束——接口定义、数据形状、验收标准——而不是体量。更现实的是账单侧：财务开始按 token 算 ROI 之后，tokenmaxxing 式玩法最先被砍掉。回头看，tokenmaxxing 暴露的是早期的一种度量陷阱：度量不了结果时，就先度量消耗。这个教训和测试用例设计完全同构：覆盖率的价值不在数量，在每一条是否跑在真实风险点上。
代码评审进入僵尸状态
流程还在，实质没了。PR 量随着 AI 生成爆发之后，评审者面对远超消化能力的 diff。评审退化成表演：扫一遍，留两条不痛不痒的意见，approve。一个典型的僵尸评审长这样：400 行 diff，评审者花 4 分钟，留一条关于变量名的评论，通过。真正的问题——那段重试逻辑只捕获了一半异常——没人提。即使对外坚持人工评审的团队也逃不掉。数据佐证了这种感受：Checksum 的调研显示，64.8% 的工程负责人认为评审 AI 生成代码比评审人写代码更耗时。引入 AI 编程工具后，一半团队的评审周期拉长了 25% 以上。僵尸流程的代价不在流程本身，而在它提供的虚假安全感：大家都以为有人看过了，其实没有。解法不是呼吁更认真，而是改顺序——让自动化验证先跑完并给出结论，人只看设计和意图。否则评审只会继续消耗时间、漏掉真问题，这正是僵尸状态。
开源模型靠成本取胜
前沿 SOTA 模型效果很好，但太贵，工程量级调用起来账单扛不住。于是分层方案开始普及。生成、补全、测试脚本编写、日志归总这类高频常规任务，走开源模型加自建推理；预算留给少数最难的问题。有团队的做法是在模型前面加一层路由：按任务难度和风险分级。常规请求先打开源池，置信度不够再升级到 SOTA。这样跑几个月，月度账单降了一半以上，质量指标没有动。开源模型在多数任务上的效果已经接近 SOTA，成本却低一个数量级。这和性能测试里的分层思路本质相同。把最贵的资源放在真正决定成败的路径上，而不是被批量流量消耗掉。对测试团队来说，这个分层思路落地更直接。批量脚本生成、用例改写交给开源模型；失败归因和风险判断留给更强的模型。成本曲线一变，架构选择跟着变，这是工程判断，不是立场问题。
中层管理在消失
AI 接管进度汇总、报告撰写和信息传递之后，中层管理的传递职能最先被压缩。跟着一起消失的，在很大程度上是传统职业发展路径：从工程师到经理的梯子变窄了。测试团队也不例外。过去专门有人汇总进度、同步信息、写周报，现在这些角色被 dashboard 和自动化报告接手。当然，中层管理消失不等于管理消失。定方向、做权衡、扛责任这些事不会因为 AI 而变少，变少的是纯传递层。对技术人来说这有好有坏。好在管理开销降低、决策离事实更近；坏在很多人的职业规划原本建在那架梯子上。围绕技术深度和交付所有权重新规划成长路径，已经不是鸡汤话题，而是现实的排期问题。越早把传递能力换成判断能力的人，越能接住这次变化。
效率提升了，为什么更忙了
AI 确实让代码生成变快，但工作总量没有下降，反而上升。一面是生成成本降低推高了需求：以前不值得做的事，现在排进了队列。另一面是验证、评审和返工吞掉了生成端的提速——写代码花一小时，评审花两小时。看看自己的日历就明白：会议没有减少，PR 队列变长了，还多出一堆顺手就能做的实验性需求。经济学家给这个模式起了个现成的名字：Jevons 悖论。资源使用效率提升时，该资源的总消耗量反而增加。这和我们在性能测试里反复验证的规律一致。单环节吞吐提升不等于系统吞吐提升，瓶颈只会转移。所以问题不在于 AI 有没有提升效率，它提升了；而在于流程有没有围绕新的效率重新设计。个人时间也一样：不重新设计流程，提速就会在别处连本带利还回去。
招聘难的两副面孔
招到好工程师依然很难。但头部 AI 实验室面对的是另一种难：门口挤满了想进来的杰出候选人，连非常强的简历都会被拒。一面招不到，一面挑不完，错位的不是人数，而是能力定义。代码生成商品化之后，面试考察的重心转向判断力：能不能定义问题、设计验证、对结果负责。这个标准对候选人来说更难伪装，对面试官来说也更难放水。测试侧同样出现这种分化。执行型测试岗位的需求在收缩；能设计验证方案、能给 AI 生成代码量化质量风险的人更抢手。对准备换工作的人来说，信号很明确：展示判断力的作品，比展示产量的作品更有说服力。
这七个变化看似分散，底下指向同一件事：AI 改变了软件生产的成本结构。工具、流程、组织、招聘，每一个环节都在被重新定价。我们能做的，是在重新定价的过程中，把那些习以为常的安排重新检查一遍。IDE 的位置、评审的作用、工时的去向、职业梯子的终点，都在清单上。有三件事可以先落地：把自动化验证放在人工评审之前；把脚本编写、日志归总这类常规生成任务路由到开源模型；把作品集从展示产量换成展示判断。这些问题想清楚了，效率红利才会真正落到自己的工作流程里。否则它会以某种看不见的形式，在别处兑现。下次打开工作台时，不妨先从这几个问题问起。
收录于 FunTester 原创专题：AI ，测试有点东西
相关阅读：AI 生成越快，人审核越累 · 让测试速度真正跟上 AI 生成速度 · 反直觉：顶级 AI 加持，效率却在下降 · Agentic Coding 的监督机制 · 技术人的非线性职业发展