AI客服PRD写法：锁定单笔订单，先写回复再对接口

当AI客服需求遇上退款场景，产品经理如何避免“支持退款咨询”沦为一句空话？本文作者拉着客服一起写PRD，从一笔订单的查询、解释到转人工，拆解AI需求中“哪些事不该模型管”的边界，并分享如何用真实咨询路径验证设计、用客服和测试的视角补全异常场景。

这个退款助手的需求，我是拉着客服一起写的。

让她挑一笔还在处理中的退款单，从用户点进订单页开始，把她平时的操作走一遍。打开客服后台看订单状态，翻支付记录，审核卡住的再给财务发消息问一句。中间她会跟用户说几句话，到某个节点转给专员。

这些操作我一条条记下来，记完再分：页面负责什么，接口给什么，哪句话只能说一半，哪一步必须落回人手上。

一、先把它按到一笔订单上

“支持退款咨询”这五个字，拆开至少是四件事：查进度，解释规则，判断这笔能不能退，真的把钱退出去。四件事的成本差很远。

范围这么写，排期过得去，但没有一个人知道要做多少。客服以为包括解释退款原因，业务想顺带把催退款接住，研发估的是接知识库加一个聊天入口。等到联调才发现，催退款还得建工单、分配处理人、挂响应时效。

第一版我写三个动作：查、解释、转。

查这笔退款到哪一步；解释这一步对用户意味着什么、还要等多久；查不清、解释不了的，带着上下文交给客服。退款申请、修改金额、催办不进这一版，沿用现有入口。

这么切是因为两件事的出错代价不一样。查询说错了，用户白等一会儿，解释一句还能补；退款金额错了是钱的问题，要走财务流程。放在同一版里做，测试没法分开验，出了问题也分不清是模型说错还是流程没走通。

入口只有两个选择：订单详情页，或者客服首页。

我定在订单页。

退款这件事的信息全在这张页面上，订单号、支付方式、退款状态、最近一次更新时间，用户已经看见了。他从这里点进客服，系统知道他在问哪笔单。

放客服首页，第一个动作是选订单，选完确认是不是这一笔，然后才轮到问题本身。这三个来回，只为了把系统本来就知道的事让用户再说一遍。

客服首页这条路一旦开，第二版就得处理多笔退款、对话中途切订单、用户报错单号，这些都得排在后面。

PRD 里落成这一段：

任务：查询当前订单的退款进度。

入口：订单详情页的退款进度区域。

页面传入：登录会话、订单标识。

完成结果：用户看到最新退款状态、更新时间和下一步动作；需要核查时，从当前对话转接。

本期动作：查询、解释、转接。

本期不做：发起退款、修改退款金额、催办。

“本期不做”那一行不好写。产品得先想清楚这版到底不碰什么，才敢把文档交出去。

二、先写回复，再对接口

用户的话通常是“昨天就说在处理了，今天怎么还没到”。

别急着写模型该怎么想，先写你希望他看到的这句话：

你的退款已经审核通过，正在等待发起退款。

最近一次状态更新是昨天。

需要的话，可以联系人工客服核查进度。

写完拿这句话去找研发，只问一件事，每个词是哪个字段给的。“审核通过”是状态机哪个节点，“等待发起退款”是 pending 还是 processing，“昨天更新”记的是审核时间还是最近一次同步时间。

三个问题答不上两个，这段就没写完。好处是它问得很细节，研发没法用“应该能查到”糊过去，有就是有，没有就得当场说。

更新时间最容易出问题。页面上有这个信息，接口里未必有字段。业务系统只记操作时间，支付状态是定时同步的，两个时间差几个小时是常事。选哪个得在评审时说定：给用户看同步时间，他关心的是系统什么时候知道，不是人什么时候点的。定了写进文档，前端展示、模型解释、客服话术共用一套，别再各说各的。

到账时间是同一个问题。支付渠道给的是区间，不是承诺。说“预计 1-3 个工作日”，还是说“我们已经在处理”，这是两种产品。我用前者。用户会拿这句话去跟平台对账，错一次就是投诉。

接口返回那一块写四样：状态、更新时间、下一步说明、人工核查标记。订单归属校验放后端，别把订单号丢给模型，让它自己判断“这是不是你的单”。这一步放在哪，文档里得写出来，不写研发默认交给模型。

一份 AI 需求里，“哪些事不该模型管”这一节，通常要花更多时间，也正是评审时最容易被漏掉的一段。

措辞不用定死。“正在等待发起退款”和“审核已通过，接下来会发起退款”，两种说法让客服挑顺口的。测试验状态含义和信息完整性，逐字匹配只留给资费、时效、条款这种错一个字就要担责的地方。

把事实固定，把表达放开，改文案的时候就不用重开评审。

三、评审时让客服和测试出题

产品自己列的异常场景，都是自己答得上来的。

客服知道用户会从哪儿绕进来，测试知道怎么把条件换掉。让他们在同一份样例上碰一次，比产品在文档里列二十条靠谱。

同一句“退款到哪了”，配三笔订单：一笔审核中，一笔已发起退款，一笔渠道已确认完成。每条填满，查出来什么、回什么、页面下一步点哪儿。

往下接追问。用户说“我想找人工”，转到哪个队列，客服接进来能看到什么。用户紧接着问“能帮我催一下吗”，这版是给个入口还是有催办能力，得选一个。这些选择写进文档，研发才知道怎么拆任务。

转人工这条链单独跑一遍。测试账号，从订单页提问，点转接，让客服端真的收到。订单号、查询状态、问题摘要一起带过去，客服接起来不用再问一遍“您是哪笔单”。这一遍不跑，上线第一天就会出问题。

人工下班之后也得有个交代。机器人是 24 小时的，人工有排班，中间那段空白谁来接：留言、预约，还是直接告诉用户明天几点来。不写清楚，晚上十点进来的用户就只能对着自动回复。

评估表按这条路径填。状态解释、订单权限、转接结果分开记，用语是否顺畅另起一栏。全部混成一个总分，复盘时分不清是业务错了还是话没说好。

“用户问完还要不要找客服”这一项可以看，但不能当唯一指标。有些问题本来就该由人处理，顺利转过去就是完成；进度查询才该看用户有没有拿到有效信息。两类混在一起算拦截率，结果就是转人工的入口越做越深，用户找不到人，指标倒是好看了。

四、按整次咨询算一遍

演示只回答一轮，真实咨询常有三轮以上。用户问“退款到哪了”，接着问“那今天能到吗”，再补一句“我已经等两天了”。

这三轮后台怎么处理，要跟研发当面定：第一轮查到的结果在当前会话里复用多久，用户主动下拉刷新算不算重新查。复用时长看退款状态的同步频率，不能随口给个半小时。

成本也按这几轮算。模型调了几次，订单接口查了几次，总共等了多久，最后有没有转人工。试运行跑一周，拿这些数据决定优化哪一段，比在会议室里猜“用户应该不会问这么多”有用。

查询慢的时候要有交代。先显示“正在查询”，到了约定时限给重试和其他处理方式。这个时限由产品、研发、客服一起定，写进验收样例，测试直接模拟一个慢接口。

排查记录也得留：那次对话用了哪版政策，接口返回什么，助手说了什么，转接成没成。脱敏和访问权限按现有数据规则做。客服报问题时带编号过来，研发能直接翻到那一次查询。

上线之后这份文档还会继续长。一条没见过的问法，一个新的支付状态，一次客服接不住的转接，都是下一版的修改项。把结论补回原来的样例，换模型、改接口时再跑一遍，之前定下的规则就留住了。

交出去那天，研发能顺着一笔订单往下开发，客服能拿样例确认处理方式，测试能换几组条件验收，这份文档就算写完了。聊天窗口用什么颜色、推荐问题摆几条，最后半小时定，那些不费劲。

先让它把一笔退款说清楚。别的排后面。

本文由 @王蒙 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议