一个定制项目做了几个月，演示会上很顺。
输入一个问题，系统查资料、给答案、调用工具，几分钟跑完。领导点头，项目准备上线。
上线第一周，问题来了。客服发现它查不到最新库存，遇到老客户还会把两个订单混在一起。开发说接口没问题，业务说数据一直这样，项目就卡在“再优化一下”。
这不是模型突然变差，而是演示环境和真实环境本来就不一样。
演示环境是整理过的
演示前，项目组通常会做几件事：
- 挑几个典型问题；
- 准备干净的文档和数据；
- 把异常情况绕过去；
- 由最熟悉业务的人来操作。
这些动作没有错，但它们把最难的部分藏起来了。
真实业务里，问题往往出在没人整理的角落：同一个产品有两个编号，客户名称有三种写法，旧文档没有删，新政策还没进系统。
模型只能基于给它的内容回答。数据本身矛盾，它就会给出一个看起来合理、实际错误的答案。
真实数据通常有三个问题
我们在项目复盘里见得最多的，不是模型能力不够，而是数据准备不足。
第一，信息分散。 产品资料在网盘，价格在 Excel，售后规则在群里，客服经验在老员工脑子里。
第二，口径冲突。 官网写一套，销售手册写一套，客服话术又是另一套。模型不知道哪个是最新版本。
第三，权限不清。 哪些内容能给客户看，哪些只能内部用，哪些涉及个人信息，没有提前分好。
这三个问题不解决，演示越顺，上线落差越大。
验收不能只测演示题
很多项目的验收，是把演示时的问题再问一遍。系统答对了，就算通过。
更有效的验收，要从真实业务里抽题。
题目至少覆盖三类：常见问题、边界问题、异常问题。常见问题看准确率，边界问题看它会不会乱答，异常问题看它能不能停下来转人工。
还要看人工接管。系统答不出来时，用户能不能找到人；人工改完以后，知识能不能补回去；同一个问题第二次问，会不会还错。
验收样本不用很多，二十到五十条就够，但必须来自真实场景，不能由供应商提前准备。
上线后要有一个负责人
智能体上线不是结束。
知识会过期，接口会变，客户会问新问题。没有负责人，系统很快会开始失真。
负责人不一定是技术，也可以是业务骨干。他要做三件事：每周看未解决问题，决定哪些知识要更新，遇到异常时协调业务和开发。
如果没有人愿意承担这件事，项目最好先别上线。上线后没人管，比不上线更伤团队信心。
什么情况下先别做
第一种情况，数据拿不到，或者数据本身没有统一口径。先把资料整理清楚，再谈定制。
第二种情况，流程本身没理顺。智能体可以执行流程，但不能替公司决定流程应该怎么走。
第三种情况，出错代价很高，又没有人工复核。涉及付款、合同、对外承诺的场景，第一版不应该让系统单独完成。
交付前看一遍这张表
上线前，至少确认六件事：
- 真实数据能不能接进来；
- 知识有没有来源、版本和负责人；
- 权限有没有分清楚；
- 验收题是不是来自真实业务；
- 异常和人工接管有没有跑通；
- 上线后谁负责更新和复盘。
这六件事没有做完，演示再顺也只是演示。
智能体定制开发的价值，不是把一个 demo 做得很聪明，而是让它在真实业务里稳定工作。演示通过只是开始，验收和运营才是交付。
报价单要看哪几项
定制开发报价差很多，通常不是谁乱报。数据整理、接口数量、权限设计、测试集和维护，都会影响成本。
看报价时，不要只比总价，要看包含哪些工作。如果报价单只有开发费，没有知识整理、接口、验收和维护，后面很容易追加。
让对方把工作拆开：哪些是场景和流程梳理，哪些是知识和数据整理，哪些是系统对接，哪些是上线后的维护。拆不开的报价，后面也很难验收。
交付物有哪些
一个完整的定制项目，至少要留下几样东西：需求边界、知识和数据清单、接口说明、测试集、验收报告、运维手册。
没有这些，项目换人接手会很困难。系统能用，但没人知道它为什么这样设计，下一次改需求只能从头猜。
供应商怎么配合
定制项目不是把需求丢给供应商就完了。
客户要提供真实数据、能拍板的业务负责人和验收样本；供应商要说明哪些能做、哪些做不到、上线后怎么维护。
如果供应商只愿意演示，不愿意碰脏数据，项目大概率会停在上线前。合同里也要写清验收标准、数据归属和退出机制，不要只看功能清单。
如果你正在评估定制项目，可以看我们的智能体定制服务，也可以从企业 AI 解决方案验收清单开始，先定验收标准。