Lab 🧪 实验复盘

工具对比如果只看功能表，很容易变成主观偏好。本文设计一个可复现的横评实验：同一批任务、同一代码库、同一验收标准，分别交给 Claude Code、Codex CLI 和 OpenCode，比较通过率、改动范围、成本、耗时和人工干预次数。

Lab 002：同一任务交给 Claude Code、Codex、OpenCode，谁更稳？

工具对比如果只看功能表，很容易变成主观偏好。本文设计一个可复现的横评实验：同一批任务、同一代码库、同一验收标准，分别交给 Claude Code、Codex CLI 和 OpenCode，比较通过率、改动范围、成本、耗时和人工干预次数。

多工具横评实验矩阵图
多工具横评实验矩阵图

一、实验目标

本实验关注“稳定性”，不是只看某一次输出是否惊艳。

指标 说明
一次通过率 首次执行后测试和检查全部通过的比例
平均耗时 从启动到产出可评审 diff 的时间
平均成本 单任务 Token 或美元成本
改动聚焦度 是否只修改任务相关文件
人工干预次数 中途需要人类补充说明或纠正的次数
结果可审查性 是否输出清楚的修改摘要和验证证据

二、任务集设计

任务集要覆盖不同难度，不能只挑某个工具擅长的场景。

yaml
tasks:
  - id: "bugfix-001"
    type: "bugfix"
    title: "修复金额四舍五入错误"
    acceptance:
      - "新增边界值测试"
      - "pytest tests/billing -q 通过"

  - id: "feature-001"
    type: "feature"
    title: "新增用户导出 CSV 接口"
    acceptance:
      - "支持 created_after 参数"
      - "新增 API 测试"
      - "OpenAPI 文档更新"

  - id: "review-001"
    type: "review"
    title: "审查认证模块潜在安全问题"
    acceptance:
      - "输出 P0/P1/P2 分类"
      - "每个问题包含文件和修复建议"

  - id: "refactor-001"
    type: "refactor"
    title: "将同步邮件发送改为异步任务"
    acceptance:
      - "业务行为保持不变"
      - "新增失败重试测试"

三、统一运行协议

为避免比较不公平，每个工具都使用同一份任务模板。

md
你将完成一个受控实验任务。

## 任务
{{title}}

## 代码库
当前目录就是待修改仓库。

## 约束
- 只修改完成任务所需的文件
- 不要引入新依赖，除非验收标准明确要求
- 修改后必须运行指定验证命令
- 最后输出：修改摘要、验证结果、剩余风险

## 验收标准
{{acceptance}}

## 验证命令
{{verify_command}}

四、执行脚本

下面的脚本展示如何统一调度三个工具。实际项目中可以替换命令适配本地环境。

bash
#!/usr/bin/env bash
set -euo pipefail

TASK_ID="$1"
TOOL="$2"
BASE_DIR="${BASE_DIR:-/tmp/agent-benchmark}"
PROMPT_FILE="$BASE_DIR/prompts/$TASK_ID.md"
RUN_DIR="$BASE_DIR/runs/$TASK_ID/$TOOL"

rm -rf "$RUN_DIR"
git clone "$REPO_URL" "$RUN_DIR"

case "$TOOL" in
  claude)
    (cd "$RUN_DIR" && claude -p "$(cat "$PROMPT_FILE")")
    ;;
  codex)
    (cd "$RUN_DIR" && codex exec "$(cat "$PROMPT_FILE")")
    ;;
  opencode)
    (cd "$RUN_DIR" && opencode run -f "$PROMPT_FILE")
    ;;
  *)
    echo "unknown tool: $TOOL" >&2
    exit 1
    ;;
esac

(cd "$RUN_DIR" && git diff --stat > "$BASE_DIR/results/$TASK_ID-$TOOL.diffstat")
(cd "$RUN_DIR" && git diff > "$BASE_DIR/results/$TASK_ID-$TOOL.patch")

参数说明

参数 说明
TASK_ID 任务编号，对应 prompts 目录里的任务文件
TOOL claude、codex、opencode
BASE_DIR 实验输出目录
REPO_URL 被测代码仓库地址

五、评分卡

json
{
  "task_id": "feature-001",
  "tool": "codex",
  "result": {
    "completed": true,
    "tests_passed": true,
    "changed_files": 5,
    "unrelated_files": 0,
    "manual_interventions": 1,
    "duration_seconds": 184,
    "estimated_cost_usd": 0.42
  },
  "scores": {
    "correctness": 34,
    "focus": 18,
    "test_quality": 17,
    "reviewability": 8,
    "cost_efficiency": 7,
    "total": 84
  }
}
评分项 分值 说明
正确性 40 功能是否完成，测试是否通过
聚焦度 20 是否避免无关修改
测试质量 20 是否覆盖关键路径和边界值
可审查性 10 摘要、风险、验证结果是否清楚
成本效率 10 成本和耗时是否合理

六、结果展示表

text
任务           工具          通过  文件数  干预  成本   总分
bugfix-001    Claude Code   是    2      0     0.18   91
bugfix-001    Codex CLI     是    2      0     0.09   89
bugfix-001    OpenCode      是    3      1     0.12   82
feature-001   Claude Code   是    6      0     0.58   88
feature-001   Codex CLI     是    5      1     0.42   84
feature-001   OpenCode      否    4      2     0.36   61

七、常见偏差控制

偏差 控制方式
顺序偏差 随机化工具执行顺序
缓存偏差 每次使用干净 clone
人工提示偏差 使用统一 prompt，不中途追加私货
验收偏差 由脚本执行同一套验证命令
评审偏差 盲评 patch，先不看工具名

八、横评结论怎么写

横评文章不要写成“某某工具天下第一”，而要输出任务适配建议：

yaml
recommendation:
  simple_bugfix:
    preferred: "Codex CLI"
    reason: "速度快、改动小、成本低"
  complex_refactor:
    preferred: "Claude Code"
    reason: "跨文件推理和一致性更强"
  interactive_iteration:
    preferred: "OpenCode"
    reason: "TUI 体验好，适合人机来回调整"

总结

真正有价值的工具横评，不是功能清单，也不是单次体验，而是可复现的任务集、统一验收标准和结构化评分。只有这样，团队才能知道什么任务该交给什么工具，而不是靠感觉选型。