智能体定制前，我们为什么先让客户填三张纸？

我见过一个很典型的开场：客户带着三页需求来谈智能体定制。

功能写得很细：要能回答产品问题，要能查订单，要能识别客户情绪，最好还能自动生成跟进记录。最后一页写着预算范围，问我们多久能上线。

我们没有马上报价，先给了他三张纸。

对方有点意外，可能觉得这些应该由供应商来填。

但我们吃过亏。很多项目不是做不出来，而是报价前就没想清楚：这个任务到底谁在用，数据在哪里，什么算做完。做到一半再回头补，成本比一开始多得多。

第一张纸：任务清单

我让他不要写“智能客服”，而是写客服每天具体做什么。

他一开始写的是：接待咨询、处理售后、跟进订单。

太粗了。我们又往下问：

客户一般问什么？哪些问题有标准答案？哪些必须查系统？查不到时谁接手？一个问题处理完，是结束，还是要转给销售？

他写着写着，自己停了下来。原来“智能客服”里，至少混着五种不同的任务：产品咨询、订单查询、退换货、投诉、售后跟进。

这五种任务的规则、数据和风险都不一样。把它们塞进一个智能体，最后通常是谁都不满意。

任务清单不是为了把需求写长，而是为了看清哪些能一起做，哪些必须拆开。

第二张纸更麻烦：数据在哪里。

客户说，资料都在共享盘里。

我们打开一看，产品参数有三个版本，报价表有两个日期，售后政策还停留在去年。问他哪个是最新的，他说要问一下运营。

这很常见。不是公司没有数据，而是数据没有主人。

数据清单只问四件事：资料在哪、谁维护、多久更新、能不能给外部系统看。

如果这四件事答不上来，模型再强也没用。它只能基于给它的内容回答，内容本身矛盾，它就会给出一个听起来很合理、实际错误的答案。

第三张纸，是验收。

客户一开始说：“答得准就行。”

我们又追问：哪些问题必须答对？哪些问题可以转人工？哪些数据不能碰？出错以后怎么回滚？

他想了很久，写下了十几条。后来这些条目变成了测试题：常见问题、边界问题、异常问题，各挑几条，用真实业务跑一遍。

验收清单不是为了卡供应商，而是让双方对“做完”有同一个标准。没有它，项目很容易变成“再优化一下”，谁也不知道什么时候结束。

聊完以后，客户把第一版范围从“整个客服部门”缩到了一个具体任务：先做订单查询和常见售后问题。

预算没有增加，第一版反而更容易验收。对方有点不甘心，觉得功能少了。

但范围缩小后，至少上线时知道该看什么：哪些问题答对了，哪些转人工了，哪些知识还没补。

这比“做一个很聪明的客服机器人”实在。

如果只是做一个内部小工具，三张纸可以压缩成一页。

但如果项目要接客户数据、接现有系统、上线后还要有人维护，这三张纸最好别省。省下来的时间，后面通常会以返工的方式还回来。

智能体定制的起点，不是选模型，也不是比报价，而是把要解决的问题写清楚。

如果你也在评估定制项目，可以先看我们的智能体定制服务，或者从企业 AI 解决方案验收清单开始，把验收标准先定下来。