16｜系统上线之后，谁来用、谁来维护、出了问题怎么办？

上线完成了一次技术变化，持续使用还需要入口、信任、支持与责任。FDE 的交付范围因此会延伸到发布之后，帮助团队判断系统是否真正进入工作，以及它能否在变化和故障中继续提供服务。

生产准备应与项目规模、风险和依赖相匹配。小团队可以使用轻量安排，大型组织可能需要正式值班与审批。形式可以不同，但关键任务不能在异常发生时失去接手人。

试点首先要说明谁使用、处理什么任务、使用哪些数据、允许哪些动作、持续多久，以及达到什么条件才扩大。还要说明出现哪些问题会暂停，以及用户怎样回到可用流程。

例如一个资料问答助手，可以先限定一组产品、一小组销售和有依据的专业咨询；涉及例外商务条件时转人工。一个库存建议系统，则可以先生成建议，由负责人确认后在原系统中执行。

影子运行、辅助决策、有限自动化与更大范围自动化，可以作为逐步放权的不同方式。影子运行只生成结果供比较，不影响真实业务；辅助决策由人保留最终动作；有限自动化则需要明确哪些条件下允许执行。

放权不是一次设置，也不应仅由模型自报置信度决定。需要结合业务风险、明确规则与经过验证的信号。依赖变差、错误增加或新的高风险场景出现时，权限范围可以保持、收窄或回退。

UAT，即用户验收测试，应由目标业务用户按约定任务判断是否接受。开发者熟悉系统的理想路径，真实用户会按照自己的工作方式查找、补充、修改和交接，这能暴露不同问题。

验收任务应包含前置条件、操作、预期结果与签字或确认责任。租赁调度可以检查缺地址时是否阻止提交，设计业务员可以尝试只确认一件作品，仓库人员可以重复上传同一收货记录。任务应当对应岗位实际后果。

验收也应说明剩余限制。某种精细编辑由人工完成、某个接口暂时采用批次导入，可以在明确范围和责任下继续使用；若限制影响关键目标，则需要修订或收窄。

技术验收、安全验收、业务验收和运行验收各自提供不同证据。业务用户认为结果好用，不能代替权限检查；接口性能达标，也不能证明员工愿意采用。团队需要把这些条件放到同一发布判断中。

“今天系统不太稳定”不足以定位问题。结构化日志记录事件，Tracing 将一次请求中的检索、模型、工具和人工节点连接起来，指标帮助发现一段时间内的整体变化。

一条可诊断任务通常需要请求标识、用户或租户、业务对象、当前步骤、工具与版本、错误类型、输入输出边界和时间。记录应遵守数据最小化与访问要求，不应为了排错无限保存敏感内容。

举例来说，用户说“没有生成结果”，团队应能区分入口没收到、检索失败、模型超时、工具执行失败和返回入口失败。如果工具已经写入业务状态，最后发送失败就不能被当作整个任务从未发生。

版本也要关联。模型、提示词、知识快照、工具契约、业务规则和输入结构都可能影响结果。只知道应用代码版本，未必能够复现一次 AI 任务。

平均延迟之外，尾部慢请求也值得观察，因为少量很慢的任务可能打断实际工作。指标阈值应由目标任务与历史情况决定，不宜直接照搬其他项目。

SLO 可理解为在一个观察周期内约定的可靠性目标。它需要连接指标、告警和响应责任。仅把“服务稳定”写进方案，不能指导故障发生后的行动。

运行手册，也常称 Runbook，应说明常见故障怎样识别、先控制什么影响、检查哪些证据、何时升级、怎样恢复以及如何确认业务重新可用。用户也需要简明的异常入口，不必了解内部技术细节。

回滚需要明确回到哪个已知安全版本，数据状态如何处理，尚未完成的任务怎么办。恢复旧代码未必自动撤销已经发生的业务动作；订单、库存与通知等副作用需要单独核对。

人工接管应携带已有条件、已完成步骤、未完成动作和责任。若每次故障都要求用户从头重新整理材料，系统会不断消耗信任，也可能让人绕开它。

对于依赖持续失败、状态未知或可能越界的动作，应考虑暂停或降级。重试只能在明确条件下进行，不能用无限重试掩盖外部问题。

管理者需要理解指标、风险与放权决定；业务专家需要知道如何审核与纠错；一线用户需要掌握入口、适用任务和接管方式；维护人员需要知道更新、故障与恢复。

一份统一的功能介绍很难同时满足这些需要。更有效的方式，是让每个角色完成与自己有关的代表任务，并知道失败时如何继续。

例如销售学习怎样补充背景、核对依据和转交商业例外；设计师学习怎样选择父版本、提交精修结果和解释保持项；仓库人员学习怎样登记实收、合格与隔离，并确认提交是否成功。

培训结束也不意味着采用已经发生。还需要观察用户实际在哪里停下，是否重复录入，是否理解系统状态，反馈是否有人处理。系统入口若增加了工作负担，应回到流程设计寻找原因。

登录数说明有人打开，使用率说明目标用户在用，任务完成率说明工作走到结果，直接采纳率和人工干预率说明结果需要多少修正。这些行为指标有用，但需要与业务目标结合。

人工干预率高，不一定都是坏事。如果任务本来要求专业审核，人工介入是设计的一部分。相反，干预率突然下降，也可能是用户不再检查结果。解释指标时，需要回到任务性质与规则。

业务影响应与原基线保持相同口径。原来统计从收到询价到调度可接手，现在不能只统计生成时间；原来排除了等待客户，现在也应使用一致边界。否则变化可能来自统计方式，而不是系统。

用户长期绕开系统时，也应听取实际原因。资料过旧、入口不便、结果解释不足、责任不清，可能比模型质量更直接影响采用。生产反馈应进入改进任务，而不是只作为用户态度问题处理。

正式交接需要移交的不只是代码与账号，还有运行条件、业务规则、知识更新和支持机制。接手团队应当能独立完成约定范围的日常使用、问题定位与必要恢复。

交接可以通过一次任务演练检查：让接手人使用说明完成代表任务，再处理一个受控异常。如果他们只能联系原开发者才知道下一步，相关知识与责任可能尚未真正移交。

持续运行不要求每天都改系统，而是在业务、数据或技术发生变化时，能够知道该由谁判断、如何验证并安全更新。下一篇将用制造业订单风险场景，把发现、架构、评测、试点与反馈放进一个完整项目中。

AI随心创提供试点与团队落地支持，通过真实任务验证效果，整理操作说明、失败样例和优化清单。对于内容生产团队，也可以结合图片、视频、配音与小红书流程，讨论审核、交付和持续使用的组织方式。