一、AI 测试的分水岭

从“使用”到“治理”现在市面上的 AI 测试落地尝试，基本分两个流派。一派是把 Claude Code 当外包小弟，人写提示词，它出脚本，人再复制粘贴到框架里。看起来快，实则返工率高得惊人。因为每一轮对话都是独立的，没有版本约束，没有上下文锁定，出问题只能从聊天记录里翻证据。

另一派，已经开始用交付流水线的思维治理 AI。不再把 Claude Code 当成一个聊天窗口，而是当成流水线里一个“生成步骤”。这个步骤有固定的输入源、参数化模板、审批节点、质量阈值，跑完自动进入下一环节。后一种做法的核心已经不是“用 AI”，而是把 AI 输出变成可治理的资产。这就是 Harness 工程干的事。Harness（这里指 Harness 这一现代 CI/CD 平台）本身就擅长管交付流水线。它的 Pipeline、Approval、Template、变量管理这些机制，天然适合给智能体当“脊椎”。把 Claude Code 的 API 封装进 Harness 的步骤里，你就得到了一套可控的测试智能体系统，而不是一个黑洞聊天框。

说白了：Claude Code 是大脑，Harness 是让大脑可靠行动的脊椎。三、Harness + Claude Code 的脊椎架构拆解直接看架构。我们在 Harness 上搭建的测试智能体系统，核心组件是这样的：这张图看着不复杂，但和“裸调 Claude Code”有本质区别。

为什么这么做：解决了三个致命问题。 一是上下文一致性。每次运行 Pipeline，Claude Code 拿到的上下文都是同一套代码版本和 Prompt 模板，不会因为聊天滚动而丢失信息。 二是可审计。Harness 的执行历史、产物、审批记录全留档，再也不用去翻聊天记录找“上次你给我的那个脚本”。 三是幻觉可控。质量门拦截不规范或明显错误的生成结果，直接打回，形成反馈闭环.

转载于: 霍格沃兹测试开发社.