上一篇文章讨论了 AI Scaffold 和 LangChain、LangGraph 的关系。那篇文章的重点是讲清楚AI Scaffold 不是为了替代某个能力框架而是把模型调用、业务流程、项目结构、配置、日志、评测、部署和文档这些工程要素组织起来。到了真实项目里还有一个问题非常关键AI 应用改完之后怎么知道它没有变差传统软件里我们会写单元测试、接口测试、集成测试。但 AI 应用不是简单地返回固定结果。同一个问题模型可能给出不同表达。同一个 Prompt换一个模型版本可能行为变化。同一个 RAG 流程文档切片、召回参数、重排策略变化后回答质量可能明显不同。所以 AI Scaffold 如果只提供项目目录和启动命令还不够。更完整的脚手架应该把评测也纳入工程流程。一、为什么 AI 应用更需要评测很多 AI 应用刚开始开发时看起来很容易。接入模型。写一个 Prompt。加一个接口。跑几个问题。如果回答还可以就觉得功能已经完成。但问题通常出现在后面。比如改了一句 Prompt原来能回答的问题突然答偏了。换了一个模型回答格式不稳定了。调整了知识库切片召回内容变少了。新增了一个工具调用Agent 开始乱走流程。上线后用户问法变多测试时没覆盖的问题暴露出来。AI 应用的问题往往不是“完全不可用”而是“局部变差”。这类问题最难发现。因为它不会像普通代码错误一样直接报异常。它可能只是回答不够准确、不够稳定、不符合业务语气或者在某些边界场景下给出危险建议。所以 AI 应用需要评测不是为了追求形式而是为了让项目具备可维护性。二、传统测试和 AI 评测有什么区别传统测试通常关注确定性结果。例如defadd(a,b):returnabassertadd(1,2)3输入是1和2输出就应该是3。但 AI 应用不是这样。例如用户问请帮我总结这份合同的主要风险。模型的回答可能有很多种表达方式。它不一定每次都逐字相同但只要核心风险识别正确、表达清晰、没有编造就可以接受。所以 AI 评测不能只做字符串完全匹配。它更关注回答是否命中核心事实。是否引用了正确上下文。是否遗漏关键风险。是否出现幻觉。是否遵守输出格式。是否符合业务边界。是否具备稳定性。这也是 AI Scaffold 需要单独设计评测层的原因。普通测试体系解决不了全部问题。AI 应用需要把确定性检查和非确定性评估结合起来。三、Prompt 改动为什么容易引入隐性问题Prompt 是 AI 应用里最容易被频繁修改的部分。开发者可能会不断调整角色设定。输出格式。约束条件。示例样本。工具调用说明。安全边界。语言风格。这些改动看起来都不大。但在大模型应用里小改动可能带来明显行为变化。例如原来的 Prompt 是请基于用户提供的材料回答问题。后来改成请尽可能详细地回答用户问题。这句话看似只是让回答更丰富。但如果没有同时强调“只能基于材料”模型可能开始补充材料之外的内容。这就是典型的 Prompt 退化。不是代码报错。不是接口失败。而是行为偏移。如果没有评测集开发者很难知道这次改动影响了哪些问题。所以 AI Scaffold 应该鼓励把 Prompt 当作可测试资产而不是随手改的字符串。四、RAG 应用应该评测哪些指标RAG 应用的核心链路通常包括用户问题 - 查询改写 - 向量召回 - 重排 - 上下文拼接 - 模型回答其中任何一环变化都可能影响最终结果。所以 RAG 评测不能只看最终回答。更合理的做法是拆开看。第一类是召回质量。例如是否召回了正确文档。正确内容是否排在靠前位置。是否召回了无关内容。关键条款是否被切片切断。第二类是回答质量。例如回答是否基于召回内容。是否正确引用了依据。是否遗漏重要信息。是否把多个文档的信息混淆。第三类是稳定性。例如同类问题换一种问法是否还能召回正确内容。同一批问题在 Prompt 调整后是否明显变差。新增文档后旧问题是否还能正常回答。RAG 评测的重点不是证明系统完美。而是要尽早发现召回、上下文和回答之间的断点。五、Agent 应用应该评测哪些指标Agent 应用比普通问答更复杂。因为它不只是回答问题还可能选择工具、执行步骤、调用外部接口、维护状态。因此 Agent 评测至少要关注三件事。第一工具选择是否正确。例如用户问帮我查询这个订单的物流状态。系统应该调用订单或物流查询工具而不是直接编造结果。第二执行顺序是否合理。例如一个退款流程可能需要查询订单 - 判断状态 - 检查退款规则 - 发起退款 - 返回处理结果如果 Agent 跳过规则检查直接发起退款就可能产生业务风险。第三失败时是否能正确兜底。真实系统里工具可能超时外部接口可能失败用户信息可能不完整。Agent 不能在失败时胡乱继续。它应该能返回明确的失败原因或者转人工处理。所以 Agent 的评测不只是看最后一句话好不好。还要看中间轨迹是否符合业务流程。六、AI Scaffold 里可以怎么组织评测目录如果把评测作为工程能力目录结构就应该提前设计。一个简单可用的结构可以是ai-scaffold/ app/ prompts/ workflows/ services/ evals/ cases/ datasets/ runners/ reports/ baselines/其中cases存放评测用例。datasets存放文档、问答样本或业务样本。runners存放评测执行脚本。reports存放每次评测报告。baselines存放历史基线结果。这样的好处是边界清楚。业务代码在app里。评测资产在evals里。每次修改 Prompt、Workflow 或检索策略后都可以运行一轮评测。这比靠人工随便问几个问题可靠得多。七、如何设计一组最小可用评测集评测集不需要一开始就很大。很多团队的问题不是评测集太小而是完全没有评测集。一个最小可用评测集可以先覆盖三类问题。第一类是核心场景。也就是产品最常见、最重要的问题。例如文档分析应用里总结文档。提取风险。生成报告。回答文档相关问题。第二类是边界场景。例如用户问题信息不足。文档里没有答案。用户要求输出不存在的数据。用户问了超出业务范围的问题。第三类是风险场景。例如要求泄露系统提示词。要求绕过权限。要求生成不可靠结论。要求模型假装知道不存在的信息。先把这三类问题覆盖起来评测体系就已经有了基本价值。后面再随着真实用户问题不断扩充。八、评测用例应该包含哪些字段评测用例最好不要只写一行问题。它应该包含足够的信息方便后续自动运行和人工复核。例如{id:rag_contract_001,type:rag,input:这份合同里有哪些付款风险,expected_points:[识别付款周期,识别违约责任,说明风险来源],forbidden_points:[编造合同中不存在的条款,给出法律结论替代风险提示],tags:[contract,risk,rag]}这里的expected_points不是要求模型逐字一致。它描述的是回答必须覆盖的关键点。forbidden_points描述的是不能出现的问题。这样评测就更接近真实 AI 应用。因为真实用户关心的是回答是否有效而不是模型是否输出了某个固定字符串。九、如何保存输入、输出和期望结果AI 应用评测要能追溯。一次评测至少应该保存测试用例 ID。输入内容。Prompt 版本。模型名称。检索参数。召回片段。模型输出。评测结果。运行时间。原因很简单。如果某次评测失败团队需要知道到底是哪里变了。是 Prompt 变了。是模型变了。是知识库变了。还是检索参数变了。如果什么都不记录只看到“这次回答不太好”就很难定位问题。AI Scaffold 可以在脚手架层面约定这些记录字段让项目从一开始就具备追溯能力。十、自动评测和人工评审怎么结合AI 评测不能完全依赖自动化。但也不能完全依赖人工。更合理的方式是分层。第一层是规则检查。例如是否返回 JSON。是否包含必填字段。是否超过长度限制。是否出现禁用词。是否引用了上下文编号。这类检查适合自动化。第二层是语义检查。例如回答是否覆盖关键点是否存在幻觉是否符合业务语气。这类检查可以借助模型评审也可以人工抽检。第三层是业务确认。例如法律、医疗、金融、企业内部流程等高风险场景最终仍然需要业务人员确认。所以 AI Scaffold 的评测体系应该支持多种结果来源规则检查结果 模型评审结果 人工评审结果不要幻想一个自动评分就能解决所有质量问题。但也不要因为不能完全自动化就放弃评测。十一、如何把评测接入开发流程评测如果只存在于文档里很快就会失效。它必须进入开发流程。一种可行做法是修改 Prompt 或 Workflow ↓ 运行核心评测集 ↓ 查看失败用例 ↓ 修正 Prompt、检索或流程 ↓ 生成评测报告 ↓ 合并或发布这和普通软件开发里的测试流程类似。区别在于AI 应用的评测结果不一定只有通过和失败。它可能包含通过。失败。需要人工复核。输出变差。输出变好。格式正确但语义不足。这些状态都应该被记录。只有这样团队才知道每次迭代的影响。十二、评测结果如何反哺 Prompt 和 Workflow评测不是为了生成一份报告就结束。它真正的价值是反过来指导系统优化。例如评测发现同类问题经常遗漏限制条件。那可能说明 Prompt 里对限制条件的强调不够。如果评测发现模型回答经常引用不到正确文档。那可能不是 Prompt 问题而是检索策略问题。如果评测发现Agent 经常跳过确认步骤。那可能是 Workflow 设计问题。所以评测结果要能映射到工程改进点。这也是 AI Scaffold 的价值。它可以把 Prompt、Workflow、Retriever、Tool、Repository、日志和评测报告放在一个统一工程结构里让问题定位更清楚。十三、常见误区第一个误区是只测几个正常问题。正常问题当然要测但边界问题和风险问题更重要。很多 AI 应用真正出问题都是在非标准问法里。第二个误区是只看最终回答。对于 RAG 和 Agent 应用中间过程同样重要。召回错了即使回答看起来流畅也可能是错的。工具调用错了即使最终话术自然也可能有业务风险。第三个误区是把评测当成一次性工作。AI 应用会不断变化。Prompt 会改。模型会换。知识库会更新。业务规则会调整。所以评测集也要持续维护。第四个误区是迷信单一评分。一个8.5分并不能说明系统真的可靠。更重要的是失败用例是什么失败原因是什么是否影响核心业务场景。十四、总结AI 应用工程化不只是把项目跑起来。更重要的是让项目可以持续迭代。而持续迭代的前提是每次修改之后都能判断质量有没有变化。这就是评测的意义。对于 AI Scaffold 来说评测不应该是后期补上的附属功能。它应该和 Prompt、Workflow、RAG、Agent、日志、配置、部署一样成为脚手架里的基础能力。一个成熟的 AI 应用项目至少应该回答这些问题我们有哪些核心评测用例Prompt 修改后如何回归RAG 召回是否稳定Agent 工具调用是否符合流程输出是否符合格式和业务边界失败用例如何记录和复盘评测结果如何反哺下一次优化如果这些问题没有答案项目就很难长期维护。AI Scaffold 的价值就是把这些工程实践提前放进项目结构里。让 AI 应用不只是能演示。也能验证、能回归、能排查、能持续演进。