作为在软件工程一线折腾了十来年开发流程的人我这两年最大的感受是我们正在经历一场从“工具驱动执行”到“意图驱动协同”的深刻转变。以前大家聊 TDD说的是“红-绿-重构”三步走核心是人肉写测试、人肉对照需求现在大模型把代码生成、测试生成、行为描述解析都拉到了一个近乎“随叫随到”的层面很多团队开始重新审视一个问题——行为驱动开发BDD和测试驱动开发TDD在大模型时代到底该怎么组合才能形成真正的研发闭环。我见过太多团队把 AI 当成“高级自动补全”写代码倒是快了但需求理解错了、测试形同虚设、回归全靠人工点一点最后反而更忙。这篇文章我想结合我自己的实践聊聊怎么基于 Behavior-Driven 的理念把大模型嵌入 TDD 的循环里重构整个开发工作流让软件研发从“写代码”变成“定义行为—验证行为—固化行为”的闭环。这篇文章适合正在摸索 AI 辅助研发流程的工程师、技术负责人以及想给团队引入 AI-TDD 但不知道从哪儿下手的同学。1. 为什么传统的 TDD 和 BDD 在 LLM 时代反而“卡脖子”了1.1 理想中的 TDD 闭环现实中为什么总断裂教科书里的 TDD 非常美好先写一个失败的测试然后写最少代码让测试通过最后重构。这套逻辑的核心是“测试即需求”测试写得足够具体代码行为就被锁死在预期里。但现实是绝大多数团队的 TDD 流程在第一环就断了——让业务方和开发一起把需求拆成可执行的验收标准这件事比写代码难得多。我见过很多团队的“TDD”其实是“测试后补”功能写完了再补几个能跑通的单元测试纯粹为了覆盖率数字好看。为什么会这样因为需求描述往往是自然语言自然语言充满歧义而测试代码是刚性约束。从“大概意思”到“精确断言”之间的鸿沟全靠开发一个人脑补。脑补出来的测试大概率测的是“开发理解的需求”而不是“业务真正要的行为”。BDD 的初衷就是解决这个问题。它用 Given-When-Then 这种半结构化描述把业务人员的“人话”和测试代码的“机器语言”做了一次桥接。Gherkin 语法就是这套桥接的载体。但传统 BDD 落地还有个硬伤从行为描述到生成可执行 step 定义需要写大量胶水代码这些代码既不产生业务价值又非常琐碎。团队做着做着就觉得投入产出不成正比Gherkin 文件沦为文档BDD 也就名存实亡了。1.2 大模型把“需求语义”和“测试代码”之间的翻译成本拉到了接近零过去我们写 BDD 测试最痛苦的是维护 step definitions——每个 Given/When/Then 句子背后都要有一段绑定代码把自然语言映射到具体 API 调用。这种映射本质上是一种“翻译”而且是极具规律性的翻译。恰好大模型最擅长的就是这种规律性内容生成。我自己的实操经验是现在让 LLM 根据一份产品需求文档直接生成 Gherkin 特征文件准确率已经相当高尤其是当你把上下文工程做好之后。所谓上下文工程就是把业务规则、既有代码风格、API 契约、历史测试样例一次性塞给模型它生成的行为描述基本能直接进入评审环节。这一步的变化是革命性的传统 BDD 最大的成本在“写特征文件 写 glue code”大模型把这两块的边际成本压到几乎为零。于是真正的人力可以投入到“评审行为描述是否符合业务预期”上而这恰恰是软件开发里最有价值、最不可替代的部分。从这个角度看AI-TDD 并不是抛弃 TDD而是把 TDD 闭环里最薄弱、最耗时的环节用自动化补齐让人的精力回归到“判断”而不是“翻译”。2. 重构后的工作流Behavior-Driven AI-TDD 的四个阶段2.1 阶段一用大模型辅助生成行为描述锁定业务意图我建议的模式是这样的产品经理或业务分析师先输出一段用户故事和关键业务规则哪怕是一段比较粗糙的、带口语化描述的文本都没关系。接下来开发人员把这段文本连同项目的代码结构、API 设计文档、历史特征文件范例一起交给大模型让它产出结构化 Gherkin 描述。这里有个关键细节——不要一上来就要求模型生成完整测试套件。我踩过这个坑一次性让它生成太多东西出来的结果看着像模像样实际跑起来全是假阳性。我现在习惯把它拆成两个子任务第一步只生成 Feature 层面的行为描述交给业务方人工评审第二步等描述确认没有歧义了再让模型生成对应的测试骨架和 step 定义。为什么拆成两步因为行为描述一旦错了后面所有测试和代码都是建立在沙滩上的城堡。人工评审行为描述这个动作是整个工作流里成本最低、收益最高的质量关卡。而且对业务方来说读 Given-When-Then 描述比读代码容易一百倍他们能真正参与进来而不是只在提需求的时候出现一次。2.2 阶段二智能生成失败测试明确“进步”的定义需求锁定之后第二个阶段是把 Gherkin 描述翻译成可以运行的测试代码。这一步我强烈建议用大模型生成但在落地前必须加一道“静态校验”。具体来说你让 LLM 生成测试代码后先别急着跑让它在同一个上下文里生成一份自检清单这个测试覆盖了哪条业务规则它断言的行为是否和 Gherkin 里的每一步严格对应有没有可能绕过业务断言、只测实现细节的漏洞把这份自检清单贴进代码评审里人只需要把注意力放在“模型理解的业务规则对不对”而不是去逐行检查它调用了什么方法。这一步的产出是一套故意跑不通过的测试正是 TDD 里那个“红”。很多工程师会让大模型直接生成功能代码把测试“变绿”但这样逻辑就反了。AI-TDD 的精髓在于先让测试按需求意图变红再由人类工程师或者 AI 辅助生成的实现代码去“追赶”这个红色信号。红色测试才是需求的“可执行定义”它在那里就说明我们对自己要交付的内容有了刚性约束。2.3 阶段三实现最小代码闭环到“绿”有了失败测试实现阶段其实变成了一个真正的“解题”过程。此时你再把测试代码、相关接口定义、调用上下文交给大模型让它生成最小实现符合 TDD 里“只写能让测试通过代码”的原则。这一步输出的代码往往比人凭感觉写的更精简因为它不需要“考虑过度设计”只需要满足当前这组断言。不过在实现阶段我不建议直接全盘接受 AI 的输出。这个环节需要把大模型的输出当作“第一候选人”然后由经验丰富的工程师做两件事第一检查是否引入了测试之外的副作用第二检查命名和结构是否和现有代码库风格一致。实测下来标准统一样式统一库的团队AI 生成的代码通过率很高反之如果代码库风格混乱AI 生成的内容就容易越写越乱。2.4 阶段四持续回归与固化形成研发闭环最后这个阶段是我最想强调的——研发闭环的价值不在第一次开发而在后续每一次迭代。传统 TDD 之所以难坚持是因为维护测试的成本会随项目演进不断升高需求一变相关测试就要跟着改牵连甚广。很多人觉得“我都花了时间写测试需求改了全得重写那测试到底是资产还是负债”在大模型驱动的 AI-TDD 工作流里这个问题的答案清晰了测试是资产因为需求变更时的关联测试更新现在可以由 AI 辅助完成通知成本大幅下降。当用户故事发生变化你把变更描述和现有测试一起丢给大模型它能快速生成变更影响清单——哪些测试要改毫无动力哪些测试需要删除哪些测试需要新增。这一步让“重构—扩展—回归”真正循环起来整个研发过程不再是线性的“写码—交付”而是一个不断围绕行为定义更新的闭环。3. 实操落地我在真实项目里是怎么配置这套工作流的3.1 从零搭建基于 LLM 的架构设计助手这里我分享一个可复现的实操路径。选型上我并不执着于某个特定模型而是更看重三个能力长上下文理解、代码生成质量、是否支持结构化输出。长上下文是最关键的指标很多时候 AI 生成的测试跑错了不是模型智商问题而是它没看到足够的项目背景所以在 ReAct 模式或者普通对话里要把项目的目录结构、关键配置文件、API 路由都塞进上下文。我的建议是搭建一个“会话模板”概念模板里有四块固定内容项目技术栈与目录树、核心领域模型定义、现有测试风格样例、Git 提交规范。每次让 AI 生成测试或实现代码前先自动把这个模板附加到请求里。这个模板本身就是上下文工程的核心成果比一味追求更高级的模型更能稳定提升输出质量。3.2 本地代码库检索工具让上下文真正精准单纯把整个仓库塞给模型不现实上下文再长也有天花板。这里我引入本地代码检索工具的思路先对仓库建立索引按包名、函数名、类名切块然后用向量检索或者关键词检索召回和当前任务相关的代码片段拼装成动态上下文。举个例子假设你现在要为一个订单服务的支付接口生成 BDD 测试动态上下文会优先召回订单实体的字段定义、支付接口的入参出参结构、已有支付逻辑的单元测试、异常分支的相关代码。这一步把从“泛泛的 AI 编程助手”变成了“真正懂你这个项目的结对编程搭档”。不过这里有个容易忽略的点代码检索索引是需要维护的。分支一切、大重构一来索引就可能失效。我的实践经验是不要过度依赖自动化索引更新而是把这个工具用在“稳定主干”的工作流里做功能开发够用即可。3.3 借助 CI 让行为描述与代码同步如果你已经跑通了上面的流程下一步建议把 AI 生成的内容接入 CI 做自动校验。我现在的方案是Gherkin 文件变更时自动触发一个脚本脚本调用大模型检查——当前实现中是否存在和 Gherkin 描述不一致的 step是否有测试方法引用了命名不清晰的绑定这一步的目的不是在 CI 里跑一份“AI 评审报告”代替真人评审而是把那些低级的 “描述和实现漂移”问题拦截在合并之前。CI 里跑 AI 校验的成本其实很低因为只有 Gherkin 变更时才触发而且模型调用量也不大。执行下来我最大的感受是它迫使我们养成了“改代码先改行为描述”的纪律。以前团队里大家都觉得 Gherkin 是文档可有可无现在它成了 CI 检查的源头谁敢不更新谁就过不了流水线这个策略直接让研发闭环真正落到了流程级。4. 踩过的坑与排查技巧4.1 陷阱一把 AI-TDD 用成了“AI 写码人写测试”这是我在不同团队见到最频繁的误用方式。很多人觉得 AI-TDD 就是让 AI 写代码人负责写测试把关。但真按这个模式运作效果往往很差因为在人写测试的一侧仍然存在需求理解偏差的老问题AI 写实现代码只是在“快速实现错误需求”速度越快、错误越远。反过来也不对AI-TDD 的合理模式应该是人和 AI 协同在“行为定义”层面一起产出高质量的特征描述然后 AI 基于描述生成测试代码最后 AI 在测试约束下生成实现。人的注意力集中在“业务语义是否正确”上机器的注意力集中在“从语义到代码的转换”上。如果你发现自己处于“人写测试、AI 写代码”的模式赶紧把这个比例倒过来。4.2 陷阱二上下文缓冲区的救火式修复很多工程师在让大模型生成代码时习惯“报错一次补一次”错了就把错误贴回去让它改再错再补。这种典型的救火式上下文会带来两个问题对话上下文窗口被杂音塞满真正重要的需求信息反而被稀释而且模型会因为最近的错误信息“过度拟合”到当时的失败路径上陷入反复改一处、坏另一处的循环。我的排查经验是一旦出现连续三次修复不成功果断开启新会话把从失败中提炼出的关键约束比如“支付金额必须大于 0”“订单状态不能直接跳过已支付”浓缩成新的上下文重新生成。这个小技巧我至少让项目里的 AI 生成通过率提高了两倍不止。4.3 陷阱三忽略了“行为描述评审”是人的工作AI-TDD 里最容易犯的认知错误是觉得大模型连行为描述都能生成内容一定没问题于是业务方和开发组成的评审直接被跳过了。这是我见过最危险的做法——相当于把需求分析也外包给 AI 了。我必须强调AI 生成的行为描述质量和它的输入质量正相关。如果输入需求本身就是含糊不清的输出描述也会在“含糊地精确”之间摇摆。这个阶段必须有人工评审参与而且评审的重点不是看它写得好不好而是逐条问“这一步真的代表了业务规则吗”“这个 Given 条件在实际业务里存在吗”“这个 Then 断言是必然结果还是可能分支”这一步省不得省掉了前面所有自动化都是空转。4.4 几张表帮你快速评估工作流是否健康为了帮你快速判断自己的 AI-TDD 工作流有没有问题我整理了两份速查表。第一张是角色责任表每周对照检查一次环节应该由谁负责常见错误业务规则澄清产品经理业务方完全交给 AI行为描述生成AI开发协同完全手工撰写Gherkin 评审开发业务方共同只看不评、直接跳过测试代码生成AI生成人工静态校验盲目信任 AI 输出实现代码生成AI生成工程师决策人写测试而 AI 写实现回归审核工程师 CI 自动化依赖 AI 评分代替判断第二张是信号体检表出现对应症状就知道哪里出了偏差症状根因调整建议测试覆盖率很高但线上 bug 不少测试断言没对应行为描述测了实现细节重新从 Gherkin 反查每个测试的目的AI 反复修改但测试一直不通过上下文杂音太多开新会话浓缩约束条件Gherkin 文件和实际代码明显漂移没有在变更流程里约束“先改特征描述”接入 CI 行为一致性校验业务方对最终交付不认可行为描述评审阶段被省略强制加入人工逐条评审关卡5. 关于研发闭环的再思考前面聊的大部分内容都在讲 AI-TDD 怎么落地、有哪些细节坑。但我心里最想分享的其实是这套实践背后的一个观念转变软件研发的闭环从“代码和需求的关系”变成了“行为描述和现实世界的关系”。过去我们写需求文档写测试用例写代码本质上是把真实世界的问题数字化。但数字化的过程必然丢失信息需求文档和代码之间的映射关系只能靠人维护。AI-TDD 的工作流是通过让“行为描述”成为一等公民——它既接近自然语言让业务方可以理解又接近可执行代码让机器可以验证——来把信息丢失降到最低。一个额外的观察是这个工作流对团队的沟通模式有反向塑造作用。推行 AI-TDD 之后业务方和开发的对话方式变了不再说“做个 XX 功能”而是慢慢习惯“XX 功能在什么条件下应该表现出什么结果”。这个沟通模式一旦养成本身就是团队能力提升的体现。另外从技术演进角度看我判断接下来的方向是 agent 化的工作流。也就是不再靠人在会话里手动拼接模板、调用检索工具而是让一个研发 agent 自主判断什么时候该检索代码、什么时候该生成测试、什么时候该提交人工评审。到那个阶段AI-TDD 就会从“人在回路中的辅助模式”进化为“人监督 agent 的委托模式”。但不管工具怎么变行为驱动的核心思想——先定义可验证的行为再实现它——都不会过时这也是我对这套工程方法长期价值的判断基础。如果你正准备在团队里推 AI-TDD我的建议是不要一上来就铺全流程先选一个边界清晰的中型模块跑通“行为描述生成—测试生成—实现生成—人工评审”的小闭环把节奏和模板跑顺了再逐步扩大范围。这种渐进式的推进方式虽然看起来慢但实际是最稳妥、最难翻车的路径。