北京
AI系统上线之后，头几个月几乎总会出问题，而且出问题的位置高度雷同。这不是开发团队水平不行，而是定制开发的固有属性——系统活在现实里，现实不会站着不动。上线即完事，只适用于烤面包机。
架构里假设的东西，和现实里实际发生的事，完全是两回事。没有持续的监控、修bug和后续迭代，这套系统很快就会变成一堆死重。这个阶段跳不过去。
那么，头几个月到底会坏在哪？几乎总是同样几件事。
数据会漂移。系统当初是在特定的价目表、排期表和文档上学会干活的，而这些数据自己有生命：发票格式改了，供应商网站上的某个板块挪了位置，你的一部分逻辑就在盲跑。
外部依赖不会打招呼就变。模型更新了，回答方式就略有不同；平台API改了版本或者限流规则。你什么都没做，系统的行为已经变了。
人的用法和你的假设不一样。测试里是干净整齐的请求，现实里是错别字、半截话，以及压根没进过计划的问题。这些全都落在测试从没看过的地方。
业务本身在变。新服务、新规则、新流程。为旧方案拼起来的逻辑悄悄对不上了，而且没人察觉，直到出事。
这四件事都不意味着系统建得差。它们是定制开发的正常属性。所以维护不是可选的保险，它是系统本身的一部分：盯它在真实数据上的表现，在用户发现之前抓住bug，在数据和流程变化时让逻辑保持对齐。没有这些，一个长期运行的系统会先无声地蔫掉，然后肉眼可见地垮掉。
如果你正在上线一套AI系统——自研的或者定制的——从一开始就把维护排进计划，把它当作开发的一个阶段，而不是以后再想起来的一个选项。这个阶段跳不过去，没有它，开发成果就变成死重。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
