“帮我清理这份表格”容易得到一个看似合理、实际不符合业务要求的结果。问题通常不在提示词不够长，而在关键决策没有写出来：什么叫重复？空值怎么办？谁可以删除数据？
本文使用虚构客户表演示，不涉及真实个人信息。目标是让你在开始一次 AI 任务前，用五分钟写出可检查的交付约定。
把动词变成具体结果
假设 CSV 有三行：
| row_id | name | |
|---|---|---|
| 1 | Alice@example.test | Alice |
| 2 | alice@example.test | Alicia |
| 3 | 空值 | Bob |
“按邮箱去重”至少有三处歧义：是否区分大小写、保留第一条还是最后一条、空邮箱是否算重复。
本例约定：去除邮箱两侧空格并转为小写后比较；重复项保留原文件中第一行；空邮箱保留并标记为待人工检查。这个大小写规则是本练习的业务选择，不是所有邮箱系统都应采用的通用规则。
交付物也要具体：生成新 CSV、重复记录清单、处理摘要；原始文件只读。摘要至少报告输入数、输出数、重复数和空邮箱数。
一份可以直接改的任务模板
目标：按以下业务规则整理客户 CSV，输出可复查结果。
输入：fixtures/customers.csv；编码 UTF-8。
规则：
1. email 去除两侧空格并转为小写，作为比较键。
2. 比较键重复时保留第一行，其他行进入 duplicates.csv。
3. 空 email 不参与去重，保留并计入待检查数量。
4. 不改变 name 字段，不推断或补全任何个人信息。
交付：
- cleaned.csv、duplicates.csv、summary.json。
- 实现代码及可重复运行的检查命令。
限制：输入文件只读；不上传文件，不安装新依赖。
验收：下面的样例全部通过，重复运行输出一致。
不确定时：指出会影响输出的歧义；不要自行编造字段值。
模板中的“限制”应该来自实际工作需要。对公开示例，没有必要加入与任务无关的几十条规则；对公司资料，则要明确允许读取的路径与数据处理环境。
用反例补全验收
仅测试正常数据容易掩盖错误。把以下六类输入放进样例文件：
| 输入情况 | 期望结果 |
|---|---|
| 同一邮箱大小写不同 | 按本例规则合并 |
| 邮箱前后有空格 | 去空格后比较 |
| 两条不同姓名、相同邮箱 | 保留第一条，另一条进重复清单 |
| 两条空邮箱 | 两条都保留 |
| 姓名包含逗号 | 用 CSV 解析器正确读取 |
| 空文件或缺少 email 列 | 给出明确错误，不生成误导性成功结果 |
其中“两个空值不合并”能快速区分实现是否真正理解了规则。文件数量没有变少，并不代表程序没工作；可能恰好没有重复项。
验收时看证据，不只看回复
检查原始文件摘要或 Git diff，确认输入未被修改；重新运行脚本，确认输出一致。用以下等式做第一层核对：
输入行数 = 输出行数 + 重复清单行数
待检查的空邮箱行数 <= 输出行数
等式成立仍不能证明业务逻辑正确，还需要逐项检查上面的反例。AI 回复“测试通过”时，应同时给出执行命令、实际结果和未验证项目。没有运行环境时，应该把“建议测试”与“已执行测试”分开。
什么时候先用固定流程
文件整理、格式转换等步骤明确的任务，通常可以先拆成“解析 → 校验 → 处理 → 导出”。Anthropic 的官方文章区分了预定义工作流与由模型动态决定步骤的 Agent；这种区分有助于避免为简单任务引入过多自主决策。
参考：Building effective agents，核验日期：2026-09-07。本文的 CSV 规则和任务模板为本站教学示例，不是该来源的实验结论。
动手练习
把模板改成“按订单号整理发票清单”。额外回答三个问题：同一订单出现不同金额怎么办？缺少订单号怎么办？保留规则能否追溯到原始行号？写出这三个答案，再让 AI 开始实现。
下一步：用固定评测集检查 AI 输出。