这个系列积累的证据,现在可以摆在一起回答工程化问题了
前面 13 篇文章逐个验证了具体项目——每篇都在回答"这个场景里 LLM 到底做了什么、传统工具做不到的是什么"。这一篇不再引入新的开源项目,而是把已经验证过的证据摆在一起,回答规划文档留到最后的三个更偏工程实践的问题：测试场景下的 Token 成本量级,跟代码生成场景比起来是什么水平；人工确认门应该放在流程的哪一步；哪些场景明确不该用 LLM 做测试。 这三个问题不需要新的开源项目验证,需要的是把已经读过的具体数字和具体设计放在一起对比。
成本量级：数千美金 vs 一毛钱,差的不是模型,是任务边界怎么划
先摆出两组已经验证过的真实数字。
代码生成场景：我自己之前记录过的一套企业级 Bug 修复端到端工作流（ai-bug-e2e-workflow-enterprise）,12 个节点全 AI 驱动,从 Jira 取单到 Gerrit 提交，调试阶段烧掉了数千美金 Token。里面有一个具体的失败案例很说明问题：一次实测里,单个 Turn 跑了 117 个 tool calls 之后,在 Sonar 扫描结束准备继续下一步时,API 请求直接被服务端 abort——不是 Agent 不知道下一步做什么,是整个 Turn 的上下文已经大到服务端拒绝请求。根因是"长链路上下文爆炸"：读 Jira、下载解压日志、分析日志文本、读多个源码文件、Code Review 结果、Sonar 扫描报告,所有内容都堆在一个 Turn 里线性累积。
测试场景：这个系列里验证过的两个数字。文章 11 里 AutoRestTest 的 README 原文——"testing an average API with ~15 operations using GPT-4o-mini, the cost was approximately $0.1"，测一个 15 个接口的 API 只要一毛钱。文章 13 里 pytest-triage 的默认配置——--ai-budget=10，一次测试运行无论有多少个失败用例，最多花 10 次模型调用，而且每次调用的 prompt 大小有硬性上限（"4 KB of traceback, 2 KB of each output tail, 1 KB of the exception message",典型 prompt 大小"well under 2 KB"）。
这两组数字差出几个数量级,不是因为测试场景用的模型更便宜,而是任务边界划分方式完全不同。 Bug 修复工作流里,LLM 要做的事情是端到端的：读日志、定位根因、改代码、理解 Code Review 反馈、修代码、再理解 CI 报错——每一步的输出都要喂给下一步作为输入,上下文线性累积,而且没有硬性预算上限,因为"修复一个 Bug"本身没有一个自然的调用次数上限。 测试场景里,这个系列反复验证的模式是把 LLM 限定在一个很窄、边界很清楚的环节：AutoRestTest 只让 LLM 生成"看起来真实"的字段取值,顺序决策和依赖推断交给强化学习和向量相似度；pytest-triage 只让 LLM 在测试已经失败之后追加一段诊断文字,而且从架构上就给这个环节设了预算硬上限和四层防御式包装。窄任务边界本身就意味着可预算——你可以提前算清楚"最坏情况下这套系统会花多少钱",而端到端任务边界做不到这一点,因为链路有多长、要重试几轮,事先并不知道。
这也回答了规划里"测试场景 Token 成本量级"这个问题的核心：不是"测试比代码生成天生便宜",是这个系列里验证过的、真正落地的测试项目,几乎全部采用了"LLM 只做一个窄环节 + 硬性预算上限"的设计,这个设计本身决定了成本量级能被算清楚、压得低。 反过来,如果有人真的想做一个"端到端 AI 测试工作流"（读需求、写测试、跑测试、分析失败、改测试、再跑）,大概率会撞上跟 Bug 修复工作流同样的上下文爆炸问题——这不是测试场景的特权,是任务边界设计的产物。
人工确认门该放在哪：这个系列给出的答案是"只审查失败案例",不是"生成后审"或"执行前审"
规划里的问题是三选一：生成后 review、执行前 review,还是只 review 失败案例。把这个系列和 Bug 修复工作流里验证过的人工确认设计摆在一起看,答案已经很清楚地偏向第三种。
Bug 修复工作流里的三个人工确认门,都不是"生成后马上审"或者"执行前先审"，而是在自动化路径已经跑到尽头、系统自己判断需要升级的时候才触发：确认门 A/B 是在 Code Review 自动重试跑满 3 轮仍不通过之后才触发,系统展示对比报告,给出"接受当前代码"或"人工修复剩余问题"两个选项;确认门 C 是在 Gerrit 收到 CI 流水线的失败投票之后才触发。没有一个确认门是在 AI 生成代码之后立刻插入的"先给我看一眼",也没有一个是在 AI 开始执行之前的"先批准我才能动手"——全部是"自动化路径走到头、遇到系统自己判断不了的情况,才把人拉进来"。
这个系列里验证过的测试项目走的是同一条路。pytest-triage 的设计更极端——它甚至没有一个真正意义上的"确认门",AI 判断只是在测试已经失败之后追加一段诊断信息,人要不要看这段诊断、要不要采纳,完全是可选的,AI 的判断从架构上就不允许反向影响测试运行的真实结果（"AI never affects the test verdict"）。vlmkit 的两阶段管线也是同样的模式——Stage 2 产出的是 FIX: 建议行,是一个供人参考的修复提案,不是自动应用的补丁；只有在检测到视觉差异（也就是"已经发生的失败/变化"）之后,这套 AI 判断才会被触发。
为什么"只 review 失败案例"是这两个场景都收敛到的答案,而不是"生成后 review"或"执行前 review"？ 因为后两种模式的成本结构不可控——如果每次生成都要人工看一眼,人力成本会跟自动化的调用频次线性增长,自动化本身失去了意义；如果每次执行前都要审批,等待审批的延迟会吃掉自动化节省的时间。"只 review 失败案例"把人力投入和"系统本身判断不了/自动化路径已经走到尽头"这两个信号绑在一起——只有在这两个信号同时出现时,才需要人,平时不需要。 这也是为什么 Bug 修复工作流的三个确认门都设在"重试次数耗尽"或者"外部系统给出明确失败信号（CI 投票）"这两类触发条件上,而不是设在"每次 AI 输出之后"。
哪些场景明确不该用 LLM 做测试
规划里点名了三类场景,结合这个系列 13 篇文章验证过的证据,可以给出具体理由,不只是直觉判断。
高频回归测试——这是成本结构问题,不是能力问题。文章 11 验证过 Schemathesis：一个基于 Hypothesis 的属性测试引擎,靠 schema 驱动的边界值枚举,零外部 API 调用、完全确定性、可无限重跑,回归测试要跑多少次都是零边际成本。如果换成 LLM 来做同样的边界值挖掘,每一次回归都要花一次 API 调用的钱和延迟,调用频次一旦跟 CI 触发频率（每次 commit、每次 PR）绑定,成本会随着团队规模和提交频率线性甚至超线性增长——这跟前面算清楚的"测试场景成本量级低"恰好相反,因为那个结论的前提是 LLM 只在窄环节、低频触发,一旦把 LLM 塞进每次 commit 都要跑的高频回归路径,窄环节设计撑不住高频调用。
纯逻辑单元测试——这是任务结构问题。文章 11 已经点出核心：schema/类型系统能穷举"合法"的边界,不需要语言理解就能推导出边界值、极端值、类型不匹配这些经典缺陷类别。纯逻辑代码（一个排序函数、一个状态机转换）的正确性判断标准是明确的、可形式化的,不存在"这个值算不算真实业务数据"这种需要常识判断的模糊地带——这恰好是这个系列反复确认的、LLM 增量价值最薄的地方。
对确定性要求极高的场景——这是风险容忍度问题,pytest-triage 的架构设计已经给出了最具体的答案：如果一个判断结果需要 100% 可复现、不能有任何模型幻觉带来的偶发性,就不能让 LLM 的输出直接进入判断链路,只能让它作为判断链路之外的旁路建议。 pytest-triage 把这个原则做成了"不变式"——AI 从不允许影响测试的通过/失败结果,即便模型报错、超时、返回垂圾内容,整次运行的结果都跟没装这个插件时逐字节相同。这不是"LLM 不够准所以不能用",是即使 LLM 未来变得更准,只要判断结果需要绝对确定性,把 LLM 放在判断链路里这件事本身的风险敞口就不会归零——所以架构上直接把它排除在判断链路之外,是唯一能把风险敞口锁定在零的做法。
总结
- Bug 修复端到端工作流（企业级实践）调试阶段烧掉数千美金 Token,核心原因是任务边界是端到端的（读日志、改代码、理解 CR、改代码），上下文线性累积且没有自然的调用次数上限，实测中单 Turn 117 个 tool calls 后被服务端直接 abort。
- 这个系列验证过的测试场景成本量级低几个数量级（AutoRestTest 测一个 API 约一毛钱、pytest-triage 默认预算每次运行最多 10 次调用),根本原因不是测试天生便宜,是这些项目普遍把 LLM 限定在一个窄环节并配合硬性预算上限,窄边界本身让成本变得可提前算清楚。
- 人工确认门该放在"只 review 失败案例"这一步,而不是生成后审或执行前审——Bug 修复工作流的三个确认门都设在自动重试耗尽或外部系统给出失败信号之后才触发,pytest-triage 和 vlmkit 的 AI 判断也都只在检测到失败/变化之后才产出建议,且从不自动应用、从不反向影响真实结果。
- 高频回归测试不该用 LLM,因为窄环节+低频触发的成本结构一旦换成高频触发就撑不住,而 Schemathesis 这类零边际成本的确定性方案本来就能无限重跑；纯逻辑单元测试不该用 LLM,因为正确性标准可形式化、不存在需要常识判断的模糊地带；对确定性要求极高的判断链路不该让 LLM 直接介入,因为只有把它排除在判断链路之外,才能把幻觉带来的风险敞口锁定在零，而不是指望模型未来变得足够准。
- 贯穿这 14 篇文章的同一个结论在这里收尾：LLM 在测试自动化里能落地、能控制成本、能保证可靠性的项目,无一例外都是把 LLM 限定在一个需要语义/视觉/语言理解的窄环节,剩下的部分——顺序决策、依赖推断、正确性判定、失败/通过的最终结果——交给更便宜、更确定、也更容易审计的传统技术。这不是 LLM 能力不够,是"测试"这件事的大部分工作,本来就不需要语言模型。
欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页