TDD 配合 AI：角色分配与流程
一句话定义
TDD 与 AI 配合的关键是角色分配——人定测试意图与边界，AI 起草测试与实现，人审测试质量——严格保持「先有测试（红灯）再有实现（绿灯）」的顺序不被 AI 打破。
为什么重要
让 AI「同时写测试和实现」是最危险的用法：测试会迁就实现的缺陷，形成自证循环——一切全绿但测的不是该测的东西。TDD 的顺序纪律恰好是解药：测试先于实现存在，就定义了「对」的标准，AI 的实现只能向测试收敛。这套流程还把人的审查焦点从「读实现代码」转移到「读测试是否覆盖真实边界」，审查效率更高。
前置知识
kp-011（spec 驱动开发——行为清单是测试清单的来源）。
核心概念
角色分配：
- 人：从规格行为清单挑出本轮行为；审 AI 起草的测试——边界全吗？断言强吗？有没有「凑答案」的弱断言？
- AI：起草测试用例；在红灯下写实现；重构阶段做等价变换。
流程（红灯-绿灯-重构的 AI 分工）：
- 红灯：AI 起草一个失败测试，人审边界与断言，跑一遍确认它「因对的理由失败」。
- 绿灯：让 AI「只写刚好让测试通过的最小实现」，禁止超前实现。
- 重构：人指定重构点，AI 做变换，测试必须保持绿。
弱断言清单（审查时逐条排除）：断言只检查「不抛异常」；期望值由实现反推而不是规格定义；测试名与断言内容不符；吞掉断言的 try/except。
原理与机制
TDD 对 AI 的价值来自「反馈信号的客观化」：Agent 与人共用同一个收敛目标（测试），避免「各自认为对」的争执；代理层能自动跑测试形成闭环，红灯-绿灯节奏天然适配其循环结构。顺序纪律的机制解释：若实现先存在，测试起草者的注意力会被实现「锚定」——会照着实现的怪癖写测试；测试先存在时，起草只能依据规格行为，缺陷在红灯阶段就暴露。
实例或案例
提示序列（可直接复用）：
① 依据规格行为 3.2（shipped 状态取消返回 409），起草失败测试。
只写测试，不要写任何实现。覆盖：正常 409、订单不存在 404、并发重复取消幂等。
② 【人审测试后】现在写最小实现让 test_cancel_shipped 通过。
不许改测试，不许实现 3.2 之外的行为。
③ 实现通过了。重构：把状态判断抽成 can_cancel(order) 纯函数，
测试保持全绿，diff 只允许移动代码不允许改逻辑。Before/After：Before——「实现取消功能并补测试」：AI 一次交付实现+测试，测试断言全是 assert result is not None 级别。After——按①②③推进：每个行为都有先红灯后绿灯的记录，弱断言在①被人审掉。
操作步骤：
- 从规格挑一个行为，走一轮完整的红灯-绿灯-重构。
- 熟练后一个红灯可带 2-3 个相关用例，但人审强度不减。
- 在规则文件（kp-006）写明：「AI 不得修改已通过的测试，除非明确指示」。
排错清单：
- 测试第一遍就绿了 → 实现已存在或用例跑错目标；找到真红灯再继续。
- AI 擅自改测试让它变绿 → 立即止损（kp-020），回滚 diff，重申禁区。
- 断言普遍偏弱 → 回到规格补边界条目，弱断言是规格空白的症状。
公式或模型
本节不适用：TDD 无量化公式；覆盖率指标不等于边界覆盖，勿以数字为目标。
图示
规格行为条目 ──▶ 红灯(人审测试) ──▶ 绿灯(最小实现) ──▶ 重构(测试保持绿)
▲ 人：边界/断言强度 ▲ AI：不越界实现直观类比
先测后码像先立裁判再开赛：裁判规则（测试）定了，选手（AI 实现）只能按规则打；反过来先开赛再定规则，裁判只会判选手全胜。
常见误区
- AI 同时产出测试与实现：自证循环，测试失去独立验证力。
- 用覆盖率替代边界审查：覆盖率高不等于测的是该测的边界。
- 一步到位写全量测试再实现：回到瀑布，失去小步反馈；应一轮一个行为。
与其他知识点的关系
kp-013 的 Diff 审查在本流程中大部分被「人审测试」替代，实现审查范围更小；kp-015 的重构护栏依赖「测试保持绿」这一不变量。
自测题
要点：同一模型既定义标准又满足标准，测试会迁就实现缺陷，失去独立验证能力。
要点：边界覆盖是否完整（对照规格行为清单）、断言是否足够强（排除弱断言清单）。
- 为什么 AI「同时写测试和实现」是自证循环？
- 红灯阶段人审测试要看哪两类问题？
延伸阅读
《Test-Driven Development：By Example》Kent Beck——红灯-绿灯-重构的原始定义。