AI Agent项目如何做用户验收？真实项目经验总结

全文约 3600 字，预计阅读 7 分钟。AI Agent的产出是概率性的，传统UAT的"对/错"二元判断失效了。本文分享一个三层评估架构（自动完整性检查 → LLM-as-Judge → 业务抽样验收），以及工程与业务协作的三个认知陷阱。

"AI项目还需要做UAT（User Acceptance Testing）吗？"

这个问题是在我们的AI Agent系统即将交付业务用户时，工程团队内部提出的。表面上看这是一个简单的流程问题，但深入想下去，你会发现它触及了AI项目与传统软件项目之间的一个差异:

传统软件的产出是确定性的，AI的产出是非确定性的。

传统UAT验证的是"功能是否按规格工作"：输入A，是否得到B？通过还是不通过？

但AI Agent的产出存在天然的方差，同一篇输入文档，跑两次可能得到措辞不同、侧重点不同、甚至结论略有差异的输出。

在这种情况下，"对不对"这个问题本身就不成立了。

我们最终的答案是：AI项目仍然需要UAT，但目的从"验证对错"变成了"管控质量下限"。

这篇文章记录了我们从设计到实施的完整过程和经验。

传统UAT建立在两个隐含假设之上：

1. 输出是确定性的，相同输入必须产生相同输出

2. 正确性是二元的，要么对，要么错

AI Agent项目同时打破了这两个假设。

我们的系统是一个多步骤的分析管线，由多个AI Agent执行，大致上，分步骤进行结构化信息，补充背景，深度分析，和生成结果等若干步骤。

每一步都有LLM参与，每一步的输出都存在方差。

如果还用"输出必须完全一致"来验收，这个系统永远过不了UAT。

我们最终采用的验收标准是一个质量区间：

下限

产出不能低于这个水平（事实、关键信息、格式等七个评估维度）

上限

不设上限，AI有时候会给出超预期的洞察

验收判断

产出是否稳定落在下限之上？

这个转变听起来简单，但执行起来有一个关键难题：下限由谁来定义？

工程团队可以定义"格式不能乱"，但无法定义"分析深度够不够"。这直接引出了我们设计UAT时最核心的架构决策。

经过反复讨论，我们把UAT评估拆成了三层，每层对应不同的验证目标和执行方式。

这一层回答的问题是："系统有没有正常跑完？"

具体检查项包括：

• 每个Agent是否产出了目标文件？文件是否合理？

• 输出格式是否符合模板约定？

• 上下游数据是否正确传递？

• 完整性标记是否存在且状态为complete？

这一层完全可以自动化，写成脚本在每次管线运行后自动执行。不需要人工参与，不需要业务判断。

我们在实践中学到的一个教训是：不要只检查"有没有"，还要检查"是不是空泛的"。

例如，早期版本的检查会验证"影响分析章节是否存在"，但AI有时候会输出一段看似完整实则全是套话的内容，类似于"值得关注"、"需要进一步观察"、"可能有影响"。我们后来增加了一个"空泛内容检测器"，维护了一个套话词库，当影响分析章节中的套话密度超过阈值时，标记为警告。

另一个实践发现：字段匹配的正则不能太宽泛。

系统会给每项分析标注优先级（P1-P4），需要检查不同产出文件之间优先级是否一致。最初的检查逻辑是"在整个文件中搜索P[1-4]"，结果经常误匹配到正文中推荐行动表格里的优先级标注，而不是元数据头部的优先级字段。修复方法是限制只在文件前15行或带有 "Priority" 标签的行中提取。

这种bug很细小，如果没检测到，gate check就会持续误报优先级一致。

这一层回答的问题是："产出的内容质量有没有明显退化？"

核心思路：用一个LLM来评估另一个LLM的输出。 这不是什么新概念，但在实际落地时有几个关键设计决策：

决策1：需不需要标准答案（Golden Set）？

最初我们以为必须先准备一批人工审核过的"标准答案"才能启动LLM-as-Judge。后来发现这是一个"鸡生蛋，蛋生鸡"的问题：你需要系统产出来让业务审核，但你又想在业务审核之前就有自动化评分。

解决方案是把评估维度分为两类：

客观维度的评分可以立即启动：

事实准确性

产出中提到的数据、名称、时间线是否与输入材料一致？有无捏造？

信息覆盖率

让Judge先从输入材料中提取关键事实列表，再核查产出是否涵盖

格式合规

是否符合模板结构要求

主观维度则需要留白，等业务用户校准后再填充：

• 分析深度是否足够？（"足够"的标准由业务定义）

• 行动建议是否可操作？（"可操作"的标准由业务定义）

• 优先级判断是否合理？（判断逻辑取决于业务团队的决策体系）

这里有一个重要的认知纠正： 在讨论过程中，工程团队一度想把主观维度也先写好："我们先定一个标准，不完美也没关系，后面再校准"。但这实际上是工程团队在替业务用户定义什么叫"好"。

UAT目标是"让系统产出符合用户需求"，这个"需求"的定义权必须在用户手里。先写再改的成本比看似更高的"等用户反馈"实际上更高，因为它会在校准阶段引入锚定效应，业务用户会被你预设的标准所影响。

决策2：LLM-as-Judge的准确度够用吗？

LLM-as-Judge与人类评判的一致性大约在70-80%。这意味着它不适合做最终裁判，但非常适合做回归预警。

它的核心价值是：

• 改了prompt后，跑5篇测试，5秒出分数，看是否明显下降

• 换了底层模型后，量化对比质量差异

• 新增输入类型后，快速检测系统能否处理

这一层回答的终极问题是："这个产出对我做决策有用吗？"

没有任何自动化手段可以替代这一层。但关键在于如何设计业务用户的参与方式，使其成本最低、反馈质量最高。

这就来到了架构的第三部分，不再仅仅是AI和软件，而是"人件"。

这是我们整个UAT实践中最有意思的部分，也是我认为对读者最有价值的部分。

我们最初的计划是：

1. 工程做好技术准备

2. 给业务用户发一份UAT说明文档，解释为什么需要测试、怎么测试

3. 用户按照文档执行测试

4. 收集反馈

这个计划的问题在第2步。业务用户的时间极度稀缺，发一份流程说明文档的大概率结果是"已读未回"。你在要求对方学习一个对他没有直接价值的新流程。

修正后的做法是：不发流程，发产出。不解释为什么，直接问好不好。

例如，我们给业务用户发的测试邮件核心内容是：

"附了3份系统产出，请花15分钟看一下： 1. 哪份质量OK？ 2. 不OK的哪里不满意？ 3. OK的能否作为后续基线？"

三个问题，每个一两句话就能回答。用户面对的是具体的产出物，不是抽象的流程描述。 他的自然反应就是评价好坏，这正是我们需要的输入。

在系统还有已知问题时，有一种诱惑是"先发给用户看看，让他早点参与进来"。

不要这样做。 第一印象一旦形成就很难扭转。如果业务用户看到的第一版产出质量很差，你后续需要花数倍的努力来重建信任。"上次你给我看的那个完全不能用啊"这种记忆会持续很久。

正确的做法是，先确保产出达到你自己觉得"拿得出手"的水平，再发出去。这意味着UAT的启动时间可能会推迟，但每一次与业务用户的交互都应该是高质量的。

工程团队天然倾向于"把事情做完再交付"。但在AI项目的UAT中，有些事情不应该做完，因为做完就意味着你替业务做了判断。

最终形成的分工模式：

核心原则：工程降低业务的审核量，业务提供质量标准的定义权。 两边各做自己擅长的事。

很多介绍AI评估的文章会说"你需要先准备一个Golden Set"，让人觉得这是一个前置条件、一个需要专门投入资源去做的事。

我们的经验是：Golden Set是自然沉淀出来的，不是刻意制造的。

流程是这样的：

1. 系统产出 → 自动评分 → 标红异常

2. 异常case推给业务审核

3. 业务说"这篇OK" → 它就成了一个golden case

4. 业务说"这篇不行" → 它的反馈成了评分标准的校准数据

第一轮可能有0个golden case，但每过一轮就会积累几个。不需要一开始就有50篇标注好的标准答案。

这种"从生产中沉淀"的方式有两个好处：

零额外成本

不需要业务用户专门抽时间"造"标准答案

更贴近真实场景

golden case来自真实的业务输入，而不是精心挑选的测试用例

如果你也在做AIAgent项目，以下是我建议的起步路径：

• [ ] 为每个Agent的产出定义"完整性标记"（completion marker），包含Agent名、产出物指标、状态

• [ ] 写一个基础的gate-check脚本，检查文件存在性、大小、标记存在

• [ ] 定义FAIL和WARN的区分标准

• [ ] 增加空泛内容检测

• [ ] 增加跨文件一致性检查

• [ ] 设计LLM-as-Judge的客观维度评分prompt（事实准确性、信息覆盖率）

• [ ] 确定业务对接人，但先不联系

• [ ] 用真实产出做一次自检，确认产出质量"拿得出手"

• [ ] 给业务用户发2-3篇具体产出 + 3个具体问题

• [ ] 根据反馈校准评分标准、积累golden case

• [ ] 建立日常循环：自动评分 → 异常推送 → 业务只审异常

• ❌ 在产出质量不稳定时就联系业务用户

• ❌ 给业务用户发流程文档而不是具体产出

• ❌ 替业务用户定义"什么叫好"

• ❌ 把所有检查都设为FAIL（会导致通过率过低，团队开始绕过检查）

回到开头的问题："AI项目还需要UAT吗？"

答案是需要，但UAT的本质变了。

传统软件开发中，工程和业务的协作模式是"业务写需求 → 工程实现 → 业务验收"。验收的对象是"功能是否符合需求文档"。

AI项目中，这个模式失效了，因为"需求文档"无法精确描述AI应该产出什么。你不可能写一份规格说"当输入是关于某公司财报的文章时，分析报告的第三段应该包含以下内容"。

新的协作模式是：

工程搭建质量检测的基础设施，业务通过审核真实产出来定义质量标准。两者交替迭代，而不是瀑布式交接。

工程不替业务判断"好不好"，业务不需要理解"系统怎么工作"。各自提供自己领域的专业判断，通过一个低成本的反馈循环连接在一起。

这种协作方式在传统软件开发中是不存在的。而在AI项目中，当输出是概率性的，验收变成了一个持续的校准过程。

这个校准过程的设计质量，决定了你的AI系统最终能否真正被业务用户接受和使用。

本文基于一个企业级AI Agent分析系统的真实UAT实践，项目细节已脱敏处理。文中提到的技术方案和协作模式已在生产环境中验证。