1. 为什么先写测试这件事在大模型时代突然变得不一样了如果你在过去两年里参与过任何跟大模型沾边的研发项目大概率会有一种很割裂的体感模型能力一天一个样但我们的研发流程还停留在人肉验证的阶段。产品经理丢过来一个需求你写完提示词、接上模型、跑几个 case 看着还行就上线了。上线之后用户随便换个问法输出就开始飘然后你回去改提示词改完发现原来好的 case 又坏了。这种打地鼠式的开发节奏本质上是因为我们缺少一套能自动判断这次改动到底有没有让系统变好的机制。传统软件工程里这套机制叫 TDD测试驱动开发。先写测试再写实现测试是需求的 executable spec。但问题是大模型的输出是概率性的、自然语言的、没有唯一正确答案的。你没法用assertEquals(你好, output)这种断言去卡它。于是很多人就放弃了觉得AI 的东西没法测。这个判断在 2023 年可能还成立但到了现在随着 Behavior-Driven AI-TDD 这套思路逐渐成型情况已经完全不同了。Behavior-Driven AI-TDD拆开看是三层意思。Behavior-Driven 指的是从行为而非实现出发描述需求——我们不关心模型内部怎么算的只关心它在给定输入下应该表现出什么行为。AI-TDD 指的是把测试驱动的循环应用到 AI 系统上包括提示词、工具调用、RAG 检索、Agent 编排这些环节。合起来它要解决的核心问题是在大模型输出不确定的前提下如何建立一套可重复、可回归、可量化的研发闭环。这篇文章适合三类人看。第一类是正在做 AI 应用开发、被改一处崩三处折磨的工程师第二类是带团队、需要给 AI 项目建立质量门禁的技术负责人第三类是对 AI 工程实践感兴趣、想了解大模型时代研发范式怎么演进的开发者。我会从工作流重构的角度切入把 Behavior-Driven AI-TDD 的完整闭环拆开讲包括它跟传统 TDD 的本质差异、评测集怎么建、断言怎么写、CI 怎么接、以及我在实际项目里踩过的那些坑。需要先说明一点这套方法论不是银弹它有自己的适用边界。对于纯创意生成类场景比如让模型写诗硬套行为断言会很别扭。但对于绝大多数有明确业务目标的 AI 应用——客服问答、代码生成、数据抽取、流程自动化——它是目前我见过最靠谱的工程化路径。2. Behavior-Driven AI-TDD 和传统 TDD 到底差在哪2.1 从确定性断言到行为契约的思维转换传统 TDD 的核心是确定性给定输入 A必须输出 B。测试失败就是失败没有中间地带。这套逻辑在 AI 场景下直接失效因为同一个提示词跑两次模型可能给你两个措辞完全不同的答案但语义上都是对的。Behavior-Driven AI-TDD 的做法是把断言从精确匹配升级为行为契约。什么叫行为契约就是我不规定你具体说什么但我规定你必须满足哪些约束。举个例子一个客服机器人的行为契约可能是回答中必须包含退款政策的关键信息、不能承诺超出权限的赔偿、语气必须礼貌、不能泄露其他用户信息。这些约束可以用规则、用另一个模型、用嵌入相似度等多种方式去验证。这个思维转换的关键在于你测的不是输出本身而是输出所体现的行为。这跟 BDD行为驱动开发在传统软件里的思路是一脉相承的只是验证手段从 Cucumber 的 Given-When-Then 步骤变成了更适合自然语言的混合验证策略。2.2 概率性系统里的通过标准怎么定这是最容易被忽略、也最容易扯皮的地方。传统测试通过率是 100% 或 0%AI 系统的通过率往往是这次 87%上次 91%。那到底多少算通过我的经验是分场景定阈值而且要区分硬门禁和软监控。硬门禁指的是绝对不能破的底线比如安全合规相关的断言通过率必须 100%破一条就阻断发布。软监控指的是质量指标比如回答相关性、格式正确率可以设一个基线比如 90%低于基线就告警但不阻断。这里有个反直觉的点不要追求 100% 通过率。如果你的评测集全部通过要么是评测集太简单要么是你在过拟合评测集。健康的评测集应该始终有 5% 到 15% 的 case 处于边缘失败状态这些 case 恰恰是你下一步优化的方向。我见过团队为了刷到 100% 通过率把评测集改得越来越简单最后评测集完全失去意义这是典型的自欺欺人。2.3 评测集本身就是最重要的资产在传统 TDD 里测试代码是资产但通常不是最核心的资产。在 AI-TDD 里评测集Eval Set的优先级要提到最高。原因很简单模型会换、提示词会改、框架会升级但你的评测集定义的是什么叫做好这个东西是相对稳定的。一个高质量的评测集应该包含几个层次。第一层是黄金集也就是那些你百分之百确定正确答案的 case用来做回归基线。第二层是边界集专门收集那些容易出错的刁钻输入比如超长文本、多语言混杂、含歧义的问法。第三层是对抗集用来测试系统的鲁棒性比如提示词注入、诱导性提问。第四层是真实流量采样集从线上真实请求里定期采样保证评测集跟实际使用场景不脱节。我一般建议评测集规模从 50 到 200 条起步不要一上来就搞几千条。原因是你维护不过来而且早期需求变化快大量 case 会迅速过时。等系统稳定了再逐步扩充到上千条。3. 把研发闭环拆开Behavior-Driven AI-TDD 的五个环节3.1 需求行为化把模糊需求翻译成可验证契约一切从需求开始。产品说我要一个智能客服能回答用户关于订单的问题。这句话没法测。你要做的是把它翻译成一组行为契约。具体怎么做我会用场景 期望行为的格式来拆。比如场景用户询问订单物流状态且提供了订单号期望行为系统调用订单查询工具返回当前物流节点且不编造未发生的物流信息场景用户询问订单物流状态但未提供订单号期望行为系统主动追问订单号而不是瞎猜场景用户提供的订单号不存在期望行为系统明确告知订单不存在并引导用户核对你看拆完之后每一条都是可验证的。这个拆解过程本身就是需求澄清的过程很多模糊地带在这一步就暴露出来了。我经常跟团队说写不出行为契约的需求就是没想清楚的需求。3.2 契约到断言的映射选择合适的验证器行为契约写好了接下来要选验证手段。这里没有万能方案得根据契约的性质来选。我整理了一个常用的映射表契约类型推荐验证器适用场景注意事项格式约束正则 / JSON Schema结构化输出、字段校验最稳定优先用关键词包含字符串匹配必须提及的要素注意同义词问题语义相似嵌入向量余弦相似度开放性回答阈值需调优逻辑判断LLM-as-Judge复杂推理、语气成本高需校准工具调用调用轨迹断言Agent 系统检查参数正确性安全性规则 分类模型合规、注入防护必须 100% 通过这里重点说下 LLM-as-Judge。用大模型当裁判是现在很流行的做法但它有个大坑裁判模型本身也会飘。我的做法是任何用 LLM 做判断的断言都要先用人工标注的一批样本去校准裁判模型算出它跟人类判断的一致率。如果一致率低于 85%这个裁判就不能用于硬门禁只能做参考。另外能用规则解决的绝不用模型。字符串匹配、正则、JSON Schema 这些确定性手段又快又稳又便宜是首选。只有在规则确实表达不了的时候才上语义相似度或 LLM 裁判。3.3 红绿循环AI 版的先写测试再写实现传统 TDD 的红绿循环是写一个失败的测试红写实现让它通过绿重构。AI-TDD 的循环类似但节奏不一样。我的实践是这样的拿到一个新需求先写 3 到 5 条行为断言跑一遍当前系统看哪些失败。然后针对失败的 case 去调提示词、改检索策略、加工具。改完再跑看通过率有没有提升同时确认原来通过的 case 没有退化。这个确认没退化的步骤极其重要因为大模型系统特别容易出现按下葫芦浮起瓢的情况。这里有个实操细节每次只改一个变量。我见过太多人一次性改提示词、换模型、调温度然后发现效果变好了但根本不知道是哪个改动起的作用。正确的做法是控制变量一次只动一个地方跑完评测再动下一个。虽然慢但你能积累出什么改动有效的知识这个知识比单次的结果值钱得多。3.4 回归门禁让 CI 帮你守住底线评测跑通了接下来要把它接进 CI。这一步是把 AI-TDD 从个人习惯变成团队纪律的关键。我的做法是在 CI 里分两级。第一级是快速门禁只跑黄金集和安全性断言要求 3 分钟内出结果任何一条硬门禁失败就阻断合并。第二级是全量评测跑完整评测集包括 LLM 裁判的部分可以异步执行结果作为 PR 的评论贴出来供 reviewer 参考。快速门禁的 3 分钟限制很重要。如果 CI 太慢开发者就会想办法绕过它。所以快速门禁必须精简只保留最关键的断言。全量评测可以慢但不能阻断开发流程它的作用是提供决策信息。还有个细节评测结果要存档。每次 CI 跑完把通过率、失败 case 列表、耗时这些指标存下来。这样你就能画出通过率随时间变化的曲线一眼看出哪次改动导致了质量下降。这个历史数据在排查问题时非常有用。3.5 线上反馈回流让评测集活起来闭环的最后一步是把线上真实数据回流到评测集。这一步很多团队会忽略导致评测集跟实际场景越来越脱节。我的做法是建一个反馈通道线上请求里凡是用户点了不满意、或者触发了人工介入、或者被安全规则拦截的 case自动进入待标注队列。每周花半小时过一遍这个队列把有价值的 case 标注后加进评测集。这样评测集就能持续进化始终反映真实的问题分布。这里要注意隐私和合规。回流的数据必须脱敏去掉用户身份信息。如果涉及敏感业务可以用合成数据替代但合成数据要尽量贴近真实分布否则评测集又会失真。4. 提示词、RAG、Agent不同环节的测试策略差异4.1 提示词测试关注稳定性而非单次表现提示词是 AI 系统里最脆弱的部分改一个词可能就影响一片。测试提示词时我特别关注两个指标通过率和方差。通过率好理解就是评测集里有多少 case 通过了。方差指的是同一个 case 跑多次结果的一致性。有些提示词单次跑看着挺好但跑十次有三次飘这种提示词就是定时炸弹。我的做法是对关键 case 跑 3 到 5 次统计一致性。如果一致性低于 80%即使通过率很高我也会标记为不稳定需要优化。优化提示词稳定性的常用手段包括明确输出格式、给出 few-shot 示例、降低温度参数、把复杂任务拆成多步。这些手段各有代价比如 few-shot 会增加 token 消耗拆步骤会增加延迟需要根据场景权衡。4.2 RAG 测试检索和生成要分开测RAG 系统出问题很多时候你分不清是检索没召回还是生成没用好。所以测试必须分层。检索层测试关注给定 query正确的文档有没有被召回召回排在第几位常用指标是 RecallK 和 MRR。这一层可以用确定性方法测因为检索结果是文档 ID可以精确比对。生成层测试关注给定正确的上下文模型有没有正确使用有没有编造上下文里没有的信息这一层就要用行为断言了重点测忠实度——回答必须能在检索到的文档里找到依据。我踩过的一个坑是早期只测端到端结果检索坏了和生成坏了看起来都是回答不对排查起来特别费劲。分层之后问题定位快了很多。4.3 Agent 测试轨迹比结果更重要Agent 系统能调用工具、多步推理的那种的测试最复杂因为它的输出不只是最终答案还有中间的思考过程和工具调用序列。对 Agent我测三个层面。第一层是最终结果这个跟普通 AI 系统一样。第二层是工具调用轨迹检查它有没有调用正确的工具、参数对不对、有没有多余的调用。第三层是步数效率同样一个任务用 3 步完成和用 10 步完成质量是不一样的后者往往意味着推理绕了弯路。轨迹断言怎么写我的做法是把期望的轨迹抽象成必须包含和禁止包含两类。比如一个查天气的 Agent必须包含调用天气 API禁止包含调用支付 API。这种粗粒度的断言比精确匹配整条轨迹更实用因为 Agent 的路径本来就有多种合理走法。5. 我在实际项目里踩过的那些坑5.1 评测集过拟合通过率上去了线上却崩了这是我早期犯的最大的错误。当时团队为了冲通过率不断针对失败的 case 调提示词调到评测集 98% 通过。结果上线后用户反馈一堆问题。回头一看评测集里的 case 被我们喂了太多次提示词已经针对这些具体 case 过拟合了换个问法就失效。教训是评测集要留出保留集。我现在的做法是把评测集分成开发集和保留集开发集用来日常调试保留集平时不碰只在发布前跑一次。如果开发集通过率 95%保留集只有 70%说明过拟合了得回头检查。5.2 LLM 裁判的偏见它偏爱像自己的回答用 LLM 当裁判时我发现一个规律裁判模型倾向于给风格跟自己相似的回答打高分。比如用某个模型当裁判它会偏爱那种结构工整、用词正式的回答哪怕内容其实一般。解决办法有两个。一是用多个不同来源的裁判模型投票降低单一模型的偏见。二是定期用人工标注校准发现偏差就调整裁判提示词。我现在会在裁判提示词里明确写不要因为回答长度或格式而加分只关注内容准确性这样能缓解一部分偏见。5.3 温度参数的两难稳定性和多样性温度调低输出稳定但可能死板温度调高输出多样但可能飘。这个权衡没有标准答案得看场景。我的经验是评测时用生产环境的温度。有些团队评测时用温度 0生产用温度 0.7结果评测通过率很高线上却各种飘。评测环境必须跟生产环境一致否则评测结果没有参考价值。如果生产确实需要一定温度那评测时就要接受通过率会低一些并且要测多次取平均而不是只跑一次。5.4 成本失控评测跑一次烧掉几百块LLM 裁判和多次采样都很烧钱。我见过一个团队评测集 2000 条每条跑 5 次每次都用 GPT-4 当裁判跑一次评测几十美元。这种成本没法支撑高频 CI。优化手段有几个。一是分级评测快速门禁用规则和小模型全量评测才用大模型。二是缓存同样的输入输出对裁判结果可以缓存复用。三是采样全量评测不必每次都跑全部 case可以随机采样一部分。我用下来这些手段能把评测成本压到原来的十分之一左右。5.5 团队协作评测集谁来维护这是个组织问题但很关键。如果评测集只有一个人维护他一休假整个流程就停了。我的做法是建立评测集 owner 轮值制度每周一个人负责处理反馈队列、更新评测集。同时把评测集的修改纳入 code review任何新增或修改 case 都要有人 review保证质量。另外评测集要版本化跟代码一起管理。这样出问题时能追溯到是哪个版本的评测集、哪次改动导致的。6. 从工具链角度看这套闭环怎么落地6.1 评测框架的选型思路市面上评测框架不少选型时我关注几个点能不能自定义断言、能不能接 CI、结果好不好分析、社区活不活跃。我的建议是不要一上来就上重型框架。早期用 pytest 加几个自定义断言函数就能跑起来简单直接。等评测集大了、需要多人协作、需要可视化报表了再考虑专门的框架。过早引入复杂工具学习成本高而且很多功能你根本用不上。如果团队已经在用某个测试框架优先复用它。比如 Python 团队用 pytestJava 团队用 JUnit把 AI 断言写成插件或工具类融入现有流程比另起炉灶阻力小得多。6.2 数据管理评测集的存储和版本控制评测集本质上是数据存储和版本控制要做好。小规模几百条直接用 JSON 或 YAML 文件放代码库里就行方便 review 和 diff。大规模上千条可以考虑用数据库但要注意导出和版本快照。每条 case 建议包含这些字段唯一 ID、输入、期望行为描述、断言配置、标签用于分类统计、创建时间、最后修改时间。标签特别有用能让你按场景、按难度、按来源分类看通过率快速定位问题集中在哪。6.3 可观测性把评测指标接进监控评测不只是 CI 的事线上也要监控。我会把线上的一些关键指标比如工具调用成功率、回答被拦截率、用户负反馈率接进监控面板跟评测指标放一起看。这样能形成离线评测 - 线上监控的双保险任何一边异常都能及时发现。线上监控还有个好处是能发现评测集覆盖不到的问题。评测集再全也是有限的线上流量是无限的两者互补。7. 这套方法论适合什么样的团队和场景Behavior-Driven AI-TDD 不是所有 AI 项目都适用。我的判断标准是如果你的 AI 系统有明确的业务目标、可定义的期望行为、并且会持续迭代那它就适用。具体来说客服问答、代码助手、数据抽取、文档处理、流程自动化这些场景都非常适合。因为这些场景的好是可以定义的评测集能建起来断言能写出来。反过来纯创意生成写小说、生成艺术图、探索性研究让模型自由发挥找灵感这类场景硬套行为断言会很别扭。这类场景更适合人工评估加轻量级的质量指标不必强求自动化闭环。团队规模上我觉得 3 人以上的 AI 研发团队就该考虑这套方法。人少的时候靠人肉验证还能撑人一多、迭代一快没有自动化门禁必然乱套。而且这套方法的价值是随迭代次数累积的迭代越频繁收益越大。最后说个心态问题。建立这套闭环前期投入不小建评测集、写断言、接 CI可能要花一两周。很多团队在这个阶段就放弃了觉得还不如直接调提示词快。但我的经验是一旦闭环建起来后面每次迭代的效率会指数级提升。前期那一两周的投入在第一个月就能回本。这是个典型的磨刀不误砍柴工的事关键是要熬过冷启动阶段。我在最近一个项目里把评测集从 0 建到 150 条接进 CI前后花了大概十天。之后每次改提示词从原来的改完手动测半小时还不放心变成提交后等 CI 三分钟出结果而且心里有底。这个体验的差异做过 AI 应用开发的人应该都懂。