让编程代理动手前，先写清验收条件

给编程代理一句「给报表页加 CSV 导出」，它可能直接开写，也会替你决定那些没说清的行为。dev.to 的一位作者分享了自己的做法：代码生成前，先和代理约定一份编号验收清单，把过滤规则、导出字段和必须保留的功能提前定下来。

目前能确认什么

作者把清单叫作「Done means」：每一项都应是能在运行中的程序上检查的结果，而不是「导出正常」这样的笼统描述。

节选里的 CSV 示例包括：按当前筛选条件和排序导出，字段及表头与可见表格一致，导出 50,000 行时页面保持响应，已有 PDF 导出继续工作。这里的 50,000 行是示例验收要求，不是工具的性能实测。

作者会借助 Claude Code 的 plan mode 或 Codex 的 /plan，让代理先读相关代码，再提出最多六个影响行为的问题，并给出推荐答案。人确认后，代理才整理验收清单。

开发完成后，作者另开一个没有参与编写的新会话，逐项运行程序或测试，提交命令输出、截图或文件作为证据；无法检查的项目要明确留下。检查已有功能是否受影响，属于回归验证，也是清单的一部分。

我的判断

这套做法最有价值的地方，是把产品决策从 diff 里提前拿出来。

对程序员来说，审查「导出是否遵守筛选条件」和审查「代码是否正确实现筛选条件」是两件事。先定行为，后看实现，能减少代码写完才发现需求理解不同的返工。

但清单的质量仍取决于人的判断。代理给出的推荐答案可能让确认更快，也可能让人顺手接受未经思考的默认值。

新会话检查可以提供另一轮核验，却不能保证发现所有问题。节选没有给出效果对照数据；「页面保持响应」也缺少明确判定尺度。真正落地时，这类条目还需要补上检查方法，否则验收时仍会产生分歧。