测开必看｜可落地实操：用独立验收和反例检查 AI 自测

摘要

OpenAI发布的Harness Engineering文章记录了一种agent-first研发实验：团队让Codex承担代码、测试、CI、文档和内部工具的实现，人负责设计环境、明确意图并建立反馈环。本文核对公开数字的性质，分析这对测试角色的启发、不能推出的结论和团队可落地的试验方式。

一个研发任务交给Agent后，代码很快出现，单测也跟着生成，CI还显示通过。此时测试工程师真正要回答的，可能已经不是“它有没有写测试”，而是“测试覆盖的风险是不是由一个独立标准定义的”。当同一个Agent既写实现、又写测试、再按自己生成的标准解释结果，速度的确可能提升，质量判断也可能在无意中失去独立性。

OpenAI发布的《Harness engineering: leveraging Codex in an agent-first world》分享了一项公开工程实验。文章称，一个由Agent承担代码、测试、CI配置、文档、可观测性和内部工具实现的团队，先从空仓库起步，约五个月后代码规模达到约百万行；期间约1500个PR被打开并合并，最初由三名工程师驱动Codex，后来团队扩展到七人。文章还写明，“约为手写所需时间的十分之一”是团队估算，不是独立对照实验或通用生产效率保证。这里的数字是OpenAI对自身实验的公开描述，不能直接外推到任何公司的交付速度。

这个案例适合测试工程师关注，因为它把问题从“AI能不能补全代码”推到了“研发团队主要工作是否会转向环境、规格、反馈和治理”。本文将围绕四件事展开：公开文章真正披露了什么；哪些流行解读超出了证据；当Agent负责实现和自测时，独立质量判断怎么保留；小团队怎样做一轮可回滚的试验。核心判断是：代码生产比例可以变化，但系统的验收权、风险边界和责任归属不能因为产出速度上升而变模糊。

从“人写代码”到“人设计工作环境”

过去的软件工程任务大致围绕需求、设计、编码、测试和发布展开。代码是最可见的工作产物，测试往往在代码形成后检查行为是否符合需求。Agent-first流程把一部分实现交给模型，人的时间开始更多花在组织仓库知识、说明约束、构造工具、配置反馈机制和决定何时停止。OpenAI文章用“Humans steer. Agents execute.”概括其经验，但这个口号是团队对自身实践的总结，不应被理解成所有工程师都已退出编码。

如果把研发活动拆成五个部分，可以看到变化并非简单的“人少做、AI多做”。

这张表是本文的岗位分析框架，不是OpenAI公开团队的角色表。它表达的重点是：Agent接手某些操作后，人类工作会向“定义目标、选择证据、批准风险”迁移，而不是工作消失。

这份公开材料能证明什么，不能证明什么

能核验的事实包括：OpenAI公布了一个Agent承担多类工程产物的实验；文章给出时间、PR、代码规模和团队人数等自报信息；团队强调仓库结构、测试、CI、文档、可观测性和内部工具共同构成工作环境。文章还展示了他们如何把约束写进代码库、用自动化检查保护结构，并在开发中持续修复问题。

不能从中直接推出：所有团队都能以相同比例提速；百万行代码天然代表产品质量；小团队不再需要测试；人类审查可以完全去掉；或Agent生成的测试已经独立证明了实现正确。尤其“十分之一时间”是团队自己的估计，比较对象和工作量边界依赖原文口径，不能在标题里包装成客观行业基准。百万行和1500个PR也只是规模信号，不是用户价值或缺陷率指标。

因此更值得分析的是机制。Agent能够连续工作，依赖的不是单个模型，而是仓库上下文、可调用工具、任务约束、自动反馈和人类判断组成的Harness。提示词不足时，Agent可能做出看似合理但与系统约定冲突的改动；工具权限过大时，错误可能被执行；反馈不完整时，测试通过也不能排除关键路径没有被覆盖。所谓生产力变化，来自任务拆解、信息准备、并行执行和快速反馈共同作用。

最容易被忽略的反常识：Agent越会自测，越要检查谁定义了“通过”

一条最简单的风险链是：Agent看到需求，写实现；同一Agent根据需求写单测；它运行单测并修改实现直到通过；最后再生成测试报告。如果测试只覆盖Agent已经理解到的需求，它可能把同一个误解同时写进实现与测试。结果是“测试通过”只说明二者相互一致，不说明业务目标被正确理解。

这与传统开发里开发者写测试并非完全不同，但Agent的生成速度会让同源偏差更快扩大：需求遗漏可以被复制到多个文件，假设不清会被传播到mock、断言、文档和验收说明中。因此“代码通过测试”需要回答：测试断言来自哪里？是否有独立的业务规则来源？是否保留了能够击中错误实现的反例？数据与环境是否真实？关键断言是否能在实现发生错误时失败？

一份独立质量证据清单

• 需求证据：由产品规则、监管要求或业务负责人确认的约束，不由Agent自行补全后当成事实。
• 测试证据：至少有一部分样本由不同角色或不同机制制定；对高风险条件加入边界值、反例和状态迁移。
• 运行证据：保留具体提交、环境、测试版本、工具调用、失败信息和重试次数。
• 结果证据：检查业务状态和外部副作用，不以进程退出码或Agent自述替代。
• 责任证据：标记哪些操作由模型建议、哪些由人批准、哪些由自动化执行，确保出现问题时能够回溯。

小团队怎么做一次低风险Agent-first试验

不必先把整个项目交给Agent。选一个边界清楚、可回滚、失败代价可控的任务，例如生成一个只读API的测试适配层，或为已有CLI补一组文档和测试。先明确试验不是“看模型能不能写代码”，而是比较工作流：哪些步骤交给Agent后能减少等待，哪些步骤仍需要工程师判断，哪些新错误是由权限、上下文或反馈不足导致。

试验准备：给Agent只读仓库、创建分支、运行测试的权限；将生产密钥、生产写权限和部署凭证隔离。仓库里放清晰的目录说明、测试命令、编码约定和“不允许改变的业务不变量”。任务开始前由工程师写出可观察的验收条件和至少一个负例。

执行过程：Agent每次改动应关联任务目标和验证结果。限制并行工作范围，避免两个Agent同时修改同一核心文件。出现失败时，先保留首次失败的输出，再让Agent修复，防止最终通过结果掩盖中间发生过的破坏。测试人员不需要逐行复述所有代码，但要能追问改动影响了哪些状态、外部调用和异常路径。

验收对照：不只看平均耗时。记录人类审查时间、无效改动、遗漏的业务条件、测试有效性、回滚难度、Agent重试次数和新增工具风险。速度变快但审查负担翻倍，可能只是把瓶颈从编码转移到了验收；生成了更多测试但反例变少，也不等于覆盖更好。

这张表是本文建议的试验记录模板，不是OpenAI公布的内部指标。把每个判断对应到一条证据，试验复盘才有机会区分真正提效与把工作量转移到验收端。

结束条件：出现未授权写操作、无法解释的测试删除、测试仅通过修改断言实现、关键状态不可观测、重复副作用无法控制时，立即停止并回滚。试验成果可以是失败模式清单，不必强行宣布Agent-first成功。

角色变化不是“少写代码”，而是把边界和证据设计清楚

OpenAI原文没有提出一个新的职称。它提供的是一次特定团队实践：随着Agent承担更多实现工作，工程师把更多精力放在设计环境、拆分目标、设定可执行约束和构建反馈机制。对测试工程师而言，可迁移的变化不是换一个头衔，而是更早参与验收标准、独立证据和风险边界的设计。

这里也有反方边界。Agent持续依赖模型能力、上下文窗口、工具生态、权限治理和组织流程；对于复杂需求、隐性业务规则、物理设备、法规责任等场景，人类判断仍然关键。某个内部项目的效率数据不等同于外部团队可复现结果。即便实现成本下降，产品方向错误、权限过宽、质量证据不足和运维责任缺位，造成的损失也不会自动变小。

未来6—18个月，测试团队可以观察几类可验证信号：Agent改动是否能稳定通过独立验收；跨仓库任务是否更少依赖人工补上下文；测试缺陷是否因同源生成而增多；审查时间是否随代码产量同步上升；工具调用是否具有可审计、可撤销和最小权限控制；生产问题是否能从Trace还原到具体动作。这些信号比“团队说效率提高了”更能说明研发方式是否真的改变。

测试工程师的具体行动

先把你负责的一条业务流程写成四列：目标、允许动作、禁止动作、结果证据。再选一个Agent可以安全执行的子任务，让它在隔离环境里跑，记录每一步工具调用。最后，单独设计一条“实现和自测都可能一起错”的反例，用来检查验收是否独立。这个练习不要求先学会训练模型，却能让你看清Agent到底替代了什么、扩大了什么风险，以及团队还缺哪种质量证据。

OpenAI这篇文章值得测试工程师读，不是因为它证明所有公司都应照搬，而是因为它把研发工作的稀缺资源说得很具体：人的时间和注意力。当编码动作变得更容易，选择做什么、如何验证、何时停止反而变成更重要的工程判断。测试不一定消失，但只检查“功能有没有跑”可能不够；能定义验收边界并证明结果可信的人，会更接近研发决策的中心。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。