开发者随时在旁边修问题时，AI 试点往往运行得不错。真正的考验发生在之后：文档更新了、接口断了，或者最懂系统的人休假一周。
让试点进入日常业务之前，不能只交付演示和密码。使用团队需要知道：系统负责什么、绝不能做什么，以及出问题时如何继续工作。
下面是一份起点清单。审核深度应与操作后果相匹配：起草内部摘要和修改客户记录，不适合采用完全相同的审批要求。
1. 明确谁负责作决定
确定判断业务价值的负责人、维护系统的技术负责人，以及处理异常的审核人。小团队可以一人兼任多个角色，但职责仍要写清。
记录谁能暂停流程、谁批准变更、谁联系供应商，并安排替补。“有问题找开发者”不是可持续的操作规程。
2. 画出实际工作流
用一页说明触发条件、输入来源、处理步骤、输出、连接的系统和人工确认节点，并标明信息何时离开自有系统。
例如客服草稿助手：工单到达，检索批准的帮助资料，生成草稿，客服核查来源，再由客服发送。要明确：生成草稿不等于获得发送授权。
同时说明输入缺失、重复、过期或超出支持范围时，系统应该如何处理。
3. 交接权限，而不是在文档里分享密钥
凭据应存放在团队批准的凭据管理系统中，不应出现在交接 PDF 或聊天记录里。交接材料只需说明账号归属、需要的角色和获取权限的流程，不包含密钥本身。
确认公司控制的管理员能管理托管平台、源码仓库、模型服务账号和关联工具。说明员工或供应商退出时，如何撤销访问权限。
4. 监控要能指导行动
先关注能让负责人采取行动的信号：
- 哪些任务失败，正在等待谁处理。
- 是否出现异常延迟或依赖不可用。
- 抽查中发现了哪些无依据或错误输出。
- 使用量和费用是否超出团队批准的预算。
- 哪些可能影响客户的动作仍待批准。
不要默认保存所有提示词和文档。先确定哪些运行记录确有必要、谁能访问、保留多久。排查问题不应该以建立失控的客户信息档案为代价。
5. 演练人工接管
“把 AI 关掉”并不是完整的恢复方案。要写明替代流程、接手人员，以及未完成任务的核对方式。
以客服场景为例，暂停草稿生成后，新工单仍应进入正常队列。工作人员应能分辨哪些草稿已审核、哪些未审核、哪些内容已经实际发送。正式依赖之前，用模拟故障验证接管流程。这个场景仅用于说明，不代表已完成的客户案例。
6. 为变更保留基线
对工作流定义、指令、参考文档和重要配置做版本管理，记录当前运行版本和批准人。
更换模型、资料来源或集成方式之前，重新运行有代表性的测试题集，覆盖信息缺失和历史故障，不要只测试最简单的情况。提前约定何时回到上一版本，以及谁作出决定。
具体检查方式可以参考我们的 AI 质量测试指南。
7. 提前约定供应商退出资料
持续支持结束前，确认已获得源码访问、部署说明、流程图、不含秘密值的配置清单、已知限制和测试用例。列出哪些第三方订阅需要继续付费，哪些组件不能转移。
至少让第二位团队成员能够解释如何暂停流程、如何使用人工替代方案。如果只有原开发者能做到，交接就还没有完成。
用一次演练验收交接
让接手团队分别处理三种情况：依赖服务不可用、答案错误、负责人缺席。观察他们能否识别问题、停止不安全操作，并在没有开发者实时指导的情况下维持必要工作。
这种演练往往比再做一次成功演示更有价值。只有当系统的边界和恢复方式与正常流程一样清楚，才适合真正进入日常业务。
