AI系统交付完，谁来维护？

行业里有个不太被讨论的现象：相当一部分 AI 系统不是死在上线阶段，而是死在上线之后的三到六个月。原因往往不是技术故障，而是没人负责。

一、交付后到底有哪些活

第一类是数据更新。物料表增加了新品类、供应商换了编码规则、报表口径调整了。这些变化不处理，系统的判断会慢慢失准。

第二类是规则调整。业务政策变了、客户要求变了、发现了新的例外情况。规则需要跟着改，而且改完要验证。

第三类是异常处理。系统给出奇怪结果时，要有人能判断是数据问题、规则问题还是使用方式问题，并且知道找谁解决。

这三类活加起来不算多，但必须有人认领。没人认领的系统，会在第一次出错之后被悄悄弃用。

二、三种常见安排及其风险

安排一：客户自己维护。最健康，但前提是客户方有一个从项目第一天就参与的接手人。临时指派一个人来接，通常接不住。

安排二：服务方长期托管。省心，但会形成依赖，而且长期费用累计下来不便宜。适合客户方确实没有任何技术人手的情况。

安排三：混合模式。日常操作和简单规则调整由客户自己做，复杂问题按次或按年向服务方购买支持。这是大多数中小企业最现实的选择。

三、接手人这个角色最关键

无论选哪种安排，客户方都必须有一个明确的接手人。这个人不需要是技术专家，但需要满足三个条件：熟悉这个业务、愿意学、在公司待得住。

最好的做法是让他从项目第一天就参与——跟着做需求调研、跟着看原型、跟着改规则。这样交付时不需要额外的知识转移，因为他一直在里面。

反面案例是项目做完才指定接手人，然后安排两天培训。这种交接几乎必然失败，因为他不理解每个设计背后的原因。

接手人不是交付时才需要的角色，是项目第一天就该坐在会议室里的人。

四、阿优至简的视角

我们在项目启动会上会明确问一个问题：这套东西以后谁负责？答不上来的项目我们会建议先缓一缓，把这个人定下来再启动。

这个问题有时候会让客户不太舒服，但它比任何技术讨论都重要。一个没有主人的系统，做得再好也只是延迟死亡。定下接手人之后，我们会让他全程参与，交付时自然完成移交。

落地前的三条至简建议

1. 先定人：启动会上明确接手人姓名，写进项目章程。
2. 先参与：让接手人从需求阶段就在场，而不是交付时才出现。
3. 先分级：把维护工作按难度分级，明确哪些客户自己做、哪些找服务方。

决定一套系统寿命的，往往不是它做得多好，而是有没有一个真正把它当自己东西的人。