一项固定价格的图片服务原来能覆盖成本，上游改价后，收入看起来没变，月底却开始亏钱。调用数量没有明显增加，变化可能藏在更贵的模型、重复尝试或人工补图里。
先从上游账单和订单表核算就能发现很多问题。订单不多时，按月人工对账比做实时成本面板更合适。需要跨多个提供方持续处理时，再把调用和费用关联到每张订单。
EasyNet 的调用标识可以帮助定位这张单经过了哪些处理，提供方再记录实际模型、使用量和上游任务关联。订单服务读取这些获准记录，不必收集完整客户素材来计算成本。
价格需要保留生效时间和计费单位，历史订单不能套用今天的单价。失败尝试、存储和人工修改也要按约定计入；上游尚未给出的费用应标成估算或待确认，而不是算作零。
还要由业务负责人定义何时暂停接受新订单、何时调整报价，以及已有订单怎样履约。成本上升可以促使改变未来定价，不能自动向已付款用户补扣差额；利润口径也应由合作方共同确认。
挑一张成功订单和一张多次重试的订单，逐项对照上游账单，再用改价前后的同类订单比较。能解释差额具体来自哪里，才有依据决定换方法、调价格还是停止某项服务。
- 01
固定价格订单
收款事实来自支付记录
- 02
关联全部尝试
成功、失败和上游任务号一起留存
- 03
账单核对差额
缺账标未知，不自动向旧订单补扣
同样三次尝试，改价前后分别算一遍
示例金额均为虚构的分单位已结算费用，不查询实时价格。上游未出账时先停止计算，避免显示虚假的盈利。
本地示例 · python
orders = [
{"period": "before", "paid_cents": 500, "attempt_costs": [100, 100, 100]},
{"period": "after", "paid_cents": 500, "attempt_costs": [200, 200, 200]},
]
# Each fictional order includes two failed attempts and one successful attempt.
for order in orders:
costs = order["attempt_costs"]
if any(cost is None for cost in costs):
raise ValueError("Cost is pending; reconcile the upstream invoice")
margin = order["paid_cents"] - sum(costs)
print(order["period"], "margin_cents=", margin)
if margin < 0:
print("review_new_orders")预期结果：同样收入和尝试次数，改价前输出 before margin_cents= 200，改价后输出 after margin_cents= -100，并提示 review_new_orders。任一费用为 None 时要求对账，不当成零。
接入时的检查项
- 代表性订单能从收入追到各项实际费用，失败重试没有被漏算。
- 价格变化按生效时间应用，不用当前价格回算所有历史订单。
- 账单缺失和估算误差可见，预警不会被表面上正常的调用成功率掩盖。