五十块钱的旅程#

事情很简单：我在 Amazon 买了个五百多刀的东西，没拆封，价格降了 50 刀。找客服问有没有 price adjustment，回复干脆：“We don’t offer price adjustments. You can return it and rebuy at the new price.”

Amazon 官方帮助页面写得更干脆：we don’t offer price matching。理由是他们的价格”constantly changes to remain competitive”——价格天天变，所以不给你调。退货原因里甚至专门有一个选项叫 “Found a better price”。他们不做 price adjustment，但在退货理由的下拉菜单里替你准备好了它的替代方案。

Amazon 现行政策下唯一的正式价格保护只有两样：预购商品在发货前会自动按最低价收费；电视产品在收货后 7 天内降价可以联系客服退差价。其余所有商品，唯一的路径就是退了重买。

于是我退了重买。一个没拆封的包裹，从 Brooklyn 坐 UPS 到 Pennsylvania 的 Martins Creek 退货中心，单程大概 120 公里。然后 Amazon 再从仓库发一个一模一样的东西给我，再走一趟。两趟运费，两次分拣，两次包装。为了 50 块钱。

三百三十块钱的成本#

根据供应链研究者 Simone Peinkofer 在 The Conversation 发表的分析，退货的物流处理成本大约是商品价值的 66%。我退的这个东西五百多刀，66% 就是三百三十多刀。

三百三十刀。为了拒绝一笔 $50 的 price adjustment。

这个 $330 包括什么：UPS 从消费者手里取件运到退货中心的运费、退货中心工人拆包检查的人工、重新包装入库的操作成本。退货处理的时间是正向发货的两到三倍，因为每一件退货都需要人工检视、判断状态、决定去向——是重新上架、折价卖给 Amazon Warehouse、打包送去清仓拍卖，还是直接扔掉。

而且这还没完。退回去的商品即使完好无损，一旦进了退货流程就不再是”新品”了。Amazon 的 Grade and Resell 系统会把退货分级——New、Very Good、Good、Acceptable——然后以折扣价挂在 Amazon Warehouse 或 Renewed 频道。哪怕东西原封未动，只要走过一遍退货流程，重新上架时的标价就会低于原价。一个五百多刀的商品，二手折价就算只打九折，也是五十刀的价值蒸发。这个数字恰好等于当初那笔 price adjustment 的金额。

所以 Amazon 为了拒绝一笔 $50 的 price adjustment，选择了：花约$330 处理退货物流，承受退回商品的折价损失，再花一趟正向发货成本把新商品送过来。Price adjustment 的成本是什么？在数据库里改一个数字，退 $50。

把这个场景放到宏观数据里：美国每年退货约 35 亿件商品。到 2022 年，退货产生的废弃物约 95 亿磅——比 2019 年的 50 亿磅几乎翻了一倍。这 95 亿磅里有多少是因为”降价了，退了重买”？没人统计过。Amazon 提供了 “Found a better price” 这个退货理由选项，但没有公布过这个选项的使用比例。

这技术有多难#

有一种常见的解释：如果 Amazon 开了 price adjustment 的口子，所有人都会在价格波动时要求退差价。Amazon 的价格一天变动数百万次，如果每次降价都要处理 adjustment 请求，客服系统会被淹没。

2026 年了。

京东的”价保”是一个完全自动化的系统。京东自营商品——家电签收后 30 天内，数码和日用百货签收后 7 天内——如果降价，用户在 app 里点一下”一键价保”，系统自动比对价格差异，审核通过后差额原路退回。整个流程不需要人工客服介入，不需要人工判断，不需要用户解释理由。京东甚至做了自动价保功能：系统定期监控你买过的商品价格，发现降价直接帮你把差价退了，用户什么都不用做。

这套系统催生了一个完整的第三方生态：浏览器插件京价保帮用户自动监控所有历史订单的价格变化，发现降价就自动申请价保。插件是开源的，逻辑简单到可以当 Chrome Extension 入门教程用——监控价格变化、比对差值、调用申请接口，三个步骤。

价格比对是一个数据库查询。差价计算是减法。Partial refund 是支付系统从诞生第一天就支持的标准操作——任何一张信用卡的 partial refund 都是一个 API 调用的事。Amazon 自己的系统每秒处理的交易量比京东还大，它的 AWS 每天处理的 API 调用以万亿计。自动 price adjustment 的技术复杂度，对 Amazon 来说大约相当于在 DynamoDB 里多写一行记录。

退一万步讲，就算不做自动化，就算不退信用卡——给用户发一个 $50 的 Amazon credit 有多难？Amazon Gift Card 系统运转了二十年了。在用户账户里加一行余额，这不是工程挑战。

所以真正的问题从来不是”能不能做”。

摩擦即筛选#

有一个更诚实的解释：Amazon 故意不做 price adjustment，因为退货流程自带的摩擦是他们的筛选机制。

如果 price adjustment 只需要点一个按钮，每一个发现价格波动的用户都会申请。Amazon 的动态定价系统一天变动数百万次价格，大部分波动幅度在几块钱以内。如果每次波动都触发退差价，积少成多是一笔巨额支出。

退货流程自带一个天然的筛选阈值：只有差价大到值得你跑一趟 UPS 的人才会真的退。差价 $5 的不会退。差价$10 的大部分不会退。差价 $50 的，像我这样的人会退。这个筛选机制把大量小额差价请求在源头就过滤掉了，而 Amazon 不需要为此做任何工程开发——UPS 的取件流程就是他们的防火墙。

这套逻辑在纯商业层面上说得通。退货流程是全自动的：贴标签、UPS 取件、入库扫描，不需要客服人工介入。Price adjustment 即使自动化了，也需要处理边界情况——优惠券叠加、third-party seller 的定价权、闪购和限时折扣的排除——每一个边界情况都是一条业务规则，每一条业务规则都是一次产品决策。

京东的价保规则列了二十多条排除情形：百亿补贴不适用、秒杀不适用、无货不适用、赠品不适用、直播间专享价不适用。京东做了这件事，但也为此承担了规则维护和用户纠纷的成本——知乎上有大量关于价保规则争议的帖子，用户认为被规则的文字游戏坑了。

Amazon 的选择是：与其花工程资源建一个 price adjustment 系统、然后花产品资源维护二十条排除规则、然后花客服资源处理用户对排除规则的争议——不如什么都不做，让物流系统兜底。物流成本是 $330，但这笔钱分散在 UPS 的运费、仓库工人的工时、商品的折价损失里，不会在任何一张损益表上显示为”因拒绝 price adjustment 而产生的额外支出”。会计上看不见的成本，就是不存在的成本。

而那个 $50 的 price adjustment，退给用户，白纸黑字写在财报的 revenue deduction 里。

环保是个好名字#

Amazon 的 Climate Pledge 承诺 2040 年实现净零碳排放。他们的退货处理页面自豪地写着”our mission at Amazon is to give it a second life”。他们有 Grade and Resell 计划、有清仓拍卖平台、有捐赠项目。

与此同时，他们的客服在告诉你：退了重买。

这让人想起另一家公司。2020 年，Apple 宣布 iPhone 12 不再附带充电器和耳机。官方理由：减少碳排放，减少电子废弃物，包装更小意味着每个托盘能装更多手机，运输效率更高。环保主义者鼓掌。

然后有人算了一笔账。根据 Hypebeast 的报道，Apple 因为不再附带充电器和耳机，额外获利超过 65 亿美元。每台设备节省约 $35 的配件成本，乘以数亿台的出货量。这些配件需要另外购买，单独包装，单独运输——佛罗里达大学的 Sara Behdad 指出，如果消费者单独购买充电器和耳机，额外产生的包装和运输可能会抵消甚至超过 Apple 声称的碳排放节省。法国不信这一套，立法要求所有智能手机必须附带耳机——于是 Apple 在法国把 iPhone 盒子塞进一个更大的盒子里，里面放上 EarPods。

环保是个好名字。它可以用来命名任何一个让公司省钱的决策。不给充电器叫环保。不给 price adjustment——如果 Amazon 想给它找个理由的话——也可以叫环保：不做 price adjustment 就不会有人专门为了 $50 差价把一个五百多刀的包裹从纽约运到宾夕法尼亚再运回来。

当然，Amazon 没有这么说。他们只是说”we don’t offer price matching”，没有解释为什么。这可能是因为”我们故意用退货流程的摩擦来筛选低价值差价请求”这句话写在帮助页面上不太好看。

时间旅行#

回到那个时间线。

包裹 4:57 PM 在 Brooklyn 被 UPS 扫描收件，5:05 PM 到 Maspeth，7:30 PM 入库。“Return request is created”——8:03 PM。

两套系统，两条时间线。

UPS 的扫描是实时的。司机扫码，时间戳立刻写入 UPS 的追踪数据库，显示的是扫描地点的本地时间（Brooklyn = Eastern Daylight Time）。这是物理世界的时间。

“Return request is created” 是 Amazon 后台的系统事件。Amazon 内部用 UTC 存储时间戳，前端显示时转换成 PST 或者用户本地时区——具体哪个时区，取决于你在哪个界面看。Amazon 自己的卖家论坛里，卖家们争论了好几年搞不清报表里的时间戳到底是 UTC 还是 PST。

更可能的情况是，Amazon 的退货工单生成本身就是异步的。你在 app 里点了”退货”，系统生成标签发给 UPS。UPS 拿着标签去取件，实时扫描。而 Amazon 后台的退货工单可能要等到某个批处理周期才正式 create 出来——写入数据库、关联订单、触发退款流程。物理世界的包裹不等软件系统的事务提交。

结果就是追踪页面上出现了一个微型时间悖论：包裹在退货请求被创建之前三个小时就已经在路上了。两个系统各自记录各自的真相，没有人觉得需要协调一下它们的叙事顺序。

这个时间线上的错位，某种意义上是整件事的缩影。Amazon 的物流系统足够高效，能在你点”退货”的几个小时内就派 UPS 上门取走包裹。Amazon 的定价系统足够智能，能一天变动数百万次价格来保持竞争力。Amazon 的 AWS 足够强大，能支撑全球三分之一的云计算负载。

但这三个系统之间，没有一条简单的管道，能在价格降了 $50 的时候，往你的账户里写一行$50 的 credit。

一百二十公里#

这个包裹现在正在去 Martins Creek 的路上。到了以后，会有人拆开它，检查一下，发现它完好无损——因为我根本没拆封——然后决定它的去向。如果运气好，它会被重新贴标上架。如果运气不好，它会以七折八折的价格挂在 Amazon Warehouse 频道，成为一个 “Used - Like New” 的商品，等一个对价格更敏感的买家。

与此同时，一个一模一样的商品正在从某个仓库出发，往 Brooklyn 方向走。

两个包裹，两趟运费，两次碳排放。Amazon 的追踪页面上，退货工单比包裹晚了三个小时。在 Amazon 的数据库里，这笔退货从 8:03 PM 开始存在。在物理世界里，它从 4:57 PM 就已经上路了。

两个时间，两套系统，两趟包裹，一个 Climate Pledge。

都是真的。