让 AI 核对运费表，找出哪些单子是在亏钱发

先讲结论：先对口径，再算钱

前面几件活都是拿一份数据自己跟自己比：标题够不够长、库存够卖几天、毛利是正是负。

这件不一样。运费核对要拿两份来源不同的资料对照：你设的运费规则，和实际发出去的订单。

而两份来源不同的资料放一起，最常见的问题不是算错，是口径对不上，而且不报错。

报告照样跑得出来，数字照样规整，只是结论是错的。

所以这一层要多做一个动作：先确认两份资料能对上，再让它算。

这件活原来怎么做

还是那家虚构的四人宠物用品团队，数据是编的。

老板看对账单的时候发现一件事：某个月的物流支出比预想的高出一截，但订单量没涨多少。

问题出在哪不知道。运费规则是半年前设的，当时按商品重量分了几个段，每段一个价。之后上了新品、换了包材、开了几个新的配送区域，规则一直没动过。

没人核对过实际发出去的包裹落在哪些段、每一单是赚是亏。

这件活人工做的问题不是难，是要把运费规则、订单、实际物流账单三份东西对着看，一单一单算。几千单没人愿意做。

第一次：报告很漂亮，结论是错的

小李把运费规则、订单导出、物流账单都放进目录，让 AI 算每个重量段的收支。

报告出来了，格式清楚：三个重量段亏钱，最严重的一段平均每单亏 12 块。

老板拿着这个数去看了几个具体订单，发现对不上——报告说亏的那几单，实际是赚的。

原因是两份资料说的「重量」不是一回事：

• 运费规则按的是商品重量，也就是商品本身多重
• 物流账单按的是包裹实重，含包材，而且多件订单是合并成一个包裹的

一个 800 克的商品，加上包材可能是 950 克，跨到了下一个重量段；两件 800 克的商品合并发货是 1.7 公斤，又是另一个段。

AI 拿商品重量去匹配运费段，算出来的是「理论上应该收多少运费」，而账单上是「实际付了多少」。两个数放一起比，比的是两件不同的事。

这个错误最麻烦的地方是它不报错。两份表都有「重量」这一列，都是数字，合起来算得通。你不专门去核，看不出来。

修法：先让它核对口径

修正方法不是改算法，是在算之前加一步。

在说明书里写：

开始计算之前，先核对两份资料能不能对上：

• 各自的「重量」指的是什么，单位是什么
• 能不能按订单号一一对应，有多少对不上
• 两边的订单数量差多少

先把这些写在报告最前面，等我确认口径没问题，再算钱。

加上这一步之后，第二次跑出来的报告开头是这样的：

运费规则里的重量字段是商品重量（克），物流账单里是包裹实重（克），两者不是同一个口径。 订单导出里有 4,218 单，物流账单里有 4,196 单，22 单在账单中找不到。 建议先确认是否用包裹实重重新匹配运费段。

这就是对的形态。它没有硬算，而是先把不一致摆出来。

这一步值得作为一条通用做法记下来：只要一次要用两份以上来源不同的资料，就先让它核对口径，再让它算。

多花的这一步大概三十秒，省掉的是一份看起来正常、实际错误的报告。

第二次：还有 22 单对不上

口径的问题解决了，但那 22 单对不上的还在。

小李本来想让 AI 直接跳过，后来觉得不对，去查了一下——是退款后重新发货的订单，账单上有、订单导出里没有（因为导出的时候筛了状态）。

这 22 单本身金额不大，但它暴露的是导出条件的问题。如果不查，以后每次核对都会少这批。

所以说明书里加了一条：

对不上的订单单独列出来，不要跳过，也不要估算。列出订单号和差异原因的线索（比如只在一边出现）。

「对不上的不许跳过」这条很重要。默认情况下模型倾向于把干扰项排除掉好让结果干净，但那些排除掉的往往正是值得看的东西。

结果：两个亏钱的段

口径对齐、异常单单列之后，结论变了：

• 1.5 到 2 公斤这一段在亏，平均每单亏 8.4 元，这个月一共 312 单，亏了 2,600 多
• 超过 5 公斤的大件段也在亏，单量不大只有 47 单，但平均每单亏 34 元
• 其余段都是正的，其中 0.5 公斤以下那段利润率最高

亏的原因也不一样：

• 1.5 到 2 公斤那段是包材变了——换了更厚的防撞包装，平均加了 120 克，一批订单跨到了下一段
• 大件段是运费规则压根没覆盖，超过 5 公斤走的是默认价，而实际物流费按重量线性涨

第二个是典型的「规则没跟上业务」：设规则的时候还没有大件商品，后来上了，没人回头改运费表。

但改不改运费，是人定的

和前面几篇一样，这一层的产出是清单，不是动作。

为什么改运费这件事不能自动：

• 涨运费会影响转化，亏的那个段可能正是你的走量段，涨价之后单量掉了更不划算
• 有些段是故意亏的，比如小件包邮是为了拉新
• 改法有好几种：涨运费、改包材、调重量段分界、或者干脆改商品包装规格
• 运费规则改了立刻对所有访客生效，撤不回来

所以报告只说「这个段在亏多少」，怎么办由人决定。

这件活的背景——运费到底该怎么配、不同市场的差别在哪——美国、日本、欧盟、澳洲四篇分别写过，可以对照着看。

跟着做：核对运费表

不要求懂编程。前提是你已经按第一篇装好了工具。

第 1 步：建工作台

mkdir -p ~/shipping-check/data ~/shipping-check/reports && cd ~/shipping-check

第 2 步：准备三份资料

第一份多半要自己整理。后台的运费设置一般导不出来，手抄一遍就行，一次性的活。

导订单的时候别筛状态，或者至少记下自己筛了什么——上面那 22 单就是这么漏的。

第 3 步：写说明书

# 运费核对说明

## 资料在哪

data 文件夹里有三份：运费规则、订单导出、物流账单。

## 先核对口径，再算钱

开始计算之前，先检查并报告这几件事：

- 三份资料里的「重量」各指什么，单位是什么
- 能不能按订单号一一对应，各有多少条对不上
- 三份资料的订单数分别是多少

把这些写在报告最前面。口径不一致的时候，明确说出来，不要自行换算后继续算。

## 怎么算

- 每单毛利差 = 实收运费 − 实付运费
- 按重量段分组，算每段的：单量、平均毛利差、总毛利差
- 用物流账单的包裹实重来分段，不要用商品重量
- 计算要用程序算，不要估算

## 对不上的怎么办

- 单独列出来，不要跳过，不要估算
- 写清楚是只在哪一边出现
- 如果对不上的超过总量的 5%，在报告开头明确提醒我

## 报告写成什么样

在 reports 文件夹生成报告，按这个顺序：

1. 口径核对结果
2. 对不上的订单清单
3. 各重量段收支：按总亏损金额从大到小
4. 亏损最严重的那几段，各挑 3 个订单举例，写清楚这一单收了多少、付了多少

## 不许做的事

- 不许改 data 里的原始文件
- 不许直接改后台的运费设置
- 不给「应该涨到多少」的建议，只说现状
- 口径对不上时，不要自行猜测换算关系

最后那条是这件活特有的。如果不写，它很可能会「贴心地」帮你把商品重量加个估计的包材重量换算过去——那个估计值是编的，而结论看起来完全正常。

第 4 步：跑，先看第一段

进工作台启动工具，说：

按说明书核对运费，生成报告。

跑完先看报告第一段的口径核对结果，别急着看哪个段亏钱。

口径对不上，后面全部作废。这和前面几篇「先看缺什么」是同一个道理。

第 5 步：验收

挑三单手工核。从报告说亏得最多的那段里挑三单，自己看订单和账单，算一遍收了多少付了多少。这三单对上了，整段的结论就可信。

核对不上的那些。随便挑两个，去两份资料里确认确实只在一边出现，而不是订单号格式不同导致匹配失败（比如一边带前缀一边不带）。

核总数。三份资料的订单总数和你后台看到的对不对得上。

第二件经常出问题——订单号格式不一致是最常见的「对不上」原因，而它看起来像是真的缺数据。

之后怎么用

建议每月跑一次，跟着对账走。

另外这几个时机要额外跑一次：换包材之后、上了新的重量段商品之后、开了新配送区域之后、物流商调价之后。

这四件事都会让原来的运费表失效，而且都不会有人提醒你。

常见卡壳

回到那个比喻

第一条是这一层新增的动作。前面几件活只用一份资料，这件开始用多份，而多份资料的第一个问题永远是口径。

你手上那件活，能不能交出去

这个系列后面的选题，一部分会直接来自读者的实际问题。

如果你手上有一件活拿不准该不该交给 AI，把这三件事发过来就够：

• 这件活是什么：多久做一次，一次大概花多久
• 你是按什么规则做的：判断标准能不能说清楚
• 做完怎么验：有没有办法看出它做对了没有

这三件事正好就是判断能不能交出去的三个条件，你写的过程中多半自己就有答案了。

我会挑典型的写成文章——判断它属于哪一层、该怎么交、哪一步必须你自己来。涉及店铺的具体信息一律脱敏，不会出现店名和真实数字。

联系方式在关于页面。

下一篇

这一篇的活是「算清楚现状」。下一篇的活性质不同：盯住美国各州的销售税门槛——它不是算一次就完了，而是要持续盯着，因为越过门槛之后你有登记义务，而没人会通知你。

参考资料

• Claude Code Overview
• Codex CLI