demo 的两小时，和上岗的两个月
用现在的低代码平台，搭一个能聊的 AI 客服确实只要一下午：接一个大模型 API，贴几篇产品文档，一个对答如流的 demo 就出现在面前。很多团队在这里得出结论——「AI 客服很简单，下周就能上线」。
然后，真实成本才开始计费。客户不会按 demo 的剧本提问：他们会打错字、一句话里夹三个问题、问一个知识库里根本没有的答案。上线第一周你就会发现，问题不在「模型聪不聪明」，而在一系列从来没被定价的隐性工作：知识文档补全、回答口径统一、兜底话术设计、坏例（bad case）收集与回归测试。demo 成本是「搭起来」的成本，生产成本是「敢让它面对客户」的成本——两者通常差一个数量级。
我们给客户报价时会说一句实话：AI 项目最贵的往往不是模型调用费，而是「你还不知道它会在哪里出错」。
解法：先建评测集，再谈上线
我们的做法，是把「感觉差不多了」变成可以度量的标准。上线之前，先和业务方一起攒一套评测集：50 条以上来自真实场景的问题——包括错别字、无关闲聊、故意刁难——每一条配上标准答案或标准处理动作。然后让 AI 全量跑一遍，约定两个数字：准确率达到多少才允许上线；「不知道」的拒答率落在什么区间才算合格。
同样重要的是退出标准：什么情况下自动降级转人工、谁负责每周抽查坏例、连续多少条答错就回滚到上一版。有退出标准的 AI 客服才敢放开跑，因为它永远有一条安全的底线。
一个正在跑的例子：AI 口语考官
这套方法我们正在一个真实项目里使用：某英语教育机构的分级测评系统（项目进行中，本文已脱敏）。它的 AI 环节不是聊天客服，而是一位「口语考官」——学生录音作答，AI 按任务评测或快速评测两种模式给出评分，老师再在工作台回放录音、逐题复核评语。
这个场景对评测体系的要求比客服更苛刻：AI 参与的评分直接影响学生的定级。所以整条链路天然带着「评测集 + 人工复核 + 可回滚」三件套——AI 评分不是终审，是初审；每个分数都能回放到原始录音；老师改判时，原报告零改动地生成新版本。项目还谈不上完美，但正因为评分有依据、错误可追溯，机构才敢把它放进真实的教学流程。把「考官」换成「客服」，方法论完全一样。
上线前，先问自己这 5 个问题
- 我有没有 50 条以上来自真实客户的测试问题？
- 每道题有没有明确的标准答案，或标准的处理动作？
- AI 拒答（说「我不知道」）的比例，我接受的上限是多少？
- 出现连续错误时，降级转人工的规则和责任人是谁？
- 上线后由谁、以什么频率抽查坏例并更新知识库？
五个问题里有三个答不上来，说明你还没有准备好为「真实成本」买单——但这不是坏消息，它恰恰说明项目还有救：先补评测，再谈上线。