第 3.12.3 节：用监控、成本与复盘锁定验收标准和交付风险
方案是否能交付，不能只凭感觉，需要结合“用监控、成本与复盘锁定验收标准和交付风险”的验收样例和实际证据。完成本节后，你应该能够写出监控、成本与复盘的验收样例、通过/不通过标准、判断阈值和风险说明。
实现步骤或决策流程
推荐技术流及原因
本章推荐的技术流是“交付状态台账 + Runbook（运维手册）+ Feedback Loop（反馈闭环）+ Monitoring（监控）+ Cost Control（成本控制）+ QBR（季度业务复盘）”。
这条技术流不是为了让系统看起来复杂，而是为了让客户知道项目真实运行情况，并且把续费和增购建立在证据上。
- 交付状态台账：记录能力清单、上线范围、依赖资料、负责人、风险和验收状态。它解决“现在到底交付了什么”的问题。
- Runbook（运维手册）：写清楚常见故障、处理步骤、联系人、升级路径和恢复标准。它解决“出问题怎么处理”的问题。
- Feedback Loop（反馈闭环）：把错误反馈、原因分类、修正动作、复测结果和客户通知串起来。它解决“问题是否真的关闭”的问题。
- Monitoring（监控）：监控调用量、失败率、延迟、工具错误、人工转接、敏感拦截和异常成本。它解决“是否正在变坏”的问题。
- Cost Control（成本控制）：通过模型分层、缓存、限流、批处理、人工审核策略来控制费用。它解决“为什么花这些钱”的问题。
- QBR（季度业务复盘）：QBR 是 Quarterly Business Review，意思是季度业务复盘，用业务指标讨论是否续费、扩展和调整方向。它解决“下一步为什么值得做”的问题。
项目越小，技术流可以越轻；但状态、责任、反馈和成本这四件事不能省。
字段契约表
交付运营类字段契约不是给模型看的装饰表，而是项目长期维护的基础。它让每个问题、成本、变更和续费建议都有出处。
| 字段 | 含义 | 来源 | 是否必填 | 更新频率 | 风险说明 |
|---|---|---|---|---|---|
| project_id | 项目唯一编号 | 交付台账 | 必填 | 项目创建时 | 多项目客户必须区分 |
| capability_name | 已交付能力名称 | 验收清单 | 必填 | 能力变化时 | 防止范围不清 |
| delivery_status | 当前状态，例如内测、试运行、正式使用、暂停 | 项目经理记录 | 必填 | 每次状态变化 | 状态不清会引发误解 |
| owner_business | 客户业务负责人 | 客户组织表 | 必填 | 人员变化时 | 决策和验收需要责任人 |
| owner_operation | 运维负责人 | 服务团队 | 必填 | 人员变化时 | 问题处理需要责任人 |
| knowledge_updated_at | 资料最近更新时间 | 知识库或台账 | 条件必填 | 每次更新 | 资料过期会影响质量 |
| incident_id | 故障事件编号 | 反馈系统 | 条件必填 | 每次故障 | 用于追踪问题闭环 |
| feedback_type | 反馈类型，例如错误、改进、需求、投诉 | 用户反馈 | 条件必填 | 每次反馈 | 分类决定处理方式 |
| root_cause | 根因分类，例如资料缺失、规则冲突、接口失败 | 复盘记录 | 条件必填 | 问题关闭时 | 没有根因就无法避免复发 |
| fix_status | 修正状态，例如已接收、处理中、已复测、已关闭 | 问题台账 | 条件必填 | 状态变化时 | 防止反馈悬空 |
| cost_metric | 调用量、模型费用、工具费用、人工审核量 | 成本报表 | 条件必填 | 日或周 | 续费必须解释成本 |
| value_metric | 节省时间、采纳率、满意度、转化线索等 | 业务复盘 | 条件必填 | 周或月 | 增购需要价值证据 |
| change_request | 变更需求描述 | 客户或内部团队 | 条件必填 | 每次变更 | 区分运维和新需求 |
| trace_id（追踪编号） | 输出或事件追踪编号 | 系统生成 | 必填 | 每次关键事件 | 用于审计和复盘 |
数据准备
交付运营项目的数据准备，重点不是训练模型，而是让运行状态、问题、成本和价值都能被复盘。一个可用于作品集展示的运营数据包，建议包含六类材料。
第一，交付状态台账。记录能力清单、适用范围、上线状态、限制条件、资料依赖、负责人、已知风险和验收结果。台账要能回答客户最关心的问题：现在能用什么，什么不能自动用，出了问题找谁。
第二，运行日志摘要。保留调用量、成功率、失败率、转人工率、敏感拦截、工具错误、平均响应时间和 Trace ID（追踪编号）。展示时不需要暴露用户隐私，但要能看出系统是否稳定。
第三，反馈与故障样本。每个问题样本要有用户输入、系统输出、期望结果、影响范围、紧急程度、根因分类、修正动作、复测结果和关闭时间。没有这些字段，所谓“持续优化”就很难被证明。
第四，成本数据。至少准备模型调用成本、工具调用成本、缓存命中、人工审核量、异常调用和单位任务成本。成本不是只给财务看的，它直接影响续费方案和服务边界。
第五，价值指标。根据项目类型记录节省时间、人工采纳率、错误率下降、转人工合理率、线索转化、客户满意度或处理时长。价值指标要和客户目标对应，不能只用“调用次数多”证明有价值。
第六，变更与扩展记录。记录哪些需求属于运维，哪些属于优化、扩展或新项目；每次变更要有范围、报价、工期和确认人。这个记录能帮助作品集说明你具备商业边界意识。
制作步骤
1. 交付前先写清楚状态
在交付会上，不要只演示系统。要给客户一份交付状态台账，写清楚：已完成哪些能力，适用哪些场景，依赖哪些资料，哪些内容必须人工确认，哪些能力暂不支持，当前有哪些已知风险。
台账里最好把能力拆成“可直接使用、需人工审核、暂停使用、未纳入范围”四类。这样客户不会把试运行能力误解成全自动能力，也方便后续续费时说明服务范围。
2. 准备客户培训和运维手册
客户培训不是讲模型原理，而是让客户知道日常怎么用、怎么反馈、怎么判断结果是否可信、怎么更新资料、怎么处理异常。
Runbook（运维手册）至少要包含：账号与权限、资料更新流程、常见问题、错误反馈入口、升级联系人、故障处理步骤、暂停使用条件、恢复使用标准。手册越贴近真实工作，客户越愿意长期使用。
3. 建立反馈入口和问题分类
上线后必须有统一反馈入口。入口可以是表单、工单、客户群、内部系统，但字段要统一：问题描述、出现时间、用户问题、Agent（智能体）输出、期望结果、业务影响、紧急程度、截图或记录、Trace ID（追踪编号）。
问题分类建议分成：资料缺失、资料过期、规则冲突、检索错误、生成表达不当、工具失败、权限问题、用户误用、新需求。分类清楚后，才知道该改资料、改规则、改流程还是单独报价。
4. 设定服务等级
SLA（服务等级协议）不要写得过度承诺。可以按问题级别设置响应。
高优先级问题包括错误影响真实客户、涉及投诉、涉及金额、涉及隐私或系统不可用。中优先级问题包括回答不够准确、草稿质量下降、部分工具失败。低优先级问题包括表达优化、模板调整、报表字段微调。
每个级别要写清响应时间、处理时间、是否需要客户配合、是否进入复盘。服务等级越清楚，运维报价越有依据。
5. 做运行监控和成本监控
监控要覆盖质量和成本两条线。
质量监控看调用量、成功率、失败率、转人工率、敏感拦截、用户满意度、错误反馈数量、复测通过率。成本监控看模型调用次数、平均单次成本、工具调用成本、缓存命中、人工审核量和异常调用。
成本上升不一定是坏事。如果使用量增长、业务价值也增长，客户可以接受。真正的问题是成本上升但价值没有增长，或者没人能解释钱花在哪里。
6. 做周复盘和月复盘
周复盘适合看运行问题：本周多少反馈，多少已关闭，主要错误类型是什么，哪些资料需要更新，哪些规则需要调整。
月复盘适合看业务价值：节省了多少人工时间，采纳了多少建议，转人工是否合理，客户满意度是否变化，新增需求是否值得立项。
复盘报告不要只报好消息。要把问题讲清楚，并说明已经采取的动作。客户更信任透明的团队，而不是只展示漂亮数字的团队。
7. 区分运维、优化、扩展和新项目
很多交付风险来自范围不清。客户说“顺手帮我加一下”，团队如果每次都免费做，项目会失控；如果每次都报价，客户会觉得不灵活。
建议把需求分四类：
- 运维：资料更新、错误修正、小范围模板调整、权限维护。
- 优化：提升召回、调整分类、改进流程、增加报表字段。
- 扩展：复制到新部门、新门店、新产品线或新平台。
- 新项目：引入新的业务目标、新系统接入、新决策流程或新的高风险能力。
分类后再谈费用，客户更容易接受。
8. 用证据做续费和增购
续费不要只说“系统还要维护”。要拿出证据：运行次数、采纳率、错误率下降、节省时间、客户反馈、问题闭环、资料更新次数、成本控制结果。
增购不要只说“可以复制”。要说明复制条件：新部门是否有资料，接口是否相同，审批流程是否相同，用户问题是否相同，风险边界是否相同。能复用的是方法和部分资产，不是全部结论。
续费方案可以写成“当前价值、当前限制、继续运维能守住什么、专项优化能改善什么、扩展复制需要新增什么”。这种结构比直接报一个包月价格更容易让客户理解。