一句"年底停售"落到工程上，是四张要维护的清单
一、宣布停止供应，同时就签下了四份长期承诺
有车企对外给出了一个区域市场停售某类车型的时间表。市场解读集中在转型节奏上，那不是我们要谈的。对交付和运维团队来说，这件事的性质很明确：一个日期一旦公布，它就不再是一句口号，而是一项需要对存量用户长期兑现的义务，而且义务期远长于销售期。
这类时刻在软件行业同样常见：某个版本走到 EOL、某个旧接口下线、某款自研硬件停产。差别只在于，车企的停售会牵动一条很长的物理链条——已经卖出去的车还在路上跑，开它的人未必关注过任何公告。
于是真正的工程问题不是”哪天停”，而是四张清单：配件与维修能力、软件与固件版本、数据与接口、人员与知识。这四张清单的共同点是它们都得活很多年，而且每年都得有人复核一次——不复核就会悄悄失真，等到用户拿着问题上门，才发现答案早就没人维护了。
二、四张清单要填的字段与责任人
清单不该写成文档段落，要写成有责任人、有周期、有复核依据的表。下面这张表可以直接搬到项目管理工具里。
| 清单 | 关键字段 | 维护责任 | 复核频次 | 复核依据 |
|---|---|---|---|---|
| 配件与维修能力 | 部件号与替代件关系、末次采购时间、库存与在途、外部维修点授权状态、因缺件而不可修的判定线 | 供应链与售后联合 | 每季度 | 采购与库存实际数据、售后工单的等待件时长 |
| 软件与固件版本 | 出厂版本分布、在网设备版本分布、停售后仍可推送的更新类型、安全补丁的给到何时、OTA 服务端与证书的存续安排 | 嵌入式与云平台联合 | 每月 | 版本上报数据、补丁发布记录、服务端依赖清单 |
| 数据与接口 | 车主 App 与各互联服务的终止条件、云端依赖项、第三方服务合约到期日、终止前的告知动作与触达结果 | 产品与法务联合 | 每季度 | 服务依赖图、合约台账、告知触达率 |
| 人员与知识 | 维修手册版本、诊断工具可用性与授权、专用工装清单与状态、培训覆盖到哪些网点、离职人员的知识回收记录 | 培训与工艺质量 | 每半年 | 手册与工具的版本审计、网点培训完成度 |
字段之外还要有一个统一约束：每张清单都必须有一条”终止状态”的定义，即什么时候可以宣布这张清单不再维护。没有这条定义，清单会永远挂在某个人名下，直到他离职。
三、配件清单的难点在”缺哪个就修不了”
供多久，是对外承诺；能不能修，是对内事实。两者会脱节，因为一台设备里真正卡住维修的往往不是常用易损件，而是少数几个不再生产的部件：一个只随整车线供应的控制模块、一套需要专用工装才能拆装的组件、一个只有某家供应商做过认证的密封件。
清单里因此要有两样东西：一是关键件判定，把”停供后会导致维修不可行”的部件单独标出来，给它们比整车型更长的备货周期，并明确什么时候做最后一次采购；二是替代件的认证与记录，替代件不能只在采购系统里换个料号，要有装配验证、性能比对和一份可追溯的认证结论，说明它在哪些年款的设备上可换用。缺了这一步，几年后售后拿着替代件装上去出了问题，没人能说明当初是谁批准的、依据是什么。
顺带一条容易漏的：维修能力不只取决于有没有件，还取决于能不能读码、能不能匹配、有没有授权。诊断接口的开放策略属于第二行的软件清单，也属于这一行，两处要交叉引用而不是各写各的。
四、软件与固件清单最怕的是不知道存量有多大
停售后设备还能不能收更新，要先回答另一个问题：外面跑着的到底是什么版本。版本分布这件事在停售决定做出时经常没人答得出，因为它分散在三处：出厂时写了哪个版本（生产记录）、中间被授权服务站刷过哪些版本（线下工具记录）、用户自己联网升过哪些版本（OTA 上报）。三处不全，就只知道”卖了多少台”，不知道”现在是什么状态”。
清单要落的判断有四项：
- 停售后仍可接收哪几类更新。功能更新、缺陷修复、安全补丁是三种不同的承诺，要分开写，不能笼统说”继续支持”。
- 安全补丁给到什么时候，以及给到什么级别。要给一条可查询的表述：最后一个受支持的版本号和它的补丁级别，而不是”一段时间内”。
- 服务端基础设施要留多久。OTA 服务、证书与密钥体系、终端标识的校验服务，这些一关，存量设备连”修”的通道都没了，而且关服成本远高于维护成本，决策要提前锁定。
- 推送范围如何随存量衰减而收缩。设备在线率会一路下降，触达能力是衰减的，这决定了”我们承诺能修”和”实际能送到”不是一回事。
五、共同的坑：内部字段撑不起对外说的那句话
这类公告最常见的翻车方式，是公司对外说了内部数据模型不支持的东西。停售时间点常被同时拿去做合规申报、算库存、清订单，于是”停售”在系统里被塞进销售状态字段，结果发现这个字段没有区域维度——同一款车在有的市场继续销售、在有的市场终止销售，一句对外承诺在内部根本无法表达。等到要出报告时才补字段，历史数据已经对不上。
对策是把时间线做成数据而不是文档：每一项终止都是一个对象，带区域、带生效条件、带影响范围、带责任人、带关联的服务与部件清单，并且可以从头到尾查询。这样做还有一个额外好处——对外说出口的每句话都能指回某个字段，需要解释”我们承诺供到什么时候”时，不必再由某个人凭记忆回答。
数据与接口清单里还要补一条动作：终止要提前告知，而且要留证据。告知不是发一条推送，要有触达记录与失败重试，以及给存量用户的替代路径说明；否则服务停止之后所有的投诉都会变成”没人通知过我”。
第四张清单的失效方式最隐蔽，因为它不报错。人还在的时候，有些操作只存在于少数熟练工的脑子里：哪个工装要对准哪个标记，哪一步必须先登记旧件编号否则后续追溯断链，哪种声响属于正常而不必拆解。这些内容没写下来时，清单上那一行看着是满的——手册有版本、工具能打开、培训有签到——直到某次网点换人，同一个动作被做错才暴露。所以这一行的复核依据要再加一条抽查：取一份文档，让一个没接触过该型号的人照着完成一次标准流程，中途需要旁人开口解释的地方就是缺口。这个动作成本很低，却几乎是区分”写过了”和”能用”的唯一办法。
六、软件供应商可以直接搬走的经验
我们做云服务和 SaaS 交付时，同样的四张清单换套名词就能用：配件对应依赖组件与部署包，固件对应客户端版本与补丁级别，数据与接口对应旧 API 和导出数据格式，人员与知识对应运维手册和迁移脚本。
其中最容易照搬、也最常被忽视的是 EOL 公告的写法。一条合格的公告要有四样东西：受支持版本的完整列表与各自的终止条件；最后一版支持到哪个日期、停在哪个补丁级别的明确表述；一张可以被机器读取、可以被用户自助查询的版本对照表；终止后仍能获得什么（安全补丁、数据导出、迁移协助）与不再获得什么。
反例是绝大多数团队现在正在做的：把 EOL 写成一份 PDF 通知，版本号藏在正文里，历史版本列表散落在几个不同时期的文档中，用户想查”我这台还在不在支持范围内”要发工单。这种写法在设备量小的时候靠人工兜得住，量上来之后，每年都有人因为一张查不到的表反复解释同一件事。洹拓在一些长期运维项目里吃过这个亏，后来把”版本—支持状态—终止日期”做成一张对外的可查询表，公告只负责引用它，不再自己承载细节，维护成本和争议都下降了一截。