AI 系统上线后的前 90 天怎么管？一份运营路线图

本文目录

AI 知识库、客服助手或自动化工作流刚上线时，团队往往盯着两个信号：能不能用，以及有没有人用。运行一段时间后，棘手的问题才会出现。

同一类任务的输出为什么忽好忽坏？知识更新后，旧问题是否重新出现？自动执行失败时，业务人员去哪里接管？模型费用没有失控，为什么维护工时却越来越多？

上线不是项目终点，而是运营事实开始积累的第一天。下面的 90 天并非行业标准，也不要求所有企业照搬同样的工期。准确地说，它是一套管理框架：先看清系统在真实工作中怎样运行，再建立可重复的更新机制，最后决定扩大、维持还是收缩。

第 0 天：没有这五项，不要急着放量

先把地基打牢。

正式进入运营前，先确认五个基础条件。

第一，明确业务负责人。技术团队可以修接口、调模型，不能替业务决定什么结果可以接受。第二，保留上线前基线，包括处理量、人工耗时、积压、返工和严重错误。第三，运行过程可追踪，至少能知道输入属于哪类任务、调用过什么工具、在哪一步失败以及最终是否由人接管。第四，准备停用或回退路径，避免系统异常时业务只能原地等待。第五，写清数据、工具和执行权限，尤其是发送、修改、审批等会改变业务状态的动作。

今年发布的《智能体规范应用与创新发展实施意见》也把权限管理、异常检测、人工干预、阻断恢复和过程可追溯列入智能体规范应用要求。对企业来说，这些能力不是合规材料里的附录，而是日常运营能否接住问题的前提。

如果五项条件尚未齐备，先限制流量和自主范围。让系统生成草稿、由人确认，通常比直接自动执行更容易发现真实问题。

第 1—30 天：先建立事实，不急着优化平均数

先看清全貌，再谈优化。

第一个月的目标是回答”系统到底在处理什么”。不要只看调用量、满意度或平均正确率，它们会把高价值任务、简单任务和危险错误混在一起。

先按业务结果把每次运行分成四类：可以直接使用、人工修改后使用、转人工处理、任务失败。再把失败继续拆开，例如知识缺失、资料冲突、输入不完整、接口超时、权限不足、工具选择错误和规则没有覆盖。

分类不必一开始就很复杂，但要让团队能把问题交给正确的人。知识缺失由内容负责人处理，接口超时由技术负责人处理，规则冲突则需要业务负责人决定。否则所有问题都会被笼统归为“模型不稳定”，优化也只能反复改提示词。

这一个月还要同时记录三类成本：模型与基础设施支出、人工复核与返工时间、维护人员用于排查和更新的时间。只有把三者与合格任务放在一起，企业才能看到真实的单位成本。

月底不必追求一张漂亮的总分。更有用的输出是一份运行事实表：主要任务有哪些，哪类失败最常见，哪些错误后果最重，人工接管发生在哪里，以及现有日志还看不见什么。需要更细的字段，可以参考站内的生产运行监控表。

第 31—60 天：把问题变成回归机制

看到问题只是第一步，更重要的是把它固化为机制。

第二个月要建立一条从真实失败到安全更新的闭环。

每周从转人工、严重错误和高频修改中抽取有代表性的样例，脱敏后加入回归评测。样例应保留输入和理想答案，同时记录它为什么重要、错误后果是什么，以及最终结果去哪个系统核验。这样，团队在调整知识、提示词、模型或工作流后，才能检查新版本有没有修好旧问题，又破坏了什么。

任何更新都应带着版本和变更说明。知识库更新要记录来源、适用范围和生效时间；模型或提示词调整要说明解决的问题；工作流修改要列出权限、工具和人工确认点是否变化。高风险变更先在小流量或影子环境运行，再逐步扩大。

这一阶段最值得警惕的不是“没有更新”，而是很多人都能随时更新，却没有人对整体结果负责。把发布、回归、回退和责任人固定下来，比频繁追逐新模型更能减少生产波动。完整做法可以继续阅读AI 工作流变更管理指南。

第 61—90 天：做一次扩大、维持或收缩的决定

第三个月不该只做运行汇报，而要形成投资判断。会议可以围绕五组问题展开。

业务结果

处理量、时效、积压或返工相较基线发生了什么变化？改善来自 AI，还是同时发生的流程调整和人员变化？暂时无法归因时，应明确写成未知，而不是把所有变化都记在系统名下。

人工介入

人工确认是在控制风险，还是把原来的工作换了一个入口？哪些修改能用于改善系统，哪些只是补救不稳定输出？如果大量任务必须重新完成，自动化率再高也没有意义。

完整成本

合格任务的成本是否可接受？模型、基础设施、复核、排错、知识维护和业务协调都应计算在内。低调用费用不能掩盖高维护成本。

权限与风险

是否出现过越权调用、敏感数据进入错误路径、错误执行或无法追溯的情况？人工接管和回退是否经过演练？涉及付款、法律承诺、用工等高后果决定时，最终责任不能交给系统。

运营责任

业务、技术、知识和安全负责人是否明确？问题响应、知识更新和版本发布有没有固定节奏？如果系统只能依赖最初的开发人员临时救火，尚不具备扩大条件。

结论可以只有三种。扩大：核心指标改善，严重风险受控，运维成本清楚，可以增加任务或自主范围。维持：局部价值成立，但样例、流程或组织条件还需积累。收缩：成本高于收益，人工返工长期不降，或责任与风险无法接受，应退回辅助模式、缩小范围甚至停止。

把运营节奏固定下来

运营不需要很复杂，但要很稳定。

90 天之后，系统仍需要一套简单而稳定的节奏。

频率	主要动作	输出
每日或异常触发	查看失败、权限异常、积压和人工接管	需要立即处理的问题单
每周	复盘失败类型，抽取回归样例，确认知识变更	问题排序与更新计划
每次发布	跑回归评测，记录版本，准备回退	可追踪的发布记录
每月	比较业务结果、人工介入、完整成本和风险	扩大、维持或收缩建议

团队不一定需要一开始就购买复杂的运营平台，但必须能回答：当前版本是什么，今天为什么失败，谁在处理，下次发布如何证明没有让它更差。

哪些企业需要建立这套机制

不是每家企业都要从头做起，但满足以下条件的应该认真考虑。

如果企业已经上线知识库、Agent 或自动化工作流，业务人员开始依赖它完成真实任务，同时又面临知识频繁变化、接口偶发失败、人工修改增加或成本难以解释，就不该继续把它当作一次性交付项目。

默碟公开的持续运营服务围绕回归评测、成本与延迟、失败和人工介入、知识与工作流更新、权限安全及月度复盘展开。它适合已经有可运行系统、愿意开放运行样例并由业务负责人参与判断的团队。具体范围可以在服务页查看；是否需要外部协助，也应先由现有日志和责任边界来判断。

前 90 天要建立的，不是一套更厚的报表，而是企业对 AI 系统的管理能力：问题能被看见，变化能被验证，风险有人接住，投入也能做出继续或停止的决定。做到这些，AI 才从“已经上线”变成可以长期使用的业务系统。