AI 上线不是终点。知识、模型、业务规则和真实问题每天都在变化。

WHY MANAGED / 01

为什么普通软件运维不足以覆盖 AI 系统？

传统运维主要关注服务是否在线、资源是否充足和数据是否备份。AI 系统即使接口全部正常，也可能因为资料过期、检索失准、模型变化或提示规则失效，持续输出不可用结果。

因此，AI 运维需要把基础设施、知识、模型和业务质量放在同一条运营链路中，并由业务人员参与定义哪些变化值得处理。

• 服务在线不等于答案正确，必须同时监控业务质量。
• 知识更新会改变检索结果，需要回归测试而不是直接发布。
• 模型版本和价格会变化，需要评估效果、延迟与成本后再切换。
• 业务规则和权限变化必须留下记录，并能快速回退。

SCOPE / 02

持续运维覆盖哪些工作？

运维范围按系统重要性、用户数量和业务变化频率确定。基础服务保障可用性和数据安全，增长阶段进一步管理知识与评测，复杂环境再增加权限审计、发布流程和跨系统问题处理。

• 基础设施：容器、数据库、证书、域名、磁盘、资源和依赖更新。
• 数据安全：自动备份、恢复演练、保留周期和异常访问检查。
• 知识治理：新增资料、版本替换、失效内容、引用和权限范围。
• 质量评测：固定任务集回归、失败分类、人工修改率和拒答行为。
• 模型运营：模型路由、参数、延迟、限额、调用失败和单次成本。
• 业务优化：用户反馈、流程卡点、新需求判断和迭代优先级。

METRICS / 03

运维效果如何衡量？

CapaLayer 不用“回答更智能”作为模糊目标，而是把技术指标和业务指标并列记录。每个系统只保留与实际决策有关的少量指标，避免为了看板而看板。

• 可用性：健康检查通过率、故障时间和恢复时间。
• 质量：事实正确率、引用正确率、拒答准确性和人工修改率。
• 效率：任务完成时间、等待时间和人工接管比例。
• 采用：活跃用户、任务量、重复使用率和旧流程回退原因。
• 成本：每项任务的模型调用、基础设施和维护成本。

BOUNDARY / 04

运维是明确范围的产品，不是无限期免费售后。

上线缺陷修复、日常运行保障、知识更新和新增业务需求属于不同工作类型。项目开始时明确响应范围、服务时间、变更次数和升级机制，既保护客户的稳定预期，也避免系统在无边界修改中失去可维护性。

新增部门、新系统集成或完全不同的业务流程，通常应重新进行场景判断和蓝图设计，而不是直接塞进原有运维范围。

• 缺陷：已确认范围内的功能不符合验收标准。
• 运维：保持现有系统可用、准确、安全和成本可控。
• 优化：根据评测和反馈调整知识、模型或现有流程。
• 扩展：新增角色、系统、知识域或业务流程，需要单独评估。