“编程第三时代“，测试人该怎么接招

前言

2026年6月，Cursor CEO Michael Truell在一次访谈中抛出一个判断：AI编程正在进入“第三时代”——云端智能体不再只是补全代码的助手，而是具备自主规划、编码、调试乃至交付能力的“数字工程师”。与此同时，《2026春季Cursor开发者习惯报告》给出了一组数据：当前已有约35%的生产代码由AI自主生成，这个比例还在以每季度5-8个百分点的速度爬坡。

这件事对开发者的冲击已经讨论得够多了。但站在测试的角度，问题更加尖锐——当你要验证的代码，有三分之一甚至更多不是人写的，传统的测试逻辑还成立吗？介入时机、验证策略、工具链该怎么跟着变？

这篇文章试图回答这些问题。不讲概念，讲实操。

目录

一、三个时代，测试侧到底变了什么 二、AI生成代码的“质量画像”：哪些地方容易出事 三、测试介入时机的前移：从“写完再测”到“生成即验证” 四、意图驱动 vs 脚本驱动：测试范式的切换 五、持续测试架构的重新设计 六、测试人的能力迁移路线

一、三个时代，测试侧到底变了什么

Michael Truell划分的三个时代，翻译成测试人能理解的话：

• 第一时代（Tab补全时代）：AI帮开发者补全几行代码，本质上还是人在写。测试侧几乎不受影响，该怎么测还怎么测。
• 第二时代（对话协作时代）：开发者用自然语言跟AI对话，生成函数甚至模块。测试开始遇到新问题——生成代码的风格不统一、边界处理参差不齐，但整体还在可控范围内。
• 第三时代（智能体自主时代）：AI Agent拿到一个需求描述，能自主完成从架构设计到代码实现再到基础调试的全流程。这才是真正改变游戏规则的阶段。

第三时代对测试的根本冲击在于：代码的生产速度和生产方式同时变了。

以前一个五人开发团队，一个迭代产出大约2000-3000行有效代码，两个测试工程师跟得住。现在同样的团队，借助Claude Code、Cursor Agent、Devin这类工具，同样周期的代码产出量可以翻到8000-12000行。更关键的是，这些代码不是一个人风格一致地写出来的，而是不同prompt、不同上下文下AI分别生成的“拼接体”。

测试侧如果还是老节奏——等开发提测，拿到代码，写用例，执行——根本跟不上。

二、AI生成代码的“质量画像”：哪些地方容易出事

跟AI生成代码打了大半年交道后，我总结了一份“高频翻车清单”，测试人重点盯这几个方向：

1. 边界条件处理普遍偏弱。AI生成的代码在“主干路径”上通常没问题，但空值、极端输入、并发场景下的防御性代码经常缺失。举个例子，让Agent生成一个分页查询接口，正常传参没毛病，但pageSize传0或传负数，大概率没做处理。

2. 安全相关的代码容易“看起来对”。SQL拼接、XSS过滤、权限校验这些，AI生成的代码往往形式上做了，但实际存在绕过路径。2026年Q1 Snyk的报告显示，AI生成代码中的安全漏洞检出率比人工代码高出22%，其中大部分是“不完整的防御”。

3. 模块间的集成缝隙。单个函数、单个类层面，AI写得不错。但当多个Agent分别生成不同模块，拼到一起时，接口契约、数据格式、异常传播链上的问题会集中爆发。这跟多人协作开发的集成问题类似，但频率更高，因为各个Agent之间没有“口头沟通”的机会。

4. 非功能性需求几乎全靠人兜底。性能、可观测性、容错降级这些，除非prompt里明确要求，AI基本不会主动考虑。生成的代码能跑通，但扛不扛得住压力，是另一回事。

三、测试介入时机的前移：从“写完再测”到“生成即验证”

传统测试流程里，测试介入的最早节点通常是“开发提测”。但在第三时代，这个节点太晚了。

道理很简单：AI Agent一个下午能生成十几个模块，如果等全部写完再测，返工成本极高。更合理的做法是把验证逻辑嵌入到代码生成的pipeline里，让每一次生成都伴随即时校验。

下面这张图展示了测试介入时机从传统模式到新模式的变化：

核心变化就一句话：质量验证不再是一个“阶段”，而是代码生成pipeline里的一个“中间件”。

实操层面，目前比较成熟的做法是在CI/CD中配置“AI代码质量门禁”，每次Agent提交的PR自动触发：静态分析（SonarQube/Semgrep）、契约测试（Pact）、边界值Fuzz（Atheris/Jazzer）、AI生成的补充用例（借助Claude或GPT做测试生成）。通不过门禁的代码直接打回，不需要人工介入。

四、意图驱动 vs 脚本驱动：测试范式的切换

过去十年，自动化测试的主流范式是“脚本驱动”——测试工程师把测试逻辑写成Selenium、Appium、Pytest脚本，CI里定时跑。这套体系跑了很多年，但有个根本问题：脚本的维护成本跟UI/接口的变更频率强耦合。

在第三时代，这个问题被放大了。AI Agent可能一天重构三次接口，每次改动都合理，但你的测试脚本全废了。

更适应当前节奏的做法是意图驱动测试（Intent-Driven Testing）。简单说，测试人员不再写具体的操作步骤和断言脚本，而是描述“测试意图”：

# 脚本驱动（传统）
def test_login():
driver.find_element(By.ID, "username").send_keys("admin")
driver.find_element(By.ID, "password").send_keys("123456")
driver.find_element(By.ID, "btn-login").click()
assert driver.find_element(By.CLASS_NAME, "welcome").text == "欢迎回来"

# 意图驱动（第三时代）
test_intent:
场景: 用户使用正确的账号密码登录系统
预期: 登录成功，展示欢迎信息
边界: 密码错误时提示"账号或密码错误"，连续5次锁定账户

意图描述交给测试Agent（比如Momentic、Carbonate、或基于Claude Agent自建的测试执行器），由Agent自己去理解当前页面结构、定位元素、执行操作、校验结果。页面改版了？Agent自己适应，测试意图不用改。

这不是科幻。2026年上半年，Momentic和Carbonate已经在多家企业落地，实际维护成本下降了60%以上。但需要说清楚：意图驱动不是万能的，复杂的业务逻辑校验、精确的数值计算验证，目前还是得靠传统脚本兜底。两种范式会长期共存。

五、持续测试架构的重新设计

把前面几节的思路串起来，一个适配第三时代的持续测试架构大致长这样：

这套架构的几个关键设计决策：

测试生成前置到需求阶段。需求进来的同时，测试Agent就开始拆解测试意图、生成验收标准。不等代码写完再想“测什么”。

质量门禁做成“硬卡点”。不是跑完给个报告让人看，而是直接拦截。门禁不通过，代码回到AI Agent自动修复，形成闭环。人只在Agent修不好的时候介入。

变异测试作为AI代码的“试金石”。传统的行覆盖率、分支覆盖率对AI生成代码意义不大——AI生成的测试很擅长“刷覆盖率”，但不一定真的在检验逻辑。变异测试（Mutation Testing）通过故意篡改代码看测试能不能抓到，是目前验证测试有效性最靠谱的手段。

可观测性兜底。再好的测试也不可能覆盖所有场景。线上通过OpenTelemetry做全链路追踪，异常数据回流到测试用例库，形成持续补充机制。

六、测试人的能力迁移路线

说到底，工具和架构都是手段，人的能力才是根本。第三时代的测试人，需要在三个方向上做能力迁移：

从“写脚本”到“定策略”。具体的测试脚本越来越多由AI生成，测试人员的核心价值转向：制定测试策略、设计质量门禁规则、定义验收标准。说白了，从“动手干活的人”变成“定规矩的人”。

从“找Bug”到“防Bug”。与其在下游捞缺陷，不如在上游设关卡。理解AI生成代码的缺陷模式，把这些模式转化成自动化检测规则，嵌入到生成pipeline里。这需要对SAST/DAST工具链有深入理解，对常见漏洞模式有系统认知。

从“测试工程师”到“质量工程师”。这个说法不新，但第三时代赋予了它真正的含义。质量工程师关注的不是“这个功能有没有Bug”，而是“整个AI辅助研发流程的质量保障体系是否健壮”。你需要懂CI/CD、懂可观测性、懂AI Agent的能力边界，甚至需要能写prompt来调优测试生成Agent的输出质量。

一个具体的能力自查清单：

写在最后

“第三时代”不是终点，它只是一个加速的起点。AI生成代码的比例会继续涨，从35%到50%到更高。测试人面对的不是“要不要变”的问题，而是“变多快”的问题。

好消息是，越是AI大规模生成代码的时代，对质量保障的要求越高，而不是越低。代码可以由机器写，但“这段代码该不该上线”的判断权，在相当长的时间里还得握在人手上。

关键是，别等着被推着走。现在就开始熟悉意图驱动测试工具，现在就去研究变异测试和质量门禁的落地方案，现在就去理解AI Agent的能力边界和典型缺陷模式。

机会永远留给提前上桌的人。