编码智能体写测试有何不同：11.4 万个 Java PR 显示，它更爱新增测试、少改旧测试

原文信息：本文译自 arXiv 论文《Testing with Coding Agents: A Large-Scale Comparison of Agent-Supported and Human-Authored Pull Requests》，作者 Roberto Milanese（都灵理工大学、莫利塞大学）、Francesco Salzano、Remo Pareschi、Fausto Fasano（莫利塞大学）与 Hovhannes Muradyan、Jingjing Wu、Mattia Fazzini（明尼苏达大学），2026 年 10 月 26 日提交（arXiv:2610.35297）。原文链接：https://arxiv.org/abs/2610.35297 。原文采用 CC BY 4.0 许可。本文为翻译（节译）：摘要、引言、研究问题、讨论与结论全文翻译，数据采集、实验方法与各研究问题的结果按原文要点节译；图表、统计模型细节与参考文献请见原文。文末附译者注。

译者导语：Claude Code、Codex、Copilot 这类编码智能体（Coding Agent）提交的 PR 越来越多，其中很大一部分是测试代码。可测试写进仓库之后，还得靠人长期维护。这篇论文分析了 391 个 Java 仓库里的 11.4 万个已合并 PR，在同一仓库内比较“有智能体参与”和“纯人工”的 PR：智能体更爱新增测试，却更少修改和删除旧测试。对正在把编码智能体引入团队的开发者和技术负责人，这个结论值得记住：测试维护不会自动跟上，得明确提出来。

摘要

背景。 编码智能体越来越多地通过拉取请求（Pull Request，PR）贡献测试，而这些测试之后要由开发者维护，因此测试工作如何分工，会影响代码的长期可维护性。

目标。 我们比较两类 PR：开发者与编码智能体协作完成的 PR（下称“智能体参与 PR”），以及检测不到智能体参与的 PR（下称“人工 PR”）。比较涵盖五个维度：测试改动的频率与幅度、测试改动的类型与上下文、测试结构、测试坏味道（Test Smell），以及代码覆盖率。

方法。 我们分析了 391 个 Java 仓库中 2025 年 1 月至 2026 年 4 月合并的 114,134 个 PR，通过 PR 级和提交级信号识别 5 种编码智能体。由于各项目采用智能体的程度不同，我们使用控制了改动规模的混合效应模型，在仓库内部比较两组。

结果。 把所有仓库混在一起看，两组修改测试代码的频率几乎一样；但在同一仓库内，智能体参与 PR 修改测试代码的优势比（Odds）是人工 PR 的 1.65 倍。智能体参与 PR 更常新增测试（优势比 1.50–1.58），更少修改（0.70–0.76）和删除（0.51–0.77）测试。它们新增测试的大多数结构特征与人工无异，且更常带有断言（Oracle）；在我们能够构建的 95 个仓库中，两组对生产代码改动的覆盖率也没有差异。但在只改测试的 PR 中，智能体写的测试对被测代码的覆盖更少。测试坏味道的差异处在显著性边缘，在单个测试方法层面也没有复现。

结论。 智能体参与与另一种测试工作组合相关联，而跨项目混合比较可能掩盖甚至反转这种差异；它与测试质量之间的关系仍不确定。

1 引言

AI 编程工具已经从补全单行代码，发展到执行完整的开发任务：现代编码智能体会围绕任务反复迭代，调用构建系统、测试框架和版本控制，直到它认为任务完成。在协作项目中，成果通常以 PR 的形式进入代码库，由开发者评审、修改和合并。智能体的普及速度很快：截至 2026 年 2 月，Robbes 等人分析的 128,018 个活跃 GitHub 仓库中，有 22.20% 到 28.66% 出现了使用编码智能体的痕迹。我们把开发者与编码智能体共同参与的 PR 称为“智能体参与 PR”，把检测不到智能体参与的 PR 称为“人工 PR”。

这种转变影响最持久的地方，很可能是测试。测试会随着被测代码的演进被阅读、修改和删除；测试代码中的设计问题——即测试坏味道——会让测试更难理解和修改。而这类问题通常在测试首次编写时就被引入，之后很少被清除。既然智能体写的测试要由开发者接手维护，两个问题就变得关键：智能体承担了哪类测试工作？产出的测试代码又是什么样子？

关于智能体测试的研究增长很快，但证据零散。针对真实智能体 PR 中测试的研究，各自只关注一个方面：测试的纳入与演化、测试结构与覆盖率、增量覆盖率与断言质量，或测试失败。其中只有部分研究比较了智能体与人工贡献，而且它们至少部分地把各仓库的数据混在一起，或者只逐个分析少量项目。真正缺少的是这样一种比较：覆盖大量仓库，在每个仓库内部估计差异，控制贡献规模，并量化这种差异在仓库之间变化多大。这很重要，因为各项目采用智能体的程度并不均衡：混合比较会把“智能体贡献的测试方式是否不同”与“哪些项目在用智能体”搅在一起，而我们会看到，后者可以掩盖甚至反转前者。

我们此前的研究比较了 AIDev 数据集中四种编程语言的 6,582 个智能体参与 PR 与 3,122 个人工 PR，发现两组包含测试的比例相近（42.9% 对 40.0%），但智能体参与 PR 把更大比例的改动用在测试代码上；在测试与生产代码协同演化时，智能体参与 PR 更常新增测试（优势比 1.79），人工 PR 则更常修改和删除已有测试；测试坏味道的差异幅度可以忽略。不过，那项研究跨仓库混合比较 PR，以测试文件为粒度对改动分类，把任何同时改动测试和生产代码的 PR 都算作协同演化，也没有测量覆盖率。

本文针对这些局限做了改进。第一，我们在仓库内部比较两组，使用混合效应模型，让每个仓库拥有自己的基线和自己的组间差异，并控制改动规模。第二，我们以测试方法和测试夹具（Fixture）为粒度分析测试改动，只有当测试改动与同一 PR 改动的生产代码有关联时，才视为协同演化；我们还用 JNose 检测测试坏味道，它能把每处坏味道定位到具体测试方法，因此既能按整个贡献比较，也能按单个测试比较。第三，我们新增两个维度：用 Hamster 提取的测试代码结构，以及在 PR 前后分别执行测试套件、用 JaCoCo 测得的代码覆盖率。由于测量覆盖率需要构建每个项目，我们把研究限定在 Java，因为 Java 标准化的构建工具让大规模构建成为可能。

为此我们需要一个新的数据集。我们收集了 2025 年 1 月 1 日至 2026 年 4 月 30 日期间、在存在智能体活动痕迹的 Java 仓库中创建并合并的全部 PR，通过 PR 级和提交级信号识别五种广泛使用的智能体：Claude Code、Codex、Copilot、Cursor 和 Devin。保留两组 PR 各至少 10 个的仓库后，得到来自 391 个仓库的 18,375 个智能体参与 PR 和 95,759 个人工 PR。基于该数据集，我们回答五个研究问题，分别比较两组在以下方面的差异：测试的频率与幅度（RQ1）、测试改动的类型与上下文（RQ2）、测试代码结构（RQ3）、测试坏味道（RQ4）以及代码覆盖率（RQ5）。

我们的结果可以归纳为五个主要发现。

第一，比较方式决定了看到什么。 跨仓库混合看，两组修改测试代码的频率几乎相同（60.1% 对 59.4%）；而在同一仓库、同等规模下，智能体参与 PR 修改测试代码的优势比是人工 PR 的 1.65 倍。

第二，测试工作的组合不同。 与同等规模的人工 PR 相比，智能体参与 PR 在各种开发场景中都更常新增测试（优势比 1.50–1.58），更少修改（0.70–0.76）和删除（0.51–0.77）测试；而两组让测试与生产代码协同演化的频率差别不大（优势比 1.12）。

第三，测试结构差别不大。 智能体参与 PR 新增测试的大多数结构特征与人工无异，唯一例外是它们更常带有断言（优势比 1.71）；修改测试时，智能体参与 PR 更常增加断言（优势比 1.31）。

第四，测试坏味道的证据较弱。 在 PR 层面，智能体参与 PR 新增测试时坏味道的净增长更小，修改测试时净增长更大，但两项估计都处在显著性边缘，在单个测试方法层面也都没有复现。

第五，覆盖率总体无差异，但有一个例外。 两组对生产代码改动的覆盖程度没有可检测的差异；但在只改测试的 PR 中，智能体参与 PR 贡献的测试对所测试类的覆盖低 11.1 个百分点——这个结果只基于 11 个同时拥有两组纯测试 PR 的仓库。

对多数指标而言，差异的大小乃至方向，在不同仓库之间变化相当大。

本文的贡献包括：一个包含 391 个 Java 仓库、114,134 个已合并 PR 的数据集，每个仓库都同时有智能体参与 PR 和人工 PR，智能体参与通过多种 PR 级和提交级信号识别；一项覆盖 391 个仓库、控制改动规模的仓库内比较，估计了差异在仓库间的变化程度，并表明跨项目混合可能掩盖或反转差异；沿五个测试维度对同一批贡献的分析；以及包含数据集、查询和分析脚本的复现包。

2 研究设计（节译）

为什么只看 Java。 测试坏味道检测只需静态读取文件，而测量覆盖率必须构建项目并运行测试套件，只有构建和测试流程标准化时才能大规模进行。Java 生态中，Maven 和 Gradle 是多数项目使用的构建系统，无论底层用哪种测试框架都提供统一的测试入口，JaCoCo 又能轻松集成到两者中。相比之下，Python 和 JavaScript/TypeScript 生态的测试框架高度分散，扩展到四种语言就需要四套构建、覆盖率语义和分析工具，结果难以比较。

如何识别智能体参与。 以往数据集大多只靠分支名前缀识别智能体（Claude Code 则靠 PR 正文中的“Co-Authored-By: Claude”）。依赖单一信号容易受项目约定影响。作者结合了 PR 级信号（分支名前缀、标签、智能体作者、智能体指派人）和提交级信号（智能体作者或共同作者）。按分支名前缀在 GitHub 搜索 2025 年 1 月至 2026 年 4 月的 Java PR，数量依次为：codex/ 约 98,300 个、copilot/ 约 36,600 个、claude/ 约 18,800 个、devin/ 约 2,900 个、cursor/ 约 2,700 个，其余智能体（Jules、OpenHands 等）都不足 200 个，因此只研究前五种。由于无法排除不留痕迹的智能体使用，对照组严格说是“以人工为主”的 PR。

数据集概况。 最终数据集包含 391 个 Java 仓库的 114,134 个 PR，其中智能体参与 18,375 个、人工 95,759 个。分布很不均匀：Codex（7,067）、Copilot（5,764）和 Claude Code（5,387）几乎占据全部智能体参与 PR，Cursor 只有 292 个，Devin 只有 9 个。智能体参与 PR 从 2025 年年中才开始普遍，其中 40% 合并于时间窗口的最后两个月。这些仓库大多规模小、年头短：中位数仓库只有 3 颗星、2.8 万行 Java 代码、3 位 PR 作者，存续 1.3 年。智能体参与 PR 改动的 Java 代码更多（中位数 93 行对 52 行），改动文件数（3 个）和提交数（2 个）的中位数相同，但合并快得多（中位数 0.6 小时对 9.7 小时）。

统计方法。 所有研究问题采用同一设计：在同一仓库内比较两组 PR（或它们改动的测试方法），使用混合效应模型——每个仓库有自己的基线和自己的组间差异——并控制改动规模。报告优势比或率比及其 95% 置信区间，用 Holm-Bonferroni 方法在每组检验内校正 p 值，同时报告仓库间差异的标准差，以衡量“差异在不同仓库里有多不一样”。

3 结果（节译）

RQ1：测试的频率与幅度。 在同等规模下，智能体参与 PR 比人工 PR 更常包含测试：在一个典型仓库里，每 100 个 PR 大约多 9 个包含测试。同时改动生产代码时，智能体参与 PR 的改动行中测试占比更高，也更可能只改测试。差异在几十行的小改动中最明显——人类开发者常常不带测试就提交这类改动；在“有测试习惯但不成体系”的项目中也最明显，而在测试已成常态或几乎不写测试的项目中较小。跨项目混合比较会漏掉这些差异，因为智能体参与 PR 主要来自本身测试较少的项目。

RQ2：测试改动的类型与上下文。 两组把测试改动与生产改动配对的频率差别不大，但改动测试套件的方式不同。在同一仓库、同等规模下，每 100 个智能体参与 PR 中，新增测试的多约 7 到 10 个，修改已有测试的少约 5 到 8 个，删除测试的少约 1 到 4 个。新增与修改上的差异，不取决于测试是针对本次生产改动、伴随无关改动，还是构成整个 PR；删除上的差距在与生产改动关联的测试上最小，主要出现在较大的 PR 中。在大多数项目里，智能体参与 PR 都更常新增测试；而在开发者更常调整和删除已有测试的项目中，混合 PR 里的维护差距更大。

RQ3：测试结构。 在同一项目、同等长度下，智能体参与 PR 新增的测试方法在结构上与开发者写的差别不大。唯一一致的差异是：智能体的测试在各种场景下都更常带有断言。其他差异取决于场景，最明显的是在只改测试的 PR 中，智能体的测试包含更多“调用—断言”序列。修改已有测试时，智能体更常至少增加一个断言，删除断言的频率则没有检测到差异。测试完全失去断言的情况在两组中都很少见，并集中在少数项目中，其中一些项目里智能体这样做的频率远高于开发者。测试结构在项目之间的差异，大于智能体与开发者之间的差异，这与“智能体遵循各项目约定”的解释一致。

RQ4：测试坏味道。 两组在 PR 层面表现出不同的坏味道演化模式：智能体参与 PR 新增测试时，坏味道总体增量（Smell Delta）更小，修改测试时更大，但两者都接近显著性门槛。校正后，只有新增测试中的 General Fixture（通用夹具过大）和 Exception Catching Throwing（测试中手动捕获或抛出异常）两类有显著差异。在单个测试方法层面，无论总体还是分类别分析，都没有发现系统性差异。

RQ5：代码覆盖率。 在改动测试代码的 PR 中，两组对生产代码改动的覆盖程度没有检测到差异，并且两组中约四分之三被覆盖的新增代码行，是由本 PR 贡献的测试覆盖的。因此，智能体“新增测试而非改造旧测试”的倾向，似乎并没有让它们的改动覆盖更差——尽管数据无法证明两组等价，也无法说明不带测试的生产改动。唯一显著的差异出现在只改测试的 PR 中：智能体贡献的测试对所测试类的覆盖低约 11 个百分点，在小 PR 中尤其如此。由于只有 11 个仓库同时拥有两组纯测试 PR，这一结论有待更大样本验证。包含测试代码在内的整体代码库覆盖率，在智能体参与 PR 中更常上升，但这主要反映了它们新增的测试代码本身。

4 讨论

第 3 节已经逐一解读了各研究问题的结果。本节讨论这些结果合在一起意味着什么，把它们与已有工作联系起来，并给出对研究与实践的启示，最后讨论有效性威胁。

由于智能体参与 PR 本质上是开发者与智能体的协作，我们观察到的差异刻画的是这种协作整体。它们可能反映智能体完成任务的方式，也可能反映开发者如何挑选、描述和评审委派给智能体的任务——我们的数据无法把两者分开。文中“智能体更常新增测试”之类的说法，都是这种描述性意义上的。

4.1 比较必须考虑项目本身

对同一批贡献做混合比较和仓库内比较，会得出不同结论（RQ1）。智能体参与 PR 集中在本身较少改动测试代码的仓库中，所以混合比较把两个问题混在了一起：在一个项目内部，智能体参与 PR 是否与人工 PR 不同；以及，哪些项目在采用编码智能体。我们之前的研究跨仓库混合了 PR，其他比较智能体与人工测试的研究也至少部分地混合了数据。我们的结果并不否定它们的发现——那些研究针对的是不同的总体和指标——但它们表明，项目构成的影响可以大到掩盖一个显著差异，甚至反转另一些差异的方向。

项目的作用还体现在另一方面。我们报告的平均差异，概括的是一组各仓库特定差异的分布，而这个分布的离散程度往往比平均值本身还大。所以“智能体参与 PR 测试更多”这类说法在平均意义上成立，在某个具体项目里未必成立。部分变化是有规律的：在测试频率、新增测试和断言上，项目里已经普遍这样做时，差异最小——这与智能体（或引导它们的开发者）遵循各项目约定的解释一致。其余变化尚无法解释，可能的调节因素包括：测试套件的成熟度、持续集成与代码评审的严格程度、是否有智能体指令文件，以及使用的是哪种智能体。

4.2 智能体承担了不同份额的测试工作

把 RQ2、RQ3 和 RQ5 放在一起看，两组的差异更多在于承担哪些测试任务，而不在于写出的测试本身。智能体参与 PR 更常新增测试、更少修改或删除测试，但它们新增测试的大多数结构特征没有可检测的差异，对生产改动的覆盖程度也没有。这些是“一个 PR 是否执行某项任务”的差异，而不是新增多少测试、测试套件增长多快的差异。

一种可能的解释是：新增测试是一项自成一体的任务，从手头改动的上下文就能完成；而修改或删除已有测试，需要先弄清它在检查什么，再判断它是否仍然需要。另有两种解释看似合理但尚未验证：智能体可能被指示为自己的改动新增测试，而不是修订已有测试；开发者可能倾向于把需要新测试的任务委派给智能体。无论原因为何，如果智能体的采用继续增长，已有测试的维护可能会转移到开发者身上，过时的测试可能在智能体贡献最多的地方不断累积。这是否真的发生，只能通过对每个项目历史上测试改动的纵向分析来确认。

我们的覆盖率结果与已有研究不能直接比较。Alves 和 Teixeira 在 Python 中跨仓库混合比较，报告纯 AI PR 的增量覆盖率高于人工 PR；而我们在仓库内部没有检测到新增代码行覆盖率的差异。Dipongkor 等人在 PR 合并后的测试套件上，分别带上和去掉该 PR 的测试改动运行，以固定生产代码、只改变测试，从而估计这些测试改动带来的覆盖增益。我们则比较两个完整版本，并把覆盖率归因到单个测试方法，因此我们统计的“被本 PR 测试执行到的新增已覆盖行”中，也包括已有测试本来就会执行到的行。

4.3 测试质量仍是悬而未决的问题

关于测试质量的证据，不如关于工作类型的证据那么确定。RQ4 中 PR 层面的坏味道估计处在显著性边缘，新增与修改的方向相反，且在单个测试方法层面没有复现，因此我们只把它们当作假设。如果得到证实，它们意味着智能体参与 PR 更常执行的，恰好是坏味道增量较低的那类活动，因此对一个项目的净影响取决于它的测试工作组合。两个层面结论不一致，有几种并不互斥的解释：定义在测试类或共享初始化代码上的坏味道（如 General Fixture）在 PR 层面会被计入，在测试方法层面只能部分归因；少数增量极大的贡献可能主导 PR 层面的估计；两个层面对 PR 的加权方式也不同。把增量拆成新引入和被移除的坏味道、单独处理类级坏味道、评估极端贡献的影响，可以区分这些解释。

另外两个结果提示了质量差异可能存在的地方（如果有的话）。失去断言的测试很少见，但集中在少数项目中，其中一些项目里智能体参与 PR 失去断言的频率远高于人工（RQ3）；在只改测试的 PR 中，智能体贡献的测试对所测试类的覆盖更少（RQ5）。两者都只基于少数仓库，而且坏味道和覆盖率都不能衡量测试能否发现缺陷。更普遍地说，对智能体所写测试质量的估计可能取决于分析单元，因此研究这一问题时应说明结论成立的层面，并尽可能报告不止一个层面。

4.4 启示

对研究者。 比较智能体参与与人工贡献时，应在项目内部比较，或在模型中显式考虑项目身份，因为混合比较会把智能体的行为与智能体的采用混为一谈。应说明并论证分析单元，因为在同一数据上做贡献级与方法级分析，可能得到不同估计；覆盖率研究应说明一个指标把哪些测试、哪些代码行归因于一次贡献，因为看似相近的设计估计的其实是不同的量。最后，目前大多数证据关注的是智能体写了哪些测试，而我们的结果表明，智能体没有更新或删除的测试，对测试套件的演化同样重要。

对开发者。 在我们的数据中，智能体新增的测试与同一项目中开发者写的测试相似，对其所伴随的生产改动的覆盖也没有可检测的差异。主要差异在已有测试上：引入编码智能体的团队，不应假定已有测试的维护会像人工工作那样同步跟上，而可以明确提出要求，比如让智能体检查并更新与其改动代码相关联的测试。评审智能体参与的 PR 时，有两项成本很低的检查：被修改的测试是否仍包含断言；在只新增测试的 PR 中，新测试实际覆盖了被测类的哪些部分。智能体对已有测试的修改是否需要针对坏味道更严格地评审，则取决于 RQ4 估计的稳健性。

对智能体与工具的开发者。 智能体参与 PR 修改或删除测试的可能性更低，这指出了一个具体的设计方向。智能体的指令和脚手架可以把测试维护纳入任务本身，例如先检索与待修改生产方法相关联的已有测试，在编写新测试之前询问这些测试是否需要更新或删除。智能体还可以报告哪些已有测试覆盖了被改动的代码、它们是否已更新，让这种遗漏对评审者可见。坏味道检测和单测试覆盖率在 PR 上计算成本都不高，如果 RQ4 和 RQ5 的差异被证明稳健，两者都可以集成到这类报告中。

4.5 有效性威胁（节译）

• 构念效度。 智能体是否参与是从它留下的痕迹推断的，组合多种信号能降低对单一约定的依赖，但无法穷尽；不留痕迹的智能体使用会被归入人工组。作者特别指出，不能想当然地认为这种误分类只会让估计偏保守，因为是否留痕本身可能与智能体、时期、项目约定和贡献类型相关。另外，有痕迹不代表智能体写了多少、开发者改了多少，“智能体参与”只是一个二元近似。
• 内部效度。 这是观察性研究，报告的是相关而非因果。开发者可能把范围清晰、容易测试或从零开始的任务交给智能体；模型控制了仓库和改动规模，但没有控制任务类型与难度。而且只分析了已合并 PR，结果描述的是经过评审后被项目接受的内容，而非智能体最初的产出。
• 结论效度。 两项坏味道总体增量模型若与另外两项一起做 Holm 校正，p 值（0.024 和 0.046）将不再显著，因此只作参考。不显著不等于等价。
• 外部效度。 研究限定在 Java，结论不应直接外推到其他生态；RQ5 只覆盖能用 Maven 或 Gradle 构建的仓库。要求两组各至少 10 个 PR，使 22,932 个有智能体活动的仓库中只保留了 391 个。结果主要刻画 Codex、Copilot 和 Claude Code 三种智能体，描述的是 2025 年 1 月到 2026 年 4 月这一快速变化阶段，而非稳定状态。

5 结论与未来工作

本文沿五个维度比较了智能体参与 PR 与人工 PR 中的测试：测试的频率与幅度、测试改动的类型与上下文、测试代码结构、测试坏味道和代码覆盖率。在 391 个同时包含两组 PR 的仓库、114,134 个已合并 Java PR 上，我们的所有比较都在仓库内部进行，并控制了贡献规模。

结果支持三个结论。第一，智能体与人工贡献的比较取决于项目：跨仓库混合看，两组改动测试代码的频率几乎没有区别；而在仓库内部，智能体参与 PR 改动测试更频繁，且差异大小在仓库之间变化很大。第二，智能体参与与另一种测试工作组合相关联：更多新增、更少修改和删除已有测试，而新增测试的大多数结构特征和对生产改动的覆盖没有检测到差异。第三，智能体参与是否影响测试质量仍无定论：坏味道差异处在边缘且取决于分析层面，智能体测试在纯测试 PR 中覆盖较低的结论也只基于少数仓库。对开发者而言，这意味着不应假定已有测试的维护会随着智能体参与的工作自然完成，可能需要明确提出。

后续方向包括：对每个项目历史上测试的新增、修改和删除做纵向分析，看单次贡献层面的差异是否会导致测试套件更快膨胀，或把维护负担转移给开发者；对仓库级调节因素建模，解释仓库间的差异；把坏味道增量拆成新引入与被移除两部分，调和两个分析层面的结论；在更多智能体有足够样本的数据集上做分智能体比较；把智能体的初始产出与评审修正区分开，以便把差异归因到智能体、开发者或评审过程；用变异测试（Mutation Testing）检验覆盖率差异能否转化为缺陷发现能力的差异；以及在其他生态和更长时间窗口上复现本研究。

数据集、查询和分析脚本已在作者的复现包中公开（Zenodo，DOI：10.5281/zenodo.21914644）。

译者注

1. 数据怎么读：中位数仓库只有 3 颗星。 样本以小型、年轻的 Java 项目为主，智能体参与 PR 的合并中位时间只有 0.6 小时，很多可能是作者本人在用智能体快速迭代。大型团队、强评审流程下的情况未必相同，论文自己也把“CI 与评审严格程度”列为待研究的调节因素。读结论时，更适合把它当作“风险提示”，而不是“智能体写的测试一定更好或更差”。
2. 落地建议：把“维护旧测试”写进智能体指令。 论文最可操作的结论是：智能体倾向于另起炉灶写新测试，而不去动旧测试。国内团队在使用编码智能体时，可以在仓库的智能体指令文件（如 AGENTS.md、CLAUDE.md 或 IDE 插件的规则文件）里明确要求：“修改生产代码前，先找出覆盖该方法的已有测试，判断是否需要更新或删除，并在 PR 描述中列出”。评审时再加两项轻量检查：修改过的测试是否仍有断言；纯新增测试的 PR 实际覆盖了被测类的哪些分支。
3. 与华为云产品的关系。 这两项检查都适合放进流水线自动执行，而不是靠人工记忆。在华为云上，可以用代码托管 CodeArts Repo 的合并请求评审规则约束智能体 PR，用流水线 CodeArts Pipeline 在合并前运行测试并生成 JaCoCo 覆盖率报告（重点看本次改动行的增量覆盖率），再用代码检查 CodeArts Check 扫描测试代码中的规范问题。对智能体提交占比高的仓库，定期统计“长期未改动但对应生产代码已多次变更”的测试文件，可以及早发现论文担心的“过时测试堆积”。

相关阅读

• 让 AI 编程智能体替你“拆依赖”：Flask 案例研究的五种策略与五条经验：https://bbs.huaweicloud.com/blogs/709270b0c61a40a29d65af75a4a3b480
• gopls 交互式重构上线：结构体标签、接口实现、移动声明都能“先问再改”：https://bbs.huaweicloud.com/blogs/412452f8a1434bb9a01771d1c81ba9bd