很多人最近都在让 AI 写代码但真正卡住他们的不是“AI 不会写”而是“不知道让它写什么、写完了怎么证明它是对的”。我在重构一个库存管理模块的时候也撞上了同一堵墙——几千行存量代码没有任何测试没人说得清每个分支到底在守护什么业务规则。当时我重新把 Behavior-Driven Development行为驱动开发和 TDD测试驱动开发捡起来再把大模型嵌进循环里意外形成了一个能自我驱动、可持续反馈的研发闭环。这篇文章就围绕这套思路展开为什么大模型时代值得重构开发工作流Behavior-Driven 如何成为 AI 最稳定的需求锚点AI-TDD 闭环怎么设计、怎么落地以及我在真实项目中踩过的坑和排查思路。这个话题适合三类人正在评估 AI 辅助开发工具、却不知道怎么约束 AI 产出质量的团队写过 TDD 但觉得心智负担太重、想找更轻量姿势的工程师以及做研发效能或工程基建、需要给团队设计一套可复制工作流的技术负责人。下面所有内容都来自我自己的工程实践按可复现的标准来写。1. 为什么大模型时代需要重构开发工作流1.1 传统 TDD 的心智负担恰好是大模型最擅长消除的部分传统 TDD 的核心循环是“红-绿-重构”先写一个失败的测试再写最少量的代码让它通过最后重构。道理所有人都懂但真正坚持下来的人很少。我自己的体感是卡点从来不是“不会写测试”而是每次动手前都要先做一次完整的心智建模——这个行为到底会产生什么可观察结果边界条件有哪些异常路径怎么触发这些思考很重尤其在业务压力大的时候大脑会本能地想“先写实现测试之后补”。结果是测试永远在“之后”。大模型介入之后这个循环的成本结构变了。AI 天然擅长两件事把模糊需求翻译成结构化的断言以及从一段行为描述里枚举边界场景。它可以在一分钟内产出一整套 Given-When-Then 场景和对应的 Step Definitions而人类要做的是审阅和裁定——这正好把传统 TDD 里最消耗认知的“翻译环节”外包了出去。注意这里的核心不是“AI 帮你写代码”而是“AI 帮你把行为契约固化下来”。行为契约一旦立住后面的实现反而是相对机械的活。1.2 旧的研发流程里需求、代码、验证是三条断裂的线绝大多数团队的现状是需求在 Jira 或飞书里代码在 Git 仓库里验证在 CI 的流水线里三者之间靠“人肉同步”。需求文档更新了代码里的注释和实现没跟上测试挂在 CI 上但没人能说清每个用例对应哪条业务规则。这种断裂在存量项目里尤其明显——我看到过无数个“所有测试都绿、但业务逻辑已经和需求文档完全脱节”的代码库。大模型时代的工作流重构本质上就是要把这三条线重新缝起来。Behavior-Driven 提供了缝合的线用 Gherkin 语法描述行为用 Step Definitions 桥接代码用 AI 把需求文档翻译成测试场景。这样一来需求变更时先改特性文件AI 再据此更新测试和实现CI 会告诉你哪里断了。整个链路不再依赖某个人的“记性”而是依赖一条可执行、可追踪的行为链。我管这个叫“从文档到断言的短路径”。1.3 认知资源再分配人从“写”转向“判”很多人担心大模型会让工程师失业我的观察正好相反——它逼着工程师升级到更难的层级。过去我们要花大量时间写样板代码、写维度测试、调整 mock这些确实可以被 AI 压缩。但 AI 压缩了“写”的时间之后腾出来的注意力必须投到“判”上这个行为是用户真正需要的吗这个场景的优先级是多少AI 生成的断言是不是测了没意义的东西换句话说AI-TDD 的本质是认知资源再分配。工程师不再是代码的生产者而是行为契约的鉴定者。哪个场景应该进特性文件哪个场景应该被丢弃哪个断言的方向需要修正——这些决策仍然需要领域知识和业务判断。所以这篇文章不适合那种“想让 AI 全自动写代码”的人它适合愿意把 AI 当杠杆、但依然自己握方向盘的人。2. Behavior-Driven大模型时代最稳定的“需求锚点”2.1 为什么是 BDD而不是单纯的单元测试驱动我在设计这套工作流的时候认真对比过“直接用自然语言让 AI 写单测”和“先写 BDD 特性文件再让 AI 展开”。前者看起来更快但实际用下来问题很大自然语言太散同一个词在不同语境下含义漂移AI 这次生成的断言方向对下次就跑偏了。而且自然语言没法强制执行别人或者三天后的你根本看不懂这个测试到底在守护什么。BDD 的 Gherkin 语法则像一种“需求界的 DNS”——它把业务术语映射到可执行的测试步骤。Given 描述前置状态When 描述触发动作Then 描述期望结果这种三分法非常机械、非常结构化恰好是大模型最擅长的稳定输入。而且 Gherkin 是有“上下文”的Feature、Scenario、Background、Scenario Outline 提供了层次化的语境让 AI 不至于迷失在零散的句子里。我做过一个对比实验用同样的需求描述分别让 AI 写自然语言单测和 Gherkin 特性文件前者生成的测试用例覆盖了不到 60% 的边界场景后者因为有场景骨架的引导覆盖率接近 90%。2.2 Gherkin 语法就是给 AI 的发号施令板Gherkin 本身不需要多高深它的关键词就那么几个但每一个关键词都在向 AI 传递约束信号Feature定义行为主题相当于给 AI 限定“这段代码在守卫什么业务能力”。Scenario定义一条具体的行为路径相当于告诉 AI“这是一个可观测的业务事件”。Given定义前置条件AI 需要据此设计 mock、初始化数据、设置系统状态。When定义触发动作者AI 需要据此找到被测入口API、函数、用户交互。Then定义可验证结果AI 需要据此生成断言——注意是“可验证的结果”不是实现细节。这套结构比自然语言 prompt 强在三个点第一它是机器可解析的工具链可以直接处理第二它是双向契约业务人员能读、开发人员能改、AI 能执行第三它天然鼓励“从行为出发”的思考方式倒逼团队在写代码之前先达成对行为的共识。我现在的习惯是任何新功能进入开发前先花 20 分钟和产品经理把 Gherkin 场景写完。这不是额外负担——这是在给 AI 装“护栏”。没有行为规格的 AI 编程就像没有轨道的自动驾驶看着在动随时可能翻。2.3 从需求到断言的“三层翻译”模型这套工作流里有一个我最看重的抽象叫“三层翻译”。第一层是业务语言到行为规格的翻译也就是把产品需求里的描述变成 Gherkin 场景——这层必须由人来主导AI 可以辅助建议场景但裁定权在人。第二层是行为规格到测试脚手架的翻译也就是 Step Definitions 和断言骨架——这层可以完全交给 AI因为它是机械的、确定性的。第三层是测试驱动到功能实现的翻译也就是让实现代码满足测试——这层是 AI 最擅长的代码生成能力。三层翻译模型的价值在于每一层都有明确的输入输出任何一层断掉都能定位。需求变了你只需要动第一层的 GherkinStep Definitions 报错了你知道是第二层的翻译问题实现不通过测试你知道是第三层的生成质量问题。相比“直接让 AI 写完整文件”的黑盒方法这套模型的排障路径清晰得多。3. AI-TDD 闭环从“写代码”到“经营验证信号”3.1 闭环的六个环节与 AI 的介入方式我落地的 AI-TDD 闭环由六个环节组成需求解析、场景建模、测试生成、实现生成、验证反馈、重构收敛。每个环节 AI 介入的深度不一样这是设计上很关键的一点。需求解析AI 辅助提取行为主体、参与者、触发条件、期望结果输出结构化摘要。人工确认。场景建模AI 生成候选 Gherkin 场景包括正常路径、边界路径、异常路径。人工筛选和调整。测试生成AI 生成 Step Definitions 和断言代码。人工审阅断言方向。实现生成AI 生成满足测试的最简实现。人工确认设计约束。验证反馈CI 执行真实测试把失败信息回传给 AIAI 分析根因和建议修复方向。重构收敛AI 识别重复代码、过长函数、坏味道给出重构方案人审阅后执行。这个闭环和传统 TDD 最大的不同是“验证信号与生成器分离”。AI 生成了测试和实现但它不能自己给自己判分——验证必须由真实的测试运行器、真实的 CI 流水线来完成人类负责解读失败信号、决定下一步。这一条我要反复强调只要让 AI 自己验证自己你很快会得到一堆“看起来很绿、其实没意义”的结果。3.2 红-绿-重构循环在 AI 时代的变体经典 TDD 是“红-绿-重构”AI-TDD 是它的超集但节奏变了。传统循环里红阶段是写测试绿阶段是实现重构阶段是清理AI-TDD 里红阶段变成了“让 AI 生成一份诚实的失败测试”这不是文字游戏——它非常关键。AI 有一个天然缺陷它倾向于生成“确保能通过”的代码包括在测试里也是如此。如果你让它“先写测试”它往往会写出不痛不痒的断言因为这些断言肯定不会失败。解决办法是明确要求 AI 先生成一个会触达目标行为但没有实现的测试让它先红。我用的一个技巧是让 AI 先提交一次红色 commit把这个测试放进去然后记录失败信息。这一步看起来多此一举其实是在建立“诚实基线”——测试必须能真实地反映行为缺失。绿阶段也别让 AI 自由发挥。我会给 AI 设定约束只写让当前测试通过的最少代码不顺手重构、不添加额外功能。这个约束在传统 TDD 里是纪律问题在 AI-TDD 里是 prompt 设计问题。实测下来加上这句话之后AI 生成的“顺手代码”减少了一大半。重构阶段是 AI 发挥最稳定的地方。代码重复、圈复杂度高、过长的参数列表这些识别类任务大模型很擅长。我会定期把最近一段时间的 diff 丢给 AI让它输出一份坏味道清单和重构建议。注意是“建议”不是“直接改”因为 AI 的重构方案有时候会破坏行为契约必须由人来判断。3.3 工具链选型与角色分工速查整套闭环并不依赖某个特定的 AI 产品我用的是通用大模型 API 加一套轻量胶水代码。工具链选型遵循一个原则AI 可以接入任何环节但验证器和版本控制必须由标准工具承担。下面是我当前使用的组合可直接参考环节工具AI 介入深度人工介入点场景建模Gherkin 编辑器VS Code 插件即可生成候选场景筛选与确认测试生成pytest-bdd / behave 大模型 API生成 Step Definitions审阅断言方向实现生成Copilot 或自写 CLI 调 API生成实现代码审阅架构约束验证反馈GitHub Actions / GitLab CI分析失败日志决定修复策略重构收敛任何已接入的 AI 助手识别坏味道批准重构方案有人问我为什么不用更 heavy 的 Agent 框架我的回答是闭环的复杂度不来自 AI 部分而来自“人-AI-验证器”之间的交接。团队如果已经用 GitHub Actions 和 pytest 跑测试那就保持这些基础设施不变只插入 AI 生成环节。换一个全新的 AI 框架反而会引入新的不稳定变量。4. 一次完整的实战登录模块从行为规格到绿色测试4.1 用 Gherkin 写清行为契约我用一个非常典型的登录模块来演示整套流程。这个模块虽然简单但足够说明问题——它有正常路径、异常路径、锁定策略非常适合展示 BDD 怎么约束 AI。假设我们是先写好了下面的特性文件这段内容的职责是“把行为契约钉死”不涉及任何实现细节# features/login.feature Feature: 用户登录 作为系统用户 我想要通过邮箱和密码登录系统 以便进入我的个人工作空间 Scenario: 正确的凭证允许登录 Given 系统存在一个已注册用户 aliceexample.com And 该用户的密码为 Passw0rd! When 用户提交邮箱 aliceexample.com 和密码 Passw0rd! Then 系统返回登录成功 And 系统发放一个会话令牌 Scenario: 密码错误时拒绝登录 Given 系统存在一个已注册用户 aliceexample.com When 用户提交邮箱 aliceexample.com 和密码 wrong-password Then 系统返回登录失败 And 系统提示认证失败原因 Scenario: 连续失败五次后账户锁定 Given 系统存在一个已注册用户 aliceexample.com And 该用户已经连续登录失败 4 次 When 用户再次提交错误的密码 Then 系统返回账户锁定 And 系统记录锁定时间这份文件本身就是需求文档不需要额外的翻译。接下来的所有 AI 生成任务都以它为唯一事实源。4.2 让 AI 生成 Step Definitions一个高复用 Prompt 模板把特性文件丢给大模型之前我会加一层约束 prompt。我用的模板大致长这样你可以直接抄走你是一名测试工程师。请根据以下 Gherkin 特性文件为 pytest-bdd 框架生成 Step Definitions。 要求 1. 每个 Given/When/Then 步骤都对应一个 Python 函数且使用 pytest-bdd 的 given/when/then 装饰器。 2. 不实现被测系统内部逻辑只定义测试环境的行为。 3. Given 步骤负责初始化 mock 数据或系统状态。 4. When 步骤负责调用被测入口auth_service.authenticate。 5. Then 步骤负责断言断言必须可以验证真实返回值。 6. 用中文注释说明每个步骤的行为意图。 7. [重要] 生成的测试在目标行为尚未实现时必须能够失败红。以下是 AI 基于上述模板生成的结果我做了少量人工修正# features/steps/login_steps.py import pytest from pytest_bdd import given, when, then, scenarios scenarios(../login.feature) # 行为系统存在一个已注册用户 given(系统存在一个已注册用户 aliceexample.com) def registered_user(user_repo): user_repo.create(emailaliceexample.com, passwordPassw0rd!) return user_repo.get_by_email(aliceexample.com) # 行为设置该用户密码 given(该用户的密码为 Passw0rd!) def user_password(registered_user): assert registered_user.password Passw0rd! # 行为模拟连续失败状态 given(该用户已经连续登录失败 4 次) def fail_count_4(user_repo): user_repo.set_fail_count(aliceexample.com, 4) # 行为用户提交登录凭证 when(用户提交邮箱 aliceexample.com 和密码 Passw0rd!) def submit_valid_credentials(auth_service): auth_service.submit_credentials(emailaliceexample.com, passwordPassw0rd!) # 行为用户提交错误密码 when(用户提交邮箱 aliceexample.com 和密码 wrong-password) def submit_invalid_credentials(auth_service): auth_service.submit_credentials(emailaliceexample.com, passwordwrong-password) # 行为系统返回登录成功 then(系统返回登录成功) def assert_login_success(auth_service): assert auth_service.result.is_success is True assert auth_service.result.user_email aliceexample.com # 行为系统发放会话令牌 then(系统发放一个会话令牌) def assert_token_issued(auth_service): assert auth_service.result.token is not None assert len(auth_service.result.token) 16 # 行为系统返回登录失败 then(系统返回登录失败) def assert_login_failed(auth_service): assert auth_service.result.is_success is False # 行为系统提示认证失败原因 then(系统提示认证失败原因) def assert_failure_reason(auth_service): assert auth_service.result.failure_reason is not None # 行为系统返回账户锁定 then(系统返回账户锁定) def assert_account_locked(auth_service): assert auth_service.result.is_locked is True # 行为系统记录锁定时间 then(系统记录锁定时间) def assert_lock_timestamp(user_repo): assert user_repo.get_lock_time(aliceexample.com) is not None这里有个细节值得强调Step Definitions 里完全没有实现登录逻辑它只负责“搭舞台”和“验收结果”。AI 生成这一步的时候最大的风险是偷偷把业务逻辑塞进测试代码里比如在 When 步骤里直接操作数据库而不是调用auth_service。我的 prompt 里第 2 条就是专门堵这个问题的。4.3 跑红、跑绿、重构的全过程记录现在进入真正的 TDD 循环。环境里还没有auth_service这个模块所以跑pytest会直接报导入错误——这就是“红”阶段。这个红和传统 TDD 的红不太一样它不是验证行为是否正确而是验证测试脚手架是否诚实。我习惯把这个红色记录成一个 commit并在 commit message 里写清楚“此刻测试失败是因为目标行为尚未实现而非断言写错”。这个 commit 的意义在于如果哪一天测试翻红你可以回溯到底是这版引入的缺陷还是 Assertion 本身的方向错了。接下来让 AI 生成实现。我给的 prompt 是请实现用户认证模块 auth_service要求如下 1. 支持通过邮箱和密码进行认证。 2. 正确凭证返回成功和会话令牌令牌至少 16 位随机字符串。 3. 密码错误返回失败和失败原因。 4. 连续失败 5 次锁定账户并记录锁定时间。 5. 只实现满足上述测试的行为不要添加额外功能。AI 生成的实现大致如下# auth/service.py import secrets import time from datetime import datetime, timezone MAX_FAIL_COUNT 5 class AuthResult: def __init__(self, is_success, user_emailNone, tokenNone, failure_reasonNone, is_lockedFalse): self.is_success is_success self.user_email user_email self.token token self.failure_reason failure_reason self.is_locked is_locked class AuthService: def __init__(self, user_repo): self._user_repo user_repo self._result None property def result(self): return self._result def submit_credentials(self, email, password): user self._user_repo.get_by_email(email) if user is None: self._result AuthResult(False, failure_reasonuser_not_found) return if user.is_locked(): self._result AuthResult(False, user_emailemail, is_lockedTrue, failure_reasonaccount_locked) return if user.password password: self._user_repo.reset_fail_count(email) token secrets.token_hex(16) self._result AuthResult(True, user_emailemail, tokentoken, failure_reason) return count self._user_repo.increment_fail_count(email) if count MAX_FAIL_COUNT: self._user_repo.lock_account(email, locked_atdatetime.now(timezone.utc)) self._result AuthResult(False, user_emailemail, is_lockedTrue, failure_reasonaccount_locked) else: self._result AuthResult(False, user_emailemail, failure_reasoninvalid_password)跑 pytest这次全绿。绿色之后不要急着收工——让 AI 做一个快速审查有没有重复逻辑有没有过度设计比如上面代码里is_locked和failure_reason account_locked其实存在信息冗余AI 会建议把is_locked收敛为failure_reason的派生状态。你可以采纳也可以拒绝但这一步必须做。我在实践中发现整个循环里重构阶段的性价比最高因为它花一分钟省下的是未来数小时的理解成本。5. 落地踩坑实录七个高频问题与排查思路5.1 AI 生成“原地过测试”的低质量断言最典型的坑是AI 写的断言看起来在验证实际什么也没验证。比如它可能写成assert result is not None而不是assert result.token is not None或者直接用 mock 对象本身导致无论系统怎么坏测试都是绿的。这是 AI-TDD 特有的“假绿”风险传统 TDD 里你不会犯这种低级错误但 AI 会而且犯得很自然——因为它追求的是“测试通过”不是“测试有意义”。排查思路很简单每一条Then断言都要反问一句如果被测代码删掉这一行测试会不会失败如果不会这条断言就是废的。我在 Code Review 时会专门跑一次“删除实验”把实现代码清空看测试翻红数量如果翻红数量远小于断言数量说明断言在裸奔。5.2 特性文件写得太虚AI 生成的场景跑偏BDD 的威力上限取决于 Gherkin 的质量。如果你的场景写的是“用户正常登录”AI 生成的 Step Definitions 只能猜测“正常”是什么意思。我踩过最痛的一次是特性文件里写了Given 用户处于有效会话状态结果 AI 生成的 Given 步骤直接调用了登录接口把前置条件变成了被测行为测试链路直接短路。这类问题的根因是“行为规格不够具象”。我自己定的标准是特性文件里的每个 Given 状态都必须是可构造的能通过测试替身注入每个 When 动作必须是单个入口调用每个 Then 结果必须是可观测的返回值或副作用。做不到这三点就不要开始写代码。5.3 上下文窗口塞不下整个项目的测试上下文项目一大你会发现把现有代码结构和接口定义全塞进 prompt 里是不可能的。我早期尝试把所有模型的定义都发给 AI结果上下文一长AI 开始丢三落四生成代码的质量断崖式下跌。这个问题的解法和传统软件开发一样——靠抽象隔离。我的做法是维护一份浓缩的“系统契约文件”包含核心模块的公开接口、数据模型定义、关键业务规则控制在 200 行以内。每次让 AI 生成代码前只喂这份契约文件和当前任务相关的特性文件不喂整个项目代码。这就是我前面说的“上下文工程”不是上下文越长越好而是上下文越精准越好。5.4 AI 生成的测试代码通过 import 依赖传递了副作用有一次 AI 生成的 Step Definitions 在 import 阶段就连接了一个外部测试数据库导致本地无法跑测试CI 也时好时坏。排查了半天最后发现是 AI 在 Given 步骤里实例化了真实的 repository 而不是用 mock。这个问题在传统测试里叫“测试隔离失败”但在 AI 生成场景下特别容易复发因为 AI 没有“测试应该独立于环境”的隐性知识。应对措施是在 prompt 里显式声明规则Given 步骤禁止访问真实网络、禁止操作真实数据库、禁止依赖环境变量所有外部依赖必须通过 fixture 注入。不要觉得这些规则啰嗦——AI 不知道你的工程约定你把约定写在 prompt 里它才能遵守。5.5 测试套件膨胀CI 时间从 3 分钟涨到 26 分钟AI 生成代码的成本趋近于零导致我的项目里测试文件疯狂膨胀每个 AI 生成的场景都带四五个变体CI 时间肉眼可见地涨。后来我做了一次清理发现 80% 的变体场景都覆盖了同一段逻辑只是参数不同。这不是 AI 的问题是我没有设置“场景收敛规则”。现在我给 AI 下了硬限制每个 Feature 的正常路径场景最多 3 个边界场景最多 5 个异常路径场景最多 3 个。超出这个数量的场景必须说明理由否则直接丢弃。这个限制反而逼着 AI 去挑最重要的场景而不是堆数量。5.6 重构阶段 AI 破坏行为契约AI 在重构阶段有时候会“优化掉”一些它看不懂的行为。比如有一次它把锁定账户的判断从“失败次数 5”改成了“失败次数 5”测试还是绿的但业务规则已经从“第五次失败锁定”变成了“第六次失败锁定”。这是一次典型的静默破坏——测试覆盖了场景但没覆盖精确阈值AI 就钻了空子。现在我让 AI 重构前必须先列出“行为不变性清单”也就是哪些规则在重构后必须保持然后每一轮重构都对照清单检查。人的角色在这里再次凸显AI 可以生成清单但清单的正确性需要人核实。5.7 AI 生成场景缺失业务上下文最后一个高频问题不是技术问题而是流程问题AI 生成的场景有时候在技术上完全正确但在业务上毫无意义。比如它会为登录功能生成“邮箱为空时返回失败”的场景技术上没毛病但如果产品明确说了“邮箱为空前端就不让提交”这个测试就变成了纯粹的噪音。我的诊断是AI 只是行为的翻译器不是业务的来源。这条经验最终让我把工作流里的“需求解析”环节完全划给了人工——人和产品经理对齐再让 AI 展开。换句话说AI-TDD 闭环的开环节点必须在人这一侧闭环的回环节点才可以让 AI 接手。6. 边界清醒AI 负责铺路工程师负责导航6.1 AI 擅长的三件事翻译、枚举、识别把这几轮实战里 AI 的表现放一起看它的能力边界已经比较清楚了。AI 做得最好的三件事是第一把一份行为规格翻译成可执行的测试和实现这个翻译速度快到令人麻木第二枚举边界场景它不需要理解业务只要训练数据里有足够多的类似模式它就能列出你遗漏的边界条件第三识别坏味道代码层面的重复、过长函数、参数混乱这些有明确信号的特征AI 的检出率已经很高。这三件事都有一个共同点它们处于“给定输入推导输出”的映射通道里有比较明确的对错标准。6.2 AI 目前做不好的三件事裁定、权衡、负责AI 做不好的事情恰好是工程师的核心价值。第一是裁定两个业务规则冲突时该听哪个AI 会给你一个用概率拼出来的答案但概率不是真相。第二是权衡为一个边界场景加测试的收益是否值得维护成本AI 无法判断因为它的优化目标里没有“长期可维护性”这一项它只追求 token 级的合理性。第三是负责出了线上事故AI 不会背上责任但工程师会。这份责任决定了流程里必须有人的签字环节。我并不是说“人比 AI 更重要”而是说这套闭环里两者的角色完全不同。AI 在铺路——把机械劳动铺掉人在导航——决定路往哪修、修到什么程度、哪些路段可以拆掉重来。6.3 团队落地这套工作流的四个阶段最后给你一个可以直接抄的落地节奏。不要一上来就让全团队切换我推荐用四步走。第一步选一个边界清晰、行为可观测的模块做试点。我当年选的是登录认证你也可以选订单状态机、权限校验这类模块。目标是跑通闭环产出第一份 AI 生成的行为规格和测试。第二步建立团队共享词表。把 Gherkin 里用到的业务术语固定下来比如“有效会话”“锁定账户”“结算完成”统一命名杜绝同义表述。这一步直接影响 AI 后续生成的稳定性。第三步把闭环接入 CI。让特性文件的变化自动触发测试套件让失败信息自动汇总到团队群。这一步的意义是建立“信号自动化”。第四步逐步放开 AI 的自主权。先在测试生成环节放开稳定后再放开实现生成最后才是重构。每个环节的放开都需要配套 prompt 模板和人工审阅标准。我用这个四步法带了两个团队大概六周左右AI 生成代码的接受率从最初的不到一半提升到了稳定在八成以上。这个数字不是目标它只是建立在行为契约稳固之后的自然结果——你没有为 AI 设下清晰的边界AI 就不会给你可靠的行为。最后分享一个我在实践中逐渐养成的习惯每次让 AI 进入红绿循环之前我都会先问自己一句这个行为规格如果将来被删除会有人在意吗如果答案是不会我就不该让 AI 为它写任何测试。这个习惯某种意义上也是 AI-TDD 给我带来的最大转变——我写测试的动机从“证明代码是对的”变成了“记录业务真正在乎什么”。至于代码本身AI 已经能做得足够好而“业务真正在乎什么”是我作为工程师永远无法外包的最后一公里。