一、为什么 AI 项目上线后更需要维护
传统软件上线后也要维护，但 AI 项目的维护更敏感。因为 AI 依赖的不是一套固定逻辑，而是知识、提示词、模型能力、接口状态、业务规则和使用反馈共同作用。
任何一个环节变化，结果都可能变化。
产品价格变了，知识库不更新，AI 就会答旧口径。业务流程变了，提示词和规则不调整，AI 就会按旧流程办事。系统接口字段变了，Agent 还按旧参数调用，就会报错或写入错误数据。员工反馈没有记录，系统就会一直重复同样的问题。
所以 AI 项目不能只按“开发交付”理解。它更像一套持续运行的业务能力，需要有人管资料、管规则、管接口、管权限、管效果。
如果前期报价或计划里完全没有维护安排，后面一定会补成本。区别只在于，是提前把维护机制设计好，还是等问题爆出来以后再救火。
二、第一块维护工作：知识库更新
知识库是企业 AI 应用最常见的基础能力，也是最容易被低估的维护项。
知识库不是上传一次就结束。企业服务说明会改，产品功能会改，报价边界会改，售后政策会改，内部流程会改，客户常问的问题也会改。只要业务在动，知识库就必须跟着动。
知识库维护至少包括五件事：
- 新资料进入前要审核，不能谁都随手上传；
- 旧资料要下线，不能让过期文档继续被检索；
- 同一问题要统一口径，不能多个版本互相冲突；
- 敏感资料要分权限，不能让所有人都能查；
- 答错的问题要回到资料层修正，不能只在线下提醒员工。
很多企业做 AI 知识库时，只算了搭建费用，没有算“每周谁来更新”。这会导致一个常见结果：上线第一周大家觉得新鲜，一个月后资料过期，员工开始不信，最后又回到人工问人。
比较稳的做法，是为知识库设置业务负责人。技术团队可以负责接入、检索和权限，但业务负责人必须负责资料口径。因为 AI 答案能不能代表公司，最终不是技术问题，而是业务责任问题。
三、第二块维护工作：提示词和业务规则
很多人把提示词看成一次性的配置。项目上线前写好一版，测试通过，就认为结束了。实际使用后会发现，提示词和业务规则需要持续调整。
原因很简单：真实问题比测试问题复杂。
用户会用各种表达方式提问，员工会输入不完整的信息，客户会追问边界问题，系统会遇到原来没想到的异常。第一版提示词不可能覆盖所有情况。
提示词维护不是每天随意改一句话。它更像业务规则迭代，需要有记录、有样本、有版本。
建议企业至少保留三类记录：
- 哪些回答被人工修改；
- 修改原因是什么；
- 是提示词问题、知识库问题、流程问题，还是模型能力边界。
如果只是觉得“回答不够好”就不断改提示词，项目会越来越乱。正确做法是先看错误类型，再决定改哪里。资料缺失就补知识库，字段不清就补业务口径，动作越界就加权限和确认点，表达不稳定才调整提示词。
这一点很重要。提示词不是万能补丁，它不能替代业务流程和数据治理。
四、第三块维护工作：系统接口和权限
当 AI 只是回答问题时，维护压力还相对可控。一旦 AI 开始接 CRM、工单、订单、财务、项目管理、小程序、企业微信或后台系统，维护复杂度会明显上升。
接口会变。字段会改。权限会调整。第三方服务会限流。调用失败需要重试。写入动作需要日志。敏感操作需要人工确认。AI Agent 如果能执行动作，就必须被当成一个会操作系统的角色来管理。
企业至少要提前设计这些问题：
- AI 能读取哪些系统；
- AI 能写入哪些字段；
- 哪些动作只能生成建议，不能直接执行；
- 每次调用接口是否留日志；
- 调用失败后怎么处理；
- 权限变化后谁负责同步；
- 系统升级后谁回归测试 AI 流程。
Microsoft 提到的 agent 治理和运行时安全，本质上也是在回答这些问题：当 AI 不只是聊天，而是开始操作系统时，谁能看见它做了什么，谁能限制它不能做什么，谁能追溯出问题的原因。
中小企业未必一开始就需要复杂治理平台，但至少要有最小可用的权限和日志机制。没有这些机制，AI 自动化越多，风险越难排查。
五、第四块维护工作：反馈闭环
AI 项目能不能变好，很大程度取决于反馈有没有进入闭环。
很多企业上线 AI 后，员工会在群里说“这个回答不准”“这个流程又错了”“这个客户不能这么回”。但如果这些反馈只是散在聊天记录里，没有进入系统维护流程，AI 不会因此变好。
反馈闭环应该回答四个问题：
- 谁收集反馈；
- 反馈按什么类型分类；
- 多久处理一次；
- 处理结果如何回到知识库、提示词、接口或流程规则。
反馈可以先从简单表格开始，不一定一开始就做复杂后台。关键是字段要有用：问题原文、AI 回答、人工修改、错误类型、责任人、处理状态、下次复测时间。
一周复盘一次，就能发现很多规律。比如 40% 的错误来自资料过期，30% 来自字段不清，20% 来自问题表达不完整，10% 才是真正的模型能力边界。这样团队就知道该优先改什么，而不是盲目换模型。
六、项目里必须有人负责这 4 个角色
AI 项目上线后，至少要有四类责任。
第一，业务负责人。负责判断 AI 回答是否符合公司口径，哪些问题能自动处理，哪些必须人工确认。
第二，知识库负责人。负责资料更新、版本清理、知识缺口补充、过期内容下线。
第三，技术负责人。负责模型接入、接口稳定性、权限控制、日志记录、异常排查和系统升级后的回归测试。
第四，使用者代表。负责收集一线员工反馈，判断系统是否真的省时间，而不是给员工增加额外操作。
小公司不一定要四个人分别担任，可能一个人兼多个角色。但角色必须明确。最危险的是所有人都觉得“有人会管”，最后没有人真正负责。
如果一个 AI 项目没有维护责任人，我一般不建议直接扩大范围。因为范围越大，后面的失控成本越高。
七、上线后前 30 天应该看什么
AI 项目上线后的前 30 天，比上线当天更重要。
第一周看基础稳定性。系统能不能正常访问，知识库能不能检索，接口有没有失败，员工是否知道怎么使用，明显错误是否能当天修正。
第二周看回答质量。哪些问题经常答错，哪些资料找不到，哪些回答需要人工大改，哪些场景应该转人工但没有转。
第三周看业务效果。重复沟通有没有减少，员工是否真的节省时间，客户响应是否更快，工单或线索处理是否更清楚。
第四周看扩展条件。当前流程是否稳定，负责人是否愿意继续维护，是否有足够样本证明值得扩展到第二个场景。
这 30 天里，不建议急着加新功能。第一版 AI 项目最需要的是把一个小闭环跑稳，而不是把功能铺大。没有稳定样本就扩展，很容易把问题带到更多流程里。
八、维护成本应该怎么提前写进方案
负责任的 AI 项目方案，不应该只写开发费用，还应该写维护费用和维护边界。
至少要写清楚：
- 上线后多久内包含问题修复；
- 知识库更新由谁负责，服务商是否协助；
- 提示词和规则调整包含几轮；
- 接口变化是否属于维护范围；
- 新场景接入是否另算；
- 是否包含月度复盘报告；
- 是否保留操作日志和错误样本。
这些内容提前写清楚，后期合作会顺很多。否则客户以为“上线以后都应该包”，服务商觉得“这是新需求”，项目就会陷入反复扯皮。
对企业来说，也要理解一点：AI 项目越接近真实业务，维护就越不是可有可无。因为它会影响客户沟通、员工效率、数据流转和业务判断。没有维护预算的 AI 项目，很难长期稳定。
九、哪些场景维护压力低，适合先做
不是所有 AI 场景都适合第一版。
维护压力相对低的场景包括：
- 内部常见问题问答；
- 售前资料整理；
- 会议纪要和待办提取；
- 客服工单分类；
- 销售线索摘要；
- 项目周报草稿；
- 文档初步归档和检索。
这些场景的共同点是：AI 主要做辅助，不直接做高风险决策；结果可以人工复核；错误成本相对可控；资料范围比较明确。
维护压力高的场景包括：
- 自动报价；
- 自动退款；
- 合同条款判断；
- 财务付款审批；
- 生产系统变更；
- 大客户投诉处理；
- 删除、冻结、授权等敏感操作。
这些场景不是不能做，而是不适合作为第一版全自动。更稳的做法是先让 AI 做资料整理、风险提示和草稿建议，把最终动作留给人工确认。
