AI 越聪明，越不要给框架

文章主旨：AI 编程时代，测试框架不应在探索前就替 AI“定题”，而应后置于自由探测与证据收敛之后，由框架把已被证实的结论固化为可长期运行的回归守护资产。

关键要点：

1. “测试全绿只说明当前测试预言被满足，不等于系统一定正确”，真正的失效点常藏在异步重试、跨服务时序、幂等边界和脏数据回放中。
2. 传统测试框架的优势在于让已知验证路径低成本重复，但若让它在探索前就约束目录结构、Mock 方式和覆盖率目标，会“提前收窄 AI 的搜索空间”。
3. AI 做测试需要四种关键能力：上下文理解、执行与观测、假设与反例构造、测试预言构造。
4. 更合适的流程是“自由探测—证据收敛—回归守护”三层结构，强调用可复现证据包而不是未经验证的测试代码作为中间产物。
5. 测试框架的最终定位应是“可执行的团队记忆”，覆盖率只是过程指标，测试预言和关键业务契约的覆盖程度更有长期价值。

内容结构：

引入：文章从常见现象切入——编程 Agent 接到补测试任务后，能迅速交付新增测试文件、断言、CI 通过和覆盖率上涨，但线上故障仍可能藏在异步重试、权限切换、跨服务时序与脏数据回放中。作者认为这不是 AI 不会写测试，而是任务在起点就把问题“翻译”成了单测、分支断言和覆盖率阈值，导致 AI “努力完成题目”却未追问题目本身是否漏掉了真正脆弱路径。因此，“AI 时代不是不需要测试框架，而是不该让测试框架先替 AI 定义问题”。

“测试全绿，问题为什么还在”：作者指出，测试全绿只能证明已有规则被满足，无法自动暴露未被表达的风险。以支付状态更新为例，Agent 容易为成功、失败、异常三条路径补单测并 Mock 外部依赖，但重复回调、超时与成功回调乱序、幂等键跨租户冲突、账务与通知顺序重放才是真正危险的不变量。若任务入口是“补单测”，AI 很可能停在方法边界；若入口是“寻找变更可能破坏的业务不变量”，它才会扩展到状态、时间、数据和依赖关系。

“框架不该替 AI 定题”：框架是“工程经验的压缩包”，擅长让已知路径稳定重复。问题在于探索之前就把测试类、Mock 交互和覆盖率报表当成唯一表达，会过早收窄 AI 的搜索空间。作者同时澄清：“框架后置”是认知顺序上的后置，不是禁用 JUnit、pytest、Mock 服务或测试运行器。

“AI 探索需要的能力”：作者用表格列出 AI 在测试活动中需要完成的四种基础工作。上下文理解要求读懂调用链、数据模型、权限规则和历史故障，产出受影响路径与风险假设；执行与观测要求运行变体、采集日志、比对 Trace，产出可解释异常信号；假设与反例构造要求改变输入边界、事件顺序、超时、重试和依赖故障，产出最小反例与复现步骤；测试预言构造则要求用业务不变量、契约、差分结果或参考实现判断对错，产出可验证的正确性标准。作者特别强调：测试预言不是“多写几条断言”，而是先说清哪条业务规则不能被突破，例如“支付成功后余额只能增加一次”“重复回调不改变最终状态”。

“先探索，再收敛”：作者将流程分成三层。第一层自由探测是在受控沙箱中扩大问题空间，要求 Agent 主动改变输入、顺序、时间并注入故障，主要产物是证据包（explore/ 目录下的 hypothesis.md、reproduce.md、traces/、counterexamples/），而不是急于合入的测试代码；没有可重复的复现，不进入下一层，也不能进入 CI。第二层证据收敛负责确认故障是否真实、稳定、是否值得沉淀为长期测试资产，是否过度绑定当前实现，可使用差分测试、属性测试、变异测试或真实依赖回放验证结论；作者引用 OpenAI 2026 年对 138 个 SWE-bench Verified 难例的审计，指出 59.4% 存在测试设计或问题描述缺陷，以此说明当 AI 快速“满足测试”时，测试预言本身是否准确会成为更明显瓶颈。第三层回归守护才引入正式测试框架和 CI，通过命名、分层、夹具管理、隔离策略、重试边界、并行执行和质量门禁，把一次问题发现变成团队日后不必重新思考的保护网。

“框架应该成为团队记忆”：作者认为，稳定的回归测试表达的不只是“某行代码该怎么跑”，还包括一条团队公认行为事实，因此框架更像“可执行的团队记忆”。文中引用 Meta TestGen-LLM 在 Instagram Reels 与 Stories 评估中 75% 候选可构建、57% 能稳定通过、25% 能提升覆盖率的数据，以及另一项基于运行观察的测试生成工作中 518 个测试被纳入生产并执行超 960 万次的案例，说明“模型可以广泛提出候选，系统必须严格筛选哪些候选值得进入回归资产”。但作者也强调这些案例不能代表所有语言、模型或团队。

“测试预言比覆盖率更重要”：覆盖率只能说明代码是否经过，不能证明断言足以识别错误；变异得分更接近“断言能否识别被引入的错误”。作者引用 2025 年 LLM 单元测试研究中的警示案例：某些 100% 覆盖率测试套件的变异得分只有 4%，说明“可见指标很容易被做满，真正预言能力却可能没有同步提高”。团队应持续跟踪的结果指标包括：是否发现真实缺陷、是否覆盖关键业务契约、是否引入 flaky 或维护成本、测试修改能否被独立复查、以及从异常发现到形成可靠回归保护的周期。

“安全边界前置，模板后置”：文章明确提出两类约束不可混淆。应前置的安全边界包括脱敏数据、只读副本、密钥隔离、命令白名单、时长与成本预算、禁止生产写入、限制外部调用、保留执行审计；不应过早固化的思考模板包括“只能写单测、必须先 Mock、只能补现有目录、只看覆盖率阈值、预设故障一定发生在哪个方法”等。前者保护系统与资源，应严格执行；后者限制问题发现，应根据证据按需引入。

“最小落地方案”：作者给出五项可实操的起步建议：建立独立探索空间；为每个待纳入正式套件的 AI 测试定义证据包；将探索性产物与正式回归用例分离开；保护已确认的关键测试，Agent 可建议修改但关键断言调整必须触发更严格评审；调整度量方式，记录候选测试接受率、flaky 率、契约覆盖、缺陷拦截和回归形成时间。关键不是多建流程，而是让探索与守护互相支撑。

“结语”：作者收束全篇：测试框架在 AI 时代没有过时，只是从 AI 的思考边界变成团队可信知识的边界。应先让 AI 寻找“尚未命名的失败路径”，再让框架把被证实的结论变成可重复、可审查、可回归的保护网。框架最好的位置不是在探索起点，而是在事实被发现之后。

文章总结：全文语气务实冷静，建议团队将 AI 视作探索者、将测试框架视作守护者，坚持“先探索、后收敛、再守护”的原则，以避免自动化测试带来虚假的安全感。

FunTester

查看原文：AI 越聪明，越不要给框架

文章来源：

FunTester

扫码关注公众号