这项由香港中文大学、新加坡管理大学与哥伦比亚大学联合开展的研究，于2026年5月发表在软件工程领域的学术预印本平台（arXiv编号：2605.17242），感兴趣的读者可通过该编号检索原文。研究提出了一个名为TDDev的框架，系统研究了如何用"测试驱动开发"策略让AI编程助手真正生成可交付使用的完整Web应用。

你有没有遇到过这种情况：让AI帮你写一段代码，代码确实跑起来了，但打开浏览器一看，按钮点不了、数据提交失败、页面跳转一片混乱？这就是当前AI编程工具普遍存在的尴尬——它们能生成"能运行的代码"，却很难保证生成"真正好用的网站"。

这个区别听起来微妙，实际上却是天壤之别。根据研究团队引用的一项基准测试，当前最先进的AI编程助手生成的Web应用，超过70%都无法满足功能需求。也就是说，你用AI帮你做一个购物网站，十次里有七次，这个网站在某些关键功能上会出问题——要么搜索没反应，要么购物车清空了，要么注册流程卡死。

这篇研究的核心目标，就是弄清楚为什么会这样，以及怎样系统地解决它。

一、从"能跑"到"能用"，中间差了什么

要理解这个问题，先来打个比方。你雇了一位厨师，告诉他"做一顿丰盛的晚餐"。厨师把菜做好摆上了桌——看起来色香味俱全。但如果没人真正坐下来尝一口，就没法知道盐是不是放够了、鱼有没有腥味、甜点够不够甜。

AI生成网站的过程也是如此。AI写完代码就像厨师把菜摆上桌，而检验这顿饭好不好吃，需要有人真正"坐下来吃"——也就是打开浏览器，点击按钮，填写表单，完整走一遍用户流程。

问题在于，现有的AI编程助手根本不做这一步。它们写完代码，最多在终端（命令行窗口）看一眼有没有报错，但终端里显示"运行成功"，并不等于用户在浏览器里能顺畅使用。网页上的交互逻辑、按钮状态、跨页面跳转，这些错误通常是"无声的"——代码没有崩溃，程序没有报错，但用户就是完不成他们想做的事。

研究团队把这个问题总结为三个卡点。第一个卡点是"需求不够具体"。用户通常只会说"帮我做一个食物配送平台"，但这句话对AI来说太模糊了——它不知道用户需要能搜索食物吗？需要用户注册吗？需要配送员确认订单吗？没有具体的操作步骤和预期结果，AI只能凭猜测实现功能，结果当然不稳定。

第二个卡点是"没办法在浏览器里测试"。正因为网站的正确性只能在浏览器里感知，AI就无法自己验证自己的作品。传统的测试方法（比如给代码写单元测试）对Web应用不管用，因为那些测试检验的是代码逻辑，而不是用户实际看到和操作的界面。

第三个卡点是"失败信息没法直接用"。就算AI知道某个地方出了问题，浏览器里的错误通常是"用户体验到的问题"，而不是"可以直接修代码的信号"——比如"提交按钮不见了"、"登录后页面没有跳转"。这类信息需要人工翻译成程序员能理解的修复指令，AI自己做不到。

正是这三个卡点，让AI生成的网站质量难以保证，也让开发者在使用这些工具时不得不花大量时间手动测试、手动反馈、手动修改。

二、软件工程界的老办法：测试驱动开发

研究团队借用了软件工程领域一个有几十年历史的方法来破解这个难题，叫做"测试驱动开发"（Test-Driven Development，简称TDD）。

这个方法的思路其实非常朴素：在写任何代码之前，先把"我希望这段代码做到什么"用可以运行的测试案例写清楚。就像你在厨师进厨房之前，先写好一份"菜品验收标准"——这道菜需要颜色金黄、外皮酥脆、内部熟透，吃起来咸淡适中。厨师做好后，直接按这份标准逐项检查，不合格的就返工，合格才算完成。

这样做有两个好处：开发目标变得清晰具体，而且每次改动都能立刻知道有没有破坏原来好用的功能。

然而，研究团队发现，把TDD直接用在AI生成网站这件事上，并不简单。原因就是前面提到的三个卡点——需求不够具体、无法浏览器测试、失败信息无法转化。于是他们构建了TDDev，一个专门为Web应用生成设计的TDD基础设施，把这三个卡点一一打通。

三、TDDev的三步流程：从模糊需求到可验证测试

TDDev的第一步，是把用户那句模糊的"帮我做一个食物配送平台"，变成一系列具体可执行的测试案例。

研究团队在这里借鉴了一个叫"肥皂剧测试"的思路。这个名字听起来很奇特，它的意思是：通过模拟真实用户（甚至是极端用户）的行为轨迹来发现系统漏洞，就像肥皂剧里总有各种意想不到的情节一样。具体做法是，先让AI扮演不同类型的用户——比如"一个想发布多余食物的社区协调员"和"一个在寻找附近免费食物的居民"——然后问：这些用户会在网站上做什么操作？

通过这种角色扮演的方式，AI会自然生成多样化、有代表性的使用场景。每个场景都被进一步细化为三部分：功能描述（比如"发布食物"）、操作步骤（比如"填写食物名称，点击发布按钮"）、以及预期结果（比如"食物出现在首页列表中"）。这样的测试案例既具体到可以在浏览器里逐步执行，又清晰到可以判断"通过"或"失败"。

研究团队在10个真实项目上验证了这套测试生成方法的效果。在62个参考功能点中，自动生成的测试案例覆盖了57个，覆盖率高达91.9%。没有覆盖到的5个功能点，都是那种需要对整个系统结构非常熟悉才能发现的"导航类功能"，比如"页面顶部有全局导航栏"——这类需求连有经验的人工开发者也不一定会第一时间想到。

TDDev的第二步，是在AI生成网站代码后，自动把网站跑起来，并且模拟真实用户在浏览器里逐步操作，验证每个测试案例。

这个步骤的难点在于灵活性。传统的浏览器自动化测试工具（比如Playwright或Selenium）需要提前知道网页的结构——哪个按钮叫什么名字、在哪个位置——才能写出精确的操作脚本。但AI生成的网站每次结构都可能不一样，不能提前写死脚本。

研究团队的解决方案是让另一个AI扮演"虚拟用户"。这个虚拟用户每走一步，都先看一眼当前页面的内容结构，然后决定下一步该做什么——是找到那个"提交"按钮然后点击，还是在输入框里填写内容。整个过程动态生成操作指令，不依赖预设的页面结构，因此能适配各种不同风格的AI生成界面。验证完成后，这个虚拟用户会给出"通过"、"失败"或"部分通过"三种判定。

研究团队测试了这个"虚拟用户"的准确性，结果很有意思。在40个测试案例中（20个使用功能正常的网站，20个使用人为注入了已知缺陷的网站），虚拟用户的整体准确率达到87.5%。更关键的是，它对"有缺陷的网站"的识别率达到100%——所有20个有问题的网站，一个都没有漏掉。对"功能正常的网站"，有5个被误判为失败，但没有一个"有缺陷的网站"被误判为正常。

这种"宁可多报错，绝不放行有缺陷的版本"的特性，对于一个修复循环来说恰恰是最理想的。误报失败只会多修一轮，代价可控；而漏报缺陷则会让有问题的代码悄悄通过，造成更大麻烦。

TDDev的第三步，是把浏览器里观察到的失败，转化为AI编程助手能直接使用的修复指令。

浏览器里的失败是"用户视角的感受"，比如"点了登录按钮，页面没有跳转"。但AI修代码需要的是"程序员视角的诊断"，比如"登录表单缺少提交按钮，导致表单无法提交"。TDDev会把虚拟用户的整个操作轨迹和失败原因整合成一份结构化报告，写清楚：在哪个功能点上出了问题，之前完成了哪些操作步骤，失败发生在哪一步，浏览器当时呈现的是什么状态。这份报告让AI编程助手有了明确的修复起点，不再需要人工翻译失败信息。

四、四种开发策略的比拼：谁来决定什么时候测试

有了TDDev这套基础设施，研究团队进一步研究了一个重要问题：应该由谁来主导测试流程，以及测试应该多细粒度地介入开发过程？

他们设计了四种开发策略进行对比实验。

第一种叫"无TDD基线"，就是现在的默认状态——AI收到需求，直接写完整个网站，交付之后才做一次性评估，没有任何中间测试和反馈。

第二种叫"主动式TDD"，由AI自己决定何时使用测试工具。研究团队给AI配备了启动服务器、运行测试、停止服务器三个工具，并告诉它应该按照"实现—部署—测试—修复—重复"的流程来工作，但由AI自主决定什么时候执行每个步骤，不做强制约束。

第三种叫"全项目TDD"，由外部系统强制控制。AI先一次性生成完整的网站代码，然后系统强制进入最多5轮的测试—修复循环：每轮都部署网站、运行所有测试案例，把所有失败的报告汇总后交给AI修复，如果全部通过就提前结束。

第四种叫"增量式TDD"，管控力度最强。系统把所有功能按顺序排好，每次只让AI实现一个功能点，然后立刻测试这一个功能（同时回归测试所有已通过的功能）。通过才进入下一个功能的开发，否则就在这个功能上持续修复，直到通过或达到尝试上限。

五、实验结果：正确的策略能让准确率翻倍，错误的策略让努力白费

研究团队在两个基准测试（WebGen-Bench和ArtifactsBench）上，用两个AI编程助手（ClaudeSDK和OpenCode）、两个底层模型（Claude Sonnet 4.6和Qwen-3.5）进行了系统性对比实验。

最直接的发现是，有TDD基础设施的策略，都大幅优于"无TDD基线"。在WebGen-Bench这个以复杂功能性Web应用为主的基准测试上，最佳TDD策略相比无TDD基线的准确率提升了34到48个百分点——这是一个非常显著的差距，相当于原本十个功能里有七个不过关，现在变成了十个功能里有三四个不过关。

然而，更关键的发现藏在不同TDD策略之间的比较里。研究结果揭示了一个出人意料的规律：最优策略因底层模型的不同而截然不同，而且错配策略的后果不只是效果打折，而是完全白费甚至适得其反。

使用Claude Sonnet 4.6模型时，"主动式TDD"表现最好，准确率达到65.8%，而"增量式TDD"的准确率只有31.5%，与根本没有TDD的基线（31.3%）几乎没有区别。换句话说，用了增量式TDD，花了更多时间和计算资源，结果和什么都不做一样。

使用Qwen-3.5模型时，情况完全颠倒。"增量式TDD"表现最好，准确率高达71.4%，而"主动式TDD"只有41.0%，"全项目TDD"居中为51.4%。

这个规律让研究团队深入分析了两个模型的代码生成风格。Sonnet倾向于"整体生成"——给它一个任务，它会一口气写出一个结构完整、逻辑连贯的完整应用，需要修改时也是整体重写，而不是在原有代码上打补丁。Qwen则倾向于"保守扩展"——它会先读懂已有代码，然后在原有基础上谨慎地添加新功能，保持代码的分散性和模块化。

这两种风格与TDD策略的契合度解释了实验结果。增量式TDD本质上假设AI是"保守扩展"型——每次只加一个功能，保留已有代码。Qwen天然符合这个假设，所以增量式TDD给它带来了46个百分点的准确率提升。Sonnet不符合这个假设：每次"增量实现"，Sonnet都会把整个应用重写一遍，导致上一轮刚通过的功能被覆盖掉，回归测试发现一堆新问题，整个增量循环就变成了原地打转。五轮尝试消耗殆尽，准确率纹丝未动。

主动式TDD则给了Sonnet最大的自由度——自己决定什么时候测试、测试多少次。Sonnet充分利用了这个自由：生成完整应用，测试一遍，找到缺口，整体重写，再测试，一轮下来准确率就已经大幅提升。给Qwen这种自由度反而是负担：Qwen在一个长期会话里持续叠加代码补丁，越到后期复杂度越高，最终因为积累的技术债务导致服务器运行出错。在五个测试案例中，有两个的几乎所有功能在最终评估时都失败了，而且消耗的计算资源（以token数量衡量）比Sonnet多了70%，准确率却低了25个百分点。

六、代价的差距：25倍的成本差异

研究团队还详细记录了不同策略的计算资源消耗，结果同样触目惊心。

以Sonnet模型为例，主动式TDD消耗了590万个token（AI处理文本的计量单位，可以粗略理解为"思考量"），准确率比基线提高了36.7个百分点，平均每提升1个百分点的准确率消耗约9.1万个token。增量式TDD消耗了970万个token，准确率没有任何提升，成本相当于无穷大。

Qwen模型的增量式TDD表现最佳，准确率提升了46.7个百分点，但总消耗高达1.087亿个token，每提升1个百分点消耗约232.7万个token——是Sonnet主动式TDD效率的整整25倍。如果你在用API计费服务，这意味着同样的准确率提升，用错了策略要多花25倍的钱。

全项目TDD对Qwen来说是性价比最高的选择：4500万token，准确率提升26.7个百分点，每个百分点消耗97万token，远低于增量式的2327万token。

这个成本分析给出了一个很清晰的实践建议：能力强、倾向整体生成的模型，选主动式TDD，高准确率低成本一举两得；能力较弱、倾向保守扩展的模型，优先考虑全项目TDD作为性价比最高的选项，增量式TDD只在对准确率有极高要求且不在乎成本的情况下才值得考虑；无论用哪个模型，都要避免把增量式TDD用在整体生成型模型上，这是唯一一种既不提升质量又大量消耗资源的组合。

七、真实开发者怎么说

除了这些数字，研究团队还找了三位真实的专业开发者来对比体验TDDev和另一个同类工具Bolt.diy。每位开发者分别用两个工具完成同一个WebGen-Bench里的Web应用，直到达到自己满意的状态为止。

使用Bolt.diy时，平均整个开发过程花了15.2分钟，其中4.7分钟是开发者自己在主动干预——打开浏览器测试、发现问题、思考怎么描述问题、写出新的指令再提交。这个4.7分钟并不是连续的，而是分散在整个15.2分钟的每一个节点上，要求开发者一直保持注意力，时刻待命。

使用TDDev时，开发者只需要在最开始输入需求，然后就可以完全放手，去做其他事。整个过程平均花了18.7分钟，比Bolt.diy多了3.5分钟——但这3.5分钟完全是机器在自动运转，开发者无需在场。整个过程的人工干预次数为零，额外的提示词也是零。

三位开发者都表示，TDDev是完全的"放手型"体验。其中一位的描述颇为贴切："它去掉了整个循环中最让人崩溃的部分——你得自己开浏览器，搞清楚哪里出错了，再想办法解释给AI听。"另一位则关注了结果质量："它产出的应用是真的能从头到尾跑通的，不只是看起来像那么回事。"

这个用户研究揭示了一个值得深思的视角：对于AI辅助开发工具来说，"总耗时"并不是衡量效率最重要的指标，"开发者需要主动在场的时间"才是。TDDev把开发工作从"开发者需要持续监督和干预的人机协作"变成了"开发者只需启动一次、结束时检查结果的自动化流程"。

说到底，这项研究描述的问题和解决方案，不只是关于AI写代码的技术细节，它触及了一个更根本的问题：当我们把一项创造性工作交给AI完成时，"完成"的标准应该是什么？是代码没有语法错误？还是程序能跑起来？还是用户真的能用它完成他们想做的事？

研究团队用34到48个百分点的准确率提升，以及零人工干预的用户体验，给出了他们对这个问题的回答：真正的"完成"，是用户能把事情做成。而通往这个目标的路，需要把测试、部署、观察、修复的完整循环纳入AI的能力范围，而不是留给人工事后补救。

这个框架的研究还有明显的扩展空间。目前TDDev只处理了单用户的前端交互场景，涉及多用户认证、复杂后端逻辑的应用还没有系统验证。此外，研究中发现的"模型生成风格决定最优策略"这一规律，只在两个模型上得到了验证，是否适用于更大范围的模型家族，还需要更多数据支撑。研究团队自己也提出了未来的方向：探索能够在运行时自动识别模型风格、动态调整TDD策略的自适应系统——那时候，也许连"选哪种TDD策略"这个问题本身，也能交给AI自己来回答。

如果你对这项研究的完整技术细节感兴趣，可以通过arXiv编号2605.17242查阅原论文，研究团队也公开发布了TDDev的完整代码和实验数据，可通过论文中提供的Zenodo存档链接获取。

Q&A

Q1：TDDev生成的Web应用测试案例准确率有多高？

A：TDDev的测试生成模块在10个真实项目的62个功能点上，覆盖了57个，整体覆盖率达到91.9%。负责在浏览器里执行测试的"虚拟用户"模块整体准确率为87.5%，对有缺陷网站的识别率达到100%，没有出现漏报缺陷的情况。

Q2：TDD策略用错了会有什么后果？

A：后果非常严重。以Claude Sonnet 4.6模型为例，使用增量式TDD后准确率仅有31.5%，和完全不用TDD的基线（31.3%）几乎没有区别，但消耗了970万token，相当于花了大量资源却毫无收益。Qwen模型使用主动式TDD时，消耗资源比最优方案多，准确率却低了约25个百分点，成本效率相差高达25倍。

Q3：TDDev和现有AI网站生成工具相比有什么不同？

A：传统AI网站生成工具（如Bolt.diy）在生成代码后需要开发者手动打开浏览器测试、发现问题、写新指令反馈。TDDev把整个测试—发现问题—生成修复报告—重新生成的闭环全部自动化，用户只需在开始时提交需求，此后无需任何干预。用户研究显示，TDDev的人工干预时间和额外提示词数量均为零。