客户说「做个 AI 助手」，我该怎么问回去

「我们客服每天处理很多重复咨询，能不能用 AI 做个助手？」

如果这句话是客户对我说的第一句话，那我的第一反应不该是打开平台新建应用。我应该先问回去。

因为这句话里几乎没有可用信息：多少咨询？重复的是什么？谁来用？做到哪一步算完？不能做什么？上线后怎么算成功？

我做过三年一线业务，自认为「听懂客户」是我的强项。但老实说，我以前靠的是直觉 —— 听对方讲一段，脑子里蹦出一个方案。这在小团队、短链路的场景里够用，可一旦对方是个有两百人客服团队、有工单系统、有合规要求的企业，直觉就会漏掉关键的东西，而且漏在哪你自己都不知道。

后来我学了一套结构化的做法，分三步：把需求拆成 7 个维度 → 写成一张 8 字段的画布 → 用 4 个信号判断该用什么模式承载。 这篇文章是这套方法的完整记录，包括我自己拿它重做旧方案时的发现。

第一步：把一句话拆成 7 个维度

客户不会说「我要一个标准模式的知识问答应用」，他只会用业务语言描述痛苦。我的工作是把这句话拆开。

维度	要问清楚什么	示例回答
背景与现状	现在谁在处理？量多大？痛点是慢、不准、成本高还是体验差？	客服 200 人，大量问题重复，夜间响应不稳定
业务目标	要提升什么指标？降本、提效、提准确率、提转化率还是合规？	降低转人工率、缩短响应时长、提升满意度
使用对象	谁用？员工、客服、运营、销售、客户还是管理层？	一线客服看回复建议，客户自助，主管看热点
任务边界	智能体负责到哪一步？只回答，还是生成工单、调接口、写报告？	先回答常见问题；退款、投诉升级、身份校验转人工
资料与知识	有没有制度、FAQ、SOP、话术、产品手册、历史工单？质量可用吗？	有 FAQ 和历史话术，但格式不统一
系统与工具	要不要接 CRM、工单系统、数据库、企业微信、小程序？	需对接工单，后续接企业微信和小程序
限制与验收	有哪些不能答、不能做、不能越权的边界？怎么判断达标？	敏感问题拒答；准确率、转人工率、响应时长作验收

七个问题问完，那个「做个 AI 助手」基本就被翻译成一个具体得多的东西了。

第一期只切最容易闭环的口子

这里有一条我特别认同的原则：不追求一次覆盖客户的所有愿望。

第一期只选最容易闭环、最容易验证价值的切口。判断依据很朴素：

能找到稳定资料的 → 优先做知识类能力
流程已经固定的 → 优先做流程自动化
需要多角色协同的 → 先确认每个角色职责是否清楚
需要读写文件、跑代码的 → 先手工验证一遍，再决定是否沉淀成固定应用

理由不是「循序渐进」这种漂亮话，是很现实的：第一期的成败决定有没有第二期。 一个覆盖面广但每块都半吊子的方案，验收时哪一块都拿不出硬指标。

我自己在校园业务里就是这么做的 —— 先只做「内容生成」一类 Agent，跑通了、有人用了，才加话术推荐和知识问答。如果一上来三类一起上，大概率三类都是半成品。

第二步：写成一张 8 字段的画布

问完之后，把答案压缩成一页能评审、能搭建、能验收的画布。

不追求长，只求关键决策说清楚。八个字段：

背景与现状 —— 现在业务怎么做，痛点在哪，为什么现在要引入 AI
业务目标 —— 要提升的核心指标（准确率、解决率、响应时长、转人工率、采纳率、生成耗时）
用户与入口 —— 谁用，在哪用（Web / 企业微信 / 小程序 / API / 内部系统）
承载模式 —— 标准 / 单工作流 / Multi-Agent / 智能工作台，并说明为什么选它
知识与资料 —— 需要哪些文档、FAQ、SOP、历史工单、话术、表格、数据库
流程与工具 —— 哪些步骤、节点、插件、API、数据库、企业系统
输入与输出 —— 用户输入什么，输出什么，要不要 JSON / 表格 / 报告 / 工单 / 文件
边界与验收 —— 不能做什么，异常怎么兜底，用哪些指标和测试集验收

第 8 个字段是最容易空着的，也是最不该空的。

我以前写的方案（那份 3.2 万字的家具零售方案就是典型）往往把前七个字段写得极详实，第八个一笔带过 —— 「敏感问题转人工」就算写完了。结果方案看起来很专业，但没法验收：什么叫敏感？转人工的触发条件是什么？准确率多少算达标？不知道。

一份不能验收的方案，本质上是没写完的。

第三步：用 4 个信号判断承载模式

需求清楚了，接下来是技术选型。这里不需要做复杂的评分矩阵，抓住四个信号就够：

判断信号	典型表现	优先方向
流程是否固定	步骤清楚、每次按同一路径执行	单工作流模式
答案是否需要稳定溯源	围绕制度 / 产品 / 政策 / FAQ，答案要可信可引用	标准模式
是否需要角色协作	需调研、分析、复核、写作、风控多角色分工	Multi-Agent 模式
是否需要动手处理文件 / 代码	读文件、生成文件、跑代码、处理表格	工具增强模式
是否还在探索需求	只想把想法快速生成初稿	工作台入口

同一个需求可以分阶段换模式。 这是最容易被忽略的一点 —— 很多人上来就选最复杂的 Multi-Agent，因为它听起来最先进。

举个酒店智能服务助手的例子：

第一期：标准模式做信息问答（住客问早餐几点、健身房在哪）
第二期：流程固定后用工作流串起「参数收集 → 工单生成 → 结果通知」
第三期：经营分析再引入 Multi-Agent

每一期的复杂度都在前一期的验证基础上增加。跳级是方案失败最常见的原因。

从画布到搭建：四层拆解

画布解决「要做什么」，接下来要解决「怎么搭」。拆四层：

① 业务流程拆解 —— 把业务动作按顺序写出来，区分由用户完成 / 智能体完成 / 仍需人工。关键判断：流程越固定越适合工作流，越开放越需要 Agent。

② 输入输出拆解 ——

输入：问题、文件、图片、表格、链接、编号
中间变量：意图类别、关键字段、检索结果、判断结果、置信度、异常原因
输出：自然语言 / 引用来源 / 结构化字段 / JSON / 报告 / 工单号

中间变量这一层我以前不重视，后来发现它决定了你能不能调试。不把中间变量定义清楚，出问题的时候你只能看到一头一尾，中间全是黑箱。

③ 知识依赖拆解 ——

制度政策类：按主题拆、保留版本、打开引用
产品服务类：命名清晰、更新机制明确
话术案例类：精选高质量样本、按问题类型整理
表格数据：字段规范、清空行、明确是否需要 Text-to-SQL

「保留版本」这一条我吃过亏。资费政策更新了，旧文档没下线，系统同时召回新旧两份，给出自相矛盾的答案 —— 用户不会觉得是「文档管理问题」，只会觉得「这个 AI 不靠谱」。

④ 系统依赖拆解 —— 查什么系统、调什么能力、守什么权限、留什么日志。

两条红线

这套方法里有两条是硬性的，没有商量余地。

红线一：操作分级。

只读查询 → 权限范围内自动执行
创建工单等可逆动作 → 校验入参并留痕
删除、付款、改价、赔付、改配置 → 必须审批或二次确认，并准备回滚与人工接管

红线二：高风险领域保留人工审核。

法律、医疗、金融、绩效处分这类输出只能作为辅助信息，必须由授权专业人员审核。

而且要记住：免责声明不能替代可靠依据、权限控制、人工确认和申诉渠道。 在页面底部写一行「AI 生成内容仅供参考」，不构成任何责任转移。

拿这套方法重做我的旧方案

学完这套东西，我回头干的第一件事是拿 3.2 万字的家具零售方案开刀。

结果有点尴尬：那份方案里其实什么都有 —— 七个环节的拆解、每个环节的现状还原、AI 方案、落地形态、价值测算，写得很细。

但它没有一页能评审的画布。

客户（或者说我自己家人）看完 3.2 万字，还是回答不了三个问题：第一期到底做什么？做完怎么算成功？不做什么？

按八个字段重做之后，整份方案压成了一页纸。剩下三万字变成附件 —— 需要细节的时候去翻，但决策只看那一页。

这个变化让我意识到一件事：方案的价值不在于厚，在于能不能拿去评审。 一份没有人能一次性读完的方案，等于没有人真正评审过它。

这套方法对我真正的改变

我原来以为自己的强项是「听得懂客户」，学完之后发现，我真正的强项是**「能从客户的抱怨倒推出可衡量的目标」** —— 客户说「宣传跟不上」，我能推出「周内容产能太低」这个可量化的指标。这个能力是三年一线喂出来的，很难教。

但过去我缺的是结构。靠直觉推导，快，但会漏：漏掉权限边界、漏掉验收指标、漏掉「什么不该做」。而漏掉的东西往往在交付后期才暴露，那时候改的成本极高。

现在我的动作是：直觉负责找到痛点，模板负责保证不漏项。

这两件事不冲突，而且是互补的。只有模板没有直觉，方案会很规范但抓不住真问题；只有直觉没有模板，方案抓得准但会在细节上翻车。

最后

如果你也在做 AI 方案，有一句话我想单独强调：

客户嘴里的需求，几乎从来不是真正的需求。

「给我做个聊天机器人」，真问题可能是报销单流程太慢，或者排班表全靠人肉协调。

把问题问对，比把方案做漂亮重要得多 —— 而问对问题的前提，是有一套能逼自己逐项检查的结构。

我以前靠运气做到这件事。现在我靠七个问题。