圈子里最近流行一个变化：测试岗位面试，开始考你“怎么用 Claude Code 搭一套自动化测试管线”。不是手写脚本，是问架构。
手工测试缩编的寒气还没散，AI 测试工具又来挤占舒适区。但大部分团队用 Claude Code 的方式，还停留在对话框里敲“帮我写个登录页的测试用例”上——快是快了，可谁能保证每次出来的东西质量一致？上下文丢失、幻觉断言、无法复现，随便哪一个都能让测试结果变成摆设。
这不是工具的问题，是缺少工程骨架。
本文不会教你 Claude Code 的提示词技巧。我们要干的事情，是用 2 小时把一套“工程骨架”搭起来——用 Harness 流水线把 Claude Code 驯化成可审计、可回滚、可度量的测试智能体系统。不急，一步一步来。
目录
一、测试团队的“AI 恐慌”不是假焦虑
二、AI 测试的分水岭：从“使用”到“治理”
三、Harness + Claude Code 的脊椎架构拆解
四、一个真实的对比：裸调对话 vs. 工程化流水线
五、从 0 到 1 落地的两条实施路径
六、最后一个问题
一、测试团队的“AI 恐慌”不是假焦虑
打开招聘软件，手工测试岗位的需求量过去一年压缩了将近 30%，但冒出来一堆新词：AI 测试开发、智能体工程、Claude Code 自动化。很多在手工测试里打磨了五六年的人，突然发现自己简历上的“精通用例设计”不值钱了。
在校生更懵。学校还在教等价类边界值，企业要的是“能不能搭一套自动反馈的测试系统”。中间差的那块，不是工具操作，是工程化。
Claude Code 这种代码助手，能把生成测试脚本的效率提升好几倍。但效率不等于有效。真正的变化不是 AI 能写脚本了，而是测试活动的控制平面变了——过去是人直接控制用例和断言，现在是人控制智能体，智能体控制用例。如果中间没有可靠的治理层，整个测试体系就会变成一堆不可信的自动生成文本。
所以恐慌的本质，不是怕被 AI 取代，是怕自己还不会给 AI 当“驯兽师”。
二、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”有本质区别。
怎么做的：我们在 Harness 里定义一条 Pipeline，Stage 包括“生成”“审查”“执行”。生成阶段用一个 Script Step 跑一个封装的 CLI 工具，把仓库里的需求描述、上下文代码、测试基线和参数化 Prompt 拼接后，丢给 Claude Code，产出测试脚本。紧接着是一个 Approval Step，可以人工抽查，也可以跑自动化规范检查。通过后才进入执行。
为什么这么做：解决了三个致命问题。
一是上下文一致性。每次运行 Pipeline，Claude Code 拿到的上下文都是同一套代码版本和 Prompt 模板，不会因为聊天滚动而丢失信息。
二是可审计。Harness 的执行历史、产物、审批记录全留档，再也不用去翻聊天记录找“上次你给我的那个脚本”。
三是幻觉可控。质量门拦截不规范或明显错误的生成结果，直接打回，形成反馈闭环。
Harness Pipeline 的配置片段长这样（简化版）：
pipeline:
stages:
-stage:
name:"Generate & Review"
steps:
-step:
type:Run
name:"Claude Code Test Generation"
spec:
shell:Bash
command:|
claude-code generate \
--prompt-template "${pipeline.variables.prompt_template}" \
--source-path ./src \
--output-path ./tests/generated
failureStrategies:
-onFailure:ManualIntervention
-step:
type:Approval
name:"Human Review"
spec:
message:"请抽查生成的测试用例，确认后继续。"
-step:
type:Run
name:"Execute Tests"
spec:
command:|
pytest ./tests/generated --junit-xml=results.xml
-step:
type:Run
name:"Archive & Notify"
spec:
command: |
harness-cli upload-artifact results.xml
本质上，Harness 工程把一次不确定的 AI 生成，变成了一个有状态、可中止、可回溯的确定性流程。
四、一个真实的对比：裸调对话 vs. 工程化流水线
我们拿一个真实模块“用户登录”来对比三种做法。
做法 A：纯手工
测试人员根据需求写用例，然后逐条转成自动化脚本。平均耗时 4 小时，覆盖边界条件靠个人经验，回归时不敢随便改。
做法 B：裸调 Claude Code
打开 Claude Code，输入“给用户登录功能写一套 pytest 用例”，10 分钟得到一堆测试函数。看着像模像样，但跑起来发现断言值写死，CSRF token 没处理，密码明文对比。重新让它改，改完又丢了前面好的部分。反复修了 3 个小时，最终可用率只有 60% 左右，剩下的靠人补。下次需求一变动，又要来一遍。
做法 C：Harness + Claude Code 流水线
第一次配置花了 1.5 小时定义模板、审查规则和流水线。此后每次需求变更触发生成，10 分钟内出脚本，质量门自动挡掉 80% 的明显问题，人工只看 20% 的边界。一次通过率从 60% 拉到 90% 以上。最关键的是，脚本产物和测试结果都进了归档，下次回归可以直接复用，上下文不会丢。
这个对比揭示了一个残酷事实：没有工程化护栏的 AI，在测试领域就是个快一点的垃圾制造机。 快不稀缺，可信才稀缺。
五、从 0 到 1 落地的两条实施路径
到这里，你可能感觉到“这个东西我不会，需要系统学”。不急，落地不复杂，但有两条路径，取决于你现在的起点。
路径一：如果你是测试新手或在读学生
不要从零学 Harness 所有模块。从“抄一条最小 Pipeline”开始。找你们项目里一个最简单的接口，把上面那个 YAML 模板复制进去，把 Claude Code 的命令换成你们能用的版本，跑通一次。
你要建立的核心意识不是“我会用 Harness”，而是“任何 AI 产出物必须有门控和版本”。这个意识比你刷 100 道测试面试题都管用。
路径二：如果你是有经验的测试工程师
你的增值点不是会用 Claude Code，而是设计反馈闭环。在流水线里加一个“结果异常自动重试 Prompt 优化”的步骤。比如执行失败率超过阈值，自动调整 Prompt 的参数并重新生成，这就形成了一个最小智能体回路。
更进一步，你可以把测试结果喂回上下文库（比如向量索引），让下一轮生成更精准。未来的测试团队，核心工作不再是编写用例，而是设计智能体的反馈回路。
落地有一个铁律：第一版别求完美，必须能在 2 小时内跑通。跑不通的架构，再漂亮也没用。
六、最后一个问题
现在抬头看看你手头的测试系统：如果有一天需求文档变了，你的测试用例能自动重新生成、审查、执行并反馈结果吗？如果不能，那目前这套系统缺的就不是 AI，而是一根能扛住不确定性的“工程脊椎”。
这根脊椎，今天你花 2 小时就能装上。
你的系统现在具备这种反馈闭环吗？
