核对两份 7 月订单表，并解释 170 元差异

170 元不难算，难的是这 170 元叫什么

两份 7 月订单表都能重算，总额却差 170 元。系统 A 把退款记在原订单日，系统 B 记在退款发生日。公式都对，口径不同。

表格差异经常披着算术问题的外衣。

对账首先是语义审计，然后才是计算。 这节课会先对齐主键、日期、单位和退款规则，再生成逐行差异与守恒检查。

表格对账最难的通常不是公式

两张表总额不同，可能来自：

• 一个按订单，一个按支付流水；
• 日期范围或时区不同；
• 含税/未税、元/分或币种不同；
• 退款记在不同日期；
• 重复行、空主键、前导零；
• 四舍五入和允许容差。

直接说“找出差异”会诱导模型按相似列合并。你要先确认两张表是否可比。

第一步：保存只读起点

reconciliation-lab/
  source-readonly/
    system-a.csv
    system-b.csv
  rules/
    reconciliation-policy.md
  output/

两份 CSV 是虚构数据，不含真实客户信息。真实任务只读取完成对账所需列，个人、薪酬、银行和客户数据必须遵守组织政策。

第二步：分别做数据剖面，不直接 join

只读剖面 system-a.csv 与 system-b.csv。
分别报告：
- 行数、列数、列名；
- 日期范围和时区；
- 主键空值、重复和格式；
- 金额单位、小数位、正负号；
- 状态分布；
- 无法解析值。

不要合并，不修改，不解释根因。

预期

你应发现：

• system-a 以 order_id 一行一订单；
• system-b 可能同一 order_id 多行，因为付款和退款是流水；
• system-b 有一条重复 transaction_id；
• 两表退款符号和记录时间需要按 policy 解释。

若 Codex 直接按 order_id 一对一合并，先停下，恢复剖面阶段。

第三步：阅读数据字典与正式口径

reconciliation-policy.md 定义：

• 以 order_id 为业务关联键；
• system-b 先按唯一 transaction_id 去重，再按 order_id 汇总；
• 金额单位均为元；
• 退款在发生月份计入负数；
• 绝对差 <= 0.01 元视为容差内；
• 日期以 Asia/Shanghai 解释。

这些是本练习口径，不是 Codex 可以自行改变的建议。任何例外进入待确认。

第四步：先输出匹配计划

生成 output/match-plan.md，说明：
1. A/B 各自的唯一行定义；
2. B 去重键与重复处理；
3. order_id 标准化规则；
4. 退款和日期口径；
5. 差异分类；
6. 哪些情况禁止自动匹配。

在我确认计划前不要生成最终差异表。

禁止用姓名、电话、模糊文本自动匹配。没有共同主键时应暂停，而不是用“看起来像同一客户”补齐。

第五步：生成逐行差异

确认计划后：

输出 output/differences.csv，字段：
order_id,a_amount,b_amount,difference,category,
a_source_line,b_source_lines,rule,needs_confirmation

category 只能是：
matched, a_only, b_only, amount_mismatch,
duplicate_pending, date_or_status_mismatch, within_tolerance, unmatchable

同时生成 output/summary.md，但汇总不能替代明细。

检查点 1

每条 amount_mismatch 必须同时保留 A/B 原值和来源行。总差异 170 元应能由 differences.csv 中非容差项逐行相加得到。

如果 summary 说 170，但明细相加不是 170，摘要无效；不要手改摘要数字。

第六步：做行数与金额守恒

行数：

A 总订单数 = matched + a_only + amount_mismatch + 其他互斥 A 分类
B 唯一流水汇总后的订单数 = matched + b_only + amount_mismatch + 其他互斥 B 分类

金额：

A 总额 - B 去重及退款处理后总额
= 各 order_id difference 之和
= 170.00

分类必须互斥，否则一条订单被重复计入。duplicate_pending 单独报告，不在确认处理前混入正式汇总。

第七步：把事实与解释分开

summary.md 分四层：

已观察事实：具体订单、原值、差值、来源行
可能解释：退款时间、状态延迟、重复导出
需要确认：财务/业务系统负责人需要回答什么
建议动作：补数据、修规则或确认容差

“可能是退款延迟”不能写成根因，除非有系统记录或负责人确认。

第八步：故障与恢复

前导零 order_id 被转成数字

现象：A 的 00107 与 B 的 107 被误合并或丢失。恢复原字符串，按 policy 明确是否允许标准化；没有规则就标 unmatchable。

重复流水被直接删除

保留重复原行与 duplicate_pending，依据 transaction_id 和来源行说明。只有规则确认后才能排除汇总。

退款符号反了

回到 policy 检查负数约定，重新计算受影响 order_id 和总额；保留修正前后的差异记录。

第九步：迁移练习

新规则：容差从 0.01 调整到 1.00，但只对汇率换算订单适用。你要增加订单类型条件，不能全局放宽。

提示：

1. 先识别哪些行有 currency_conversion=true；
2. 其他订单仍使用 0.01；
3. 更新 match-plan 和分类规则；
4. 重新计算汇总并说明变化。

完成后用 rubric 核对，再看参考答案。

下一次先写字段字典，再写公式

找两张小表，为主键、日期、金额和状态各写一句业务定义。双方确认以后再合并。

只要口径仍有歧义，就把结果标成待确认。数字精确到小数点后两位，也不能弥补定义不一致。

完成检查

• 两表分别剖面后才匹配
• 主键、日期、单位、退款和容差来自 policy
• 每条差异保留两边原值与来源
• 行数分类和 170 元金额差都守恒
• 重复与无法匹配记录没有被隐藏
• 事实、解释和待确认责任人分开