AMR 是台带轮子的电脑，售后合同却按机床签

同一批 AMR，销售阶段讲的是算力和算法，到了售后合同里，就只剩下机架、轮组、电池和激光雷达。这两张纸之间的落差，才是武汉工厂真正要付出的隐性成本。硬件坏了，换件修好，问题闭环；可 AMR 的故障里，相当一部分根子并不在零件，而在那套看不见的调度与导航逻辑上——而多数售后合同，对这部分几乎只字未提。

交付即冻结：合同里没人写的那行"软件现状交付"

谈售后条款时，注意力通常都放在保修年限和换件范围上，很少有人注意到合同附页里往往有一句类似"按交付时的软件版本提供支持"的表述。这句话看上去中性，实际效果是把车出厂那一刻的算法水平，永久定格成后续所有维保的基准线。

AMR 的故障，根子常常在软件层：调度任务下发冲突、路径重规划卡死、避障参数与现场环境不匹配、充电策略在节拍变化后失效。这类问题不会亮红灯，它们表现为频繁的停顿、绕路、空跑，按合同条款一查，结论却是"设备完好"。而你的产线不是静止的——料架改了位置、路径加了拐点、节拍提了速，车还在用出厂那套参数，应对一套已经不存在的现场。所谓"车越用越笨"，很多时候不是硬件老化，是软件没有跟着现场一起更新。

落到谈判桌上，要做的事很具体：把"软件现状交付"这句模糊表述改成明确的更新义务，安全类与兼容性补丁必须免费且及时提供；导航、调度这类性能型升级，约定频率或触发条件，比如现场条件变更后多少日内给出评估；任何版本变更都要附回归测试说明，并承诺与既有接口兼容。谈判时直接追问一句："三年后这批车跑的，是不是还是出厂那套脑子？"只要对方含糊，就把更新义务写死进合同。

日志默认存在供应商服务器里，等于把裁判员让给对方

软件类问题的判定依据，全部藏在一类东西里：每台车的运行日志。AMR 本身就是行走的记录仪，任务回执、心跳记录、路径时间、充电日志、上下电记录，天天都在留痕。故障一发生，供应商一句"你们现场网络或地面条件的问题"，就能把话题从定责改成扯皮。要拆掉这句话，靠的不是当场争辩，是日志里的时间戳。

但这里有一个多数合同没写清楚的坑：日志默认存在供应商的系统里，你想核验，只能等对方截图、导出、加工。数据在谁手里，谁就掌握了"这算不算故障"的解释权。更别忽略另一层——你产线的工况数据，恰好是对方算法迭代最好的训练材料，用途边界不写，就等于默许对方拿你的产线去练自家的模型。

这一节要谈定的内容并不复杂，核心是四条边界：维修时长与故障频次，以日志与工单时间戳为唯一计量口径；你方有权随时调阅原始日志，并且日志镜像一份落到本地；数据的使用范围限于本合同项下的维保与故障分析；供应商不得将运行数据用于自身产品训练或对外提供。这节谈起来不热闹，但它才是让前面所有承诺"可被验证"的那根支柱。

补偿按"维修工时"算，是 SLA 里最划算的错位

售后合同的赔偿条款，大多挂在"维修时长"或"到场时长"上：几小时没修好，就补几个小时的工时或服务券。这个计量单位天然偏向供应商——它量的是对方花了多少时间，而不是你损失了多少。

你真正损失的计量单位，是产线停摆的时间：从线体停下来的那一刻起，到恢复可生产为止。中间无论卡在等响应、等备件、等定责，还是等一个软件版本回滚，每一分钟都在你的账上，而供应商的工时表根本体现不出这一段。

谈判时要做的，是把补偿的触发口径从"维修工时"换成"产线停机时长"：起算点定在线体停摆，不以工程师到场为准；赔付设单次与年度上限，防止争议长期挂账；再把年度赔付情况与续约费率、考核挂钩，让条款真正有牙齿。决策层面想清楚一件事：SLA 谈判的本质，是把一句漂亮的承诺翻译成可计算的代价。计量单位选错，条款写得再厚，也只是账面游戏。

AMR 和传统机床最大的区别不在有没有轮子，在于它的能力是软件定义的、它的状态是数据可证的。售后合同谈到最后，决定三年后这台车还值多少钱的，往往不是保修年限，而是这三处容易漏掉的落点：软件的版本别被冻结，日志的裁判证留在自己手里，补偿的计量单位换成产线时间。武汉工厂节奏快、产线改造频繁，AMR 生命周期里软件的权重只会越来越高。现在签下的这份合同，本质上是在为三年后那台车的"脑子"定价——这笔账，值得在签字前算清楚。