智能体上线前验收：20 条问题跑一轮，产出一张记录表

一句话结论

智能体上线前，用 20 条真实场景问题跑一轮验收并逐条记录，一份验收记录表就能挡住大部分上线事故。

这篇解决什么问题

我见过太多智能体是「自己试的时候很顺，同事一上手就翻车」——因为发布前只点了三五条顺手的问题。这篇就是把上线前那次验证，变成一件有清单、有记录、有结论的活。

适用：智能体已经能跑通一轮对话，准备给内部同事或外部用户使用。不适用：还在纠结要不要做智能体，或者知识库根本没喂进去的阶段，那时候验收没有意义。

开始前要准备什么

• 扣子或 Dify 账号一个，两家的免费额度做这一轮足够
• 一个能正常对话的智能体，别在空壳上验收
• 20 条问题清单，先草稿写在记事本里也行
• 一张表格，飞书表格或 Excel 都可以，先建好表头
• 整轮预留两到三小时，拆成两段做也不影响

具体怎么做

第 1 步 · 把 20 条问题凑齐

别自己硬想。把你写给智能体的角色说明整段贴给 AI，让它按场景分布出题，比拍脑袋凑得全。

你是一名测试设计人员。下面是我给一个智能体写的角色说明，请据此设计 20 条验收问题。
要求：
1. 分五类，每类 4 条：正常业务问题、信息不全的问题、超出范围的问题、容易误解的模糊问题、故意诱导或带情绪的问题。
2. 每条写得像真实用户打出来的字，一句话到两句话，不要写成考题口吻。
3. 输出表格，四列：序号、类别、问题原文、这条想验证什么。
4. 最后单独列出你认为最容易让这个智能体答错的三条，并说明理由。
角色说明如下：
【把角色设定、能做什么、不能做什么、知识库覆盖范围贴在这里】

预期产出：一张 20 行的表格，五类问题齐全，每题都标了要验证什么，还额外拿到三张「高危题」。

第 2 步 · 建一张验收记录表

表头字段先定死，不然后面 20 条会记成流水账。我第一版只记了「问题」和「通过没通过」，回头想看原因，一条都回忆不起来。

我要给一个智能体做上线验收，需要一张记录表。请给出表头字段和每个字段的填写说明。
约束：
1. 字段不超过 8 个，要能一行记完一条问题的完整结果。
2. 必须包含：问题类别、用户问题原文、智能体原始回答、判定结果（通过／部分通过／不通过）、一句话判定理由、严重程度、需要改的位置（提示词／知识库／工具调用／超纲）。
3. 判定理由只写一句话，不要长篇分析。
4. 最后告诉我，填表时最容易被敷衍过去的是哪个字段，以及怎么防止。

预期产出：一份字段清单，照着在表格工具里建表，几分钟能建完，后面所有记录都往里填。

第 3 步 · 一条一条跑，跑一条贴一条

整轮跑完再回头补记录，是件几乎做不到的事。跑一条贴一条，中途别去改配置，否则前面几条的结论就作废了。

下面是这轮验收里的一条记录，请判断回答是否合格。
判定标准：
– 通过：关键信息答对，且没有编造内容。
– 部分通过：方向对，但漏了关键点或表述含糊。
– 不通过：答错、答非所问，或编了知识库里没有的内容。
请输出四行：
1. 判定结果
2. 一句话判定理由
3. 严重程度（阻断／严重／轻微），并说明依据
4. 最可能的问题出处：提示词、知识库、工具调用，还是问题本身超纲
用户问题：你们的设备保修期是多久
智能体回答：【贴它的原话】
角色说明和知识库范围：【贴简要版】

预期产出：每条一行判定结果，20 条跑完，表格自然是满的，不用二次整理。

第 4 步 · 把不通过的归堆

单条看是毛病，归堆看才是模式。这一步很多人容易忽略，但改配置的效率差别很大——按根因改，一次能修掉好几条。

以下是我这次验收里所有判定为「部分通过」和「不通过」的记录，共【N】条，请做归因分析。
要求：
1. 按根因分组，不要按问题类别分。可能的根因包括：角色说明没写清、知识库缺内容、有内容但检索不到、工具调用参数错、模型对模糊问题的处理习惯。
2. 每组写清：涉及哪几条（只写序号）、判断依据、改动最小的修法。
3. 按「改一次能解决多少条」从多到少排序。
4. 如果某几条其实是同一个根因，合并掉，别重复列。
记录如下：
【把不通过的记录整段粘进来，含原始回答和理由】

预期产出：两到四组根因，每组带一个最小改法，接下来改什么、先改哪个，一目了然。

第 5 步 · 复跑几条，抽几条通过的对照

只复跑失败的那几条，很容易漏掉「改 A 坏 B」。我踩过：补了退款知识，结果把发票那题的答法带偏了。

我刚改了这个智能体的配置，改动是：【一句话说明改了什么】。请从下面这 20 条问题里挑出 8 条用于回归测试。
挑选规则：
1. 原先不通过的全部入选。
2. 再挑 3 条原先通过的，优先挑和改动内容相邻的场景。
3. 输出表格：序号、问题原文、上轮结果、这轮重点看什么。
20 条问题原文：
【粘贴题目清单】

预期产出：一份 8 条左右的回归清单，跑一遍，就能判断改动是真修好了还是换了个地方坏。

第 6 步 · 写一句人话结论

验收表最后得落一句能贴进群里的话，别只留一堆「通过」。这一步我一般自己写，让 AI 起个草再改。

请根据我这份验收记录，写一段上线结论，控制在 150 字以内。
包含四件事：
1. 测了多少条，通过、部分通过、不通过各多少。
2. 还剩下什么问题，影响哪类用户。
3. 建议：直接上线／限定范围上线／暂不上线，选一个并说理由。
4. 上线后一周内重点观察什么。
记录：【粘贴整张表或摘要即可】

预期产出：一段 150 字以内的结论，附一句「限定范围上线」之类的明确建议，直接发出去。

实测记录

最容易错的 3 个地方

下面三条都是我或者同事真踩过的，不是理论上的可能。

1. 问题全挑顺手的，等于没测。至少留五条刁钻的。
2. 跑一条改一版配置，结果没法对比。整轮跑完再动手。
3. 只记「不通过」，理由空着。理由才是归因的原料。

可复用的东西

整篇的六段提示词可以抄成一份固定清单：出题、建表、单条判定、归因归堆、回归挑题、写结论。存成一个文档，下次换智能体只需要替换角色说明和记录内容。

验收这事本身不复杂，难的是把它当正事做，而不是发布前点两下。20 条问题挡不住所有问题，但能挡住那些一上线就会被同事撞见的问题。

你现在手上这个智能体，如果明天就要给别人用，你能立刻报出哪三条它是答不好的吗？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接