“这个编码 Agent 很强”是开发者社区里常见的结论，但很多文章没有写清楚：用了什么版本，运行在哪台机器，仓库是什么状态，任务提示词是什么，失败有没有重试，最后的代码有没有经过人工修改。

如果这些条件没有记录，所谓测评往往只是一次体验。它可以帮助作者形成印象，却不足以支持读者复现，更不能直接推出跨工具、跨模型和跨环境的排名。

本文不宣布哪个工具更强，而是提供一套可执行的测评方法。目标是让你在同一份仓库、同一套任务卡和同一套验收标准下，比较 Codex、WorkBuddy 的开发模式或其他 AI 编码工具，并把模型能力、工具集成、提示词和环境差异分开记录。

1. 测评先回答四个问题

开始之前先明确：

测什么：理解项目、修复 Bug、生成页面还是写脚本？
给谁测：新手、熟悉项目的开发者，还是团队日常流程？
用什么证据判断：测试、diff、截图、日志还是人工返工？
结论想服务什么决策：个人选型、团队试点还是流程改造？

不同决策需要不同测试。

如果你只是想知道哪个工具适合自己修小 Bug，一组受控任务就够了；如果要为团队选择工具，就需要覆盖不同类型的任务，并记录权限、协作和返工成本。不要为了让文章看起来“全面”而堆一大组互不相关的任务。

2. 先冻结测试环境

至少记录下面这些字段：

字段 示例写法 为什么重要
测试日期 2026-08-04 模型和工具会变化
工具名称与版本 工具名、桌面版或 CLI 版本 区分产品版本差异
模型或模式 当前实际使用的模型、推理档位或模式 避免把模式差异归因于工具
操作系统 Windows、macOS 或 Linux 及版本 影响命令和依赖
仓库提交 Git commit 或压缩包校验值 保证输入一致
依赖状态 锁文件、运行时和包管理器版本 避免环境漂移
权限 只读、工作区写入、联网和审批 影响 Agent 可执行动作
网络 可联网、受限网络或离线 影响下载和检索
任务提示词 完整保存，不只写摘要 影响任务边界
重试规则 是否允许重试、最多几次 防止人为放大结果

可以用一份 Markdown 文件记录：

# Evaluation Run

## Subject
- Tool:
- Version:
- Model or mode:
- Date:

## Environment
- OS:
- Runtime:
- Package manager:
- Repository commit:
- Network:
- Permissions:

## Task
- Prompt file:
- Input files:
- Acceptance checks:
- Retry rule:

## Evidence
- Execution log:
- Diff:
- Test output:
- Screenshots:
- Human rework:

这份记录本身也是测评产物。没有它，后面很难解释为什么同一工具这次和下次表现不同。

3. 任务一：陌生项目理解

第一类任务测试 Agent 能否在不修改代码的前提下建立项目模型。

输入

选择一个规模适中的真实仓库，固定提交版本。仓库应包含启动文件、测试、配置和至少一个不熟悉的模块。不要在任务前替工具写一份完整项目说明，否则测到的主要是人工准备质量。

任务卡

请只读分析当前仓库，不要修改文件。

请输出：
1. 项目的启动入口和主要模块；
2. 开发、测试和构建命令；
3. [指定模块] 的调用路径；
4. 可能影响本任务的配置和环境变量；
5. 当前能确认的风险；
6. 仍然缺少证据的问题。

要求：
- 每个具体结论附文件路径或命令来源；
- 不要猜测仓库中没有出现的配置；
- 不要修改、生成或删除文件。

验收

检查六项：

是否找到了真实启动入口？
命令是否来自项目配置或实际执行？
调用路径是否遗漏关键中间层？
是否把推断写成了事实？
是否读取了与问题无关的大量文件？
是否遵守了只读范围？

这个任务的结果不是“回答写得长不长”，而是证据路径是否可靠。一个篇幅很长但无法回到文件的总结，不能算理解任务成功。

4. 任务二：受控 Bug 修复

第二类任务测试 Agent 能否从复现到修复，再到回归验证。

输入准备

选择一个可以稳定复现的 Bug，最好已经有失败测试或明确的复现步骤。提前准备正确答案的验收条件，但不要把修复方案写进提示词。

例如：

问题：登录表单连续点击会创建重复请求。
现象：同一用户操作会触发两次提交。
范围：登录表单和直属测试。
禁止：升级依赖、修改接口协议、顺手重构其他表单。
验收：连续点击测试通过，现有登录测试通过，类型检查通过。

任务卡

目标：修复登录表单的重复提交问题。

请按顺序执行：
1. 先定位并复现问题，或说明为什么可以从代码路径确认问题；
2. 提出最小修复方案；
3. 只修改登录表单及其直接测试；
4. 补充覆盖连续点击的测试；
5. 运行相关测试和类型检查；
6. 最后说明修改文件、验证命令、结果和剩余风险。

如果环境无法运行测试，请明确说明，不要把未执行写成通过。

验收

先看功能是否正确，再看工程质量：

原始复现是否消失？
新增测试是否真的覆盖问题？
现有测试是否出现回归？
类型检查和构建是否有结果？
修改是否越过任务范围？
Agent 是否隐藏了失败或跳过的检查？

一个工具可能修复了 Bug，但删除了测试或扩大了 diff；也可能测试通过了，但修改了不允许碰的接口。任务完成不能只用“测试通过”一个字段判断。

5. 任务三：前端或脚本交付

第三类任务用于观察 Agent 能否把代码改动变成可用产物。

前端任务

目标：在不修改路由和接口的前提下，调整首页的错误状态。
范围：首页及其直属组件。
约束：保留现有组件库和品牌色，桌面端与 390px 宽度都要可用。
验收：启动开发服务，检查正常、加载、失败三种状态，查看控制台，并保存桌面和移动端截图。
交付：修改文件、启动命令、检查结果、未覆盖的交互。

记录的不只是截图，还要记录：页面是否实际启动、截图对应哪个提交、是否有控制台错误、移动端是否出现溢出，以及人工修改了多少内容。

脚本任务

目标：写一个脚本，把输入目录中的日志按日期提取成 CSV。
输入：提供一组正常日志、空文件、格式错误和重复记录。
约束：不修改原始日志；输出字段和时间格式固定；错误输入要有说明。
验收：对固定样本运行，逐行对照预期 CSV，并记录错误处理结果。

脚本任务适合测试确定性，因为输入和预期输出可以固定。前端任务更依赖浏览器、视口、图片和人工视觉判断，结论要单独记录，不要把两者合并成一个“代码能力分数”。

6. 设计指标，但不要急着加总分

建议把指标分成硬指标和观察指标。

硬指标

这些指标可以直接判定：

指标 记录方式
任务是否完成 通过、部分完成、失败
功能是否正确 验收测试或固定样本结果
测试结果 命令、退出码和失败列表
约束是否遵守 diff 和文件范围
产物是否存在 文件路径、截图或运行地址

观察指标

这些指标更适合写日志和复盘：

人工返工了哪些内容？
Agent 进行了多少次无效尝试？
失败后是否改变了策略？
是否主动请求了缺失信息？
最终总结是否准确反映验证结果？

可以用 通过 / 部分 / 失败 / 未测 记录每项，不必先设计一个看似精确的总分。因为“能否修复 Bug”和“是否方便办公用户上手”很难用同一权重公平合并。

7. 保存每次执行的证据

一次测评至少保存以下文件或信息：

run.md：环境、任务、规则和结论。
prompt.txt：实际发送的完整提示词。
transcript.txt：关键执行记录和工具输出。
diff.patch：实际代码差异。
test.log：测试、类型检查和构建结果。
screenshots/：前端任务的桌面和移动端截图。
rework.md：人工修改了什么，以及为什么修改。

如果工具不方便导出全部对话，可以至少记录每个关键阶段：开始前的任务、实际调用的工具、失败原因、修改文件和验证输出。不要只保存 Agent 的最终总结，因为总结可能遗漏失败尝试。

8. 控制变量的方法

一次只改变一个因素

比较两个工具时，尽量固定：

同一仓库提交。
同一输入数据。
同一验收标准。
尽量相同的任务描述。
相同的网络和依赖状态。
相同的权限边界。

如果 A 用只读模式，B 用全自动写入模式，最后差异不能归因于模型或产品本身。

任务顺序随机化

同一仓库被第一个工具改过后，第二个工具再测试就不公平。更稳的做法是：

为每个工具准备独立副本。
每次从同一基线提交开始。
不同工具交替测试任务顺序。
每个任务结束后保存完整 diff 和日志。

重试规则固定

一次成功、一次失败都可能是随机波动。你可以规定：每项任务最多执行固定次数，或者连续多次测试直到证据足够。无论采用哪种方法，都要提前写进测试方案，不能看到不满意的结果才偷偷重试。

9. 如何解释失败

失败记录不要只写“模型不行”。可以按下面的类别归因：

失败类别 例子 下一步
目标误解 把修复 Bug 做成重构 改任务范围和验收
上下文缺失 没找到配置或调用方 补文件索引或搜索路径
工具限制 无法运行测试或打开页面 调整环境或权限
实现错误 修改逻辑本身不正确 复现、补测试、重新执行
验收缺失 产物看似完成但没有证据 加测试、截图或来源
环境故障 依赖、网络或端口问题 修复环境后重跑
人工标准不清 不知道什么算“好看” 提供样例、反例或规格

分类的价值在于让下一轮测试知道该改变什么。如果所有失败都被归为“模型能力不够”，你就无法知道是换工具、补上下文还是修环境。

10. 结果怎么写才不夸大

一份合格的测评结论至少包含四层：

条件：在哪个版本、环境、仓库和权限下测试。
证据：完成了什么，哪些测试通过，改了哪些文件。
判断：在这组任务上，哪个工作流更适合当前目标。
限制：样本、版本、任务难度和人工返工对结论有什么影响。

例如：

在 Windows、某次固定提交、工作区可写且保留人工审批的条件下，工具 A 完成了 3 个受控 Bug 修复中的 2 个；工具 B 完成了 3 个中的 2 个。A 在项目探索阶段提供的文件证据更完整，B 在报告整理阶段的格式返工较少。样本只有 3 个任务，且未覆盖远程协作和大型仓库，因此不能据此推出普遍排名。

这种写法可能没有一句“谁赢了”抓眼球，但它更接近可复核的工程结论。

11. 发布前检查清单

[ ] 工具名称、版本、模型或模式已记录。
[ ] 操作系统、依赖、仓库提交和网络状态已记录。
[ ] 每项任务都有输入、范围、约束和验收条件。
[ ] 失败和重试规则在执行前已经确定。
[ ] 代码任务保存了 diff 和测试结果。
[ ] 前端任务保存了视口、截图和控制台结果。
[ ] 人工返工内容被单独记录。
[ ] 没有把单次体验写成普遍性能结论。
[ ] 结论明确写出条件和限制。

Anthropic 的 Demystifying evals for AI agents 讨论了 Agent 评估需要结合任务、环境和可观察结果。这里不要求个人用户搭建复杂评测平台，但应保留足够证据，让别人知道你到底测了什么。

12. 结论与限制

AI 编码工具的测评，核心不是让一个 Agent 完成一次炫技任务，而是建立一个可以重复执行、可以解释失败、可以回看证据的验收流程。

陌生项目理解关注证据路径，Bug 修复关注复现、最小改动和回归测试，前端或脚本交付关注真实运行结果。任务卡、环境记录、diff、日志和人工返工记录组合起来，才能把“感觉好用”变成“在这些条件下适合这个任务”。

这套方法不能消除模型随机性，也不能让三项任务代表所有项目。它的边界正是它的价值：结论只对已经记录的环境、版本、任务和验收条件负责。需要更可靠的团队决策时，应增加任务样本、重复执行和独立审阅，而不是把一次演示的分数写得更精确。

资料与说明