# 从可运行到可交付：基于多智能体测试驱动的开发范式用于从需求生成全栈Web应用 - 来源：HuggingFace Daily Papers（社区热门论文） - 发布时间：2026-05-17 08:00 - AIHOT 分数：73 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.virxact.com/items/cmpc80hvi00aksl6k8762pzia - 原文链接：https://arxiv.org/abs/2605.17242 ## 精选理由 把TDD塞进多智能体代码生成，直接把Web应用的正确率从不到30%拉到70%以上，更重要的是他们发现给不同模型配错了开发协议反而会雪崩，做Agent工程的必读。 ## AI 摘要 针对编码智能体生成的Web应用超70%不满足需求的问题，本文提出TDDev框架。该框架通过三阶段实现自动化闭环：先将需求转化为结构化测试，再通过浏览器模拟交互验证应用，最后将故障转化为修复报告。首次针对Web应用生成的TDD实证研究发现，引入TDD基础设施可提升质量34-48个百分点。关键结论是最佳协议需与模型生成风格匹配，不匹配将完全抵消TDD优势并最多增加25倍Token消耗。用户研究证实，该框架使人工干预降为零，开发转向自主反馈优化。 ## 正文 余璇 香港 yxwan9@cse.cuhk.edu.hk 梁庭硕 香港 徐嘉凯 哥伦比亚大学 纽约 美国 肖靖宇 香港 霍彦彤 新加坡管理大学 新加坡 新加坡 ythuo@smu.edu.sg 吕荣聪 香港 lyu@cse.cuhk.edu.hk （2009年6月5日） 摘要。 编程智能体能够根据自然语言描述生成网页应用，然而近期一项基准研究表明，生成的应用在超过70%的情况下无法满足功能需求。核心难点在于，网页的正确性无法通过源文件或终端输出来评估：应用必须被部署、通过模拟浏览器交互来运行，并且失败必须被转化为可操作的修复信号——这些步骤当前的智能体在没有人工介入的情况下无法完成。 我们提出了TDDev，一个通过三个阶段自动化这一闭环的框架：（1）在编写任何代码之前，将高层需求转化为结构化的验收测试；（2）部署应用并通过基于浏览器的交互模拟进行验证；（3）将浏览器观察到的失败转化为供编程智能体使用的结构化修复报告。借助TDDev，我们开展了首个针对网页应用生成的测试驱动开发（TDD）策略的受控实证研究，比较了两种编程智能体、两种骨干模型以及两个基准测试下的四种开发协议。 TDD基础设施相较于无TDD基线，持续将生成质量提升了34至48个百分点。核心发现是，最优协议取决于模型的生成风格：整体构建应用的模型最受益于智能体强制执行，而保守扩展代码的模型则受益于增量式强制执行。协议与生成风格不匹配会完全消除TDD带来的收益，同时将模型 token 成本提升高达25倍。一项用户研究证实，TDDev将人工开发者的干预降至零，将工作负载从持续的提示词工程转变为自主的、反馈驱动的优化。 多模态大语言模型，代码生成，用户界面，网页开发 acmlicensed XXXXXXX.XXXXXXX 请务必从您的参会确认邮件中填写正确的会议名称；2018年6月3日至5日；纽约州伍德斯托克 978-1-4503-XXXX-X/2018/06 软件及其工程 自动编程 计算方法 人工智能 1. 引言 网络应用程序应用广泛且具有重要经济价值：报告估计活跃网站数量超过11亿个，每天另有25.2万个新网站上线（web, 2024; wor, 2024）。随着编码智能体（Dong等人，2025a）的发展，商业工具已允许用户描述一个应用程序并收到可运行的原型（Lovable, 2026）。然而，可运行代码与可交付应用程序之间存在关键区别：一项近期基准研究表明，最先进智能体生成的应用程序在超过70%的情况下未能满足功能需求（Lu等人，2025），用户只能手动识别并修复故障。 测试驱动开发（TDD）是一种软件工程实践，开发人员通过迭代方式为特定功能编写测试，并实现代码以满足该测试（Mathews和Nagappan, 2024）。TDD提供了一种缩小可运行与可交付之间差距的原则性方法：通过在编写任何代码之前指定可执行的验收测试，TDD使需求具体化，并为智能体提供明确的目标；通过针对已部署的应用程序运行这些测试，智能体可以获得结构化反馈，从而优化代码以满足需求。当测试失败时，失败结果直接指出问题所在以及预期行为应该是什么，从而将每个缺陷转化为可操作的修复信号，以改进应用程序。 先前的研究表明，TDD 风格的反馈循环能够显著提升传统编码智能体，从仓库级别的漏洞修复（Yang 等人，2024；Zhang 等人，2024；Xia 等人，2025）到多智能体软件工作流（Lin 等人，2025）以及测试优先的代码生成（Fakhoury 等人，2024；Mathews 和 Nagappan，2024；Alshahwan 等人，2024；Foster 等人，2025）皆是如此。然而，这些方法都依赖同一种反馈：来自编译器、测试脚本或终端的结构化文本，这些文本是智能体可以直接看到的。 不幸的是，Web 应用开发打破了这种反馈循环：以往的智能体通过运行代码并读取编译器或终端的输出结果来验证其工作，而 Web 应用则带来了三个现有“面向智能体的 TDD”方法无法处理的挑战： 需求具体化。Web 应用的需求通常以高层级的自然语言形式出现（例如，“一个购物网站”）。在没有人工澄清的情况下，这些模糊的指令必须被转化为可操作的具体浏览器交互脚本：即一系列具体的导航、输入和点击操作，并配以浏览器智能体能够执行和判断的可观察预期结果。 交互式验证。正确性无法通过源文件、编译器或终端来评估。应用必须被部署并在浏览器中通过模拟用户交互来运行——例如点击按钮、提交表单以及在页面间导航。这个过程也无法预先编写脚本，因为智能体生成的实现本质上具有非确定性，每次运行时的 UI 结构、元素层级或交互流程都可能不同。 失败转化。Web 应用的失败是一种体验，而非明确的日志：诸如导航中断、状态更新缺失等错误，必须在浏览器中观察到，然后转化为精确、可操作的反馈，供智能体用于修复。这些失败往往是上下文相关的，并且面向用户，这使得它们比标准的编译器或运行时错误更难捕获。 在当前实践中，人类开发者手动执行所有三个步骤：他们部署应用、进行交互并观察问题所在，然后将这些观察结果转译回供智能体使用的文本指令。这不仅劳动强度大且令人沮丧（Becker 等人，2025），也意味着测试驱动开发循环无法自动化，从而使得对网页应用生成的测试驱动开发策略进行受控的实证研究变得不可行。 在本文中，我们提出了 TDDev，这是一个框架，它解决了所有三个挑战，并使编码智能体能够在最少人工干预的情况下，以闭环的测试驱动开发方式开发网页应用。具体来说，TDDev 将自然语言需求转化为结构化的验收测试（需求具体化），部署生成的应用并通过基于浏览器的用户交互模拟来执行它（交互式验证），并生成结构化的失败报告供编码智能体直接采取行动（失败转译）。 借助 TDDev，我们进行了一项受控研究，比较了四种开发协议，这些协议在两个维度上有所不同：智能体是否能访问测试驱动开发基础设施，以及反馈循环是由外部强制执行还是留给智能体自行决定。我们跨两个编码智能体、两个基础模型和两个基准进行了评估。结果表明，与无测试驱动开发的基线相比，测试驱动开发基础设施始终能将生成质量提升 34 到 48 个百分点。关键在于，最优协议取决于模型：能够整体生成代码的强模型从智能体驱动的测试驱动开发（低强制力）中获益最大，而保守生成代码的模型则从增量式测试驱动开发（高强制力）中获益。协议与模型生成风格不匹配会完全消除测试驱动开发的收益，同时将 token 成本增加高达 25 倍。 总之，本文做出了以下贡献： 我们描述了阻碍编码智能体将测试驱动开发应用于全栈网页应用开发的三个具体挑战。 我们提出了 TDDev，一个模块化框架，它自动化了所有三个挑战，并实现了用于网页应用生成的闭环测试驱动开发。 我们对两种编码智能体和两种骨干模型在四种开发协议下进行了对照研究，首次实证分析了测试驱动开发策略如何影响 Web 应用生成质量。 我们发布了 TDDev、所有实验数据以及评估测试夹具，以支持复现和未来研究。 2. 背景 2.1. 任务定义 给定一个高层级文本需求，编码智能体生成一个全栈 Web 应用。该应用若可部署、能在浏览器中正确渲染，并满足基于该需求生成的验收测试套件，则视为正确。需求中的每个元素都指定了一项面向用户的交互及其预期结果；若所有元素均在部署环境中得到满足，则应用通过验收。 2.2. 相关工作 2.2.1. UI 代码生成 UI 代码生成从截图或设计图像生成前端代码，经历了从早期基于 CNN 的原型设计（Aşıroğlu 等人，2019；Cizotto 等人，2023；Moran 等人，2018；Xu 等人，2021；Chen 等人，2018；Nguyen 和 Csallner，2015；Beltramelli，2018；Chen 等人，2022）到基于 MLLM 且视觉保真度更高的方法（Si 等人，2024；Wan 等人，2025；Wu 等人，2025；Gui 等人，2025；Zhou 等人，2024；Xiao 等人，2024，2025；Wan 等人，2024）的演进。这些工作侧重于前端外观而非全栈功能；WebGenBench（Lu 等人，2025）表明，即使是最先进的系统也经常无法满足功能需求，这凸显了我们的工作所要填补的空白。 2.2.2. 编码智能体 编程智能体在仓库级软件工程任务中已展现出强劲性能，涵盖问题修复（Yang 等人，2024；Zhang 等人，2024；Ruan 等人，2025；Xia 等人，2025）、程序修复（Bouzenia 等人，2025；Rondon 等人，2025）、构建自动化（Yu 等人，2025；Kim 等人，2025）以及多智能体开发工作流（Lin 等人，2025；Wang 等人，2025）等方面。对智能体运行轨迹的实证分析揭示了区分成功与失败执行的行为模式（Bouzenia 和 Pradel，2025）。这些系统共有的一个关键使能因素是执行环境可直接访问：智能体能够运行代码、读取终端输出，并在紧密循环中根据编译器或测试反馈采取行动。Web 应用开发打破了这一假设——其正确性取决于部署、浏览器渲染以及真实的用户交互，而这些都无法仅通过终端或编译器输出来捕捉。 2.2.3. GUI 测试 自动化 GUI 测试已通过多种范式进行了探索。录制回放方法易于使用，但随着应用程序的演进，往往脆弱且维护成本高昂（Yu 等人，2023）。诸如 Monkey 之类的随机测试工具（and，2023）减少了人工工作量，但通常提供的功能覆盖率有限。基于模型的测试（Miguel 和 Takada，2016；Gu 等人，2019）通过从形式化模型中派生测试用例提供了更结构化的方法，但其有效性取决于模型质量，需要持续更新，并且常常忽略 GUI 语义。基于学习的方法（Lan 等人，2024；Pan 等人，2020；Li 等人，2019），通常基于强化学习，可以学习测试策略，但通常需要大量的训练数据，并且对快速变化的应用程序适应性较差，部分原因是语义理解有限（Liu 等人，2023）。最近，基于 MLLM 的方法（Liu 等人，2023，2024）已开始整合视觉语义和功能结构，为 GUI 测试提供了一个有前景的方向。这些方法证明了 UI 级观察对于评估面向用户系统的重要性。然而，它们主要是探索性的，并非旨在验证特定的功能需求或在开发循环中返回可操作的修复反馈。 2.2.4. 测试驱动开发 测试反馈已被证明能够提升多种任务中的代码生成质量。Wang 等人（Wang et al., 2022）在训练过程中使用测试执行信号；AutoCodeRover（Zhang et al., 2024）和 D4C（Xu et al., 2025）利用测试结果进行程序修复中的故障定位和补丁验证；Mathews 等人（Mathews and Nagappan, 2024）通过实验证明了当测试用例与自然语言提示词一同提供时，测试驱动开发（TDD）的优势。TiCoder（Fakhoury et al., 2024）采用交互式方法，利用大语言模型生成澄清性测试用例，由用户在代码生成前确认，仅通过五次交互即可在 pass@1 指标上实现 46% 的绝对提升。ConTested（Dong et al., 2025b）进一步利用大语言模型生成的测试套件之间的互一致性和内部一致性，在无需人工标注的情况下筛选出更高质量的代码。在工业规模上，Meta 的 TestGen-LLM（Alshahwan et al., 2024）使用大语言模型自动改进现有的人工编写测试，其中 73% 的建议在生产环境中被采纳；其后续版本采用变异测试来指导有针对性的测试生成（Foster et al., 2025）。一项涵盖 37 个大语言模型和五个基准测试的大规模研究（Shang et al., 2025）进一步描绘了大语言模型在单元测试生成方面的能力全景。这些工作共享一个共同假设：测试要么已经存在，要么验证反馈可以直接从终端或编译器获得。对于 Web 应用而言，这两个假设均不成立。表 1 总结了这些差异，并将每一项映射到 TDDev 中的一项设计决策。 媒体内容 · 前往原文查看 表 1. 传统代码任务与 Web 应用的测试驱动开发对比，以及 TDDev 对应的设计决策。 方面 传统测试驱动开发 Web 应用测试驱动开发 TDDev 的方法 执行 本地代码，智能体可直接访问 已部署的服务器，在浏览器中渲染并运行 自动框架检测与部署 需求 测试用例预先定义，具有清晰的输入-输出对 测试用例必须从模糊的自然语言需求中推导得出 通过大语言模型生成肥皂剧式测试用例 验证 终端输出和编译器反馈 基于浏览器的真实用户交互模拟 大语言模型智能体即时生成 Playwright 代码 失败转化 二进制错误与堆栈跟踪 浏览器中观察到的、面向用户的上下文相关故障 基于操作轨迹的结构化故障报告 图 1. TDDev 概览。首先将需求转化为验收测试。随后编码智能体实现应用程序，该程序被部署并在浏览器中进行验证。故障被转化为结构化修复报告，并反馈给智能体。 3. 方法论 TDDev 通过一个包含三个阶段的闭环测试驱动循环，解决了第 1 节中确定的三个挑战：验收测试生成阶段在编写任何代码之前，从自然语言需求中推导出可执行的测试；部署与基于浏览器的验证阶段部署生成的应用程序，并通过模拟用户交互来执行它；故障转化阶段将浏览器可观察到的故障转化为结构化的修复报告。图 1 给出了概览。这三个阶段被组合成四种开发协议，这也是我们研究的实验变量。 3.1. 阶段 1：验收测试生成 此阶段的目标是在编写任何代码之前，从自然语言需求中推导出一组可执行的验收测试，以便编码智能体拥有明确无歧义的开发目标，并且修复循环在整个过程中拥有稳定的评估标准。 核心难点在于推导出的需求既要有效（基于应用程序真正需要执行的功能），又要多样化（覆盖不同的用户目标，而非同一目标的变体）。如果没有一种有原则的方法，大语言模型往往会生成泛泛而谈、相互重叠的答案，这些答案集中在最显而易见的解释上，而忽略了真实使用场景的多样性。 受肥皂剧测试（一种基于场景的测试方法，通过真实或夸张的用户操作来测试系统，以发现简单测试可能遗漏的故障，Kaner, 2013；TMAP, [n. d.]）的启发，TDDev 将需求推导重新定义为关于用户而非功能的问题：谁将使用这个应用程序，他们想要完成什么？在此阶段，我们首先提示大语言模型想象具有特定目标的具体用户画像，例如，一个发布可用食品的协调员，或一个搜索附近列表的接收者。这个过程自然会产生基于真实使用场景、且在不同角色和交互模式中多样化的需求。每个画像的目标都成为一个候选测试需求。 一旦确定了需求，我们进一步提示大语言模型将每个需求细化成结构化的测试用例，包括功能描述（例如“发布产品”）、有序的交互步骤列表（例如“输入产品名称，……，点击发布”），以及在渲染页面中可观察到的预期结果（例如“产品在首页可见”）。这种细化使每个需求既可操作（浏览器智能体可以按照步骤在实时部署环境中执行），又可判断（预期结果为通过或失败提供了具体标准）。 生成的测试用例在开发开始前作为明确的工件呈现，让用户有机会审查和调整它们。 3.2. 第二阶段：交互式验证 在编码智能体生成应用程序后，此阶段通过模拟真实的用户交互来运行应用，以验证实现是否满足每个测试用例。 Web 应用程序必须在浏览器中进行评估。Playwright 和 Selenium 等脚本化工具提供了精确、可靠的交互，但它们假设应用程序的实现是预先已知的。这一假设对于智能体生成的应用程序并不成立，因为其元素结构、标签和导航流程可能因运行而异。现成的 GUI 智能体避免了此类假设，但它们往往不够精确、成本高昂，并且容易产生自身错误，这可能会干扰对应用程序本身的评估。 为了平衡可靠性与通用性，我们设计了一个轻量级的、基于大语言模型的测试智能体。如算法1所示，在验证之前，TDDev 将生成的项目部署到本地 URL，并使用 Playwright 打开它（第1行）。在每一步中，该智能体都会观察当前的辅助功能树（MDN Web Docs, 2025），即渲染页面的结构化表示，同时结合测试上下文：正在测试的功能、交互步骤、预期结果以及到目前为止的轨迹。基于此上下文，智能体要么生成并执行下一个 Playwright 操作（第13行），要么在获得足够证据后返回判定结果（通过”、“失败”或“部分通过”）（第5行）。每次交互后，已执行的操作和观察到的结果都会被追加到轨迹中（第14行），从而使智能体能够根据完整的交互历史来决定后续的操作和判断。由于操作是根据运行时渲染的页面生成的，因此智能体无需事先了解其结构即可适应不同的实现。 媒体内容 · 前往原文查看 算法1 统一浏览器验证智能体 1:测试用例、应用程序 URL、大语言模型、最大迭代次数 2:判定结果、轨迹、失败报告 3:；将浏览器导航至 4:对于 从 到 执行 5: 可见文本、元素、标签 6: 返回 Playwright 操作或判定结果 7: 如果 是一个判定结果，则 8: 如果 则 9: 返回 10: 否则 11: 12: 返回 13: 结束如果 14: 结束如果 15: 是生成的 Playwright 代码 16: 将 追加到 17:结束循环 18: 19:返回 3.3. 第三阶段：失败信息转换 仅凭原始的浏览器观察结果，对编码智能体来说通常意义不大；只有当这些结果与交互上下文（即执行了哪些操作、每一步之后观察到了什么、以及这些观察结果与预期结果有何偏差）相结合时，它们才变得可操作。此阶段在测试未通过时，将测试智能体的交互轨迹转换为可供修复的反馈。具体来说，当测试智能体返回非通过判定时，BuildFailureReport 会将累积的轨迹和智能体的自然语言推理过程总结成一份结构化报告，记录尝试了哪些操作、失败发生在何处以及观察到了什么。 例如，针对“用户登录”功能的失败可能会产生： 这份报告为编码智能体提供了一个具体的修复起点，而非对失败的模糊描述。 3.4. 开发协议 在 TDD 基础设施就绪后，它对开发过程的管控程度便成为一个实验变量。相同的部署-测试-修复工具可以在不同执行力度下应用：系统可以严格控制这些工具的使用时机和方式，将决策权交给智能体，或者完全不提供这些工具。我们沿此执行力度轴定义了三种协议，外加一个没有 TDD 基础设施的基线。 最高执行力度是增量式协议，它最严格地遵循 TDD 规范。系统每次处理一个功能：首先告知编码智能体整体目标和所有验收测试，然后提示它实现当前功能（算法 3 的第 3 行），之后进入一个有界部署-测试-修复循环（第 4–12 行）。每次尝试时，应用程序被部署，当前功能的测试与所有先前通过的测试一起作为回归测试套件运行（第 5–6 行）。如果全部通过，该功能被纳入回归基线，系统进入下一个功能（第 8–10 行）；否则，失败被分类，并要求智能体进行修复（第 11–12 行）。此协议强制执行细粒度反馈：智能体在进入下一个功能之前会收到每个单独功能的测试结果，并且先前通过的功能中的回归问题会立即暴露。 中等执行力度是整体项目式协议。智能体首先一次性实现整个应用程序（算法 2 的第 1 行），之后系统进入一个针对完整测试套件的有界部署-测试-修复循环（第 2–10 行）。每次迭代部署应用程序，运行所有测试，并记录结果（第 3–5 行）；如果所有测试通过，循环提前终止（第 6–8 行），否则失败被分类，智能体一次性修复整个应用程序（第 9–10 行）。反馈比增量式协议更粗粒度：智能体会同时看到所有功能上的失败，没有回归基线的增量锚定。 在低强制模式下，系统是智能体化的。智能体被赋予部署和测试工具，并被告知 TDD 工作流程，但系统不强制执行任何顺序或重试循环。智能体被调用一次，自行决定何时部署、何时运行测试以及何时停止。这种条件将工作流知识和工具访问的影响与外部强制执行的影响分离开来。 非 TDD 智能体作为基线。智能体仅接收需求，没有 TDD 工具，也没有重试循环。应用程序在智能体完成后被部署和评估一次，这代表了当前基于编码智能体的 Web 开发的默认实践。 所有四种条件使用相同的验收测试、相同的编码智能体和相同的基础模型，将强制级别隔离为唯一的变量。将全项目、增量式和智能体化 TDD 与非 TDD 进行比较，衡量 TDD 基础设施的整体效果；将全项目和增量式与智能体化 TDD 进行比较，将外部强制与智能体驱动的工具使用区分开来；将增量式与全项目进行比较，则隔离了增量式细粒度的优势。 媒体内容 · 前往原文查看 算法 2 全项目协议 1: 测试套件 , 编码智能体 , 尝试预算 2: 应用程序 , 记录的结果 3: 4: 对于 到 执行 5: 6: 7: 记录结果 8: 如果 那么 9: 返回 10: 结束如果 11: 12: 13:结束循环 14:返回 媒体内容 · 前往原文查看 算法 3 增量式协议 1: 有序测试用例 , 编码智能体 , 尝试预算 2: 应用程序 , 通过的回归测试套件 3: ; 空的回归测试套件, 空的应用程序 4: 对于每个 执行 5: 6: 对于 到 执行 7: 8: 9: 记录结果 10: 如果 那么 11: ; 跳出 12: 结束如果 13: 14: 15: 结束循环 16:结束循环 17:返回 4. 实验 4.1. 研究问题 RQ1（模块可靠性）：TDDev 的各个模块有多可靠？我们根据真实需求评估测试生成覆盖率，并根据已知正确和已知有缺陷的固定应用程序评估测试智能体的准确性。 RQ2（TDD 优势）：TDD 基础设施是否比无 TDD 基线提高了 Web 应用程序的生成质量？我们将全项目、增量式和智能体化 TDD 与非 TDD 进行比较。 RQ3（执行力度）：执行力度如何影响性能？我们在保持工具访问权限不变的情况下，沿着执行力度轴比较了全项目、增量式和智能体TDD三种模式。 RQ4（反馈轮次）：额外的反馈轮次如何影响准确性？我们使用 acc@ 指标分析了准确性在尝试预算范围内的变化情况。 RQ2、RQ3 和 RQ4 均通过四种实验组合（表 2）进行评估，这些组合在编码智能体、骨干模型和评测基准上有所变化，以评估其泛化能力。 4.2. 评测基准 WebGen-Bench（Lu 等人，2025）是主要评测基准，包含 101 个经人工验证功能需求的 Web 应用生成任务。每个条目包含一段描述应用的自然语言指令，以及一份 ui_instruct 条目列表，用于指定面向用户的任务和预期结果。我们使用固定随机种子（seed=42）随机抽取 50 个案例进行主要实验。 ArtifactsBench（Zhang 等人，2025）是一个用于对动态 Web UI 代码生成进行自动化多模态评估的评测基准。我们使用固定随机种子（seed=42）随机抽取 100 个案例，用于跨数据泛化评估。 4.3. 编码智能体 ClaudeSDK 是本研究所采用的主要编码智能体，它基于 Claude Agent SDK（https://docs.anthropic.com/en/docs/build-with-claude/agents）构建——这是 Anthropic 广泛采用的、用于构建生产级智能体应用的框架。该智能体遵循标准的智能体循环：它接收系统提示词、任务描述以及可用工具列表；作为骨干的大语言模型要么返回自然语言完成（表示任务结束），要么返回工具调用；工具调用被分发执行，其结果返回给大语言模型；循环重复进行，直到大语言模型停止调用工具。在所有条件下，ClaudeSDK 都能访问三个工具：write_file、read_file 和 bash。在智能体驱动测试开发（Agentic-TDD）模式下，额外提供了三个工具：start_app、run_tests 和 stop_app，并且系统提示词会指导智能体遵循 TDD 工作流程顺序——实现、部署、测试、修复、重复。ClaudeSDK 有意保持极简，没有规划模块、记忆或多文件上下文选择功能，这样不同条件下的性能差异可归因于 TDD 基础设施，而非智能体的复杂程度。 OpenCode（https://opencode.ai）是一个完全开源、基于终端的编码智能体，支持任何兼容 OpenAI 的模型后端。它在研究社区中被广泛用作一个可复现、与模型无关的编码智能体研究基线，拥有 128K GitHub 星标。在“整个项目”、“增量”和“非 TDD”模式下，OpenCode 未经修改即可运行。在“智能体驱动测试开发（Agentic-TDD）”模式下，TDDev 的部署和测试工具通过一个注入到 OpenCode 会话配置中的 MCP 服务器暴露出来，使其在 Agentic-TDD 模式下拥有与 ClaudeSDK 相同的工具访问权限。 MCP 集成。TDDev 的环境桥接工具被打包成一个 MCP（模型上下文协议）服务器，通过标准化的 stdio 接口暴露 start_app、run_tests 和 stop_app 这三个工具。这使得任何兼容 MCP 的编码智能体都能访问这些工具，而无需修改 TDDev 的内部结构，并且这是在一致的工具接口下实现跨智能体评估的机制。 4.4. 骨干模型 本研究使用两个主干模型。Claude Sonnet 4.6（Anthropic API）是主要模型，与 ClaudeSDK 和 OpenCode 配合使用。Qwen-3.5-397B-A17B（OpenRouter API）用于与 ClaudeSDK 进行跨模型评估。在每个实验组合中，测试智能体和测试生成模块使用与编码智能体相同的主干模型。 媒体内容 · 前往原文查看 表 2. 实验组合。每个组合均运行全部四种条件（全项目、增量式、智能体 TDD、非 TDD）。 # 编码智能体 模型 基准 目的 1 ClaudeSDK Claude Sonnet 4.6 WebGen-Bench 主要 2 ClaudeSDK Qwen-3.5 WebGen-Bench 跨模型 3 OpenCode Claude Sonnet 4.6 WebGen-Bench 跨智能体 4 ClaudeSDK Claude Sonnet 4.6 ArtifactsBench 跨数据集 4.5. 实验条件 表 2 列出了本研究中评估的全部四种组合。每个组合均运行全部四种条件（全项目、增量式、智能体 TDD、非 TDD）。第 3.4 节总结了这四种条件，它们仅在一个维度上有所不同：对 TDD 循环的强制程度。全项目和增量式共享一个尝试预算；每次尝试均被记录，从而支持在不同反馈预算下进行事后分析（RQ4）。智能体 TDD 和非 TDD 仅调用一次，无外部重试循环。 4.6. 评估指标 RQ1 — 模块可靠性。测试生成覆盖率衡量的是至少有一条生成测试用例匹配的真实 WebGen-Bench 特征的比例，采用基于大语言模型的语义匹配来处理同义改写。测试智能体准确率衡量的是智能体判定结果与固定应用上预先确定的真实判定结果之间的一致率，分别针对正确和错误变体进行报告。 RQ2–4 — 准确率。遵循 WebGen-Bench（Lu 等人，2025），每个测试用例从测试智能体处获得通过、失败或部分通过的判定。准确率计算方式如下： (1) 其中表示尝试次数，每个测试用例取前次尝试中的最佳判定结果。针对研究问题2，我们报告acc@（最终准确率）以比较不同条件。针对研究问题3，我们比较增量式、全项目式和智能体TDD三种模式下的acc@曲线。针对研究问题4，我们绘制完整的acc@曲线，以描述准确率随额外反馈轮次增加的变化情况。每个条件下都会记录token消耗量（输入和输出），作为次要成本指标。 4.7. 实验设置 所有实验均在配备Apple M系列处理器和32 GB内存的MacBook Pro上进行。所有大语言模型均设置为温度参数0，并使用各模型允许的最大上下文长度。基于浏览器的测试使用Playwright配合Chromium浏览器进行。 5. 实验结果 5.1. 研究问题1：模块可靠性 5.1.1. 研究问题1.1：测试生成覆盖率 表3报告了10个采样的WebGen-Bench应用各自的覆盖率。测试生成模块匹配了62个参考测试用例中的57个，平均覆盖率达到91.9%。十个案例中有七个实现了100%的覆盖率。该模块生成的测试用例数量始终多于参考用例（平均每个应用12.4个对比6.2个），将模糊的需求分解为更细粒度的验收标准。 媒体内容 · 前往原文查看 表3. 10个应用、总计62个真实测试用例的测试生成覆盖率汇总 案例 真实 生成 匹配 覆盖率 完全覆盖（7/10） 46 93 46 100.0% 部分覆盖（3/10） 18 41 13 72.2% 总体（10/10） 62 124 57 91.9% 三个部分覆盖的案例各自遗漏了一些功能，这些功能需要仅凭高层需求无法推断出的特定操作知识。在一个食品配送应用中，该模块遗漏了“志愿者信息页面”和“主导航链接”——这些功能描述的是站点级导航而非领域特定功能，只有通过详细的UI操作说明才能显现。在所有三个非完美覆盖的案例中，核心领域功能均被完全覆盖。 5.1.2. 研究问题1.2：测试智能体准确率 表4报告了每个夹具应用的结果。该智能体评估了40个应用（20个正确，20个注入了已知错误），每个应用包含1个测试用例。总体准确率为87.5%（35/40）。 媒体内容 · 前往原文查看 表4. 测试智能体准确率汇总 变体 评估次数 正确次数 准确率 正确应用 20 15 75.0% 错误应用 20 20 100.0% 总计 40 35 87.5% 关键发现是变体之间存在不对称性：智能体在错误变体上达到了 100% 的准确率（20/20 的缺陷被正确检测到），但在正确变体上只有 75%（5 个假阴性）。所有 5 个失败都是对正确应用的假阴性——当应用功能正常时，智能体报告了失败。没有出现假阳性：智能体从未放过一个有问题的应用。 这 5 个假阴性分为两类。选择器生成错误占了三个案例：智能体生成的 Playwright 选择器无法匹配任何元素并超时。例如，计算器的运算符按钮显示为 +，但测试步骤要求“点击加号按钮”；智能体生成了 text=Add，这无法匹配任何内容。保守性失败占了两个案例：智能体过于保守，连细微差异也拒绝通过。例如，在一个注册表单应用中，确认消息的措辞与测试用例的预期字符串不同，被智能体拒绝了。 这种不对称性是 TDD 反馈循环中理想的失败模式。假阳性（放行有问题的应用）会悄无声息地传播缺陷；这种情况从未发生。假阴性（拒绝正确的应用）会触发一次不必要的修复轮次，这种做法保守但安全。100% 的缺陷检测率才是闭环系统中真正重要的特性。 5.2. 研究问题 2：TDD 基础设施相比基线能否提升质量？ 表 5 总结了所有三种实验组合和四种条件下的准确率。我们报告了 acc@1（首次尝试）和 acc@5（五次尝试中的最佳结果）；条件 C 和 D 是单次尝试，因此它们的两个值相同。 媒体内容 · 前往原文查看 表 5. 各组合与执行条件下的 Acc@5（%）。每个组合的最佳结果以粗体显示。OC 指 OpenCode。Art. 实验在 Artifact Bench 上进行。 组合 增量式 整体式 智能体 基线 ClaudeSDK + S4.6 31.5 49.1 65.8 31.3 ClaudeSDK + Q3.5 71.4 51.4 41.0 23.3 OC + Q3.5 45.7 50.7 27.3 11.7 ClaudeSDK + S4.6 (Art.) 81.4 86.2 82.9 78.6 在所有三种 WebGen-Bench 组合中，至少有一种采用 TDD 的条件显著优于 Non-TDD。对于搭配 Sonnet 4.6 的 ClaudeSDK，智能体式 TDD 达到了 65.8%，而 Non-TDD 为 31.3%，提升了 34.5 个百分点。对于搭配 Qwen-3.5 的 ClaudeSDK，增量式 TDD 达到了 71.4%，而 Non-TDD 为 23.3%（提升了 48.0 个百分点）。对于搭配 Qwen-3.5 的 OpenCode，全项目式 TDD 达到了 50.7%，而 Non-TDD 为 11.7%（提升了 39.0 个百分点）。跨数据集组合（在 ArtifactsBench 上搭配 Sonnet 4.6 的 ClaudeSDK）也显示出积极的 TDD 效果，但差距明显更小：最佳条件（全项目式，86.2%）比基线（78.6%）高出 7.6 个百分点。我们将差距缩小归因于 ArtifactsBench 更狭窄的任务分布——该基准测试偏向于自成一体的游戏和动画任务，在这些任务中，能力强的模型通常可以一次性满足需求，留给 TDD 循环发挥价值的空间较小。 5.3. 研究问题 3：执行力度如何影响性能？ 最优执行力度并非统一不变——它取决于基础模型的能力。对于搭配 Sonnet 4.6 的 ClaudeSDK，智能体式 TDD 达到了最高准确率 65.8%，显著优于全项目式（49.1%）和增量式（31.5%）。值得注意的是，搭配 Sonnet 的增量式 TDD 表现并不优于 Non-TDD（31.3%），这表明高执行力度的严格逐功能结构反而限制了一个能力强的模型，而非帮助它。相比之下，对于搭配 Qwen-3.5 的 ClaudeSDK，增量式 TDD 取得了最佳结果 71.4%，且随着执行力度降低，性能下降（全项目式：51.4%，智能体式 TDD：41.0%）。搭配 Qwen-3.5 的 OpenCode 遵循了类似的趋势，全项目式（50.7%）优于增量式（45.7%）和智能体式 TDD（27.3%）。 在 ArtifactsBench 上，三个强制级别产生的结果非常接近（高：81.4%，中：86.2%，低：82.9%），彼此之间的差距都在 5 个百分点以内。较窄的任务分布——主要是自包含的游戏和动画——降低了结构化强制本应帮助发现和修复的失败类型的多样性，使得强制级别几乎没有空间来区分结果。 5.4. 研究问题 4：反馈轮次如何影响准确率？ 媒体内容 · 前往原文查看 表 6. 跨反馈轮次的 acc@（%）——针对全项目和增量式（5 个案例的平均值）。acc@1 值已在表 5 中报告。 组合 协议 TDDev + Sonnet 4.6 全项目 41.5 44.9 49.1 49.1 增量式 31.5 31.5 31.5 31.5 TDDev + Qwen-3.5 全项目 45.2 48.0 51.4 51.4 增量式 59.7 66.4 69.7 71.4 OpenCode + Qwen-3.5 全项目 36.9 40.0 49.2 50.7 增量式 45.7 45.7 45.7 45.7 表 6 显示了对于全项目和增量式（Agentic-TDD 和非 TDD 为单次尝试；它们的值出现在表 5 中），准确率如何随额外的反馈轮次而变化。全项目在所有三种组合中都显著受益：准确率在 和 之间大约翻倍（Sonnet：21.3% 到 49.1%；Qwen：29.0% 到 51.4%；OpenCode：24.0% 到 50.7%）。增益在前两轮最大，之后递减，所有三种组合在 时趋于平稳。 增量式呈现出明显不同的轨迹。对于 Sonnet，增量式在 后收敛，并且没有进一步改善，最终达到 31.5%——远低于全项目@5（49.1%）。对于 Qwen，增量式在所有五轮中持续改善（59.7% 到 71.4%），表明对于生成风格保守的模型，增量式协议在更高的尝试预算下仍然有效。OpenCode 搭配 Qwen 在 之前有所提升，之后稳定在 45.7%。 一个值得注意的交叉组合观察结果：在基于 Qwen 的组合中，尽管轨迹差异很大，但 Whole-Project@5 和 Incremental@5 都收敛到相似的范围（49–51%）。然而，对于 Sonnet，Agentic-TDD（65.8%）在单次尝试中仍远高于 Whole-Project@5 和 Incremental@5。这表明，对于具有整体式生成风格的模型，TDD 循环的架构（在何时以及如何部署和测试方面的自主性）是比单纯增加反馈预算更强的质量驱动因素。 6. 讨论 6.1. 协议适配性 对日志的进一步检查表明，模型之间的性能差距不仅仅是能力问题，更是代码生成理念的根本差异——以及这种理念如何与每种协议的结构相互作用。 Sonnet 始终以整体式、从头开始的方式生成代码：给定一个任务，它会一次性生成完整、连贯的实现，当需要修复时，它会干净地重写受影响的文件，而不是打补丁。这产生了可靠、结构良好的应用程序——Sonnet 所有智能体运行中零服务器崩溃就证明了这一点。Qwen 则表现出相反的倾向：一种保守的、先读取后扩展的风格，即它首先检查现有代码库，然后进行精准的补充。这使实现更简单、更模块化，但当长时间会话中重复扩展累积在单个文件中时，会引入风险。 这些理念以一种可预测且具有实际意义的方式与协议结构相互作用。 增量式 TDD 隐含地假设了一个先读取再扩展的智能体。该协议要求智能体每次向共享代码库添加一个功能，同时保留所有先前通过的功能。Qwen 自然地遵循了这一假设，相比无 TDD 基线获得了 46 个百分点的准确率提升。Sonnet 则不然：它在每次功能调用时都会重写整个应用程序，将现有代码视为无关紧要。结果是，每个新功能的实现都会覆盖前一个，而本应推动改进的回归测试套件，每轮反而暴露出不同的问题。经过五轮迭代，Sonnet 在增量式 TDD 下的准确率与无 TDD 基线完全相同——重试预算被完全消耗，却毫无进展。 智能体式 TDD 隐含地假设了一个整体性智能体。该协议要求智能体在单次会话中构建完整的应用程序并自主驱动测试-修复循环。Sonnet 在此表现出色：它构建了一个连贯的整体，利用测试反馈识别缺失部分，并通过干净的重写来修复问题，单次尝试就比基线提升了 37 个百分点。Qwen 则陷入困境：其先读取再扩展的风格，在单次长会话中反复应用，导致服务器文件随着每次内部迭代而累积复杂性。在五个应用程序中的两个里，由于 Qwen 自身内部测试循环未能捕获的后期补丁引入了运行时错误，几乎所有功能在最终评估中都失败了。在智能体式协议下，Qwen 消耗的 token 比 Sonnet 多 70%，但得分却低了 25 个百分点——投入更多，连贯性却更差。 关键结论并非某个模型优于另一个，而是最优的 TDD 协议在原则上取决于模型：它取决于模型自然的生成风格是否与协议中蕴含的代码组织假设相匹配。这对于使用编码智能体部署 TDD 基础设施的开发者具有直接的实践意义：在选择强制策略之前，应考虑该智能体倾向于整体构建还是增量构建，因为这决定了哪种协议能够放大其优势，而非暴露其失败模式。 6.2. 成本与效率 仅凭准确率并不能决定哪种协议更实用：token 消耗直接转化为 API 成本和延迟。表 7 报告了每种组合和协议的总 token 预算（输入 + 输出，所有尝试的累计值），以及相对于无 TDD 基线的边际准确率提升。 媒体内容 · 前往原文查看 表 7. 相对于基线（无 TDD）的 token 成本和边际准确率提升。Tok/pp = 每超过基线一个百分点的千 token 数。 组合 协议 总计（百万） 百分点 Tok/pp（千） TDDev + Sonnet 全项目 5.1 +18.3 141 增量式 9.7 +0.0 — 智能体式 5.9 +36.7 91 TDDev + Qwen 全项目 4.5 +26.7 97 增量式 108.7 +46.7 2,327 智能体式 9.9 +16.7 593 有两个发现尤为突出。首先，每个模型最准确的方案——Sonnet 的智能体式 TDD（66.7%）和 Qwen 的增量式 TDD（71.7%）——其成本特征差异巨大。Sonnet 的最佳方案消耗 590 万 token，仅比其基线多 340 万；每额外提升一个百分点的准确率大约需要 9.1 万 token。Qwen 的最佳方案消耗 1.087 亿 token，比其基线多 1.068 亿；每额外提升一个百分点需要 232.7 万 token——效率比 Sonnet 的最佳方案低 25 倍。Qwen 增量式方案的极端成本源于每个功能的重试结构：六个功能各进行五轮，意味着每个案例最多有 30 次独立的 LLM 调用，随着通过的功能在回归测试套件中累积，每次调用的上下文也在不断增长。 其次，不匹配的方案不仅准确率更低——效率也更低。Sonnet 在增量式方案下消耗 970 万 token，准确率相对于基线却毫无提升；整个重试预算被消耗殆尽，却没有产生任何改进。Qwen 在智能体式方案下消耗 990 万 token，仅获得 16.7 个百分点的提升，还不到 Qwen 全项目方案（消耗 450 万 token，提升 26.7 个百分点）所实现提升的一半，而成本却超过后者的两倍。协议不匹配的代价是双重的：既降低了准确率，又浪费了 token 预算。 这些发现得出了一个清晰的实际建议。对于使用像 Sonnet 这样能力强且全面的模型的从业者来说，智能体测试驱动开发能以接近基准的成本效率提供最高的准确率，是首选方案。对于使用像 Qwen 这样更保守的模型的从业者来说，全项目测试驱动开发提供了最佳的成本-准确率权衡；只有在需要最高准确率且 token 成本不受限制时，才应考虑增量测试驱动开发。无论使用哪种模型，都应避免将增量测试驱动开发与全面模型结合使用：这是我们研究中唯一一种相比基线没有产生可衡量收益，同时却消耗了四倍 token 预算的配置。 6.3. 开发者感知 为了补充自动化评估，我们遵循 Chen 等人（Chen 等人，2018）的方法，与三位专业开发者（两位至少有两次 Web 应用项目经验的研究人员，以及一位来自初创公司的前端开发者）进行了一项用户研究。每位参与者根据 WebGen-Bench 的需求构建了两次 Web 应用：一次使用 TDDev，一次使用 Bolt.diy（一个基于浏览器的开源 Web 生成框架），每次都将应用优化至满意状态。我们记录了两种工具的人工干预时间、干预频率以及额外提示词长度。 媒体内容 · 前往原文查看 表 8. 三次开发者会话中 TDDev 与 Bolt.diy 的人工干预对比 方法 人工干预时间 / 总时间（分钟） 干预次数 额外提示词（字数） Bolt.diy 4.7 / 15.2 3.0 74 TDDev 0.0 / 18.7 0.0 0 表 8 显示，TDDev 完全消除了人工干预。使用 Bolt.diy 时，参与者在一次 15.2 分钟的会话中平均花费 4.7 分钟进行手动输入，需要三轮提示词和额外 74 个词的指导。关键的是，这项工作并非集中在开始阶段：参与者必须在每次生成周期后返回工具，测试输出、诊断故障并制定修正指令。该智能体在整个过程中需要持续关注。而使用 TDDev 时，参与者只需提供初始需求，在会话的剩余时间（平均 18.7 分钟）内完全无需参与，不需要任何额外的提示词或干预。 TDDev 的总时间略长（18.7 分钟对比 15.2 分钟），这反映了自动化基于浏览器的测试和迭代修复的成本。这并非生产力损失：额外的 3.5 分钟是自主运行的，在此期间开发者可以自由处理其他工作。相比之下，Bolt.diy 的 15.2 分钟中，有 4.7 分钟需要开发者保持活跃在场——每单位开发者时间所需的认知成本更高。 从定性角度来看，所有三位参与者都认为 TDDev 是完全无需动手且节省时间的。一位参与者指出，它“消除了整个循环中最令人沮丧的部分——自己打开浏览器、找出问题所在、然后试图解释它。”第二位参与者强调了输出质量：“它生成的应用程序实际上可以端到端运行，而不仅仅是视觉上看起来没问题。”参与者建议，未来的改进方向是减少在非必要功能上花费的时间，并增加无头浏览器支持。这些观察结果与定量结果一致：TDDev 的主要价值不在于消除开发时间，而在于消除开发者的注意力——将工作负载从持续的提示词工程转变为自主的、由反馈驱动的优化。 6.4. 对有效性的威胁 可推广性。基于单一模型、智能体或数据集得出的结论可能无法推广至其他场景。我们通过评估两个骨干模型（Claude Sonnet 4.6 和 Qwen-3.5）、两个编码智能体（ClaudeSDK 和 OpenCode）以及两个基准测试（WebGen-Bench 和 ArtifactsBench）来解决这一问题，覆盖了对比性的模型家族、开源与闭源智能体，以及不同的任务分布。 基准测试范围。基于单一基准测试的结论可能反映的是其特定的任务分布，而非通用的 Web 应用生成能力。我们引入了第二个基准测试（ArtifactsBench），其任务构成不同，并从 WebGen-Bench 中按固定随机种子抽取了 50 个样本，以确保可复现性并覆盖各类应用类型。 测试预言可靠性。来自测试智能体的自动判定可能错误分类结果，从而给准确率测量引入噪声。研究问题 1 表明，该智能体在保守偏差（仅存在假阴性，无假阳性）下达到了 87.5% 的准确率；残余误差对所有条件的影响均等，不太可能改变相对比较结果。 7. 结论 本文提出了 TDDev 框架，该框架通过自动化当前需要人工介入的三个步骤来弥合“可运行”与“可交付”之间的差距：将自然语言需求转化为可执行的验收测试、部署生成的应用程序并通过模拟浏览器交互来运行它，以及将观察到的失败转化为结构化的修复信号。我们针对两个编码智能体、两个骨干模型和两个基准测试，对四种开发协议进行了受控研究。结果表明，TDD 基础设施能够持续且显著地提升生成质量：在 WebGen-Bench 上，所有三种智能体-模型组合相比无 TDD 基线均实现了 34 到 48 个百分点的提升；该优势在第二个基准测试（ArtifactsBench）上同样成立，尽管由于其任务分布更窄，提升幅度较小。除了整体提升外，研究还揭示了执行策略的选择会以有规律的方式与模型自身的生成风格产生交互作用。 未来工作包括将基于浏览器的验证扩展到经过身份验证的多用户工作流，探索此处观察到的协议与哲学交互是否能够推广到更大的模型系列，并研究能够根据模型运行时行为推断适当协议的适应性执行策略。 数据可用性 TDDev 的所有代码和数据可在 https://doi.org/10.5281/zenodo.19251377 获取 参考文献 (1) and (2023) 2023. UI/Application Exerciser Monkey. https://developer.android.com/studio/test/other-testing-tools/monkey. Android Studio 文档，最后更新于 2023-04-12。 wor (2024) 2024. 17+ Surprising WordPress Statistics You Should Not Miss [2024]. WPDeveloper (2024). https://wpdeveloper.com/wordpress-statistics-2024 访问日期：2024-05-30。 web (2024) 2024. How Many Websites Are There in 2024? (13 Latest Statistics). TechJury (2024). https://techjury.net/blog/how-many-websites-are-there/ 访问日期：2024-05-30。 Alshahwan et al. (2024) Nadia Alshahwan, Jubin Chheda, Anastasia Finogenova, Beliz Gokkaya, Mark Harman, Inna Harper, Alexandru Marginean, Shubho Sengupta, and Eddy Wang. 2024. Automated Unit Test Improvement using Large Language Models at Meta. In Companion Proceedings of the ACM International Conference on Foundations of Software Engineering (FSE Companion). doi:10.1145/3663529.3663839 Aşıroğlu et al. (2019) Batuhan Aşıroğlu, Büşta Rümeysa Mete, Eyyüp Yıldız, Yağız Nalçakan, Alper Sezen, Mustafa Dağtekin, and Tolga Ensari. 2019. Automatic HTML code generation from mock-up images using machine learning techniques. In 2019 Scientific Meeting on Electrical-Electronics & Biomedical Engineering and Computer Science (EBBT). Ieee, 1–4. Becker et al. (2025) Joel Becker, Nate Rush, Beth Barnes, and David Rein. 2025. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089 [cs.SE] https://arxiv.org/abs/2507.09089 Beltramelli (2018) Tony Beltramelli. 2018. pix2code: Generating code from a graphical user interface screenshot. In Proceedings of the ACM SIGCHI symposium on engineering interactive computing systems. 1–6. Bouzenia 等人 (2025) Islem Bouzenia、Premkumar Devanbu 和 Michael Pradel。2025 年。《RepairAgent：一种基于大语言模型的自主程序修复智能体》。载于《IEEE/ACM 第 47 届国际软件工程大会 (ICSE) 论文集》。第 2188–2200 页。doi:10.1109/ICSE55347.2025.00157 Bouzenia 和 Pradel (2025) Islem Bouzenia 和 Michael Pradel。2025 年。《理解软件工程智能体：关于思维-行动-结果轨迹的研究》。载于《IEEE/ACM 国际自动化软件工程大会 (ASE) 论文集》。doi:10.1109/ASE63991.2025.00234 Chen 等人 (2018) C. Chen、T. Su、G. Meng、Z. Xing 和 Y. Liu。2018 年。《从 UI 设计图到 GUI 骨架：一种用于启动移动 GUI 实现的神经机器翻译器》。载于《第 40 届国际软件工程大会论文集》。第 665–676 页。 Chen 等人 (2022) W.-Y. Chen、P. Podstreleny、W.-H. Cheng、Y.-Y. Chen 和 K.-L. Hua。2022 年。《通过基于注意力机制的编码器-解码器模型从图形用户界面生成代码》。《多媒体系统》28 卷，第 1 期 (2022)，第 121–130 页。 Cizotto 等人 (2023) A. A. J. Cizotto、R. C. T. de Souza、V. C. Mariani 和 L. dos Santos Coelho。2023 年。《基于卷积神经网络和类激活映射的从原型设计生成网页》。《多媒体工具与应用》(2023)，第 1–27 页。 Dong 等人 (2025b) Jinhao Dong、Jun Sun、Wenjie Zhang、Jin Song Dong 和 Dan Hao。2025b 年。《ConTested：利用大语言模型进行一致性辅助的测试代码生成》。《ACM 软件工程论文集》ISSTA，文章编号 ISSTA027 (2025)，第 596–617 页。doi:10.1145/3728902 Dong 等人 (2025a) Yihong Dong、Xue Jiang、Jiaru Qian、Tian Wang、Kechi Zhang、Zhi Jin 和 Ge Li。2025a 年。《基于大语言模型智能体的代码生成综述》。arXiv 预印本 arXiv:2508.00083 (2025)。 Fakhoury 等人 (2024) Sarah Fakhoury、Aaditya Naik、Georgios Sakkas、Saikat Chakraborty、Madan Musuvathi 和 Shuvendu K. Lahiri。2024 年。《基于大语言模型的测试驱动交互式代码生成：用户研究与实证评估》。《IEEE 软件工程汇刊》(2024)。doi:10.1109/TSE.2024.3428972 作为期刊优先论文在 ICSE 2025 上展示。 Foster 等人 (2025) Christopher Foster, Abhishek Gulati, Mark Harman, Inna Harper, Ke Mao, Jillian Ritchey, Hervé Robert, 和 Shubho Sengupta。2025。基于突变引导的大语言模型测试生成在 Meta 的应用。收录于《ACM 软件工程基础国际会议（FSE Companion）配套论文集》。doi:10.1145/3696630.3728544 Gu 等人 (2019) Tianxiao Gu, Chengnian Sun, Xiaoxing Ma, Chun Cao, Chang Xu, Yuan Yao, Qirun Zhang, Jian Lu, 和 Zhendong Su。2019。通过模型抽象与精化实现 Android 应用的实用 GUI 测试。2019 年 IEEE/ACM 第 41 届国际软件工程大会 (ICSE) (2019)，第 269–280 页。https://api.semanticscholar.org/CorpusID:89608086 Gui 等人 (2025) Yi Gui, Yao Wan, Zhen Li, Zhongyi Zhang, Dongping Chen, Hongyu Zhang, Yi Su, Bohua Chen, Xing Zhou, Wenbin Jiang, 和 Xiangliang Zhang。2025。UICopilot：通过网页设计的分层代码生成实现 UI 自动化合成。《2025 年 ACM 万维网大会论文集》(2025)。https://api.semanticscholar.org/CorpusID:277998658 Kaner (2013) Cem Kaner。2013。场景测试导论。https://api.semanticscholar.org/CorpusID:59641340 Kim 等人 (2025) Jaehyeon Kim, Rui Rua, 和 Karim Ali。2025。BuilDroid：用于自动化 Android 构建的自校正大语言模型智能体。收录于《IEEE/ACM 国际自动化软件工程大会 (ASE) 工具演示轨道论文集》。 Lan 等人 (2024) Yuanhong Lan, Yifei Lu, Zhong Li, Minxue Pan, Wenhua Yang, Tian Zhang, 和 Xuandong Li。2024。基于深度强化学习深度增强 Android GUI 测试。2024 年 IEEE/ACM 第 46 届国际软件工程大会 (ICSE) (2024)，第 854–866 页。https://api.semanticscholar.org/CorpusID:267523834 Li 等人 (2019) Yuanchun Li, Ziyue Yang, Yao Guo, 和 Xiangqun Chen。2019。Humanoid：一种基于深度学习的自动化黑盒 Android 应用测试方法。2019 年第 34 届 IEEE/ACM 国际自动化软件工程大会 (ASE) (2019)，第 1070–1073 页。https://api.semanticscholar.org/CorpusID:210693353 Lin 等人（2025）Feng Lin、Dong Jae Kim 和 Tse-Hsun (Peter) Chen。2025 年。SOEN-101：利用大语言模型智能体模拟软件过程模型进行代码生成。载于《IEEE/ACM 第 47 届国际软件工程大会（ICSE）论文集》。doi:10.1109/ICSE55347.2025.00140 Liu 等人（2023）Zhe Liu、Chunyang Chen、Junjie Wang、Mengzhuo Chen、Boyu Wu、Xing Che、Dandan Wang 和 Qing Wang。2023 年。让大语言模型成为测试专家：通过功能感知决策为移动图形用户界面测试带来类人交互。2024 年 IEEE/ACM 第 46 届国际软件工程大会（ICSE）（2023），第 1222–1234 页。https://api.semanticscholar.org/CorpusID:264439493 Liu 等人（2024）Zhe Liu、Cheng Li、Chunyang Chen、Junjie Wang、Boyu Wu、Yawen Wang、Jun Hu 和 Qing Wang。2024 年。基于视觉驱动的多模态大语言模型自动化移动图形用户界面测试。ArXiv 摘要 abs/2407.03037（2024）。https://api.semanticscholar.org/CorpusID:270923733 Lovable（2026）Lovable。2026 年。Lovable 介绍。https://docs.lovable.dev/introduction/welcome Lovable 文档。访问日期：2026-03-20。 Lu 等人（2025）Zimu Lu、Yunqiao Yang、Houxing Ren、Haotian Hou、Han Xiao、Ke Wang、Weikang Shi、Aojun Zhou、Mingjie Zhan 和 Hongsheng Li。2025 年。WebGen-Bench：评估大语言模型从零生成交互式功能网站的能力。arXiv 预印本 arXiv:2505.03733（2025）。 Mathews 和 Nagappan（2024）Noble Saji Mathews 和 Meiyappan Nagappan。2024 年。测试驱动开发与基于大语言模型的代码生成。载于《第 39 届 IEEE/ACM 国际自动化软件工程大会论文集》（美国加利福尼亚州萨克拉门托）（ASE '24）。美国纽约州纽约市计算机协会，第 1583–1594 页。doi:10.1145/3691620.3695527 MDN Web 文档（2025）MDN Web 文档。2025 年。无障碍树。https://developer.mozilla.org/zh-CN/docs/Glossary/Accessibility_tree。最后修改日期：2025-12-15；访问日期：2026-03-27。 Miguel 和 Takada（2016）Jose Lorenzo San Miguel 与 Shingo Takada。2016 年。基于 GUI 和使用模型的 Android 应用测试用例生成方法（含变更分析）。第一届移动开发国际研讨会论文集（2016）。https://api.semanticscholar.org/CorpusID:5574875 Moran 等人（2018）K. Moran、C. Bernal-Cárdenas、M. Curcio、R. Bonett 和 D. Poshyvanyk。2018 年。基于机器学习的移动应用图形用户界面原型设计。IEEE 软件工程汇刊第 46 卷第 2 期（2018），第 196–221 页。 Nguyen 和 Csallner（2015）Tuan Anh Nguyen 与 Christoph Csallner。2015 年。使用 remaui 逆向工程移动应用用户界面（t）。载于 2015 年第 30 届 IEEE/ACM 国际自动化软件工程会议（ASE）。IEEE，第 248–259 页。 Pan 等人（2020）Minxue Pan、An Huang、Guoxin Wang、Tian Zhang 和 Xuandong Li。2020 年。基于强化学习的好奇心驱动型 Android 应用测试。第 29 届 ACM SIGSOFT 国际软件测试与分析研讨会论文集（2020）。https://api.semanticscholar.org/CorpusID:220497623 Rondon 等人（2025）Pat Rondon、Renyao Wei、José Cambronero、Jürgen Cito、Aaron Sun、Siddhant Sanyam、Michele Tufano 和 Satish Chandra。2025 年。评估 Google 基于智能体的程序修复。载于 IEEE/ACM 国际软件工程会议：软件工程实践论文集（ICSE-SEIP）。arXiv:2501.07531。 Ruan 等人（2025）Haifeng Ruan、Yuntong Zhang 和 Abhik Roychoudhury。2025 年。SpecRover：通过大语言模型进行代码意图提取。载于 IEEE/ACM 第 47 届国际软件工程会议论文集（ICSE）。doi:10.1109/ICSE55347.2025.00080 Shang 等人（2025）Ye Shang、Quanjun Zhang、Chunrong Fang、Siqi Gu、Jianyi Zhou 和 Zhenyu Chen。2025 年。关于微调大语言模型用于单元测试的大规模实证研究。ACM 软件工程汇刊 ISSTA（2025）。doi:10.1145/3728951 Si 等人（2024）Chenglei Si、Yanzhe Zhang、Zhengyuan Yang、Ruibo Liu 和 Diyi Yang。2024 年。Design2Code：我们在自动化前端工程方面走了多远？ArXiv abs/2403.03163（2024）。https://api.semanticscholar.org/CorpusID:268248801 TMAP（[无日期]）TMAP。[无日期]。探索性测试（ET）。https://www.tmap.net/wiki/exploratory-testing-et/。访问日期：2026-03-27。 Wan 等人（2024）Yuxuan Wan, Yi Dong, Jingyu Xiao, Yintong Huo, Wenxuan Wang, 和 Michael R. Lyu。2024。MRWeb：从 UI 设计生成多页面资源感知型 Web 代码的探索。ArXiv abs/2412.15310 (2024)。https://api.semanticscholar.org/CorpusID:274965541 Wan 等人（2025）Yuxuan Wan, Chaozheng Wang, Yi Dong, Wenxuan Wang, Shuqing Li, Yintong Huo, 和 Michael Lyu。2025。分而治之：从截图生成 UI 代码。Proc. ACM Softw. Eng. 2, FSE, 文章编号 FSE094（2025 年 6 月），24 页。doi:10.1145/3729364 Wang 等人（2025）Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, 和 Graham Neubig。2025。OpenHands：面向通用型 AI 软件开发者的开放平台。收录于第十三届国际学习表征会议。https://openreview.net/forum?id=OJd3ayDDoF Wang 等人（2022）Xin Wang, Xiao Liu, Pingyi Zhou, Qixia Liu, Jin Liu, Hao Wu, 和 Xiaohui Cui。2022。基于测试驱动的多任务学习与功能等价代码变换在神经代码生成中的应用。收录于第 37 届 IEEE/ACM 国际自动化软件工程会议论文集。第 1–6 页。 Wu 等人（2025）Fan Wu, Cuiyun Gao, Shuqing Li, Xinjie Wen, 和 Qing Liao。2025。基于 UI 布局信息引导的 MLLM 驱动 UI2Code 自动化。ArXiv abs/2506.10376 (2025)。https://api.semanticscholar.org/CorpusID:279319153 Xia 等人（2025）Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, 和 Lingming Zhang。2025。Agentless：揭秘基于 LLM 的软件工程智能体。Proceedings of the ACM on Software Engineering 2, FSE, 文章编号 FSE037 (2025)。doi:10.1145/3715754 Xiao 等人 (2024) 肖景宇、万宇轩、霍胤彤、徐志尧、吕荣聪。2024 年。《Interaction2Code：我们距离自动交互式网页生成还有多远？》ArXiv 预印本 arXiv:2411.03292 (2024)。https://api.semanticscholar.org/CorpusID:273821629 Xiao 等人 (2025) 肖景宇、王明、林文浩、万宇轩、刘俊良、霍胤彤、吕荣聪。2025 年。《DesignBench：基于多模态大语言模型的前端代码生成综合基准测试》ArXiv 预印本 arXiv:2506.06251 (2025)。https://api.semanticscholar.org/CorpusID:279244894 Xu 等人 (2025) 徐俊杰龙、付颖、陈馨慧、何品佳。2025 年。《对齐基于大语言模型的程序修复目标》收录于 IEEE/ACM 第 47 届国际软件工程大会 (ICSE) 论文集。doi:10.1109/ICSE55347.2025.00169 Xu 等人 (2021) 徐云、薄琳、孙小兵、李斌、蒋建民、周伟。2021 年。《image2emmet：基于网页用户界面图像的自动代码生成》发表于《软件：演化与过程》期刊 33 卷 8 期 (2021)，e2369。 Yang 等人 (2024) 杨约翰、Carlos E. Jimenez、Kilian Lieret、姚顺宇、Alexander Wettig、Karthik Narasimhan、Ofir Press。2024 年。《SWE-agent：智能体-计算机接口实现自动化软件工程》收录于《神经信息处理系统进展》(NeurIPS)，第 38 卷。arXiv:2405.15793。 Yu 等人 (2023) 余圣成、房春荣、拓子源、张全权、陈春阳、陈振宇、苏振东。2023 年。《基于视觉的移动应用图形用户界面测试：综述》ArXiv 预印本 arXiv:2310.13518 (2023)。https://api.semanticscholar.org/CorpusID:264406197 Yu 等人 (2025) 余正民、张源、文敏、聂一男、张文辉、杨珉。2025 年。《CXXCrafter：基于大语言模型的自动化 C/C++ 开源软件构建智能体》发表于《ACM 软件工程会议论文集》第 2 卷，FSE (2025)。doi:10.1145/3729386 Zhang 等人（2025）陈晨张、李玉航、曹灿、刘嘉恒、刘奥、周昌志、邓肯、吴登鹏、黄冠华、李柯娇、易奇、熊瑞斌、胡世辉、张悦、蒋宇浩、徐泽南、张元兴、周伟金、周蔡斯、连凤宗。2025年。ArtifactsBench：弥合大语言模型代码生成评估中的视觉-交互鸿沟。arXiv:2507.04952 [cs.CL] https://arxiv.org/abs/2507.04952 Zhang 等人（2024）张云彤、阮海峰、范志宇、Abhik Roychoudhury。2024年。AutoCodeRover：自主程序改进。arXiv预印本 arXiv:2404.05427（2024年）。 Zhou 等人（2024）周婷、赵彦杰、侯欣怡、孙晓宇、陈凯、王浩宇。2024年。弥合设计与开发之间的鸿沟：自动化声明式UI代码生成。arXiv预印本 arXiv:2409.11667（2024年）。