「智能化是一次性项目」错在哪？

「智能化是一次性项目」这句话，错在按工程交付的思路安排一件需要长期照看的事。用 AI 做业务系统的团队，第一年通常顺利：需求清楚、支持充足、大家新鲜。第二年问题开始出现，数据旧了、口径变了、原来的负责人调岗了，系统还在跑，但输出已经没人敢用。

误区一：把上线当成终点

错在验收方式。项目制验收看的是功能是否交付、指标是否达标，验收一过，团队解散，预算归零。可模型的效果会随环境变化而衰减，没有人盯着，衰减是无声的。

正确说法是把上线定义为一个阶段的开始，验收指标里加入可持续项：有没有指定负责人、有没有监控面板、有没有每月一次的复盘。三项都没有，交付的只是一个会过期的成品。

误区二：忽略数据会变旧

错在假设输入是稳定的。产品线会调整，客户结构会变化，业务规则一年改几次，训练用的样本很快就不再代表当下。模型不会报错，它只会安静地给出越来越偏的答案。

正确说法是建立数据的新鲜度指标：最近三个月样本占比、关键字段的分布漂移、人工修正率的变化。三项里有一项明显异常，就该安排一次重训或补样。

误区三：预算只算第一年

错在把建设费当成全部。第一年花在搭建和接入，第二年起要花在维护、重训、答疑和迭代，这部分通常占首年投入的两到三成，但很少出现在立项材料里。

正确说法是把三年预算一次列清，并把运维部分单独成项。单独列出的好处是它不会被当成临时开支，每年被优先砍掉。

正确说法：智能化是持续运营

运营的核心不是不断加功能，而是保持效果不掉。做法可以很轻：每月看一次指标，每季做一次样本补充，每半年评估一次是否还值得继续。节奏固定下来，投入就可预期。

同时要允许停用。某些场景跑了一年发现价值不足，体面地关掉比勉强维持更负责任。判断依据是使用率与人工修正率，两个数字同时变差，就该考虑退出。相关判断可看工具与数字化的距离。

长期运营要固定的三件事

一是人：一个能改配置的负责人，一个能判断业务口径的业务方，两个人不必专职，但要有明确的响应时限。二是账：每年一笔固定的维护预算，额度不必大，但要可预期。

三是节奏：固定的复盘会，固定的问题清单，固定的版本记录。三件事看起来琐碎，却是让系统活过第二年的关键。若还在起步阶段，可参考试点与推广的分批做法。还有一个现实问题：运营预算常在第二年评审时被砍，应对办法是把效果折成可比的单位，比如每月少花多少工时、少出多少返工，用同一口径连续记满十二个月。数字连续，讨论才不会退成印象之争；降本逻辑本身怎么看，可看自动降本的三个误判。

还有一件事常被推迟：交接。第一年负责的人往往就是设计者，很多判断只在他脑子里，等他调岗，接手的人看不懂为什么某个阈值是零点六。把关键判断写成三页说明，附上当时的取舍理由，这份文档比代码耐久。文档不必漂亮，能回答为什么就够，每年跟着复盘会更新一次。

第二年复核四项

• 最近三个月样本占比是否过三成
• 人工修正率是否比上线时明显上升
• 负责人是否还在原岗位
• 维护预算是否已单独列项

交接文档可以先用讯飞星火和 Kimi 各起草一版，再由负责人补上取舍理由。机器写得快，但为什么定这个阈值，只有当时的人说得清。

关于智能化是一次性项目，问得最多的三个

• 不迭代会不会马上坏？：不会马上坏，但会慢慢偏，通常半年后开始有人抱怨结果不对。
• 维护要多少人？：一个小场景每月几小时即可，关键是有人负责而不是人多。
• 怎么说服管理层批维护预算？：拿修正率和停用损失说话，比讲技术必要性有效。