交接单不该由一个人从头写到尾，而是谁产出、谁填自己那一段：方案侧填“计划口径与单位约定”，工具侧在返回结果时回填“实际调用参数、返回文件、数据版本”，人工定稿侧只做核对、判定和签收。常见的错误是让智能体把整张单子写全，包括它根本没执行过的跑数结果，于是数值一旦对不上，就分不清是模型编的，还是工具返回没被接住。建议把交接单拆成三段，每段只允许对应的执行者写入，冲突时以工具返回和数据版本为准。
交接单按“谁产出谁填、谁消费谁签收”分栏写，比指定一个统一作者更稳。方案侧写计划值、单位与量纲约定；工具侧回填实际参数、返回文件与数据版本；人工只在复核表上记录判定和不通过处理。适用场景是智能体出方案、外部脚本跑数、人工定稿的链路；验证方式是同一任务改格式前后各跑一次，比对返工次数与对不上的字段位置；边界是数据版本追溯依赖工具侧确实带了版本标识，工具不返回时需在调用参数里显式传入。
把方案里每一步标上执行者和产出物
先不要急着定谁写单子，而是把链路里的每一步摊开。分工可视化之后，“谁写”就变成“谁产出、谁签收”的自然结果。下面这张表建议直接放进方案文档开头，替换项是具体脚本名和输出路径，其他列保持稳定。
| 步骤 | 执行者 | 产出物 | 下游依赖 |
|---|---|---|---|
| 指标口径与筛选条件 | 出方案的人或智能体 | 口径说明、时间范围、过滤条件 | 跑数脚本按同一条件写查询，不得自行放宽 |
| 确定数据源与分区 | 跑数执行者 | 表名、分区或快照标识 | 后续所有数值都必须能指回这个分区 |
| 调用外部工具跑数 | 脚本或工具调用层 | 原始返回文件、调用参数、时间戳 | 汇总环节只读返回文件，不改写数值 |
| 汇总成结论 | 方案撰写方 | 结论句、引用数值、对应字段名 | 复核环节逐条比对引用数值与返回文件 |
| 复核与定稿 | 人工复核者 | 复核表、签收记录、返工说明 | 定稿版本以复核表为准，方案原文不再回改数值 |
这张表的一个直接作用是：跑数结果永远不由智能体代填。模型不知道脚本真实读了哪个分区，让它补写只会把断点掩盖掉。
在交接处强制写明单位、量纲和数据版本
数值对不上，通常不是算错，而是单位、量纲、数据版本在交接处丢了。金额写“元”还是“万元”，人数是“人”还是“人次”，库存是“件”还是“箱”，某个指标是按日快照还是按月累计，这些在自然语言方案里很容易被省略，进了工具就变成默认值。建议在每次工具返回时生成一张交接单，字段固定，缺一项就算未完成。
{
"task_id": "order_gmv_2024q1",
"input_files": ["src/orders.parquet"],
"unit": "CNY",
"dimension": "元/单",
"data_version": "orders@partition=2024-03-31",
"generated_at": "2024-04-01T10:12:33+08:00",
"call_params": {"date_from": "2024-01-01", "date_to": "2024-03-31"},
"output_files": ["out/gmv_q1.csv"],
"row_count": null
}字段说明只保留必要项：输入文件指实际读取的源文件或表；单位写币种或计数单位；量纲写“每单、每人、每月”这类比值基础；数据版本写分区、快照日期或提交号；生成时间用于判断两次结果是否同一批次。row_count 等计数由脚本写入，不要手填。若工具本身不返回版本标识，就先在 call_params 里显式传入，再在单子上记录，这一条需要在具体环境里确认工具是否支持。
从结论倒着回放到工具返回
发现数值对不上时，不建议从头顺着读方案，而是从结论往上倒查，四步走完基本能定位断点在模型侧还是工具侧。
- 最终结论：把结论句里的数值和它所在的那句话单独摘出来，确认这个数字在方案里只出现一次，避免多处引用互相污染。
- 引用数据：找到方案中标注的字段名和表名，比对结论里的数值与引用行的数值是否完全一致，包括小数位和四舍五入方式。
- 工具返回：打开 output_files 指向的返回文件，按同一筛选条件定位到那一行，比对数值、单位、量纲三项；不一致说明问题在汇总或转写环节。
- 调用参数：检查 call_params 的时间范围、过滤条件和 data_version 是否与方案口径一致；如果参数对而返回错，断点在工具侧；如果参数本身就和方案口径不同，断点在方案侧的口径传递。
四步里每一步都只做一件事：比对，不修改。改数值留到复核表登记之后，否则会丢失原始断点位置。
把人工复核点固定成一张表
复核如果只靠“看一眼”，结果会随人而变。建议把复核项写成表，每次定稿都跑同一套判定，不通过就按预设方式处理，而不是当场决定。
| 复核对象 | 判定标准 | 不通过时的处理方式 |
|---|---|---|
| 结论中的每个数值 | 能在 output_files 中定位到同值行 | 标记为待核，不允许直接改数，退回汇总环节 |
| 单位与量纲 | 与交接单 unit、dimension 字段一致 | 在方案中补写单位，并回填交接单 |
| 数据版本 | 能在 data_version 中追溯到分区或快照 | 要求重新跑数并补录版本，不接受口头说明 |
| 口径与筛选条件 | 方案口径与 call_params 完全对应 | 按方案口径改参数后重跑，保留旧返回文件对照 |
复核表由人工填写，但判定标准由方案侧和工具侧事先约定，写进交接单模板。这样换一个人复核，结论不会漂。
改完交接格式后重跑同一任务
格式改得对不对，不看文档写得多整齐，看同一任务再跑一次还剩多少返工。做法是选一个已经做过的任务，保留旧版交接记录，用新版交接单重跑，然后对比两组结果。
# 抽出两次交接单的关键字段做对比，字段缺失会直接显示在 diff 里
diff <(jq -S '{unit,dimension,data_version}' run_before.json) \
<(jq -S '{unit,dimension,data_version}' run_after.json)对比表建议只记三项：返工次数、数据对不上的字段位置、以及该位置属于模型侧还是工具侧。返工次数的口径要提前写死，例如“复核不通过后被退回汇总环节的轮次”算一次，避免各人统计标准不同。字段位置记到具体字段名（如 unit、date_to），不要只写“数值有问题”。
如果重跑后对不上的位置从“找不到来源”变成“单位写法不一致”，说明断点前移了，交接单起作用了，可以继续收紧单位取值枚举；如果返工仍然集中在同一字段，通常是该字段还没有在模板里强制必填，需要回到模板补字段，而不是继续在复核环节人工兜底。数据版本追溯在工具不返回标识的环境里无法完全自动化，这部分保留人工登记即可，不必强推。