# AI 应用上线后，谁来更新资料、处理失败和维护？ 为企业 AI 应用建立简明的日常维护安排，避免只在交付当天可用。 要点：每个投入使用的 AI 应用都需要业务负责人、维护联系人和问题记录位置。日常关注资料变动、失败任务、权限变化与实际费用；模型或流程调整后，用既有样例复测。维护频率按业务变化和影响程度确定。 ![会议结束后留在桌面的电脑与工作资料（AI概念配图）](/images/guides/covers/ai-operating-routine-v2.png) ## 明确问题由谁接收 用户遇到错误时，首先需要一个能找到的反馈入口。反馈应包含任务时间、输入类型、期望结果和实际问题，不要求员工自己判断是模型、网络还是业务规则造成。 业务负责人判断结果是否可接受，维护人员定位原因。小团队可以由同一人兼任，但职责仍要写清楚，并为负责人不在岗的情况指定替代处理方式。 ## 把变化记录下来 资料换版、模型切换、提示调整和插件升级，都可能改变结果。保存简短的变更记录，注明影响的任务和已复测的样例。不要只保留一个不断覆盖的“最终版”。 对错误较多的任务，应先确认是否出现了新的业务情况。原来只支持单份文件的流程，不能在没有验证时默认支持多份互相冲突的附件。能力边界需要随变化同步说明。 ## 保持可以暂停和恢复 发生连续错误、费用异常或资料访问问题时，维护人应能暂停相关任务，并让业务同事回到原有处理方式。停止自动化后仍要知道哪些事项已经完成，哪些等待补做。 生态可以按约定提供持续学习、交流、协助咨询与评审。企业安排应用维护，具体技术运维与响应责任另行明确，不能把课程或生态参与资格等同于系统运维服务。 ## 例行回顾先处理影响真实使用的问题 从运行记录中挑出反复发生的错误、无人接收的待办和过期资料，分别确定责任人。不要把每次回顾都变成工具新闻分享。一个具体问题从发现、修正到复测的结果，比新增一批没有接收人的应用更容易积累组织能力。 维护清单保持简短，包含问题、影响范围、当前处理和下次检查条件。对已稳定的任务降低检查频率，对刚修改或影响较大的任务保留必要观察。节奏应随使用情况变化，而不是机械安排所有任务每天重复检查。 ## 给异常任务一个能找到的维护入口 为正在使用的应用写出资料维护人、问题接收位置和暂停方式。生态中的交流、咨询与阶段评审按约定提供；系统日常运行由企业安排，部署、接口和代运维另列技术实施范围。 ## 参考来源 - [秩启｜生态](/ecosystem)：常态化学习、交流、协助咨询与评审按约定提供；成果营含首年生态费，第二年续费前确认范围与费用，不自动扣费 - [秩启｜分工与建设方法](/method)：企业分工、流程与建设方法；属于本项目方法说明，不是外部效果证据 ## 维护时关注的三类变化 - 内容变动：资料版本和业务规则 - 运行问题：失败任务与费用异常 - 人员变化：权限、责任与交接安排 ![维护时关注的三类变化](/images/guides/diagrams/ai-operating-routine.svg) ## 继续阅读 - [工作流出了问题，运行记录应该留下哪些信息？](/guides/workflow-observability) - [企业知识库如何更新，才能避免新旧答案混用？](/guides/knowledge-versioning) - [流程债务：AI 为什么会放大已有的协作问题](/guides/process-debt) 按约定持续学习、交流、咨询与评审；成果营含首年生态费，第二年续费前确认，不自动扣费。 下一步：[了解生态的交流与咨询](/ecosystem) 原文：/guides/ai-operating-routine 内容版本：guide:ai-operating-routine:v1 [结合企业情况咨询](/intake?source=%2Fguides%2Fai-operating-routine&articleId=guide%3Aai-operating-routine&versionId=guide%3Aai-operating-routine%3Av1)