第 3.12.1 节：先判断交付状态台账要解决的真实问题
进入实现之前，先围绕“先判断交付状态台账要解决的真实问题”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出交付状态台账的适用场景、不适用场景、前置条件和进入工程实现的判断标准。
章节定位
AI Agent（人工智能体）项目的商业价值不只发生在演示时，也不只发生在上线当天。真正决定客户是否续费、是否扩展、是否推荐给其他部门的，是上线后的交付运营能力：问题能不能处理，资料能不能更新，成本能不能解释，效果能不能复盘，新增需求能不能被合理评估。
本章讲第 3 卷所有项目案例背后的通用方法：如何交付、如何运维、如何复盘、如何报价续费、如何判断增购机会。它不是某一个行业的功能教程，而是把“做完一个项目”变成“长期服务客户”的方法论。
如果前面的章节教你做项目，本章教你守住项目。交付不是把入口交给客户就结束，而是让客户知道当前系统能做什么、不能做什么、出了问题找谁、什么时候复盘、什么条件下值得扩大投入。
行业业务问题
很多 Agent 项目不是死在技术实现，而是死在交付之后。
第一，客户不知道系统当前状态。哪些能力已经可用，哪些能力需要人工审核，哪些资料还没接入，哪些风险还在观察，如果没有明确说明，客户很容易把试点能力误解成全自动能力。
第二，上线后无人维护资料。Agent 的回答依赖知识库、接口、规则、表格、流程和权限。资料一旦过期，输出质量就会下降。客户可能以为是模型变差了，实际上是资料没有维护。
第三，错误样例没有闭环。用户反馈“回答错了”，如果没有记录、分类、修正、复测和通知，错误会反复出现，客户信任会下降。
第四，成本无法解释。模型调用、检索、外部工具、人工审核、服务器资源、日志存储都会产生成本。客户只看到费用增加，却不知道是使用量增长、模型选择不当、缓存缺失还是异常调用。
第五，二次销售没有证据。有些交付方一上线就推更大的项目，客户会觉得是在强行销售。更好的做法是用试点数据说明：哪些地方节省了时间，哪些问题仍然存在，扩展到其他部门需要补哪些资料和权限。
适合与不适合场景
适合做持续运维和二次销售的场景：
- 客户已经完成试点，且有真实用户、真实任务或真实业务数据。
- 项目有清楚的成功指标，例如节省时间、采纳率、错误率、转人工率、处理时长、复购线索。
- 客户内部有人负责资料、权限、反馈和业务决策。
- 系统运行中能记录 Trace ID（追踪编号）、错误样例、成本和用户反馈。
- 现有能力可以复制到相邻部门、相邻门店、相邻产品线或相邻流程。
不适合推进续费或增购的场景：
- 试点没有真实使用，只停留在演示。
- 客户没有维护资料和反馈的责任人。
- 当前系统错误较多但未复盘，就急着扩大范围。
- 增购范围需要新资料、新接口、新权限，却被包装成简单复制。
- 客户只想听“全自动替人”，不愿意接受人工审核、风险边界和运维费用。
判断能否做二次销售，可以问一句：现有项目是否已经产生可复盘证据？如果没有证据，先做运营复盘，不要急着卖更大的范围。
需求澄清清单
交付运营类需求澄清要围绕状态、责任、指标、成本和扩展边界。
| 澄清项 | 必问问题 | 判断目的 |
|---|---|---|
| 上线范围 | 当前哪些能力已交付？哪些只做内部试用？ | 防止客户误解状态 |
| 责任人 | 谁负责资料更新、权限审批、错误反馈和业务确认？ | 建立运维闭环 |
| 服务时间 | 问题响应是工作日、全天候，还是按约定窗口？ | 判断 SLA（服务等级协议） |
| 错误处理 | 错误样例多久响应，多久修正，谁验收？ | 设计问题闭环 |
| 资料更新 | 知识、规则、商品、文档、接口多久更新一次？ | 防止质量衰减 |
| 成本监控 | 模型、工具、存储和人工审核成本由谁查看？ | 支撑续费解释 |
| 指标口径 | 看节省时间、采纳率、错误率、满意度还是收入线索？ | 定义复盘标准 |
| 变更边界 | 哪些算运维，哪些算新增需求？ | 防止服务范围失控 |
| 扩展条件 | 复制到其他部门需要哪些资料、权限和流程？ | 判断增购可行性 |
| 汇报节奏 | 周报、月报、季度复盘分别看什么？ | 建立客户沟通节奏 |