AI Coding 容易产生的「隐性问题」

过去一年，AI Coding 从“玩具”迅速变成了“生产力”。

无论是前端、后端，还是测试、运维，大家都已经习惯了一种新的开发方式：

先让 AI 写一版，再在此基础上修改和完善。

但在实际项目中，我越来越明显地感觉到一件事：

AI 写的代码，问题并不集中在“明显的 bug”，

而是大量隐藏在“看起来完全正确”的地方。

而这些问题，

恰恰最容易被测试漏掉。

---

一、AI 写的代码，为什么“很难测”？

先交代一个背景：

我所在的开发团队整体水平较高。需求进入开发后，通常会先产出相当完备的 spec 来指引 AI 编码；提测前，开发也会进行比较充分的自测。

因此，AI 生成的明显错误代码，基本不会流转到测试阶段。

这类问题往往在开发阶段就已经被发现并修掉了。

那么，真正留到我这里的 bug 是什么样的？

答案通常是：

不在需求主干上，而藏在异常路径、边界情况、细枝末节的链路里。

从一段时间的测试经验来看，我的一个整体判断是：

AI 写的代码，整体质量往往“高于平均水平”，

但风险分布极不健康。

具体表现为：

• 可读性好

• 命名规范

• 结构完整

• 注释清楚

在 Code Review 时，你很难第一眼就指出“哪里不对”。

但一旦出问题，往往是：

• 线上问题

• 边界问题

• 状态异常

• 难以复现的问题

这正是 AI Coding 带来的“隐性问题”的主要来源。

---

二、常见的隐性问题类型

1. 模仿了“正确姿势”，但细节是错的

这是我在 AI 代码中见得最多、也最容易被忽略的一类问题。

（1）注释和代码不一致

例如：

• 注释中写着：“XX 情况下应展示 A 按钮”，但实际代码中并没有对应逻辑

• 注释写着“从缓存读取”，实际却是直接查了数据库表

后者对测试的影响更大。

因为这类问题，在传统认知中本应由开发保证，而非测试兜底；在人类手写代码中，几乎不会出现如此基础的背离。

更麻烦的是：

如果只进行黑盒功能测试，这类问题极难被发现。

（2）变量名、参数名与真实语义不一致

例如：

• 注释和参数名都表明这里应传入 userId

• 实际调用处却传了一个时间戳

而进一步分析后发现：

业务逻辑是对的，确实应该传时间戳，只是 AI 在生成函数时把参数名写错了。

这类问题往往来自 AI 多轮生成、拼接代码后的“语义漂移”。

有趣的是：

• 代码可以正常运行

• 业务结果也是对的

唯一的问题是：

它会在未来维护时持续制造困惑。

---

2. 对“状态”的假设过于理想化

这是 AI Coding 的高频雷区。

AI 默认的世界是：

• 网络稳定

• 请求顺序执行

• 用户操作克制

• 状态不会被中断

但现实世界是：

• 网络抖动

• 并发点击

• 快速返回

• 多端同时操作

于是你会看到：

• loading 不消失

• 状态被覆盖

• retry 叠加

• 成功和失败同时出现

这些问题，很难通过单纯的“功能点测试”发现。

有一次，同事在测试过程中顺手 review 了一段代码，发现某处直接改表又查表。进一步检查后怀疑：

这里的 Redis 锁粒度可能不合理，在主从同步和并发场景下存在一致性风险。

随后通过构造数据和并发场景，问题果然复现。

---

三、为什么传统测试方法在 AI Coding 下开始吃力？

传统测试，其实隐含着一个假设：

代码是人写的，问题主要来自“疏忽”。

但 AI Coding 的现实是：

代码是模式生成的，问题往往来自“语义偏移”。

AI 生成的代码，普遍具有两个特征：

• 可读性好

• 迷惑性高

于是测试人员常常会出现一种非常典型的感受：

“我说不上哪里不对，但我不太敢上线。”

---

四、Vibe Testing：为什么它在 AI 代码上特别有效？

不知是否有同行也有类似感受：

在负责人经验丰富的开发手中，AI Coding 交付的代码，整体 bug 数量确实是下降的。

尤其是过去那些由于疏忽、遗漏导致的 bug，几乎可以说被清零了。

也正因如此，我反而不太放心把 AI Coding 交付的代码完全交给非核心成员去测试。

最近 “Vibe Coding” 这个词很火，我想顺势提一个对应的概念：

Vibe Testing。

我更愿意这样理解它：

Vibe Testing 并不只是在验证“是否正确”，

而是在判断“是否合理”。

它关注的不是：

• 用例是否覆盖

• 分支是否齐全

而是：

• 行为是否自然

• 状态是否稳定

• 系统是否“像一个真实系统”

在 AI Coding 场景下，Vibe Testing 特别擅长发现：

• 非线性操作下的异常

• 状态残留

• 失败后的“不安定感”

• 过于“顺滑”的成功路径

---

五、说人话：Vibe Testing 其实就是“测试 sense”

说得更直白一点，Vibe Testing 本质上就是大家常说的“测试 sense”。

工作年限较长的同行，应该都有类似体验：

• 刚毕业、或刚进入一个新团队时，即便测完一个项目，也对质量没太多底气

• 随着经验积累和对项目的深入理解，却敢给一个看起来很大的需求排很短的测试周期

在我看来，Vibe Testing 能力，往往体现为以下几个方面：

1. 长期经验形成的总结性思维

甚至在开发阶段，就能预判哪些地方容易出问题

2. 对业务的细致掌握

测试往往是项目中最全面理解业务的角色，对流程、用户习惯、技术方案都有整体认知

3. 对代码的理解能力

经常 review 代码，尤其是线上问题的修复代码，会让你在面对 AI 生成代码或分析报告时更加从容

---

六、结语

AI Coding 并没有让测试变得不重要，

它只是把测试的价值，从“验证正确性”，推向了“验证合理性”。

在 AI 写代码的时代：

最有价值的测试能力，

不是会不会写更多用例，

而是能不能察觉“哪里不对劲”。

而这，

正是 Vibe Testing 的意义。