行为驱动开发、AI 与 TDD 三合一我怎么把研发工作流重构成大模型闭环Behavior-Driven AI-TDD这个名字听起来像三个流行词的缝合怪,但如果你现在正被困在“AI 写代码很快、但没人敢改”的尴尬里它可能是最能救你的一条路。我不太喜欢定义先把场景摆出来需求评审完了产品经理用自然语言写了一堆验收条件开发打开 IDE 把大模型生成的代码粘进去跑起来一看能出结果但谁都不知道这堆代码到底覆盖了哪些真实业务行为。两周后需求微调没人敢动那块代码因为没有任何测试兜底。这是当下多数团队的普遍状态。Behavior-Driven AI-TDD 解决的正是这个问题。它不是让 AI 帮你写更多代码而是先把业务行为用统一的、人能读懂、机器也能理解的语言固定下来再让 AI 围绕这些行为去生成测试和实现最后形成一个“行为定义 → 测试校验 → 实现生成 → 回归验证”的闭环。适合谁参考被 AI 生成代码质量困扰的一线开发者、想把 AI 接入团队流程但怕失控的技术负责人、以及所有在敏捷和 TDD 边缘反复试探却始终落不了地的团队。这个方案不是某个现成工具的配置教程是我在重构团队开发工作流过程中逐步打磨出来的工程实践。下面把完整思路、闭环设计、实操步骤和踩坑记录都摊开来说。1. 重审传统研发流程大模型时代的工作流为什么必须重构1.1 传统 TDD 在 AI 辅助下的尴尬处境传统 TDD 的路径是先写失败测试再写最小实现让测试通过最后重构。这套方法论在大模型出现之前已经很难坚持原因很现实写测试的时间成本远高于写实现业务方又不断压排期测试往往是第一个被牺牲的。大模型出现后很多人以为可以靠 AI 自动补测试来挽救 TDD结果发现问题更严重了。AI 生成的单测数量多、覆盖率高但基本都是围绕函数实现写的执行路径怎么走它就怎么测一旦实现逻辑错了测试会跟着一起错而且错得一本正经。它测的是“代码做了什么”不是“业务应该做什么”。这种测试给团队制造了虚假的安全感比没有测试更危险。我见过一个支付模块AI 生成的 40 多个单测全部通过人力 review 的时候才发现汇率换算的公式方向反了测试却完全没发现因为测试断言是从实现代码反推出来的实现错断言也跟着错。核心矛盾在于传统 TDD 的“红-绿-重构”循环以开发者个人自律为前提而大模型时代的 AI 代码生成把写代码的门槛降到了极低却把校验逻辑正确性的门槛抬得极高。这倒逼我们必须把注意力从“怎么生成代码”转移到“怎么定义行为的验收标准”上来。1.2 BDD 的旧瓶子为什么装得下大模型这壶新酒行为驱动开发BDD其实不是什么新概念十几年了核心是用 Given-When-Then 结构描述业务行为让产品、测试、开发用同一种语言对话。过去 BDD 落地最大的阻碍是前期结构化成本太高写一份规范的 feature 文件经常比写代码还费劲收益周期长团队很难坚持。大模型改变了这个成本结构。AI 最擅长的事情之一就是把非结构化的自然语言转换成结构化的表达。过去需要人工精心设计的 Given-When-Then 场景现在可以基于需求原文直接生成初稿人只需要做校正和决策。这意味着 BDD 从“昂贵的最佳实践”变成了“可负担的工程环节”。另一个被多数人忽略的因素是大模型输出天然不稳定同一段需求今天生成一个实现、明天生成另一个实现。怎么约束这种不稳定性光靠 prompt 没用必须在流程上建立强制校验点。BDD 的 feature 文件恰好提供了这个校验点无论 AI 怎么生成代码最终都要满足行为规范的约束。这就是“行为驱动”四个字在大模型时代重新有价值的根本原因。2. Behavior-Driven AI-TDD 的闭环机制从需求到代码的四个节点2.1 闭环的四个节点行为定义、测试生成、实现生成、回归验证我把整个研发闭环建模成四个节点每个节点有明确的输入、输出和校验标准。第一个节点是行为定义输入是产品需求原文输出是结构化的行为规范我们用的是 Gherkin 语法。这个节点是整个闭环的灵魂但也是最容易被敷衍的环节很多人拿 AI 生成一份 feature 文件就当完成任务实际上行为定义的质量直接决定后面所有环节的天花板。第二个节点是测试生成输入是行为规范输出是可执行的测试代码。这里的关键不是让 AI 自由发挥写测试而是严格基于行为规范中的场景去生成测试一个场景对应一条或几条断言链不许多也不许少。第三个节点是实现生成输入是行为规范和测试代码输出是功能实现代码。实现必须面向“让测试通过”这个目标先有测试后有实现顺序不能反。如果不写测试就让 AI 直接写实现代码很容易陷入自说自话的逻辑闭环。第四个节点是回归验证跑批量测试回读覆盖结果和失败用例再把这个结果反馈给 AI 或开发者决定是修复实现还是修订行为规范。闭环的关键在于“反馈”不是单向的“生成-交付”而是生成之后必须有校验校验失败必须有修正修正之后必须重新校验直到行为规范被完整满足为止。2.2 为什么闭环必须“左移”把意图固定成契约而不是看结果软件开发里有个概念叫左移测试意思是把质量保障活动尽量往需求阶段推。Behavior-Driven AI-TDD 本质上是一次彻底的左移而且移到了最左边——需求本身。传统开发流程中需求是起点但很快就被抛在脑后开发看到需求后进入自己的编码世界测试根据开发输出的代码反推用例产品最后验收才发现对不上。整个链路里需求的原始意图被层层损耗。闭环设计里的行为定义节点做的就是在需求阶段就引入 AI 辅助快速把意图翻译成一份不可辩驳的“契约”文件。这份契约有三个属性第一人可读产品经理能看懂并确认“对这就是我要的”第二机器可执行测试框架能直接读取它生成断言第三可版本化它进入 git 仓库像代码一样接受 review、追溯变更。一旦意图被固定成这份契约后续所有 AI 生成活动都有了参照物这时候 AI 再怎么自由发挥测试这道防线都能把它拉回来。2.3 双循环架构内循环生成外循环守护实操中我把这个闭环拆成两个循环。内循环是生成循环发生在本地开发环境AI 基于行为规范生成测试代码再基于测试生成实现代码然后立刻跑一次测试看红绿状态红了就让 AI 根据报错信息自己修绿了就进入代码 review。这个循环追求的是快速迭代我通常控制在 2~3 轮以内超过 3 轮还没绿就停下来人工介入避免 AI 陷入打地鼠式的修修补补。外循环是守护循环发生在 CI 流水线里每次代码提交后自动拉取最新的行为规范和执行测试套件检查测试覆盖率是否符合行为规范的场景覆盖要求再结合静态分析工具检查实现代码有没有绕过测试的行为。这个循环跑得慢但兜底能力强防止有人在巨大时间压力下直接把测试标注为“跳过”。两个循环不是替代关系是承接关系。内循环解决“AI 怎么把行为变成代码”外循环解决“代码怎么持续满足行为”。理解了这两层你就能看透后续所有实操步骤的目的。3. 从 0 到 1 搭建 Behavior-Driven AI-TDD 工作流3.1 工具链怎么选我不推荐任何全家桶这套工作流不依赖某个特定的 AI 平台或测试框架你可以用自己顺手的工具拼装。我的方案如下供参考AI 编程助手用的是公司内部接入的代码大模型 API可以是 Claude、GPT-4 系列或国产模型关键是具备较强的指令遵循能力行为规范用 Gherkin 语法这是 BDD 领域的事实标准测试框架用 Vitest CucumberVitest 跑得快、报错信息直观Cucumber 负责把 Gherkin 场景翻译成可执行测试CI 用 GitLab CI主要看重它 pipeline 的配置直观。提示不要在一开始追求完美工具链先用手头已有的东西跑通一次最小闭环。我见过一个团队为了引入这套工作流先花了三周做工具选型这是本末倒置。先跑起来过程中换工具的成本远低于想象。选择这套组合的核心逻辑是“每个环节都尽量选不粘人的工具”。AI 模型可以换、框架可以换只要 Gherkin 行为规范文件这个中间契约保持稳定其他全是可替换零件。3.2 第一个里程碑把需求翻译成行为规范这步是整个流程的地基需要产品、测试、开发三方参与但 AI 可以大幅压缩时间。实操中我会把需求原文和已有接口文档一起丢给大模型要求它输出一份 Gherkin 格式的 feature 文件。以一个用户登录功能为例AI 生成的初稿大概是这样的Feature: 用户登录 Scenario: 使用正确的用户名和密码登录成功 Given 用户已注册且账号状态正常 When 用户输入正确的用户名和密码 Then 系统返回登录成功 And 系统生成有效的会话令牌 Scenario: 使用错误的密码登录失败 Given 用户已注册 When 用户输入正确的用户名和错误的密码 Then 系统返回登录失败 And 系统不生成会话令牌这份初稿远不算完美问题很明显缺少边界条件的描述缺少“账号被锁定”这类业务规则的场景还有 Then 步骤里的“会话令牌”没有定义格式。但这正是人的价值所在我们在得到 AI 初稿后逐条讨论、补场景、订正措辞。这一过程通常从几小时压缩到 20 分钟而且质量更高因为 AI 给出的初稿覆盖了常见路径人的注意力都集中在补差异和边界上。行为规范不是一次性产物它会像代码一样持续迭代。需求变更时先改 feature 文件再改实现和测试这个顺序是整套方法论的核心纪律。3.3 第二个里程碑让 AI 顺着行为规范生成测试和实现行为规范确认后进入内循环。我的做法是先让 AI 基于 feature 文件生成测试代码再让 AI 基于测试代码生成实现。这一步的顺序感很微妙如果你让 AI 同时生成“测试 实现”它大概率会选择性地让测试去迁就实现相当于左手监督右手。分成两次独立的请求并且明确告诉 AI“测试代码先于实现代码生成二者不得互相引用”才能保证测试的独立性。生成测试的关键 prompt 模板我调了很久目前最稳的是这个基于以下 Gherkin 行为规范生成 Vitest 测试代码使用 cucumber 的 Given-When-Then 接口。 要求 1. 一个 Scenario 对应一个 it 测试块不允许合并或拆分场景。 2. 断言必须直接表述行为规范中的业务结果不允许反向推导实现细节。 3. 不使用 mock 来替代真实业务逻辑中的关键计算。 4. 测试文件中不得导入任何实现代码中的内部函数或状态变量。这里第三点是血泪教训。AI 非常喜欢用 mock 去模拟依赖如果 mock 力度过大测试就变成了自证清白。比如测试登录逻辑时 mock 了密码校验函数那这个测试等于没写。我的妥协方案是外部服务短信、支付网关可以 mock内部业务逻辑必须走真实代码。测试生成后交给 AI 写实现prompt 更简单核心就一句话“让以下测试全部通过不允许修改测试代码不允许在实现中使用测试替身绕过断言。”实测下来这个约束条件下 AI 生成的实现会更贴近业务表达因为它必须真实地完成行为里的每一个 Then 步骤。3.4 第三个里程碑把闭环接进 CI 流水线内循环跑通了人肉驱动着 AI 生成代码还只是第一步真正让闭环发挥长期价值的是把外循环接到 CI 流水线里。我的 GitLab CI 配置关键部分如下stages: - verify - test behavior-verify: stage: verify script: - lint-gherkin features/ # 检查 feature 文件语法 - ai-contract-check features/ dist/ # 检查实现是否满足行为契约 rules: - if: $CI_PIPELINE_SOURCE merge_request_event behavior-test: stage: test script: - npm run test:behavior - npm run coverage coverage: /All files[| ]\|[| ]([0-9.])/ artifacts: paths: - coverage/这个配置里有几个细节值得展开。第一lint-gherkin 是一个小工具负责检查 feature 文件的语法和结构完整性防止有人把 Given-When-Then 写残了还提交上来。第二ai-contract-check 是我们自己写的扫描脚本它检查行为规范里的场景数量与测试文件中的用例数量是否一致这是一道硬性关卡防止开发图省事把多个场景合并成一个测试。第三coverage 的收集不是针对代码行覆盖率而是场景覆盖率我们用 Cucumber 自带的统计功能看多少行为场景真正被执行了。外循环全部跑完一次提交才算“干净”。这套流水线初期跑一遍大约需要 4~6 分钟我刻意没有做优化就是要让人感知到这道闸门的存在。等团队形成肌肉记忆后再提速体验会好很多。4. 工程化落地时我踩过的四个大坑4.1 AI 生成的测试“假绿”断言写得太弱第一次让 AI 基于行为规范生成测试时我信心满满结果很快就翻车了。AI 生成的一组测试全绿但我随便把实现代码里的核心逻辑改错了几处测试竟然还是绿的。排查发现原因很可笑AI 给“登录失败”场景写的断言是expect(result.code).toBeDefined()而不是expect(result.code).toBe(LOGIN_FAILED)。前者只要函数返回个对象就永远通过等于没有断言。从那以后我定了条铁律AI 生成的测试里所有 Then 步骤的断言必须包含具体业务值禁止使用toBeDefined()、toBeTruthy()这类弱断言。并且我会定期做一些“测试可靠性体检”随机往实现代码里注入几个典型的逻辑错误看测试能不能拦下来。这个动作非常有效能持续暴露假绿问题。4.2 存量系统怎么改造不要一把梭从新需求切入口有人问我是不是要把所有历史代码全部重写成 BDD 风格这是大忌。历史代码通常没有行为规范文件强行反推工作量巨大而且历史需求文档大概率已经和线上逻辑脱节了反推出来的行为规范可能是在固化错误行为。我的建议是从新功能切入。具体做法是凡是新建的 Feature 或需求变更一律按 Behavior-Driven AI-TDD 流程执行存量模块保持现状只在它发生重构或重大缺陷修复时顺手补行为规范。这样既不会给团队带来毁灭性的改造压力又能让新代码的质量基线明显高于老代码。我在实操时的判断标尺是某个模块的缺陷率开始影响迭代速度时才值得为它补行为规范。先用一个季度的时间把新链路跑熟再回头处理存量模块中最痛的一两个别贪多。4.3 prompt 怎么沉淀把常见问题做成团队知识库prompt 不是写一次就永远不变的它会随团队规范、技术栈演进不断迭代。我建议在团队文档库里单独建一个“AI 指令集”目录用来沉淀几个核心模板行为规范生成、测试代码生成、实现代码生成、缺陷修复、规范校验。每个模板都标注版本号、适用场景、已知限制任何一次有效的 prompt 调整都要求提交人更新这个文档。我还踩过另一个坑给 AI 的 prompt 里塞了太多业务术语和人名导致它生成的行为规范里全是团队内部黑话产品经理都看不懂。后来统一约定prompt 中的业务描述必须使用规范的产品术语表没有术语表的先让产品经理补充。这个细节对后续结果的可读性影响极大。4.4 这套流程的价值怎么度量别看代码行数看四个指标度量是工程落地的最后一个环节但也是最容易做错的环节。千万别用“AI 生成了多少行代码”这类指标它会鼓励 AI 和人都往代码里注水。我日常追踪四个指标第一个是行为场景覆盖率即 feature 文件中被自动化测试真正执行的场景占比这是流程健康度的核心指标低于 90% 说明有人在绕过流程。第二个是测试有效拦截率统计每次缺陷修复后对应行为场景的测试是否在修复前处于失败状态如果测试没拦下缺陷而是靠人肉发现说明测试设计有问题。第三个是需求变更响应时间从 feature 文件变更到测试全部通过的时间这反映闭环的自动化程度。第四个是AI 生成代码的接受率即 AI 生成的测试和实现最终被保留下来、没有被大幅改写或删掉的比例。接受率太低的环节基本可以判断 prompt 或行为规范的输入质量出了问题。四个指标每个月复盘一次看起来枯燥但你会发现如果不追踪这些数据整个闭环到底有没有效果全凭感觉而且团队里每个人凭的感觉还不一样。这是最危险的。5. 一点心得这套工作流的边界在哪里5.1 什么项目适合、什么项目先别碰如果你在做一个以快速原型验证为主的工具类项目强烈建议别上这套流程因为行为规范文件的维护成本会拖慢试探性开发。行为驱动的价值在于“需求稳定性”如果需求一天变三次那行为规范本身就成了最大的返工来源先别给自己上枷锁。什么项目适合业务规则密集的领域比如权限系统、审批流、支付结算、订单状态机、风控规则引擎。这些领域的特点是一致的错误成本极高、业务行为可枚举、验收标准明确。在这些项目上投入行为规范的维护成本性价比通常非常高。我刚踩完的教训是不要试图把这套流程推广到全公司。先在一个 3~5 人可独立闭环交付的小组里跑起来形成完整可复制的范式和模板再横向输出。以一个小组的成功去说服其他团队比自上而下推行的阻力小得多。5.2 团队落地时最容易被忽视的三种协作习惯技术方案之外的协作习惯往往才是决定这套工作流能不能活下来的关键。第一个习惯是行为规范必须共同 review而不是开发写完了丢给测试看。我们的做法是 feature 文件合并到主干之前产品经理和测试必须要在 review 里留 thumbs-up否则 CI 不让我合。看起来增加了一个环节但实际省掉的返工远大于消耗。第二个习惯是AI 的重试必须有中断机制我见过有个同事让 AI 连续重试了 14 次去修一个测试失败最后发现是行为规范本身就写错了越修越歪。内循环里 AI 连续修 3 次仍然失败必须停下来先人工去看是测试错、实现错还是行为规范错。给 AI 设重试上限本质上是保护自己不要陷入无效的自动化追逐。第三个习惯是把行为规范和测试生成全部留在提交记录里包括 AI 的中间产物。这样做有两个好处一是以后复盘“当初这个业务规则为什么这么定”时有据可查二是训练新模型或调优 prompt 时有高质量的真实数据。这条做好了你的团队会拥有一份别人没有的语料资产这是长期价值。我在实际使用这套工作流的三个月后最大的感受不是效率变高了而是团队讨论问题的语言开始统一。以前产品说“这个功能要支持”开发理解的是“拿个输入返回个结果”测试理解的是“我要点一遍这个按钮试试”。现在大家坐下来讨论的都是 Given-When-Then每一个行为都在 feature 文件里摆着对错一目了然。最后再分享一个小技巧如果你决定尝试我建议不要从核心业务模块开始先挑一个你团队最近刚好要开发的、业务边界清晰的小功能用一天时间走一遍完整闭环。把行为规范、测试生成、实现生成、CI 接入这四步亲手跑通一次你的体会会比看十篇文章深刻得多。走完全过程你再判断要不要继续放大这套流程那时候你是带着实际操作经验做决定的。