用扣子（Coze）搭建一个数字员工
扣子（Coze）这类平台，让不会写代码的人也能搭出一个能对话、能查资料、能干活的数字员工。这篇按”角色 → 知识库 → 工具 → 测试 → 发布”的通用流程，讲清搭建思路，每一步我都会给你具体怎么做、容易踩哪些坑。注意：各平台界面会更新，本文只讲通用步骤，不绑定具体菜单。我自己带团队上过好几个客服和内部助手项目，下面说的坑基本都是真摔过的。
第一步：想清楚它是干什么的
动手前先回答三个问题：它是谁（客服 / 售前 / 知识助手）？服务哪些人？要解决哪些高频问题？把岗位定窄、定清楚，是成败的关键。一个”专门答售后退换货”的数字员工，远比一个”什么都想答”的更靠谱。
判断一个场景值不值得做，我一般用三条标准过一遍：
- 问题是否高频重复。一天问一次的场景不值得投入，一天问几十上百次、且问法高度雷同的（比如”我的订单到哪了""怎么申请退款”），才划算。
- 答案是否有边界、能被资料覆盖。数字员工不擅长开放式创造性回答，擅长的是”在给定资料范围内准确检索复述”。如果这个岗位的答案本来就千变万化、高度依赖临场判断，先别上。
- 出错的代价是否可控。客服答错一个物流问题，用户顶多多等一句话；但如果是财务、法务、医疗建议这类答错会出大事的场景，必须留人工兜底，绝不能让它自己拍板。
举个反面例子：有个客户想让数字员工”回答所有关于产品的问题”，上线两周后才发现，60% 的对话其实集中在”发货时间""退换货政策""怎么开发票”这三类上，长尾问题反而拖累了整体满意度。后来把岗位收窄成”物流与售后专员”，把开发票、议价这类交给人工，满意度和响应速度都明显上来了。想了解整体方向，可参考支柱页 AI 数字员工。
第二步：设定角色（人设与指令）
在平台里新建一个智能体后，最核心的是写好”角色设定”——也就是它的身份、语气、能做什么、不能做什么。这段文字（有的平台叫 Prompt、有的叫人设/开场白）建议按四块来写，缺一块都容易翻车：
- 身份和服务范围：不要只写”你是客服”，要写”你是某品牌的售后客服，只负责物流查询、退换货政策解答，不处理议价和投诉升级”。范围写得越窄，越不容易答偏。
- 回答风格：简洁、口语化还是正式？用不用表情符号？回答长度控制在几句话以内？这些细节直接影响用户体验，建议明确写出字数或语气要求，比如”每次回答控制在 3 句话以内，不用书面语”。
- 边界规则：这是最容易被忽略、却最重要的一块。要明确写”遇到资料库里没有的信息，直接说不确定并引导联系人工客服，禁止编造具体数字、政策或承诺”。没有这条约束，模型在不确定时会倾向于”编”一个看起来合理的答案，这在客服场景里是致命的。
- 禁止事项清单：比如”不比较竞品优劣""不承诺具体到货日期""不代替用户做退款决定”。把你能想到的雷区提前列出来，比事后修补有效得多。
一个常见误区是堆一堆”专业、耐心、乐于助人”这类形容词，这些词对模型的实际约束力很弱，不如换成具体规则：与其说”要专业”，不如说”涉及价格、政策类回答必须逐字引用知识库原文”。
第三步：接入知识库
光有人设还不够，它得”懂你的业务”。把产品手册、常见问题、政策文档等资料整理好上传到知识库，平台会自动把这些内容切分、索引，让数字员工在回答时去检索引用。这一步决定了它答得”准不准”——资料越干净、越结构化，效果越好。
实操上有几个直接影响效果的细节：
- 先整理成 FAQ 对，再上传原始文档。如果你手头只有一份 30 页的产品手册 PDF，直接丢进去平台也能切片检索，但效果通常不如你先手动整理出”问题—标准答案”的一问一答形式。因为检索命中的是片段，PDF 里上下文断裂后语义容易残缺，而 FAQ 对本身就是完整的语义单元。
- 一份资料只讲一件事。把”退换货政策""发票开具流程""物流查询方式”分成三个独立文档，比塞进一个大文档里更容易被准确检索到。检索系统按片段匹配，片段边界越清晰，命中率越高。
- 给资料打好版本和时间戳。政策文档经常更新，如果知识库里同时存在新旧两版”退货政策”，很容易检索出旧版内容误导用户。上传新版前，先把旧版删除或明确标注”已失效”。
- 起步别贪多。建议先用能覆盖 70%~80% 高频问题的一小批资料（通常几十条 FAQ）跑通整个链路，观察真实提问和资料的匹配度，再逐步扩充剩下的长尾资料。一次性塞几百个文档进去，出问题时很难定位是哪份资料在捣乱。
第四步：配置工具 / 插件
如果只是答疑，知识库就够了。但要让它”干活”（查订单状态、发起留资表单、调用第三方 API 查天气或汇率），就需要挂工具或插件。扣子这类平台内置了一批常用插件（比如联网搜索、图片生成、代码执行），也支持通过 HTTP 请求接入自定义能力，把自己系统里的接口暴露成一个”工具”给智能体调用。
配置工具时容易被忽视的两点：
- 工具的参数说明要写清楚，模型不是靠猜的。工具调用的本质是模型根据你写的”工具描述”和”参数说明”，判断什么时候该调用、传什么参数。如果参数说明写得含糊（比如只写”订单号”），模型可能传错格式或漏传必填字段，导致调用失败。要写清楚参数的格式要求、示例值，比如”订单号为 12 位数字，形如 202601160001”。
- 给工具调用加失败兜底。接口超时、外部服务挂了、返回了错误码，这些都可能发生。要在人设或指令里补一条”当工具调用失败或返回异常时，如实告知用户当前查询遇到问题，引导稍后重试或转人工，不要编造一个假的结果”。没有这条兜底，模型在工具调用失败时有时会”脑补”一个看起来正常的返回结果糊弄过去，用户拿着假信息去核实时就会出大问题。
初期不用追求大而全，先把最高频的一两个动作（比如查订单状态）配通、测稳，再逐步加。一个工具没测稳定就急着上第二个，出问题时很难判断是哪个环节的锅。
第五步：测试与调优
发布前一定要自己当用户反复测，而且要按”正常问法 + 刁钻问法 + 越界问法”三类分别测：
- 正常问法：把你预设的高频问题挨个问一遍，确认答案准确、完整。
- 刁钻问法：故意用口语化、简称、错别字甚至反着问（比如”不给退货是不是违法”），看它能不能识别出真实意图，而不是被措辞带偏。
- 越界问法：故意问超出岗位范围的问题（比如让”售后客服”回答产品研发计划），看它是不是老老实实说”我不清楚，帮你转接人工”，而不是硬凑一个答案。第三类测试最容易被跳过，但也是最能暴露角色设定漏洞的一类。
把暴露的”答错案例”整理成一张表，记录”问法—错误回答—期望回答—修复方式”，逐条对着改角色设定、补知识库或加约束规则。改完要把之前测过的用例重新跑一遍，防止改好了新问题、带出旧问题的回归。
第六步：发布上线
测试满意后就可以发布。这类平台通常支持发布到网页、微信、飞书等社交渠道，或通过 API 接口接入自己的业务系统。上线不是终点——要建立一个”每周看对话记录”的习惯，重点看两类记录：用户明确表示不满意的对话，以及触发了”转人工”或”不确定”话术的对话。这两类记录里藏着最值得补的知识库缺口和最容易被忽略的边界漏洞。
还有一个容易被忽略的细节：给数字员工设一个”人工介入”的兜底通道，并定期统计转人工的触发原因分布。某一类问题反复触发转人工，说明这块知识库或工具还没配到位，是下一步该优先补的方向。
整个流程的难点从来不在工具本身，而在”把业务知识整理清楚、把边界划分明白”。工具会变、界面会更新，但”岗位定窄、资料结构化、边界写清楚、上线后持续复盘”这套方法论是通用的。如果你想直接把数字员工落到业务里、省去摸索成本，欢迎看我们的企业服务；想自己系统学会从 0 搭一个，建议从课程入手。