怎样保证 AI 开发后的验收效率？

核心回答

我会把验收组织成四步：先写可检查条件，按影响范围选检查，自动执行并保留证据，人工集中判断业务与高风险改动。开发前就明确输入、预期行为、异常和完成标准，让 AI 知道怎样检查；完成后用相关测试、静态检查和实际操作验证，避免到最后才由人重新猜需求、逐项寻找遗漏。

验收效率要在满足质量要求的前提下，看总耗时、人工往返和返工。局部改动先做针对性检查，公共接口、权限或数据结构变化则扩大回归；已经取得的有效结果可复用，但要核对代码、测试、依赖和配置版本。结论写清通过了什么、依据在哪里、哪些尚未覆盖。

先把需求变成独立的验收条件

把每项要求对应到检查方法和预期结果。预期应来自需求、接口约定或独立业务样例，不能直接照着 AI 当前的实现生成答案，否则代码与测试可能一起误解需求。

例如给文章列表增加已有的“发布时间”列，可以先列出：默认在“更新时间”之前、数值来自已有字段、排序能改变结果、列显隐能恢复。检查时核对实际数据和交互，而不只确认页面出现了文字。低风险修改可在任务说明中列几条；涉及权限或金额的规则，则需要更明确的反例与业务状态断言。

AI 可以生成候选用例、准备数据和整理日志；确定性结果用程序比较，开放式表达用明确准则辅助判断，业务取舍和高影响问题由人重点核对。

按风险和依赖安排检查

先沿改动涉及的入口、调用方和数据流确认影响面，再选择检查：

变更情况	优先检查	扩大范围的条件
局部显示或文案	对应页面、真实数据、相关交互	影响共享组件、布局或其他入口
函数、接口或业务分支	原问题复现、正常与异常分支、调用方、类型与静态检查	改了公共约定、依赖或跨模块行为
权限、资金、迁移等高影响变更	越界与边界条件、持久化结果、失败恢复和集成验证	按具体风险安排更广回归与人工审阅

仓库规定的必需检查仍要执行。相互独立且不会争用数据、端口或其他资源的检查可以并行；共享状态的用例要隔离或有序执行。针对性检查失败、出现新改动或影响范围仍不确定时，再补相应验证。

先分清失败，再决定修复或重跑

检查要保存运行命令、退出码、标准输出与错误输出，并关联当前代码和测试输入。

断言失败，先对照预期、实际值和改动定位缺陷；浏览器未启动、依赖缺失或服务不可达时，先查环境与准备阶段。环境问题也可能由补丁引起，不能一律归为外部故障。尚未执行到断言，只能记为阻塞或未完成；命令正常退出，也要确认用例确实执行，且报告对应本次代码。

遇到偶发失败，先保留现场、检查是否能在相同条件下重现，再做有依据的重试。反复重跑到一次变绿，会掩盖不稳定性，也增加等待成本。

复用环境和产物时，检查结果是否仍适用

依赖下载、构建环境和可重置的测试数据可以缓存，减少重复准备。测试结果的复用则要核对当前代码或补丁、测试与断言、数据、依赖和配置；相关条件变化后，重新运行受影响检查。只要与当前改动无关、输入仍有效，就不必为取得相同证据盲目重复执行。

SWE-bench 的评测指南给过一个具体例子：结果按 run_id 和 instance_id 缓存，换了预测补丁却沿用这两个标识，可能仍复用旧结果，需要新的运行标识。这是该工具的缓存语义；自己的流水线也要检查缓存键与失效条件，不能把旧报告直接当成新补丁已通过。

交付时提供简短的验收记录：改动范围、验收项、代码版本或补丁标识、命令与原始输出位置、通过与失败项、未执行范围及原因。人工可以据此重点检查业务行为与高风险差异，减少反复全量阅读和重新搭环境。

可能的追问

测试本身很慢怎么办？

先分段计时，判断慢在依赖准备、构建、环境启动还是用例执行。分别考虑复用有效环境、增量构建、隔离后并行、按影响选择用例；必要的全量回归放在约定的集成或发布阶段。优化前后同时观察耗时和漏检、返工，确认等待减少时验收质量仍满足要求。

让另一个 AI 审查，就算独立验收了吗？

独立会话有助于减少对实现过程的先入判断，但仍可能共享同一误解。审查要拿需求与接口约定作依据，并回查代码、运行测试或核对业务状态；模型之间一致赞同不能代替这些证据。

怎样判断效率确实提高了？

比较相近任务的验收总时长、人工审阅时间、往返次数、无效重跑、返工及交付后缺陷，并记录变更规模与风险。单看测试数量减少或首次变绿更快，无法说明整个交付过程改善。

对应教程

参考资料