在保险查查的页面 Verify 项目(下面代号 HelixVerify )中,我们经历了 114 次版本迭代, 将相对benchmark 的风险样本召回率从 最初的 8% 提升至 98.86%,无风险样本通过率从 36.11% 提升至 54.93%。
整个 114 次迭代中,没有一行代码是我手写的。 从第一个版本开始,所有代码都是我指导 AI 完成的——包括搭建闭环环境本身的代码。早期 AI 没有闭环,效率很低:每轮迭代都需要我指出方向、审查结果、告诉 AI 下一步做什么。但 AI 在我的指导下逐步搭建出端到端测试、标准化评测、自动诊断等基础设施——每搭建一个模块,AI 就减少一项对人的依赖。
这是一个自举(bootstrapping)过程:AI 用自己写的代码,逐步把自己迭代到能够自主闭环运行。当闭环完成后,AI 可以 7×24 小时自主运行:分析问题、生成策略、修改代码、验证效果、进入下一轮——整个过程无需人工介入。我们在HelixVerify项目中的实践与 OpenAI 在 2026 年 2 月分享的理念不谋而合:人类掌舵,智能体执行(Humans steer. Agents execute.)。工程师的角色从”编写代码”转向”设计环境、明确意图和构建反馈回路”。
本文将通过 HelixVerify 项目的实践介绍我们如何一步步搭建让 AI 自主迭代的工程环境。关于测试理论和前提工具的部分在Harness Engineering：搭建环境前的理论与工具 中有介绍。
一、HelixVerify: Agent 产出检测系统
HelixVerify 是一个 Agent 产出质量验证系统，核心通过后置verify系统反馈，消除 LLM 生成页面内容时的幻觉与低质量问题。
1.1 整体架构
HelixVerify 采用三层分离架构:
- 首先人类设定目标(召回率≥90%)和安全边界(不可误杀正确样本)
- 然后就让 AI 自主迭代,完成诊断→策略→实施→验证的闭环
- 其中我作为“架构师” 指出应该执行的架构，即下面的混合验证引擎
1.2 混合验证-Rule + LLM
这个架构是我作为人类对 AI 最大的输入。刚开始我让模型持续自迭代,但发现模型(Opus-4.5)做不到自己迭代出一个合理的架构——模型更多是在自己的一亩三分地反复优化。而当我指出”Rule 引擎 + LLM 多轮检测可以优势互补”时,模型就在关键指标上持续取得很大进步。
设计思路: Rule 引擎和 LLM 各有所长,让它们各司其职:
- Rule 引擎(23 条规则): 处理确定性错误——HTML 注释残留、JSON 空数据、格式异常等。毫秒级响应,100% 确定,覆盖 30-40% 的错误。
- LLM 多轮检测(7 个维度并行): 处理语义错误——数值不准确、术语误用、逻辑矛盾、信息遗漏等。需要语义理解,覆盖 60-70% 的错误。
- FP Filter(后置过滤): 16 条规则 + LLM 语义判断,过滤两层检测产生的误报。
两者重叠约 10-20%,说明互补性好。
二、如何搭建让 AI 自主迭代的闭环环境
有了验证引擎还不够——AI 需要一个完整的闭环环境才能自主迭代优化这个引擎。本节是这篇文章的核心:搭建闭环所需的 5 个能力模块,以及让闭环 7×24 持续运行的 Loop 基础设施。
需要强调的是:这些模块本身也是 AI 写的代码。 整个过程是一个自举:早期我指导 AI 搭建端到端测试 → AI 有了”看”的能力 → 我指导 AI 搭建评测工具 → AI 有了”量”的能力 → ……每搭建一个模块,AI 对人的依赖就减少一层,直到闭环完全合上。
这些模块不是一次性搭完的,而是在 114 次迭代中由 AI 逐步搭建的。每个模块的出现,都是因为闭环在某个环节断了,AI 跑不下去了——然后我指出问题方向,AI 来实现解决方案。
2.1 端到端测试体系:让 AI”看懂”系统
AI 只能改代码,但看不懂改完之后系统内部发生了什么——这就像让一个工程师蒙着眼睛 debug。所以我们要搭建完整的端到端测试框架,让 AI 像人类工程师一样 debug:
- 模拟人类分析 case: AI 发请求、看响应、分析日志,就像人类工程师 debug 一样
- 理解 LLM 的思考过程: 通过日志中的 traceId 追踪每个请求的完整链路,包括 LLM 内部的推理过程——这让 AI 不仅知道”结果不对”,还能理解”哪一步思考出了问题”
- 自主设计测试用例: AI 根据代码变更自己设计测试,不需要人工指定
于是 AI 从”只能改代码”升级为”能改代码 + 能验证效果 + 能定位问题”。这是闭环的起点——没有这个能力,后面所有模块都无从谈起。
2.2 标准化评测(verify_bench):给 AI 一把统一的尺子
解决的问题: AI 改完代码后不知道是进步了还是退步了。没有统一标准,AI 无法自主判断迭代结果,闭环在”评估”环节断裂。
我的做法: 构建 verify_bench 评测工具,输出结构化的两份文件:
verify_bench 评测输出
├── metric.txt → 量化指标,AI 用来判断”好不好”
└── detail.txt → 逐条明细,AI 用来分析”哪里不好”
metric.txt(指标结果):
# AI 可以直接解读的结构化指标
{
“total_samples”: 202,
“tp”: 85, # 真阳性: 正确检出的错误
“fp”: 234, # 假阳性: 误报
“fn”: 1, # 假阴性: 漏报
“tn”: 345, # 真阴性: 正确通过
“recall”: 0.9886,
“pass_rate”: 0.5493
}detail.txt(逐条明细):包含每个样本的完整日志、人工标注的 Ground Truth 结果、以及 HelixVerify 产出的实验过程目录。三者并列,AI 可以逐条对比,发现”人觉得对但机器判错”或”人觉得错但机器漏掉”的具体 case。
为什么这件事对闭环至关重要? 如果 AI 没有一个可程序化调用的评测工具,它就无法自主判断迭代结果。每次改完代码都需要人来看结果、告诉 AI 好不好——闭环就断了。
于是AI 每次改完代码后能自动跑评测、自动解读 metric.txt 判断方向、自动分析 detail.txt 定位问题,自主决定下一步。
detail.txt 如何构建
detail.txt 本身是一个集合，指导 AI 去对应地方查看日志、GT 以及 实验过程目录。应读者要求，我这里附录下具体的实验目录构建步骤：
# ============================================================
# Step 1: 设置环境变量
# ============================================================
...
# ============================================================
# Step 2: 创建实验目录（带版本号和时间戳）
# ============================================================
EXPERIMENT_DIR="experiments/v101_stage1_test_$(date +%Y%m%d_%H%M%S)"
mkdir -p $EXPERIMENT_DIR
echo "📁 实验目录: $EXPERIMENT_DIR"
# ============================================================
# Step 3: 运行验证
# ============================================================
echo "🚀 开始验证 Stage 1..."
$VENV_PYTHON run_stage_validation_direct.py \
--stage 1 \
--output-dir $EXPERIMENT_DIR
# 验证输出示例：
# ============================================================
# 🚀 Stage 1 | Samples: 10
# Data: stage1.xlsx
# Temperature: 0.0 (Fixed)
# ============================================================
# [1/10] BIZ_2026011600000005289480 ✅ BC=2
# [2/10] BIZ_2026010500000004072882 ✅ BC=1
# ...
# [10/10] BIZ_2026011600000005248951 ✅ BC=2
# 💾 Results saved: experiments/v101_stage1_test_20260210_104139/stage1_results.xlsx
# ============================================================
# Step 4: 运行verify_bench评测
# ============================================================
echo "📊 运行verify_bench评测..."
cd ../../../verify_bench
....
# verify_bench会输出结果目录，例如：
# results/20260210_104510_stage1_results_eqfn_v1/
# ============================================================
# Step 5: 查看评测结果
# ============================================================
echo "📈 查看指标..."
# 找到最新的results目录
LATEST_RESULT=$(ls -td results/*stage1* | head -1)
echo "最新结果目录: $LATEST_RESULT"
# 查看核心指标
cat $LATEST_RESULT/metric.txt
# 示例输出：
# MetricPRF(
# tp = 3,
# fp = 13,
# fn = 1,
# p = 0.1875, # Precision: 18.75%
# r = 0.75, # Recall: 75%
# f1 = 0.3, # F1: 30%
# )
# MetricRecallPass(
# (风险样本)全召回率 = 66.67 %,
# (无风险样本)通过率 = 28.57 %,
# )
# 查看详细case分析（查看前30行）
head -30 $LATEST_RESULT/detail.txt
# ============================================================
# Step 6: 复制verify_bench结果到实验目录
# ============================================================
cd $VERIFY_V2_ROOT
cp -r ../../../verify_bench/$LATEST_RESULT $EXPERIMENT_DIR/verify_bench_results
echo "✅ verify_bench结果已复制到实验目录"
# ============================================================
# Step 7: 创建配置快照（推荐）
# ============================================================
.....
# ============================================================
# Step 8: 创建分析报告（模板）
# ============================================================
.....
# ============================================================
# Step 9: 查看实验目录结构
# ============================================================
echo "📁 实验目录结构："
tree -L 2 $EXPERIMENT_DIR 2>/dev/null || ls -lR $EXPERIMENT_DIR
# 期望输出：
# experiments/v101_stage1_test_20260210_104139/
# ├── config.json
# ├── stage1_results.xlsx
# ├── analysis_report.md
# └── verify_bench_results/
# ├── metric.txt
# ├── detail.txt
# └── evaluation_results.json
echo "✅ 完成！现在可以编辑 $EXPERIMENT_DIR/analysis_report.md 进行详细分析"
2.3 Badcase 自动诊断:让 AI 自己发现问题
解决的问题: 以前每轮迭代,都需要我人工分析 badcase,告诉 AI”这批误报的共同特征是 XXX,你试试从这个方向优化”。我是 AI 迭代的瓶颈。
我的做法: 让 AI 直接消费 verify_bench 的两份输出,自动完成诊断:
AI 读取 metric.txt 判断当前瓶颈在哪(是召回率不够还是误报太多),然后读取 detail.txt 聚类分析具体 case,自动生成候选优化策略并按预估收益排序。
关键设计: AI 的诊断是数据驱动的——它从 detail.txt 的逐条对比中发现规律,而不是凭”直觉”猜测。这比人工分析更系统、更不容易遗漏。
解锁的能力: 人类不再需要参与”分析问题”这个环节。AI 自己跑评测、自己分析结果、自己生成策略。
2.4 TP 对抗验证:让 AI 的改动安全
在当前的指标优化场景汇总，AI 自主迭代往往会出现“按下葫芦起了瓢”的情况，即优化了一个指标，另一个指标反而下降了。比如在 v105 中， AI 统计了高频误报的 case ,直接设计过滤规则和 prompt 。对于正确样本误报确实减少了 23 个,使得无风险样本召回率上升了，但是讲原有的风险样本错误也误杀了，风险样本召回率从 90% 暴跌至 40%。
之所以有这种”优化一个指标、破坏另一个指标”的困境，根因在于 AI 只看了误报数据,没有交叉验证正确样本。所以我们需要TP(True Positive)对抗验证——任何过滤规则上线前,必须验证它不会误杀正确样本:
实现 TP 对抗验证后,后续 30 次迭代无一次召回率下降。AI 终于可以放心地优化误报,不用担心破坏已有成果。
我们需要有手段保证AI 的迭代从”可能破坏”变为”保证不破坏”。使用代码围栏、Lint、对抗测试与模块等。
2.5 阶梯式验证:让 AI 用最低成本试错
全量评测(202 样本) 需要 60 分钟。如果每次试错都跑全量,AI 一天只能迭代几次,效率太低。
于是我从小样本到大样本逐层验证,90% 的问题在前 3 分钟暴露:
为什么不直接跑全量? 因为 AI 的大部分尝试会失败——114 次迭代中 70% 是失败或部分达标。让失败在 3 分钟内暴露,比在 60 分钟后暴露,节省了巨大的时间成本。
于是AI 一天可以迭代十几次(而非几次),大幅加速”试错-学习”循环。
2.6 Loop 基础设施:让 AI 7×24 持续运行
前面 5 个模块解决了”AI 能做什么”的问题,但还有一个关键问题:谁来驱动 AI 不停地跑下去?
人类不可能 24 小时盯着屏幕按回车。我们需要 Loop 基础设施。
Ralph-Loop:让 AI 自己决定”做没做完”
Claude Code 本身是 Loop 组成的智能体,而人类使用 Claude Code 的过程(提需求→规划→实现→review→再提需求)本身也是一个 Loop。Ralph-Loop 借助 Stop Hook,强制 AI 每次自然停下时反思任务是否完成,没完成就继续:
/ralph-loop “Fix xxx” --max-iterations 10 --completion-promise “FIXED”这个命令让模型修复 xxx,一直到 AI 认为自己修复完成并显式输出 “FIXED” 才会停止,最大迭代 10 次。
上下文窗口不会爆掉吗? 不会。Ralph-Loop 在每轮任务结束后彻底关闭当前 AI 进程并重新启动,模型将进度和状态存储在本地文件中,剥离”短期记忆”。
实际体验: 我跑通了持续运行 6 小时以上的任务。不过也得承认没有很稳定能有效运行这么久——模型会反思进入自身的”无进度循环”中,也可能触发上下文溢出(比如模型突然读了一个很大的日志文件)。保持任务原子化和可验证是关键。
之所以我要求是整个流程要做到连续跑 6h 以上—是希望至少人睡觉前启动下，睡觉后可以看结果。这个主要依赖两个，一个是 Ralph Loop 本身会不停 save session 再 resume ；第二个是需要调试到模型每次工作都有完好的实验记录，保证每一次迭代是在上一次基础上前进。让模型每次在新的 session 可以看到之前的实验记录，包括benchmark 、评测结果以及评测细节等。
Supervisor:给 AI 加一个”AI 主管”
Ralph-Loop 的缺点很明显——单纯让 AI 自己反思,不能给 AI 指导性意见,不能像人类一样 review AI 每次停下来的输出,或者在 AI 问你选 A 还是 B 方案时给出判断。
解决办法:在最外层 Loop 加一个 Supervisor Agent,它扮演人类的角色:
| 方面 | Ralph-Loop | Supervisor |
|---|---|---|
| 检测方式 | AI 输出结构化状态 + 规则解析 | Supervisor AI 直接审查 |
| 评估方式 | 基于信号和规则 | Fork 会话上下文,评估实际质量 |
| 灵活性 | 需要更新规则代码 | 更新 Prompt 即可 |
Supervisor 会判断:AI 是否在等待确认?是否做了该做的事?代码质量是否达标?用户需求是否全部满足?
不过复杂场景下 AI 归根结底不能代替人做判断。当 AI 给出选项 A、B、C 时,Supervisor 或许能根据当下情况选择,但目前还不能像人一样提出 D 选项。比如下面这个场景:AI 自己给出了几个选项并选了 A,但我明显不同意它妥协的做法——这个判断就是人的核心价值所在。
下面是 AI 在 Loop 中 “Aha Monent” 的时候: 
⚠️ Loop 过程中我们要避免上下文的无关消耗虽然每次新的 Loop 会开启新窗口。但是单次 Loop 上下文窗口依然是非常有限的资源。不珍惜的话不仅仅是效果问题，当次 Loop 也可能被中断。比如实验日志动辄数千行，多次轮询会快速耗尽上下文，导致 AI”失忆”。需要主动避免 AI 无效轮询评测过程。
# ❌ 不要多次非阻塞读取检查进度（每次重新加载全部日志）
while True:
result = TaskOutput(task_id, block=False)
# ✅ 阻塞等待，一次性获取结果
result = TaskOutput(task_id, block=True)闭环 + Loop = 基于测试的应用级”强化学习”
当 AI 有了闭环的 5 个能力模块,又有了 Loop 基础设施持续运行,整个系统就构成了一个类似强化学习的过程:
闭环合上前后的对比:
| 闭环前(v1-v70) | 闭环后(v71-v114) | |
|---|---|---|
| 人的角色 | 指导 AI 分析 badcase、指定方向、审查每次改动 | 设定目标、审批上线 |
| AI 的角色 | 执行人的指令写代码,同时搭建环境模块 | 自主完成诊断→策略→实施→验证全流程 |
| 迭代周期 | 5-7 天/轮 | 3-4 小时/轮 |
| 迭代成功率 | ~60% | ~75% |
| 召回率进展 | 0% → ~80%(70 个版本,~4 周) | 87% → 98.86%(44 个版本,~2 周) |
114 次迭代最终成果:
| 指标 | v71 基线 | v114 最终 | 提升幅度 |
|---|---|---|---|
| 召回率(Recall) | 87.42% | 98.86% | +11.44pp |
| 通过率(Pass Rate) | 36.11% | 54.93% | +18.82pp |
| 误报数(FP) | 346 | 234 | -112 (-32.4%) |
| 漏报数(FN) | 19 | 1 | -18 (-94.7%) |
三、Harness Engineering:从实践中提炼的方法论
前两节讲了我们做了什么、怎么搭建闭环。本节提炼背后的方法论——让这些经验可以复用到其他场景。
OpenAI 在 2026 年 2 月分享了类似的理念:用 Codex 智能体完成产品开发,接近 100 万行代码没有一行是人工编写的。他们总结的核心是:人类掌舵,智能体执行(Humans steer. Agents execute.)。工程师的角色从”编写代码”转向”设计环境、明确意图和构建反馈回路”。 OpenAI. 将其提炼为 Harness Engineering:
Harness Engineering = 工程师的主要工作不再是编写代码,而是设计环境、明确意图和构建反馈回路,从而使 AI 智能体能够可靠地工作并交付成果。
我们在 HelixVerify 中实践了同样的理念。这里我还想提出基于自身实践的四条核心原则：
可复制的实施路径
如果你想为自己的场景搭建类似的闭环,建议按以下顺序:
Phase 1: 让 AI 能”看”和”量”
- 搭建端到端测试体系:让 AI 能发请求、看日志、追踪调用链路
- 对接标准化评测工具:让 AI 有统一的量化指标
- 建立 Git 版本管理:每次迭代自动 commit,全程可追溯、可回滚
Phase 2: 让 AI 能”诊”和”治”
- 实现 Badcase 自动诊断:让 AI 能从评测结果中自动发现问题
- 实现 TP 对抗验证:让 AI 的每次改动都安全可控
- 实现阶梯式验证:让 AI 能用最低成本快速试错
Phase 3: 让 AI 7×24 自主运行
- 配置 Ralph-Loop 或 Supervisor,让 AI 持续迭代(现在 Claude Code 自带了原生 Loop)
- 失败案例自动记录到知识库,避免重复犯错
- 人类只需设定目标和审批上线
结语
Harness Engineering 的核心很简单:为 AI 搭闭环,让 AI 自举到自主运行。
HelixVerify 的 114 次迭代,没有一行代码是我手写的。AI 在人的指导下,逐步搭建出让自己能够自主迭代的闭环环境——端到端测试、标准化评测、Badcase 诊断、TP 对抗验证、阶梯式验证、Loop 基础设施。每搭建一个模块,AI 对人的依赖就减少一层,直到闭环完全合上,AI 可以 7×24 自主运行。
HelixVerify 在质量验证领域验证了这个理念:
- 效率: 迭代周期从 5-7 天缩短至 3-4 小时(30-40 倍)
- 质量: Recall 8% → 98.86%, Pass Rate 36.11% → 54.93%
- 成本: 原本需要很多人标注、看 Case，现在只需要开发者为 AI 建立 Harness 的环境
当你需要 AI 来完成长流程闭环任务时, 先问自己几个问题，如果哪个环节的答案是”不能”,那就是你需要搭建环境中的下一个模块。同时AI 可能为了通过 E2E 测试而”作弊”（满足测试但不满足真实需求），需要额外的三个设计来对抗。
最终人类的角色从「写代码」转变为「设定游戏规则和指导策略」。
希望这些经验能对后 OpenClaw 时代，开发者有效管理 AI 交付需求有所启发。
术语表
为了方便非算法背景的读者理解,这里列出文章中使用的核心术语:
质量验证指标
| 术语 | 英文 | 解释 | 场景示例 |
|---|---|---|---|
| 召回率 | Recall | 所有真实错误中被成功检测出的比例 | 100个真实错误,检出90个,召回率=90% |
| 通过率 | Pass Rate | 没有误报的样本占总样本的比例 | 100个样本,60个完全正确(无误报),通过率=60% |
| 真阳性 | TP (True Positive) | 正确检出的错误样本 | 检测出的错误确实是错误 |
| 假阳性 | FP (False Positive) | 误报,把正确的判断为错误 | 把正确内容误判为错误 |
| 假阴性 | FN (False Negative) | 漏报,把错误的判断为正确 | 错误内容未被检测出 |
| 真阴性 | TN (True Negative) | 正确判断为正确的样本 | 正确内容被正确识别 |
核心机制
| 术语 | 解释 | 价值 |
|---|---|---|
| TP 对抗验证 | 在设计过滤规则前,验证该规则是否会误杀正确样本 | 防止召回率下降 |
| 阶梯式验证 | 从小样本到大样本逐层验证,快速暴露问题 | 节省验证时间 |
| Rule+LLM 混合 | 规则引擎处理确定性错误,LLM 处理语义错误 | 优势互补,提升覆盖率 |
工程术语
| 术语 | 解释 |
|---|---|
| Badcase | 错误案例,包括误报(FP)和漏报(FN) |
| Ground Truth (GT) | 人工标注的正确答案 |
| Benchmark | 用于评测的标准数据集 |
| Stage | 阶梯式验证中的一个阶段 |
注: Recall 和 Pass Rate 指标均相对于当前 benchmark
参考资料:
- OpenAI: “Harness Engineering: Working with Codex in an agent-first world”: https://openai.com/index/harness-engineering/
- Ralph-Loop: https://snarktank.github.io/ralph/
- Claude Code Supervisor: https://github.com/guyskk/claude-code-supervisor