《AI不是魔法》写给软件工程师的AI工程课第九堂AI回答得好不好到底谁说了算这一篇适合谁如果你担心AI会犯错、想知道怎么判断AI靠不靠谱、以及如何让AI系统真正可信任——那么这一篇值得看完。上一堂课我们知道AI越来越像操作系统不是因为设计如此而是因为复杂到一定程度它必须如此。这一堂课我们继续回答当Prediction越来越容易影响世界谁证明它是对的一个团队用Agent自动修复CI失败。运行了一段时间一切顺利。Agent每天读日志、改配置、提交MR、重新部署、通知Slack。直到有一天老板问了一句话“上周Agent修了几个CI”团队回答“修了15个。”老板又问“真的都修好了吗”团队沉默了。因为没有人验证过。Agent每次都说“已修复”但到底部署成功了吗测试通过了吗业务恢复了吗没人知道。Agent负责行动。但谁来证明行动是否成功这就是Evaluation出现的原因。当AI只是聊天我们评估的是回答当AI开始工作我们评估的是整个系统。一、Prediction越来越容易发生也越来越需要被验证前八篇我们一直在讲一件事Prediction越来越容易发生了。第一篇Prediction是什么第二篇Prompt让Prediction理解用户第三篇Transformer让Prediction更高效第四篇RAG让Prediction获得知识第五篇Function Calling让Prediction影响世界第六篇MCP让Prediction连接工具第七篇Agent让Prediction持续发生第八篇Memory、Workflow、Permission让Prediction被管理Prediction从“一次结束”变成了“不断循环”从“只动嘴”变成了“能动手”。但问题也随之而来Prediction越来越容易影响世界影响越来越大谁证明它是对的以前AI回答错了最多是聊天记录里多一句废话。现在Agent一个错误的Prediction可能触发退款、修改配置、删除数据、部署错误代码。Prediction的代价越来越高于是Prediction必须被验证。不是有人发明了Evaluation而是Prediction越来越重要必须有人证明它是不是好的。二、Evaluation不是AI发明的传统软件一直都有很多工程师会觉得Evaluation是AI领域的新东西。其实不是。传统软件开发一直有验证环节写代码 → 单元测试 → 集成测试 → 上线每一个环节都在回答同一个问题这段代码是对的吗AI系统也是一样Prediction → Evaluation → 上线唯一的区别是传统软件验证的是代码AI系统验证的是Prediction。Evaluation不是AI发明的。它只是从验证代码变成了验证Prediction。用一张图来表示传统软件 代码 → 测试验证代码是否正确 → 上线 AI系统 Prediction → Evaluation验证Prediction是否正确 → 上线所有工程师都理解测试的必要性。没有人会上线未经测试的代码。那么为什么要上线未经评估的AI到这里Evaluation的角色已经清晰了。它不是一个独立的事后打分环节而是嵌入了AI的循环之中以前 Prediction → Action → 结束 现在 Prediction → Action → Evaluation → 下一次PredictionAgent让Prediction可以不断发生而Evaluation决定下一次Prediction是否值得继续。三、Prediction越来越复杂Evaluation也越来越复杂早期AI系统只有一个Prediction用户问一句AI答一句。评估也很简单看回答对不对。但到了Agent时代一个任务涉及多次PredictionAgent收到任务 ↓ Prediction 1该查什么资料 ↓ Action 1调用RAG ↓ Result 1返回文档 ↓ Evaluation 1文档是否相关 ↓ Prediction 2该调什么工具 ↓ Action 2调用API ↓ Result 2返回数据 ↓ Evaluation 2数据是否正常 ↓ Prediction 3下一步该做什么 ↓ ……哪一步算成功只看最终答案够吗不够。因为最终答案对了但中间可能走了弯路、调错了工具、浪费了资源。最终答案错了但中间某几步是对的需要知道在哪一步出的问题。所以Evaluation的对象从“一句回答”变成了“整个Workflow”。以前评估结果回答对不对 现在评估过程每一步决策是否合理、工具调用是否正确、Context是否被正确更新这不是有人发明了“系统评估”而是Prediction越来越复杂评估必须跟着变复杂。Evaluation不是终点。Evaluation的结果同样会进入Context影响下一次Prediction。Prediction负责前进Evaluation负责反馈。没有反馈Prediction永远不会变得更可靠。四、一个真实的工程案例一个团队用Agent自动修复CI失败。Agent的流程是这样的Agent收到CI失败通知 ↓ 读取CI日志 ↓ 定位问题发现是yaml配置错误 ↓ 修改yaml ↓ 创建Merge Request ↓ 人工Review ↓ 合并后重新部署 ↓ 通知Slack“已修复”一开始团队只评估最终结果Agent说“已修复”就算完成。但很快出了问题有一次Agent说“已修复”实际上部署后测试没有通过。Agent没有验证部署结果就擅自通知了“已修复”。团队随后改了流程在“通知Slack”之前增加了一个Evaluation步骤…… 合并后重新部署 ↓ 自动运行测试用例 ↓ 测试全部通过 ├── 是 → 通知Slack“已修复测试通过” └── 否 → 通知人工介入“修复未通过测试请检查”注意最后决定“通知Slack”的不是Agent而是Evaluation。Prediction决定下一步做什么Evaluation决定下一步还能不能继续。一个一分钟思维实验回想一下你日常的开发流程。你写完代码不会直接上线。你会先跑单元测试再跑集成测试再Code Review最后才部署。现在想象一下如果AI系统也能这样——每次Prediction之后先验证Result再决定下一步——它是不是和你写代码的流程一模一样Evaluation就是AI系统的质量门Quality Gate。工程师容易踩的坑 错误做法 只在上线前做一次评估上线后就再也不看了。 为什么错 AI系统的行为会随着输入的变化而变化。今天准确的Prediction明天可能就不准了。评估必须是持续的。 ✅ 正确做法 把评估嵌入到AI系统的Loop中——每次Prediction之后都验证Result每次验证都记录每次记录都用于改进。今天记住这一句话Prediction决定AI能做什么。Evaluation决定我们能不能相信它。如果今天只带走一个观点那就是Prediction让AI开始工作。Trust让AI真正上线。系列世界观升级走到第九篇整本书的世界观完成了一次重要升级。以前Prediction → Action → Context更新 → Prediction现在Prediction → Action → Result → Evaluation → Context Update → PredictionEvaluation插进了Loop。它不再是独立于系统之外的事后打分而是系统运行中的一个环节。Evaluation的结果同样进入Context影响下一次Prediction。回头看这九篇你会发现一个规律第一篇Prediction 第二篇Prompt → Prediction理解用户 第三篇Transformer → Prediction更高效 第四篇RAG → Prediction获得知识 第五篇Function Calling → Prediction影响世界 第六篇MCP → Prediction连接工具 第七篇Agent → Prediction持续发生 第八篇Memory / Workflow / Permission → Prediction被管理 第九篇Evaluation → Prediction被验证Prediction产生能力。Evaluation产生信任。能力决定上限信任决定下限。没有信任再强的能力也无法落地。下一篇预告当AI系统开始影响真实世界我们需要的不仅是可信的Prediction更需要一个能让Prediction稳定生存的生产环境。Demo里Prediction活在理想世界。生产环境里Prediction要面对API变更、网络抖动、权限变化、模型升级、数据漂移。一个真正能上线的AI系统需要的从来不只是Prediction。下一篇我们聊如何为Prediction构建一个真正能上线的生存环境