本文整理自 2026 年 9 月 20 日的 OnBalls 本地研究。2026 年 10 月 15 日仅做网站文字与链接适配，没有复测，也没有把历史样本更新为当前全库。
让 AI 写一个小工具，最容易漏掉的工作是提前约定：出现什么结果，才算做完。
“帮我整理收藏，去重后生成专题目录”听起来很明确。但重复指相同链接，还是相同内容？坏数据要跳过还是停止？运行到一半退出，下次重跑能不能接着来？这些问题不写出来，生成的程序就会替你作决定。
下一次开始编程前，先花几分钟写验收单。它应该让不参与开发的人，也能检查结果。
验收从最终结果开始
Anthropic 的 Agent 评估文章把一次任务的输入和成功条件放在一起定义，并区分运行过程与环境中的最终结果。这个区分适合借到日常编程：AI 的完成说明属于过程记录，文件、数据和实际行为才是要验收的对象。评估方法原文
以收藏清洗为例，“成功输出一个文件”还不够。文件要保留原始链接，遇到不完整记录时要有可见提示，同一份输入重复运行不应偷偷增加记录。需求越具体，测试越容易暴露问题所在。
可以先写这五条：
- 正常输入得到什么内容，哪些字段必须保留？
- 缺字段、空文本、格式错误分别如何处理？
- 出现相同编号但内容不同的记录，要报告还是覆盖？
- 中断或失败后，已有文件与数据会发生什么？
- 别人拿到交付物，怎样安装、运行、复查和撤回？
它们是供当前任务选择的检查项，不是所有软件通用的完整标准。比如一个临时计算脚本，与需要多人长期使用的工具，就不应该使用完全相同的交付要求。
做三个能看出区别的小样本
第一组放正常数据，让最基本的路径跑通。第二组放坏数据，每次只改一个条件：去掉编号、把文本换成空值，或让一条记录的类型不符合约定。第三组检查重复与恢复：相同输入运行两次，再模拟一次中断。
每个样本都提前写预期结果。否则程序报错后，我们可能临时把“没有崩溃”解释为合格，也可能把合理拒绝解释为失败。
2026 年 9 月 20 日这轮研究对既有收藏摄入脚本注入了七种异常：四种导致进程报错；另外三种——负数点赞、非日期字符串、同 ID 正文冲突——被接受，却没有对应这些异常的专用状态。这些坏输入是为测试构造的，不表示原收藏库有这些问题。它说明验收还应检查程序如何报告异常。（依据：2026 年 9 月 20 日本地研究记录；实验范围见文末说明。）
以下是一个示例约定，使用前需要按自己的任务修改：
| 输入 | 期望行为 |
|---|---|
| 有编号、有正文的记录 | 保留链接并生成结果 |
| 没有编号的记录 | 报告该记录，避免默默丢弃 |
| 同编号、相同正文 | 按约定去重，并留下数量记录 |
| 同编号、不同正文 | 标出冲突，等待处理规则 |
| 输出前退出 | 不把不完整结果当成最终文件 |
遇到失败后，让 AI 先解释是哪一条约定没有满足，再修改代码。这样下一轮讨论围绕一个可复现的问题展开，既能看清修复，也能避免顺手改动无关部分。
交付时，把证据一起留下
交付文件夹可以很小：运行说明、输入样本、实际结果、已知问题，以及必要的恢复步骤。涉及代码变更时，再附上变更差异，让接手的人知道哪里改过。
GitHub 对 Copilot cloud agent 的介绍把分支上的修改、拉取请求和人的审查放在同一工作流程中。这能说明审查在交付中的位置，不能推导出某次生成必然可靠。官方工作流程
我们也要区分两种结论：“这五个样本满足了约定”，与“这个工具在所有真实场景都可靠”。前者可以由小测试支持；后者还需要更广的环境、数据和维护证据。
今天就可以把下一项需求中的“做好”“可用”“自动整理”，改写成五条可检查的结果。AI 再说“完成”时，你手里会有一份能对照的约定。
研究范围与使用说明
七种异常是为诊断构造的夹具，并不表示真实收藏存在同样错误；本轮没有宣称修复既有脚本，也没有新增跨平台实测。原始夹具与内部附件不随网页提供。 外部文档只用于支持当时的概念说明；产品界面、功能和政策发生变化时，应回到官方页面核对。