大家好，我是苍一，一个干了13年的后端开发，正在探索AI编程，从产品到开发的全生命周期最佳实践，如果您感兴趣，欢迎关注👇，看我如何自我革命。

一段奇怪的课堂经历

前段时间给一家企业做AI编程内训，开场直接讲测试驱动开发，也就是TDD。先写测试用例，再写业务代码，这套方法论1999年就提出来了。

课间休息，对方技术负责人问，今天不是说AI开发提效吗，怎么先讲一个二十多年前的老概念。

答案是，不理解TDD为什么被提出来、又为什么始终没落地，就理解不了今天多Agent协作系统的角色分工逻辑。

TDD的核心矛盾

正常的开发流程，是先理清需求、写代码、跑起来看效果，最后补测试。TDD反过来，要求你先把期望行为写成测试，这时候测试一定是失败的。然后写代码，逐个让测试通过。

很多工程师的第一反应是，代码都不存在，测试什么？测一个想象吗？

Kent Beck在1999年的书里回答过这个问题。他的判断是，写代码时最大的问题不在代码层面，而在开发者的思维层面。你在写代码的同时，脑子里已经有一套预期运行逻辑。写完之后你自己去测，测的其实是自己脑中的预期模型，而不是代码本身的真实行为。

这意味着，你预判到的bug在编码阶段就已经规避了，而你没想到的问题，自测阶段依然发现不了。

TDD的本质，是把预期行为从脑子里抽离出来，变成一份独立的文档。然后由另一份独立的产物（代码）去满足它。两件事分开做，不同视角，才有可能暴露思维盲区。

这个思路在理论上完全成立。但在工业界推行了二十多年，真正坚持下来的团队极少。

为什么团队做不到真正的TDD

根本原因不是工程师水平不够，而是人类做不到对自己完全客观。

实际操作中，多数团队退化为先写代码再补测试的模式。先有了实现，再针对实现去写测试用例。这样产生的测试天然会围绕已有代码的路径来设计，看起来覆盖率很高，实际上只是为已有实现做了确认，而不是从需求出发做了验证。

这不是偷懒，是结构性的问题。同一个大脑，既设计了实现方案，又设计验证方案，验证方案天然会倾向于绕开设计的薄弱环节。

解决这个问题的办法只有一个，就是换一个独立的大脑来负责验证。但这在过去意味着多雇人。让三个工程师分别负责写测试、写代码、做审查，成本直接翻倍。

AI多Agent协作解决了成本问题

TDD二十年没落地的核心障碍是成本，而AI把这个问题绕过去了。

具体的做法是让多个Agent分别承担不同角色。一个Agent只负责写测试，它的目标函数是测试的完整性和边界覆盖。另一个Agent只负责写代码，它的目标函数是功能实现。再安排一个Agent负责审查，目标是找出前两方的漏洞。

三个独立上下文，三套独立的目标。信息不对称带来了真正的验证效果。

软件工程走到今天，终于可以用AI的分身能力把这个原则落地了。

从理论到产品：Mavis的Team Engine

MiniMax最近把桌面端升级成了Mavis，产品层面把多Agent协作做成了可用的runtime。

其中最值得关注的是Verifier机制。Worker负责完成任务，Verifier负责审查质量。两者是对抗关系，Worker想快速交付，Verifier想挑出问题退回去。

MiniMax把这套逻辑做成了一个状态机，叫Team Engine。每个任务经历producing、verifying、done三个状态。verifying没通过就踢回producing重做。这个流程是用代码实现的硬逻辑，不是靠prompt模拟角色扮演。

Token成本的实际账本

三个Agent同时跑，token消耗确实会成倍增加。但要看的是有效产出，不是单价。

实际测试中，单Agent写一个多用户登录功能，跑了8分钟，消耗约5万token，输出的代码跑不通。三个Agent协作做同样的任务，跑了14分钟，消耗约27万token，代码一次通过。

5万token产出了一个不可用的半成品，ROI为零。27万token产出了一次通过的成品。半成品的单价再低也没意义，因为它没法进入交付流程。

但反过来也要承认，并不是所有任务都需要多Agent协作。改一个按钮颜色这种量级的活，开三个Agent去做反而更慢更贵。判断标准很简单：任务复杂度超过单次注意力上限的，开Team；简单任务单Agent处理。

写在最后

从1999年TDD的提出，到今天多Agent协作系统把测试、实现、审查三个角色拆分给独立的AI来执行，中间隔了二十多年。方法论一直是那套方法论，变的是执行成本。AI没有发明新的软件工程理论，但它把过去因为成本太高而无法落地的理论，变成了可以实际运行的工程实践。

如果嫌文章太长、怕后面走丢，可以关注下面的ima知识号，让这篇文章成为你的知识顾问，随时随地等候你的提问。

知识号中内容会以笔记形式分享，可以根据大家反馈和实测情况，实时更新，保证最新方案的稳定、可用。

【ima 知识库】