上个月我把项目里一个耦合严重的支付模块完整走了一遍 Behavior-Driven AI-TDD 重构。整个过程最让我意外的不是大模型写测试写得有多快而是我把测试从“补丁”重新变成“设计工具”之后需求沟通、任务拆分、代码审查甚至跨端协作的方式全都跟着变了。今天这篇就来聊聊在大模型时代为什么行为驱动和 AI 辅助测试开发能形成一个真正的软件研发闭环以及从工作流重构到工程实践这条路上哪些思路可以直接抄作业哪些坑我已经替你踩过了。1. 传统 TDD 卡在哪里写完测试就没了下一步1.1 一项看似美好的纪律为什么难落地TDD 的红绿重构循环理论上非常自洽先写一个失败的测试让它驱动出最小实现再在绿灯保护下重构。任何有几年经验的人都知道这个循环的价值但真让团队长期坚持下来失败率极高。问题不在态度而在成本。传统 TDD 对开发者的领域思考能力要求太高。写第一个测试之前你必须把需求拆成可验证的行为想清楚输入、输出、边界和异常分支。这本身就是一份高质量设计文档的思考量。大多数业务模块留给写测试的时间往往比实现代码还紧。于是大家会走一条大家都走过的捷径先写实现再补一层“看起来会跑”的测试最后用覆盖率数字安慰自己。第二重阻力来自反馈速度。老式 TDD 提倡频繁切换红灯和绿灯但如果你要打开浏览器、启动外围服务、准备数据库数据才能验证一个行为几分钟的反馈周期足以把人的心流彻底打碎。慢反馈会让人下意识少跑测试、少写测试最后退化成“只在提测前补几个用例”。大模型恰好有能力把这两重阻力的水位降下来。它可以快速生成测试骨架、补全边界用例、甚至把 Gherkin 场景变成可执行测试代码。但这里有个关键前提如果需求本身是模糊的AI 生成的测试也只能是“对代码现有行为的影像学复制”而不是对业务行为的约束。1.2 需求歧义测试本身的“测试”谁来写传统 TDD 的第一个红依赖开发者对需求的理解。然而大多数团队的需求来源是 PRD、口头要求或者一段即时消息真正的验收标准要靠人脑“脑补”。比如“订单金额满 200 打八折”这里面没有说清楚是否包含运费、是否限制会员、折扣是否叠加。如果你直接让大模型写test_discount()它可以写出十个不同版本的断言每一个都能自圆其说但哪一个才代表业务这正是 TDD 循环断裂的根源测试一旦基于开发者的主观理解来写它就不是约束而是把开发者的假设固化成了机器可执行的规则。等测试变绿你以为验证了需求实际只是验证了当时的猜测。更麻烦的是这种隐性决策会一路传导到线上直到某个用户场景触发歧义你才会发现写测试的人当时替业务做了一个不该做的决定。所以在引入 AI-TDD 之前首要问题不是“怎么让大模型写测试”而是“用什么形式把需求意图变成模型和人都不产生歧义的规范”。在我的实践里答案就是 Behavior-Driven Development 里的行为描述。2. Behavior-Driven 真正给 AI-TDD 提供了什么需求与代码之间的语义锚点2.1 用 Gherkin 场景把人类意图变成机器可读的验收标准Behavior-Driven 的核心不是某款测试框架而是用 Given-When-Then 这样的半结构化语言把业务行为描述成“前置条件 触发动作 可观察结果”。最常用的载体是 Gherkin 语法。Feature: 订单折扣 Scenario: 会员订单金额满足阈值后自动打折 Given 用户是会员 And 当前订单金额为 200 元 When 用户提交订单 Then 系统应用 8 折优惠 And 最终支付金额为 160 元这段描述没有任何代码语法业务人员能看懂测试人员能据此写用例开发人员能据此做设计大模型也能据此理解验收标准。关键是它把“打八折”这种模糊意图拆成了可以直接验证的数值和结果。AI 拿到这类输入时不会自由发挥因为每个 Given 都是状态准备每个 Then 都是断言目标。在实践中一个 Feature 文件里通常会有主流程场景、异常场景、边界场景。把这些场景逐条喂给大模型它会自动补全测试数据、选择测试金字塔的层级甚至帮你发现遗漏的临界条件。这比让模型直接看一个类名要可靠得多。2.2 为什么 AI 生成测试需要“行为上下文”而不是一句注释我拿同样一个函数做过对比。一种方式是给大模型一句“给 getDiscount 写测试”它大概率会生成一个 happy path 用例断言输入金额和折扣比例测试通过。另一种方式是给一段订单场景要求它从用户提交订单的角度生成测试。此时它会关心订单状态、会员类型、金额阈值、优惠叠加甚至会把“支付金额精确到分”作为显式断言写进去。两者最大的差别在语义锚点的数量级。大模型是概率生成器上下文越具体输出的随机性越小上下文越模糊它越会往“平均化”的方向靠。行为上下文本身就是约束器。你把这几个 Given/When/Then 步骤作为锚点LLM 生成的代码就不太容易跑题而且生成的测试天然具备业务可读性。另一个容易被忽略的收益是可追溯性。Gherkin 场景写上需求编号和作者生成的测试代码通过注释或命名约定关联回去。将来需求变更时你能直接定位哪些测试需要调整而不是靠全文搜索某个方法名。2.3 Feature 文件的精益化从文档到测试骨架很多团队引入 BDD 时会把 Feature 文件当成写给人看的文档只在下游手工翻译成测试。这种断裂会让 Feature 文件和实际代码很快脱节。在 AI-TDD 工作流里Feature 文件应该是所有测试生成的真源头不能允许它成为观赏性文档。我在项目里会把 Feature 文件的解析做成一个小流水线先用工具读取 Gherkin 场景提取步骤文本再交给大模型生成测试代码骨架。生成好的测试文件直接放到测试目录跑一遍测试收集器确认用例数量和场景数量匹配。FitNesse 时代做这件事需要大量胶水代码现在大模型可以直接输出 pytest-bdd 风格或 SpecFlow 风格的测试类替人省掉了繁重的 Step Definition 编写。这里有一个实操提醒不要让自动化流水线一开始就做得太重。先用最朴素的“手动跑一遍 Gherkin → 复制给模型 → 粘贴产物”的方式验证流程等稳定了再把它封装成 CLI 工具。一上来就搞平台化很容易被工具本身的维护成本拖垮。3. 重构后的研发闭环红-绿-重构在大模型辅助下的完整走查3.1 闭环第一步从行为描述生成测试骨架真正的 AI-TDD 循环不是“让 AI 直接写全部代码”而是让 AI 进入 TDD 的每一步但不破坏红绿交替的节奏。第一步把 Gherkin 场景作为输入让大模型生成可执行的测试骨架。我给模型的 prompt 通常是这样的模式你是一名测试工程师。请根据以下 Gherkin 场景生成 pytest-bdd 风格的测试代码。 要求 1. 不实现任何业务逻辑。 2. 每个 Then 步骤必须包含一个真实断言。 3. 使用 fixtures 或 mocks 隔离外部依赖。 4. 输出完整 Python 文件给出文件名。 Gherkin: ...生成后直接放到测试目录运行一次。在这一步测试的全部目的就是失败。失败的姿势不重要可能是缺少实现类、缺少路由、缺少数据库表重要的是系统已经出现了一组“表达需求契约”的可执行用例。这一阶段我会强令自己和团队不允许跳过红灯直接进入实现。因为红灯是团队对需求的共同确认清空这个状态很容易让需求又变回口头共识。3.2 闭环第二步让大模型补全失败用例与边界条件第一轮生成的测试通常只覆盖主流程。我不会满足于此而是把已有测试代码和 Feature 文件一起作为上下文再追加一轮 prompt“请针对上述场景补充等价类、边界值、异常路径测试新增测试必须是当前需求支持的不要臆造业务规则。”这一步会得到大量额外测试金额正好等于阈值、会员与普通用户差异、重复提交、库存不足等等。需要一个人工审查动作逐条判断这些补充用例是否真的符合业务不确定的就标记为“待业务确认”。这正好解决了 AI 生成内容最大的隐患——它经常把“可能存在的规则”当成必然规则。边界用例一旦进入测试套件就会变成强约束所以人工闸门不能省。补完后再次运行测试确认所有新用例仍处于失败状态。如果某些测试意外通过往往是测试本身写得太弱或者被实现代码“猜中”了需要回炉加强断言。3.3 闭环第三步红期失败驱动下的实现代码生成当一组失败测试稳定出现在面前时再把它们作为输入让大模型生成最小实现。此时的上下文包含失败测试代码、测试输出、相关接口定义以及一句强约束“你可以新增实现代码但绝不能修改测试代码和 Feature 文件。”大模型在“看着测试写实现”时的表现通常好于“直接看需求写代码”。原因是断言本身提供了清晰的目标函数。实现只要做到让测试通过即可这让模型不必在需求空间里做过多推理。实际执行中第一次生成的实现可能只让一部分测试通过剩下的失败信息会再次反馈给模型。这种循环很像结对编程里的“轮到你了”。每轮反馈都用真实测试输出作为依据避免了模型空转。要特别强调的是模型被“追得太紧”时会尝试修改测试来制造绿你必须把“不允许修改测试”写进 prompt 之外还要用 CI 或文件权限卡住测试目录的写权限。3.4 闭环第四步重构期由 AI 承担机械改造人审语义测试全绿后进入重构阶段。传统重构需要开发者手工消除重复、拆分函数、命名调整这些工作大模型完全可以承担而且速度惊人。我会在 IDE 里选一段刚通过的代码让模型“在不改变现有公共行为的前提下提取重复逻辑并重命名变量”然后把结果和测试一起提交。但这里有一个必须遵守的原则AI 重构时不要喂给它过大的上下文只给它局部片段和就近的测试运行结果。它进行重构时你需要在旁边看 diff。实测中小模型倾向于做非常保守的调整强模型则喜欢“顺手优化”出一些抽象层。抽象本身不一定是坏事但如果它与当前测试没有直接关联就容易变成过度设计。我给团队的策略是AI 的重构结果必须重新跑一次全部测试并且代码评审人至少有一个人真正理解这块业务。到此一个完整的 Behavior-Driven AI-TDD 闭环就形成了。它不是一个松散的自由发挥式 AI 编码而是一套有纪律、有红绿信号、有反馈循环的工程流程。4. 工具链与模型选型本地大模型与商用 API 怎么塞进工作流4.1 工作流对模型能力的三个硬性要求不是随便什么大模型都能塞进这套闭环。我在选型时主要看三个能力维度。第一是长上下文。一个真实的 Feature 文件加对应测试文件经常有两三百行模型必须能在输入里同时容纳这些内容才不会漏掉场景。第二是指令遵循能力。它必须能听懂“只生成测试代码”“不要修改测试”“不要输出解释文本”这类要求。有的模型生成效果好但总在代码块前后夹带说明文字用起来很别扭。第三是稳定性。同样的输入重复调用如果输出测试每次都不一样团队会被调 prompt 耗死。这三个要求直接把模型分成了两个阵营轻量本地模型和重型商用 API。测试代码生成这种任务本地 7B 到 14B 量级的模型基本能胜任涉及复杂业务逻辑重构或需求语义推断时调用能力更强的 API 成功率会高很多。我的做法是“双轨并跑”团队默认使用本地模型处理日常封闭循环遇到生成质量连续不达标的情况再显式切换到远程强模型。4.2 本地部署模型在测试代码生成场景的实测印象我在一台 32GB 显存的机器上跑过量化后的 7B 和 14B 指令模型用 Ollama 暴露 OpenAI 兼容接口然后接进一个小 CLI 工具。生成简单的 pytest 测试完全没有问题Given/When/Then 步骤基本能对上。但面对一个包含五个以上场景的 Gherkin 文件时小模型会漏场景尤其是在生成第二、第三个场景时容易开始“合并同类项”。对策是把一个 Feature 按场景拆开每次只喂给模型一个场景生成后再合并。这牺牲了一点速度但质量显著提升。对于本地模型的量化精度我的建议是优先用 4bit 或 5bit 量化不要一味压到 2bit。测试代码的长尾错误信息和边界断言需要足够的指令跟随能力量化太狠会直接表现为“生成即崩”。如果你所在项目有数据合规要求不能把业务代码发送到外部 API本地部署几乎是唯一选择。把 Feature 文件和测试代码留在内网让模型走本地推理整套流程依然能闭环。代价是你需要抽时间维护模型版本和推理服务这种运维成本要算进整体工作流重构的预算里。4.3 配合现有 CI 的自动化卡点设计工作流重构最终要落到 CI 上否则“红绿循环”很容易只存在于政治正确的日报里。我目前用的做法是在代码仓库里约定三个目录features/存放 Gherkin 文件tests/存放测试代码src/存放实现代码。当 PR 里出现features/*.feature变更时CI 会自动执行一次“行为一致性检查”# 伪代码博文示例实际按项目调整 parse-features features/ /tmp/bdd_steps.json run-tests tests/ /tmp/test_result.json validate-mapping /tmp/bdd_steps.json /tmp/test_result.json这个卡点只验证两件事Feature 文件里的每个场景是否能找到对应测试方法以及这些测试是否全部执行过。它不会替代代码评审但能把“Feature 文件和测试脱节”这类问题在合并前拦下来。CI 还可以做一道反向卡点如果某次提交只改了实现代码却没有任何测试文件一起变化就自动标记为“需要人工确认测试是否充分”。这在 AI 辅助生成大量代码后尤其重要能避免模型悄悄绕过红灯阶段。5. 落地过程中的坑与对策AI 生成的测试也要被质疑5.1 大模型会自信地写出“假绿”测试AI-TDD 最大的坑不是 AI 不会写代码而是它会用非常漂亮的姿势写出没有价值的测试。最常见的情况包括断言为空、只用assert True、把实现逻辑复制进测试、或者只 mock 了所有依赖然后断言 mock 被调用了自己。def test_discount(): assert True # 假绿刚开始我把这类测试混进套件时CI 全绿覆盖数据很漂亮但一改折扣规则测试照样通过。原因就是断言没有锚定可观察行为。现在我会在生成 prompt 里强写一条规则“每个测试必须包含至少一个不依赖被测函数内部实现的数据断言禁止使用 assert True。”代码评审时第一眼永远看断言而不是看测试命名。更有效的查错手段是变异测试。对实现代码里的常量做小改动比如把八折改成七折如果测试套件没有变红说明测试根本没捕捉到行为变化。这个检查成本略高但对验证 AI 生成测试的质量特别好用。我在合入大段 AI 生成的测试前都会至少跑一次针对核心业务常量的变异检查。5.2 保持红绿循环的频率让 AI 反馈在 10 分钟以内如果一次生成测试要等五分钟生成实现又要等五分钟开发节奏会被 AI 拖垮。人没办法在每分钟一次的反馈循环里长期工作大脑会主动绕开这个高摩擦环节。解决方向是缩小工作单元。一个完整的 Feature 往往拆成若干个 Scenario每个 Scenario 就是一个循环单元。只针对当前场景生成测试再生成实现跑完进入下一个场景。这样单次生成量控制在 50 行以内绝大多数本地模型能在 20 秒到 1 分钟内完成。整个红绿循环的自然节奏被保持下来。另外一个改变是让 AI 直接生成差量文件而不是每次都重写整个测试文件。我在 CLI 工具里会把当前文件内容和新增场景追加进 prompt要求模型只输出新增部分再由脚本合并。这样生成的输出短、模型不容易幻觉且已有代码不会被无意义改动。5.3 代码审查的侧重点要改变传统代码评审主要看实现逻辑质量。到了 AI-TDD 工作流里实现代码很可能是模型写的评审人的精力要更多花在“测试与需求之间的映射”上。我一般会带着三类问题去审每个 Gherkin 步骤是不是都变成了一个真实断言测试里有没有偷偷写入实现细节导致测试和需求耦合过深有没有出现大量“为了覆盖率而测”的无效用例这些问题看起来简单但 AI 生成的代码很容易混入“装饰性测试”——它能跑、有断言、但业务价值趋近于零。人工评审必须有意识地做减法敢于删掉模型生成的多余测试。5.4 团队协作契约AI 辅助生成物必须可追溯最后是协作层面的问题。AI 生成物越来越多如果不知道哪段测试来自哪个模型、哪次 prompt出问题时就很难复盘。我给团队定了三条规则Feature 文件是需求的唯一事实来源任何人不得绕过它直接让 AI 写测试。所有由 AI 生成的测试文件头部保留生成配置注释记录模型名称、温度参数、生成命令。任何模型输出只要被人工修改就不准承诺“这是 AI 原生成品”。这三条规则不需要工具支撑靠代码审查就能执行。但它们决定了 AI-TDD 是一个可治理的工程流程还是又一场 prompt 烟花秀。6. 一个支付模块的重写案例几十次红绿循环之后的工作流重构体会6.1 我们是怎么从一个混乱模块开始的这个支付模块原本有 21% 的行覆盖率大部分测试都是“调用函数断言不为空”级别的。业务逻辑散落在服务层和一个 900 行的工具类里没人敢动。重写的起点不是先写代码而是先和业务方坐下来把历史遗留的各种“应该”“可能”梳理成一份 Gherkin 文件。这个过程花了三天产出了 20 个场景覆盖主流程、异常、边界。当这些场景变成一个一个红灯时团队的讨论方式发生了变化。以前验收测试的问题常常是“你觉得这个地方应该怎么算”现在变成了“这个 Scenario 写的是金额满 200 就打折但如果订单里有运费当前场景没有描述运费是否计入阈值”。业务方会直接回答说“运费不计入”我们就顺手把这个约束补进 Given 里。这类歧义在传统开发里通常会被实现者静默消化掉现在却能在测试变绿前被显式解决。6.2 机械劳动被替代之后人的工作重心变了重构过程中模型承担了大约八成测试骨架和一多半机械重构。真正省下来的时间不是“不用写测试了”而是“不用在测试里猜业务规则”。那些省下来的精力被放到了与业务对齐、审查断言、删掉无效测试上。几十次红绿循环后这个模块的测试数量从 17 个变成 52 个覆盖率到了 84%。我个人的体会是这套工作流最大的价值不在效率提升多少倍而是让 AI 的输出从“看起来像代码”变成了“可被行为契约校准的工程产物”。AI 出错不可怕可怕的是出错时没有任何信号能发现。在 Behavior-Driven AI-TDD 里红绿状态和 Gherkin 场景就是那组信号。如果你也正打算把大模型接进开发流程我建议先别急着搭平台而是拿一个需求边界清晰的模块把 Feature 文件、测试生成、实现生成、手动测试这四步先手工跑通一次。一旦你体会到“红灯代表需求契约绿灯代表行为满足”的感觉就不会再回到直接让 AI 写完整代码的老路了。