AI 应用上线后，维护自己做还是找人做？

📖 摘要：AI 应用交付完成、上线之后，必然要有人持续管——退化的原理已有专文讲透，本文回答更现实的第二个问题：这件事怎么安排。三种模式（完全自己做 / 完全外部 / 混合）各自的前提条件与常见问题；自己维护需要的三个硬条件（懂业务、懂 AI 应用边界、有固定时间预算）；以及一条常被忽略的判断标准——关键不是有没有人，是那个人有没有时间和判断权。最后给出建议：不管谁做，体检机制都不能省。适合：AI 应用已上线、正在决定维护方式的企业。

AI 应用上线三个月，第一次跑体检，发现三道题退化：一道是手册改版没重新入库，一道是某个检索配置被改动了，一道是新模型版本对某类问法理解变了。

修完这三道之后，真正的问题才浮出来：以后这事谁管？

一、先说清维护的范围

关于「AI 系统为什么会退化」「维护到底维护什么」，前面已有一篇讲得比较透（见文末相关文章），这里只做一句交接：

AI 系统的正确性不是交付时一次性确立的，是上线后持续维护出来的。 维护分两层——基础设施层（服务器、备份、扩容）是云厂商和 IT 部门的标准业务；真正决定"半年后还好不好用"的是业务运营层（知识更新入库、规则调优、质量体检）。

本文要回答的是第二层的承接方式：这些活，谁来干。

二、自己维护，需要三个条件

先说结论：自己做维护是可行的，但不取决于"有没有 AI 工程师"，取决于三个条件是否同时具备。

第二条最容易被低估。做维护和做开发需要的不是同一套认知：开发是"从零搭起来"，维护是"判断一个已有系统哪里不对"。后者需要对应用的每一层（数据、检索、编排、模型）都有概念——否则遇到问题只能做一件事：重启。

第三条最容易被忽略。维护是周期性动作，不是"有空就做"。而现实中，被指派做维护的人往往同时有本职工作量——一旦忙起来，第一个被推迟的就是"没有明确截止时间"的体检。

三、三种承接模式

关于混合模式，值得多说一句：它通常是效果最好的形态（业务判断留在内部、技术判断交给外部），但也是最容易出问题的形态——因为它依赖一条清晰的分界线。

分界线可以这样写：

不这么写的后果很具体：出了问题，内部说"这是技术问题"，外部说"这是业务判断"，来回几轮，退化还在。

四、一个更准的判断标准

上面三张表都能用，但如果你只记一句，记这句：

关键不是"有没有人管"，是"那个人有没有时间和判断权"。

这个判断标准来自一个真实的反面形态：挂了名但没有时间的负责人。

表现是——维护负责人定了，但这个人同时扛着本职工作；体检说好每月做，实际三个月做一次；发现问题需要修，但要先排期，一等等两周。

这种状态比"没人管"更危险，因为它给人"有人在管"的错觉。系统在退化，但没人发现；等发现的时候，损失已经积累了几个月。

所以判断承接方式是否靠谱，看的不是组织架构图上有没有这一格，而是两个问题：

• 这个人有没有固定的、不被挤占的时间？（不是"应该能有时间"）
• 他发现问题后，能不能直接决定怎么处理？（还是要走一轮汇报）

两个都是"能"，这一层才算真的有人管。

五、不管谁做，体检机制都不能省

最后一条建议，与承接方式无关：

无论自己做、找人做还是混合，都要有一套"体检"机制——拿一组固定的问题集定期回归，同样的题对比不同时期的表现，发现退化、逐条归因、修复、再复验。

为什么它不能省：没有体检，退化就是静默的。系统不会报错说"我过时了"，它只会慢慢给出过时的答案，而所有人以为它还在正常工作。有了体检，退化就变成"定期发现、定期修复"的正常过程——可发现的退化不是问题，不可发现的才是。

如果选择交给外部，这一条同样要写进约定里，而且要写具体：

为什么要写具体：因为"随时待命"和"持续正确"是两件事。前者买的是响应速度，后者买的才是系统一直好用——而只有可验证的约定，才能确保你买到的是后者。

常见问题

内部没有 AI 工程师，能不能自己做维护？

可以，但需要区分"做维护"和"做开发"需要的能力不同——维护不要求会搭建应用，但要求能判断问题出在哪一层。

具体说需要三样：懂业务（知道答案对不对）、懂应用分层（知道问题出在数据、检索、编排还是模型）、有固定时间。前两样可以通过在交付阶段深度参与来建立（跟着做一遍清洗和体检，比看文档有效）。

如果三样里只能满足一部分，混合模式通常比硬撑更现实——但前提是分工写清楚（内部管业务判断，外部管技术判断）。

混合模式的分工，怎么划才不容易互相推？

核心是把"判断"和"执行"分开，而不是把"简单的事"和"难的事"分开。

推荐分法：内部（懂业务的人）负责判断答案对不对、提出场景变化、决定优先级；外部（懂 AI 的人）负责判断问题出在哪一层、执行修复、跑体检、给回归结论。

容易出问题的分法是"内部提问题、外部全负责"——这样内部失去了判断能力，也就无法验证外部的工作质量。反过来"内部全包、外部只做紧急支援"也不牢靠，因为日常的体检动作最容易在忙的时候被牺牲。

体检多久做一次，每次做什么？

频次：与知识更新频率挂钩——知识更新频繁（如手册每季度改版）建议每月一次；更新少的可以每季度一次，但不宜更长，因为退化是静默的，间隔越长发现问题越晚。

内容：跑一组固定问题集（覆盖核心使用场景，几十道即可），对比不同时期的表现。发现问题后走四步：体检 → 归因 → 修复 → 复验。

归因这一环最关键：同样一道题答错，可能是知识过期、配置漂移、也可能是模型行为变化——三类问题的修法完全不同。不做归因就直接改，容易出现"改好了这道、碰坏了那道"。

知识更新算不算维护？多久更新一次？

算，而且它是业务运营层最常规的一项。更新频率应该由知识的更新频率决定，不由日历决定：手册改版、制度修订、新产品发布、旧文档作废——每一次知识变动都应该触发一次重新入库。

有一个容易被忽略的点：旧知识不是"错误"的，它曾经是对的——所以系统用旧知识给出的答案看起来完全正常，只是不符合现在的业务。这类问题只能靠定期核对发现，不会自己暴露。

相关文章：AI 系统上线三个月后，开始悄悄退化——为什么 AI 项目不是一锤子买卖（退化的三个原因与维护的两层，本文的前置阅读）｜独立验收（二）：上线前怎么验？一套可复用的验收方法论（上线前的验证标准，与上线后的体检机制衔接）｜企业做一个 AI 智能体，到底要花多少钱？（维护成本在整体成本中的位置）

本文基于真实交付与维护项目经验撰写（2026-08），维护循环与体检机制在实际项目中应用并验证。文中不含任何服务推销内容——三种承接模式均为中性对比。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实交付记录。