写在前面：这篇文章献给所有最近盯着 AI 生成的代码，一边点头一边皱眉，最后默默打开调试器的同行们。

前言：我好像被「优化」掉了

事情是从一个普通的周二下午开始的。

那天我接到一个需求，放在两年前我大概要写一下午。我熟练地打开 AI 助手，敲下需求，回车。三秒钟后，几十行结构工整、注释齐全、连边界情况都「考虑」到了的代码躺在了屏幕上。

我盯着它看了很久，心情复杂。

那一刻我突然意识到：我已经很久没有从零写过一个函数了。我现在干的活儿，是读它写的代码、跑它写的代码、找它写的 bug、把它写错的地方圈出来让它改——

等等，这不就是……测试工程师吗?

写到这我必须严肃声明:测试工程师是非常专业、非常重要的岗位,我无意冒犯任何 QA 同行。我想说的是另一件事——我并没有想转岗,但我好像被 AI 悄悄地转岗了。

当今现状:我们都成了「AI 代码审查员」

如果你最近也有这种感觉,放心,你不孤独。打开任何一个技术社区,你都能看到这样的吐槽:

• 「写得越来越少,看得越来越多。」
• 「我现在的工作就是跟 AI 说『不对』『再来』『还是不对』。」
• 「以前是我写 bug 自己改,现在是 AI 写 bug 我来改,工作量好像没变?」

我们来还原一下当代程序员的真实工作流:

需求 → 给 AI 提需求 → AI 生成代码 → 我读代码 → 发现问题 → 让 AI 改 → AI 又生成 → 我再读 → 还有问题 → 我亲自下场改 → 终于跑通 → 提交

发现了吗?在这条流水线里,真正属于「创造」的部分被压缩了,而属于「验证」的部分被无限放大了。

我们花在以下事情上的时间,正在急剧增加:

最微妙的是最后一行。当你写代码时,你对每一行都了如指掌;当你审 AI 的代码时,你始终带着一种**「它看起来对,但我不敢信」**的警惕。这种警惕,正是测试工程师的核心心智模型。

用 AI 和不用 AI:一场关于「掌控感」的对比

我们来认真对比一下这两种状态,不带情绪,只讲体感。

不用 AI 写代码:慢,但「踏实」

// 你亲手写的每一行,你都知道它为什么在这里publicBigDecimalcalcDiscount(Orderorder){if(order==null){returnBigDecimal.ZERO;// 这个 null 判断是我加的,我知道为什么}// ...每一行都是我的决定}

那种感觉是:慢,但每一步都踩在实地上。你脑子里有完整的执行路径,程序怎么跑你心里门儿清。出了 bug,你甚至能凭直觉定位到第几行。代码是你思维的延伸。

缺点也很真实:慢。重复劳动多。写 CRUD 写到怀疑人生。

用 AI 写代码:快,但「悬浮」

// AI 生成的,看起来很专业,但…等等publicBigDecimalcalcDiscount(Orderorder){returnorder.getItems().stream().map(item->item.getPrice().multiply(item.getDiscount())).reduce(BigDecimal.ZERO,BigDecimal::add);// 它没判断 order 为 null// 它假设 getDiscount() 永远不为 null// 它用了 multiply 但没考虑精度和舍入// 它「看起来」对}

那种感觉是:飞快,但脚不沾地。五秒钟拿到一坨代码,你的大脑反而进入了高速运转——不是创造,而是审查。你要在脑子里反向推演它的逻辑,补全它没说的假设,揪出它埋的坑。

💡 一个扎心的事实:读懂并验证一段你没写的代码,有时比自己写一遍还累。因为写的时候你只需要管「我想怎么做」,而审的时候你要管「它可能怎么错」。

这就是「测试工程师感」的来源——你的核心动作,从「表达意图」变成了「质疑输出」。

一张图说清两种状态

自己写: 意图 ──直接──> 代码 (你是作者) 用 AI: 意图 ──> AI ──> 代码 ──> 你审 ──> 信/不信 (你是审核者) ↑ 新增的认知负担都在这

为什么会这样?这其实不是 AI 的锅

冷静下来想想,这种「转岗感」的根源,不是 AI 太菜,恰恰是因为AI 把「写」这件事变便宜了。

经济学里有个朴素的道理:当一种资源变得廉价,价值就会转移到与之互补的、依然稀缺的资源上。

• 当「写代码」变便宜了,「判断代码对不对」就变贵了。
• 当「生成方案」变便宜了,「选出对的方案」就变贵了。
• 当「实现」变便宜了,「定义问题」和「负最终责任」就变贵了。

所以你感到的不是退化,而是价值重心的迁移。你不是变成了测试工程师,你是被推到了更靠上游、也更需要判断力的位置——只是这个过程来得太快,体感像是「降级」,实际上是「换挡」。

但话说回来,体感很重要。如果每天的工作让你失去了创造的快乐,只剩下审查的疲惫,那再「高级」的定位也留不住人。所以我们得聊聊怎么把那种掌控感拿回来。

如何摆脱「我成了测试工程师」的感觉

下面是一些我自己实践下来真正有用的方法,不是鸡汤,是操作。

1. 把 AI 当「实习生」,而不是「外包」

外包是:把活儿丢出去,等结果,然后验收。这恰恰是让你变成 QA 的工作模式。

实习生是:你给方向,你定结构,你 review,但关键设计你自己拍板。

具体做法:自己先写函数签名、定好接口和数据结构,再让 AI 填充实现。骨架是你的,血肉交给它。这样你始终握着主导权,审查也变成了「检查实现是否符合我的设计」,而不是「猜它到底想干嘛」。

2. 守住「架构和命名」这两块自留地

AI 很擅长写局部实现,但整体架构、模块划分、关键命名这些体现品味和长期判断的东西,请牢牢抓在自己手里。

这些恰恰是不会被廉价化的部分,也是最能带来「这是我的作品」的成就感的部分。把它们让出去,你才真的会感到空虚。

3. 给 AI 的代码建立「信任分级」

不是所有代码都需要你像 QA 一样逐行审。建立一个简单的心智分级:

• 🟢一次性脚本 / 样板 CRUD / 测试数据:跑通即可,不必细审,大胆用。
• 🟡业务逻辑 / 工具函数:读懂主干,重点看边界条件。
• 🔴核心算法 / 资金计算 / 安全相关:当成不可信输入,逐行审,补测试。

把审查精力花在刀刃上,你就不会觉得「一整天都在做 QA」了。

4. 用「写测试」反客为主

听起来反直觉:主动去写测试,反而能让你摆脱测试工程师的感觉。

因为当你先写测试(或至少先想清楚验收标准),你就是在定义「正确」的标准——这是设计行为,是上游动作。然后让 AI 去写满足这些测试的实现。

这样一来,你不是在被动地「找它的错」,而是在主动地「定义对错」。心态完全不同。

5. 定期「徒手健身」,保持手感

每周留一点时间,关掉 AI,自己从零写点东西。可以是工作里的一个核心模块,也可以是业余的小项目。

就像健身一样,不是为了和器械较劲,而是为了保持肌肉不退化。当你知道自己「随时能徒手写」,你面对 AI 时的心态会从「依赖」变成「驾驭」,那种被牵着走的失控感会消失大半。

6. 重新定义你的价值:你是「决策者」,不是「打字员」

最后是心态上的转变。

打字员的价值在于产出字符的速度,这个能力确实被 AI 大幅替代了。但程序员从来不只是打字员。

你的价值在于:理解模糊的需求、做出合理的权衡、为最终结果负责。这些 AI 给不了,也替不掉。当你把自我认同从「我写了多少代码」迁移到「我做对了多少决策」,那种「转岗焦虑」自然就淡了。

写在最后

回到那个周二的下午。

后来我没有关掉 AI,但我换了个用法:我开始自己设计骨架,让它填肉;自己定测试标准,让它去满足;把品味和判断牢牢抓在手里,把重复劳动痛快地交出去。

神奇的是,那种「我成了测试工程师」的失落感,慢慢变成了另一种东西——像是从一个亲手砌墙的工匠,变成了一个手里有图纸的工头。我依然在创造,只是创造的层级变了。

AI 不会让程序员失业,但它确实在重塑「程序员」这三个字的含义。与其纠结于「我是不是变成了 QA」,不如想清楚:在一个写代码变得廉价的时代,什么才是只有你能提供的东西。

想清楚这个问题的人,不会被 AI 转岗。

他们会带着 AI,去做以前一个人做不完的事。

如果这篇文章戳中了你,欢迎在评论区聊聊:你最近一次「徒手写代码」是什么时候?那感觉还在吗?👇

—— 与所有在 AI 时代重新寻找掌控感的同行共勉。