要验收的，不只是能用而是能被证明的能力

功能已经实现，不等于能力已经达到验收要求。

某个政务大模型项目进入验收阶段。

供应商现场演示政策问答、材料生成、事项咨询：输入几个常见问题，系统都能答；第三方报告里还有一项醒目的指标——“知识问答准确率不低于90%”。

从传统信息化项目的视角看，这似乎已经相当接近“可以验收”：功能有了，演示通过了，还有一个量化数字。

但只要再追问几句，结论就没有那么简单了：90%的题是谁出的？什么叫答对？验收的是哪个模型、哪一版知识库？半年后模型或知识库换了，这个90%还能不能代表正在运行的系统？

这不是刻意抬杠，而是AI项目验收绕不过去的变化。

传统软件验收，更多是在证明“功能有没有做出来”；AI项目还要进一步证明“能力有没有达到要求”，以及“这个结论能不能被复核”。

01能问能答，为什么还不等于能力达标？

传统软件的很多结果具有较强确定性，而AI项目面对的情况明显不同。

建设方案写“支持政策智能问答”，做出一个问答窗口当然属于完成交付的一部分。但“支持”本身并不是一个可以自然验收的结果。

它还需要回答：对哪些问题有效？什么回答算正确？遇到政策边界、例外情形时，系统应如何表现？答不上来时，是拒答、转人工，还是生成一个看似合理却没有依据的答案？

假设100道题里，模型答对90道常见问题，却在10道高风险政策问题上给出错误依据。简单平均仍然是90%，但这个结果未必意味着系统已经达到实际使用要求。

再比如，同一个问题换一种说法就得到不同答案，那么一次现场演示里的“答对”，又能说明多少稳定性？

这种现象在专业AI工具中同样存在。以“软件造价喵”为例，同一份需求多次进行功能点智能识别，结果也可能出现小幅差异。“软件造价喵”作为AI辅助型工具，可以帮助专业人员完成大量功能点识别、分类和整理等基础工作，减少重复性工作量，让更多精力集中到业务边界判断和专业分析上。

而对于这类AI工具，仅看某一次识别结果并不足以说明其真实能力。识别结果到底准不准、多次运行是否稳定、面对不同业务场景和复杂需求时表现如何，都需要通过统一、可复核的方式进行评价。也正是基于这一考虑，我们正在牵头推进《软件造价 功能点智能识别测评规范》的相关工作，通过建设覆盖不同业务场景、不同复杂程度和不同功能点类型的测评数据集，探索建立统一的测试与评价方法，对功能点智能识别工具的准确性、稳定性等能力进行客观验证。这既是希望给行业提供一把更加清晰的“尺子”，也可以通过持续测评发现薄弱场景，为“软件造价喵”后续模型优化和识别能力提升提供依据。

AI项目不能只验“有没有问答功能”，还要验证“问答能力是否达到约定目标”。

现行推荐性国家标准GB／T 45288.2—2025《人工智能 大模型 第2部分：评测指标与方法》已经建立大模型评测指标与方法的专门框架。这也说明，大模型能力并不能仅靠一次演示完整判断。

项目越涉及政策咨询、辅助审核、敏感数据、业务办理或自动执行，这个差别越值得关注。

02“准确率90%”，验收至少要追问四件事

准确率当然可以写进合同，也可以作为验收指标。

问题在于，脱离测试条件的百分数，本身并不能完整说明系统能力。

第一问：测试题是谁出的？

假设都是100道题。

一种情况是，测试题由供应商事先掌握，并已据此补充知识库、优化提示词；另一种情况是，由建设单位、业务部门或独立测评方从真实业务中抽取，供应商事前并不知晓。

即使最终结果同为90%，其解释力也并不相同。

因此，验收材料不能只留下“准确率90%”这一行数字，还应能够说明测试集如何形成，样本是否覆盖主要业务场景，以及是否包含边界问题、异常问题和容易混淆的问题。

尤其是政策问答、审批辅助等场景，如果测试题主要集中在最常见、最容易回答的问题上，最终得到的可能只是一个漂亮数字，而不一定是对真实业务能力的完整刻画。

验收题本身，也是验收证据的一部分。

第二问：什么才叫“答对”？

用户询问某项政策的申报条件，模型列出五项：四项正确，一项引用了已经失效的政策。

它算正确、部分正确，还是错误？

如果模型没有明显说错，却遗漏了一个决定能否申报的关键限制条件，又该如何判断？

如果评分规则没有提前说清，验收很容易变成“看起来差不多”的主观判断。换一批人员评价，也可能得到不同结果。

所以，“准确率90%”成立之前，应当先明确一套可以复核的判定规则。

能否按照同一套规则，对同一批回答作出基本一致的判断？

第三问：这个90%对应哪个版本？

这一点在AI项目中尤其容易被忽略。

一个大模型应用在运行过程中可能不断变化：基础模型升级、知识库更新、提示词调整、检索参数修改，甚至底层API或第三方模型也可能被替换。

如果验收报告只写“准确率90%”，却没有说明测试时对应的模型、知识库、关键配置和部署环境，后续就很难证明：

报告当时测到的对象，与现在真正运行的对象，是不是同一个对象。

这不是纯粹的技术细节，而是审计中典型的证据对应关系。

《政务领域人工智能大模型部署应用指引》提出建立全周期管理体系，并要求做好运行日志管理、定期审计日志。对项目验收而言，这意味着不仅要留下一个“合格”的结论，还要留下能够解释这一结论对应何种系统状态的版本和运行痕迹。

第四问：回答正确，就说明整个AI系统合格了吗？

如果AI只承担政策问答、知识咨询等参考性工作，主要关注点还是“说得对不对”。

但对于具备工具调用能力的智能体，情况已经发生变化。

它可能查询业务数据、调用外部接口、生成审批建议、创建任务，甚至发起实际操作。

它“做得对不对”。

例如，智能体会不会超出用户授权范围调用接口？高风险操作有没有保留人工确认？工具调用有没有权限控制和日志？异常行为能否被拦截？敏感数据会不会被不当带出？

2026年发布的《智能体规范应用与创新发展实施意见》提出加强行为管控，探索重要应用场景智能体行为可验证、可追溯，并关注模型接入、API调用和扩展工具使用等环节的安全管理。

一个AI“说得对”，并不代表它“做得也对”。

输出结果只是验收对象的一部分，执行行为本身同样需要验证。

03AI项目怎么验？可参考五层证据

AI项目当然仍然需要阶段性验收。

问题不在于“能不能验”，而在于不能仅用一次现场演示或者一个指标数字，替代完整的验收证据。

结合AI项目特点，可以把验收思路理解为五层证据：

这五层不是所有项目都必须机械照抄的检查清单。项目应用场景越关键、权限越大、持续迭代越频繁，对证据完整性的要求就越高。

第一层是交付证据，回答“东西有没有做出来”。

仍然需要按照合同、采购文件和建设方案，对软件系统、模型服务、知识库、数据集、接口、智能体、部署环境和相关技术文档等进行核对。

但完成交付，只能证明“有”，不能独自证明“好用、可靠、合规”。

第二层是能力证据，回答“做得怎么样”。

准确性、事实正确性、任务完成率、响应时间、调用成功率、稳定性等，都可能成为验证对象。但指标不是越多越专业，而应与具体场景相对应。

例如，政策问答更关注事实正确、知识时效和拒答机制；材料辅助审核更关注识别准确和漏判风险；智能体还可能涉及任务成功率和异常处置。

第三层是行为边界证据，回答“会不会做不该做的事”。

尤其是智能体、辅助审批和自动执行类AI，需要关注能够访问哪些数据、调用哪些接口、哪些动作必须人工确认，以及越权和异常调用如何阻断。

能力越强，边界越不能只停留在口头承诺上。

第四层是可复核证据，回答“凭什么说它合格”。

一份“验收合格”的报告，应当能够让后续复核人员看明白：测试样本从哪里来，评分规则是什么，测试时对应哪个版本，异常样本如何处理，相关日志和原始记录能否调取。

如果换一位验收人员或者审计人员，依据现有资料，能不能基本复核出相同的判断？

第五层是持续验证，回答“验收以后还成立吗”。

对于持续迭代的模型、知识库和智能体，当项目发生重要变化时，原来的测试结论是否仍然适用于当前系统。

例如，更换基础模型以后，原来的准确性测试是否还能代表新模型？知识库大规模更新以后，政策问答是否需要重新抽样验证？智能体增加新的工具调用以后，原有权限测试是否还覆盖新增行为？

因此，从项目审计和验收角度，还需要关注：

验收时证明的是当时那个版本“合格”，系统发生重要变化以后，原来的合格结论是否仍然具有对应关系。

至于是否需要重新测试、测试到什么程度，仍应根据合同约定、项目管理要求和实际风险判断，而不宜一概而论。

结语：AI验收真正要验的，是能被证明的能力

AI项目“能回答问题”，当然是验收的重要基础；但它还不足以单独证明项目已经达到建设目标。

当采购文件或者测评报告出现“准确率90%”“任务完成率95%”这类表述时，真正值得关注的，不只是最后那个百分数，而是：题目怎么来的，按照什么规则判断，测的是哪个版本，系统有没有守住行为边界，以及这份结论能不能被复核。

对于持续迭代的AI系统，还应关注模型、知识库或者工具链发生重要变化以后，原有结论是否仍然对应当前运行对象。

AI项目真正需要验收的，不只是一个“能用”的功能，而是一套能够被证明、被复核的能力。