AI软件评测,到底新在哪里?

AI · 软件工程 · 深度对话

一场从“另起炉灶”到“回到软件工程”的对话

阮平：最近大家都在谈大模型评测、AI Agent评测。仿佛只要软件里加入了大模型，就必须另起炉灶，建设一套全新的评测体系。你也这样认为吗？

华云：先别急着“另起炉灶”。我们得先问清楚：所谓“全新”，究竟是评测对象变了、方法变了，还是软件评测最基本的逻辑变了？

阮平：至少和普通软件不一样吧。普通软件按照程序执行，大模型却会生成答案；AI Agent还会自己安排步骤、调用工具、完成任务。

华云：所以你的判断是：普通软件按照确定规则运行，AI软件则会“生成”自己的行为？

阮平：大致如此。普通软件看功能对不对，AI软件还要看行为靠不靠谱。

华云：那我再问几个问题。采用随机算法的软件算什么？根据实时路况重新规划路线的软件算什么？根据业务状态选择不同处理分支的工作流系统，又算什么？

阮平：它们当然还是普通软件。

华云：但它们同样可能没有唯一的执行路线，也会随着环境变化得到不同结果。可见，“每次是否走同一条路”，并不是普通软件与AI软件的分界线。

阮平：可AI Agent能够自己决定用什么工具、按什么顺序完成任务，这和固定流程还是不同。

华云：传统工作流就一定是固定的吗？

阮平：不一定。它也可以动态选择分支、生成任务、调用外部服务。

华云：那么，AI Agent的任务组织方式与传统工作流之间，究竟是本质不同，还是复杂程度和实现方式不同？

阮平：这样看，更像是后者。

一、模型真的不是“软件”吗？

阮平：即使AI Agent的工作方式可以和传统流程相比，大模型本身总是特殊的。模型毕竟不是普通代码。

华云：模型可能不是工程师一行一行写出来的源代码，但它是不是决定软件行为的核心部件？

阮平：是。

华云：那么从软件工程角度看，它能不能像程序、规则引擎、配置文件和算法库一样，被编号、管理、测试和更新？

阮平：可以。

华云：再看AI软件里的其他部分。提示词像规则模板或配置脚本，知识库像数据库或外部资料源，上下文是软件当前掌握的信息，记忆是保存下来的历史状态，工具则类似接口或插件。形式虽然新，但在软件系统中都能找到对应位置。

阮平：确实都能对应上。

华云：模型版本、提示词版本和策略版本，也完全可以纳入统一的版本管理和配置管理。

阮平：也可以。

华云：那么，仅仅因为AI软件多了模型、提示词、知识库、记忆和工具，就认为它已经脱离软件工程，显然站不住脚。

阮平：也就是说，AI软件首先仍然是软件。

华云：对。模型可以很特殊，但不能因为它特殊，就把它排除在软件工程之外。

二、没有唯一答案，就没法测试吗？

阮平：可大模型的输出很开放，很多问题没有唯一正确答案。普通软件通常有明确的预期结果。

华云：人们使用AI软件时，有没有明确的期望？

阮平：当然有。

华云：比如让一个AI Agent制定出差计划，路线可以有很多种，但用户仍然会要求它满足时间、预算、安全和行程安排，对吗？

阮平：对。条条大路通罗马，但“要到罗马”这件事不会变。

华云：那么，没有唯一答案，是否就等于没有判断标准？

阮平：不等于。可以规定目标和限制条件，不必规定唯一过程。

华云：传统软件中，是不是也存在多个正确结果、多个可行路径，甚至只能用统计方式判断好坏的情况？

阮平：是。推荐系统、搜索系统、调度系统和随机算法都可能如此。

华云：所以，“没有唯一标准答案”并不是AI软件独有的问题。它只是让判断标准更复杂，却没有改变软件评测的基本逻辑。

阮平：这个基本逻辑仍然是：人在规定条件下提出要求，观察软件的实际表现，再判断它是否可以接受。

华云：正是如此。

三、AI评测结论真的更依赖条件吗？

阮平：但AI软件的评测结论，需要写清模型版本、提示词、知识库、测试样本和运行参数。它似乎比普通软件更依赖具体条件。

华云：普通软件的测试结论就不依赖条件吗？

阮平：也依赖。

华云：一个软件在Windows环境下通过测试，能否直接证明它在所有Linux环境下也合格？

阮平：不能。

华云：一个系统在1000个并发用户下运行正常，能否证明它在100万个并发用户下仍然正常？

阮平：不能。

华云：一个安全产品通过了今天已有的攻击测试，能否证明它面对未来所有攻击都安全？

阮平：也不能。

华云：所以，任何软件评测结论，都只在特定版本、环境、输入范围、运行压力和测试方法下成立。AI软件只是多了模型、提示词、知识库等需要说明的条件。

阮平：那么，“结论依赖条件”也不能算AI评测的核心区别。

华云：同样，“AI软件需要持续评测”也不是它独有的特点。普通软件在代码升级、配置变化、依赖更新或运行环境迁移后，同样要重新测试。

四、我们是不是把问题问错了？

阮平：讨论到这里，很多被认为是AI独有的特点，似乎都能在传统软件中找到类似情况。

华云：是的。我们至少可以先形成一个共识：

阮平：那是不是根本没有必要区分普通软件评测和AI软件评测？

华云：也不能这么说。密码软件、嵌入式软件、数据库软件和工业控制软件都属于软件。它们并没有各自发明一套全新的测试理论，但仍然需要有针对性的测试方法和工具。

阮平：因为它们面对的主要风险和实际难题不同。

华云：对。AI软件评测也应该这样理解。它不是一套脱离传统软件评测的新理论，而是针对AI软件特殊表现形成的一组专门能力。

阮平：那么，真正应该问的不是“AI评测是不是全新的”，而是“大模型和AI Agent让哪些老问题变得更突出”。

华云：这才问到了点子上。

五、一次运行正确，能说明它真的可靠吗？

华云：假设我们给一个普通业务软件输入同样的数据，而且版本、配置和初始状态都不变，多次运行通常会得到什么结果？

阮平：相同或等价的结果。

华云：如果第一次失败，第二次、第三次也在同一个地方失败，这个测试是不是能比较有力地说明软件确实有问题？

阮平：可以。

华云：那么，把同一个问题连续问一个大模型应用5次，结果会不会不同？

阮平：会。它可能4次答对、1次答错，也可能某一次突然漏掉关键条件。

华云：一个AI Agent执行同一项任务时，会不会选择不同的工具、参数或调用顺序？

阮平：也会。

华云：那么，对AI软件来说，一次成功能证明什么？

阮平：只能证明它这一次成功了。

华云：一次失败又能证明什么？

阮平：它说明可能存在风险，但还不能说明问题会不会反复出现，也不能说明出现的概率有多大。

华云：这就是AI软件评测中第一个特别突出的难点：

因此，AI评测不能只问“这一次通过了吗”，还要继续追问：同一个样本多跑几次，失败几次？换一种问法，结果会不会变？调整上下文顺序后，问题还在不在？更换模型、知识库或工具后，表现有没有改善？这是偶尔失手，还是能力本身存在短板？是否还有一些平时很少发生、但一旦发生后果严重的风险？

阮平：普通软件中也有并发错误、随机错误和偶发故障。

华云：没错。所以不能说这类问题只有AI软件才有。真正的区别是，这种不稳定性在AI软件中更容易直接出现在核心功能里。

普通软件通常会尽量把随机因素隔离和控制；而对大模型软件来说，带有一定随机性的生成过程，本身可能就是核心功能。

所以，两者不是“一个有、一个没有”，而是评测关注的重点不同。

六、接口都正常，答案为什么还是错的？

华云：再看另一个问题。传统软件出错时，我们通常怎么处理？

阮平：先复现问题，再检查代码、接口、数据库、配置和运行环境。

华云：最后通常能不能把问题逐步缩小到某个具体环节？

阮平：虽然有时很难，但一般可以。

华云：假设一个大模型应用的所有接口都调用成功，检索系统也正常返回资料，AI Agent的任务流程顺利结束，系统没有报任何异常，但最终答案却包含严重的事实错误。问题到底出在哪里？

阮平：可能是模型能力不够。

华云：也可能是检索时根本没有找到关键资料吗？

阮平：可能。

华云：也可能资料找到了，但最重要的内容没有排在前面吗？

阮平：可能。

华云：也可能资料本身正确，但内容太多，关键信息被淹没了吗？

阮平：可能。

华云：还可能是系统要求写得不够清楚、工具说明有歧义、历史记忆造成干扰，或者模型误解了工具返回的结果，对吗？

阮平：都有可能。

华云：那么，一个不可接受的AI行为，是不是经常很难直接对应到某一处代码错误？

阮平：是。它往往是多个环节共同影响的结果。

华云：这就是第二个特别突出的难点：

普通软件测试通常强调“复现问题并找到缺陷位置”；AI软件评测则常常要先回答：

然后才能继续追问：

七、真正的工程分界在哪里？

阮平：这样看来，普通软件评测与AI软件评测最稳定的差别，不是有没有模型，也不是有没有唯一答案。

华云：那是什么？

阮平：是同样条件下，结果能不能稳定重现；出了问题，能不能较快找到原因。

华云：这个说法更接近实际。

AI软件并不是绝对无法重复，普通软件也不是永远容易排查。我们讨论的是更常见的工程状态，以及评测时应该把注意力放在哪里。

因此，可以形成这样的结论：

这两个特点，又进一步带来了4项可以直接观察到的工程差异。

▎第一，运行方式不同

普通软件的一次运行，通常就有较强的判断价值；AI软件则更依赖同一样本多次运行、换一种表达方式重新测试，以及在不同条件下做对比。只有这样，才能更可靠地判断它的表现是否稳定。

▎第二，问题表现不同

普通软件的问题，往往表现为稳定的功能错误、程序报错或状态不一致；AI软件的问题则更可能表现为时好时坏、意思发生偏差、容易受上下文影响、工具使用不当，或者在多步任务中一步步偏离目标。

▎第三，找原因的方式不同

普通软件的问题通常可以逐步定位到代码、接口、配置或运行环境；AI软件的问题却可能同时受到模型、提示词、知识库、资料检索、工具调用、历史记忆和任务流程的影响，需要通过一组对比测试逐项排查。

▎第四，需要记录的证据不同

普通软件测试通常记录版本、环境、输入、操作步骤、预期结果、实际结果和系统日志。AI软件为了还原一次结果是怎样产生的，还要进一步记录：系统给模型的要求、用户输入和对话上下文、模型版本和生成参数、检索了什么资料以及资料的排列顺序、调用了什么工具、传入了什么参数、工具返回了什么内容、AI Agent每一步做了什么、系统状态发生了什么变化，以及自动评分和人工复核依据什么标准。增加这些记录，不只是为了“多留一些日志”，而是为了事后能够把整个过程重新拼出来。

八、AI评测平台到底要多建什么？

阮平：如果这个结论成立，AI评测平台是不是就不应该把普通软件评测平台已有的功能全部重做一遍？

华云：是的。项目管理、测试任务管理、样本管理、规则管理、权限管理和报告管理等通用功能，应当尽量复用。

阮平：那么，AI评测平台真正需要重点补上的是什么？

华云：至少有以下4类能力。

◆ 1. 可控的重复运行能力

平台要能让同一个样本在条件可控的情况下反复运行，并统一管理模型版本、生成参数、提示词、上下文、知识库、工具和运行环境。这样，平台记录的就不只是某一次结果，而是某种行为出现了多少次、不同运行之间有多大差异、改变条件后表现如何变化。

◆ 2. AI行为问题识别能力

平台不能只发现接口报错或程序异常，还要能识别事实错误、意思偏差、输出波动、任务规划失败、工具误用、越权操作、多轮对话中逐步跑偏、恶意提示攻击以及安全规则失效等更贴近AI实际行为的问题。

◆ 3. 对比排查问题原因的能力

平台要支持在其他条件尽量不变的情况下，分别更换模型、提示词、知识库、检索方式、工具说明和AI Agent的任务流程，通过前后对比帮助排查问题。它不仅要告诉我们“哪里出了问题”，还要帮助判断“问题更可能来自哪个环节”，以及改变哪些条件后，问题会减轻或消失。

◆ 4. 全过程记录与追溯能力

平台必须记录从输入到最终输出的完整过程，包括上下文、模型调用、资料检索、工具使用、AI Agent的每一步动作和系统状态变化。尤其在AI Agent场景中，最终答案只是结果的一部分。更重要的是弄清楚：它调用了什么工具、用了什么参数、得到了什么返回、是否修改了外部系统状态、是否越权、是否执行了无法撤销的操作，以及出现异常时有没有及时停止。

阮平：所以，AI评测平台的价值，不是给普通软件评测平台换一个新名字。

华云：也不是把传统测试功能重新开发一遍。

阮平：而是要解决普通软件评测平台不太擅长解决的两个问题。

华云：哪两个？

阮平：

华云：前一个问题，需要反复运行和统计；后一个问题，需要完整记录过程，并通过对比逐项排查。

九、结语：没有另起炉灶，但必须多走一步

阮平：那么，最后应该怎样概括普通软件评测与AI软件评测的关系？

华云：可以这样说：