这项由新加坡管理大学、上海交通大学以及字节跳动联合开展的研究发表于2026年2月，论文编号为arXiv:2602.07900v1，有兴趣深入了解的读者可以通过该编号查询完整论文。
当下，AI编程助手已经成为软件开发者的得力伙伴，就像厨师身边的智能助理一样，它们不仅能帮助修改代码，还能在解决问题的过程中自动编写测试代码。然而，这些AI助手自己写的测试代码真的有用吗，还是只是在模仿人类开发者的习惯，实际上并没有太大帮助？
研究团队注意到一个有趣的现象：在GitHub问题解决的排行榜上，那些频繁编写测试代码的顶级AI助手确实表现出色，但同时，几乎从不编写新测试代码的GPT-5.2模型竟然也能达到相当的问题解决率。这就好比在烹饪比赛中，有些厨师习惯在烹饪过程中反复品尝调味，而另一些厨师几乎不尝试就能做出同样美味的菜肴。这种对比让研究团队产生了疑问：AI助手编写测试代码究竟是真正有助于解决问题，还是只是一种学来的"仪式感"？
为了揭开这个谜团，研究团队设计了一个全面的实验。他们就像行为观察专家一样，仔细分析了六种先进AI模型在解决500个真实GitHub问题时的完整行为轨迹，重点观察这些AI助手是否编写测试、何时编写、以及这些测试到底发挥了什么作用。更进一步，他们还通过改变提示词的方式，分别鼓励某些模型多写测试，或者阻止另一些模型编写测试，以此来直接验证测试代码对最终结果的影响。
一、AI助手的测试编写习惯大揭秘
研究团队首先像动物行为学家观察不同物种的觅食习惯一样，仔细观察了六种AI模型的测试编写行为。这些模型包括排行榜上的明星选手：claude-opus-4.5、gemini-3-pro-preview、gpt-5.2、kimi-k2-thinking、minimax-m2和deepseek-v3.2-reasoner。
结果显示，这些AI助手的测试编写习惯简直天差地别，就像不同性格的人面对同一道数学题会有完全不同的解题习惯。有些AI助手是"测试狂魔"，几乎在每个任务中都要写测试代码。比如minimax-m2和kimi-k2-thinking，它们分别在98.6%和97.4%的任务中都会编写至少一个测试文件，就像那种做任何事都要反复检查的谨慎型人格。
相比之下，gpt-5.2则是另一个极端，它在500个任务中只写了3次测试代码，写测试的概率仅为0.6%，简直可以说是"测试绝缘体"。然而令人惊讶的是，这个几乎不写测试的模型却能解决71.8%的问题，仅比测试狂魔claude-opus-4.5的74.4%低了2.6个百分点。这就好比在考试中，有些学生习惯反复检查答案，而另一些学生直接提交，但最终成绩却相差无几。
更有趣的发现是，即使在同一个模型内部，成功解决问题和未能解决问题的情况下，测试编写频率也相当接近。这意味着写测试和解决问题的成功率之间并没有明显的因果关系，就像戴帽子和天气好坏之间可能只是巧合一样。
研究团队还发现，当AI助手确实编写测试时，它们的时间安排也各有特色。大多数模型喜欢在任务后期编写测试，就像学生在考试最后阶段才开始检查答案。而在测试编写的分布上，那些未能成功解决问题的情况往往会将测试编写分散在更长的时间段内，并且更频繁地重复运行测试，这有点像焦虑的学生会反复检查同一道题目。
二、测试代码里到底藏着什么秘密
深入分析这些AI助手编写的测试代码内容后，研究团队发现了一个颠覆常识的现象：这些测试代码的主要作用并不是严格的验证，而更像是"观察窗口"。
在传统的软件测试中，我们期望看到大量的断言语句，就像法官在法庭上做出的明确判决一样——要么对，要么错，没有中间地带。但AI助手编写的测试代码却大不相同，它们更像是好奇的观察者，主要通过打印语句来"窥探"程序运行时的内部状态。
具体来说，在所有模型中，打印语句（用于显示变量值或程序运行结果）的数量都远远超过断言语句（用于验证程序是否按预期工作）。这种比例差异相当显著，就好比在一次调查中，大部分时间都用来收集信息和观察现象，而很少时间用来下结论和做判断。
以claude-opus-4.5为例，平均每个任务会产生25个打印语句，但只有5.16个断言语句。这个比例在所有模型中都相当一致，表明AI助手更倾向于通过"看一看"来理解程序的行为，而不是通过"验证一下"来确保程序的正确性。这就像医生在诊断疾病时，更多时间用于观察症状和收集信息，而较少时间用于下最终诊断。
更进一步分析断言语句的类型时，研究团队发现了另一个有趣的模式。AI助手编写的断言主要集中在两种类型上：一种是检查局部属性（比如确认某个对象确实存在），另一种是检查精确值（比如确认计算结果等于预期的具体数字）。相比之下，那些检查范围或关系的复杂断言却非常少见，就像学生在自我检查时，更多关注"答案是不是123"这样的简单验证，而很少去验证"答案是否在100到200之间"这样的复杂条件。
这种模式揭示了AI助手测试策略的本质：它们更像是在进行"探索性调试"而不是"系统性验证"。这种方法确实有其合理性，因为在解决未知问题的过程中，了解程序的实际行为往往比验证预期结果更重要，就像探险家在未知领域更需要观察和记录，而不是急于下结论。
三、改变测试习惯会带来什么结果
为了直接验证测试代码编写对问题解决效果的影响，研究团队设计了一个巧妙的对照实验。他们通过修改提示词的方式，人为地影响AI助手的测试编写行为，就像通过改变指导语来观察学生学习行为变化一样。
实验设计分为两个方向。对于那些原本很少写测试的模型（如gpt-5.2和gemini-3-pro-preview），研究团队在提示词中明确鼓励它们编写测试文件。相反，对于那些原本热衷于写测试的模型（如kimi-k2-thinking和deepseek-v3.2-reasoner），研究团队则在提示词中建议它们避免编写新的测试文件，转而依靠推理和代码审查来保证质量。
实验结果令人意外。当研究团队成功地让gpt-5.2在64.4%的任务中开始编写测试代码时，它的问题解决成功率几乎没有变化，仍然保持在71.8%左右。这就好比让一个原本不做笔记的学生开始做详细笔记，但考试成绩却没有明显提升。
更有趣的是反向实验的结果。当研究团队阻止那些"测试狂魔"编写测试时，虽然成功地让kimi-k2-thinking在68.4%的任务中停止了测试编写，让deepseek-v3.2-reasoner在75.2%的任务中放弃了测试，但这些模型的成功率只出现了很小的下降，分别从63.4%降到60.8%，从60.0%降到58.2%。
换句话说，即使大幅改变AI助手的测试编写行为，对最终的问题解决效果影响都相当有限。在所有实验中，平均有83.2%的任务在改变测试策略后，其成功或失败的结果都保持不变，就像改变学习方式后，大部分学生的考试结果并没有发生根本性变化。
四、测试代码的真正代价是什么
虽然测试代码对问题解决效果的影响有限，但它们对资源消耗的影响却相当显著，就像给汽车加装各种检测设备可能不会显著提高行驶安全，但肯定会增加油耗一样。
当研究团队鼓励gpt-5.2编写更多测试时，虽然问题解决率没有提升，但资源消耗却明显增加了。API调用次数增加了5.5%，输出token数量增加了19.8%，输入token数量也增加了9.0%。这就像让一个原本简洁工作的人开始写详细的工作日志，虽然工作质量没有提升，但时间和精力的投入却大幅增加。
相反，当研究团队阻止那些热衷于测试的模型编写测试时，资源节省的效果非常显著。kimi-k2-thinking的输入token使用量减少了49.0%，API调用次数减少了35.4%；deepseek-v3.2-reasoner的输入token使用量减少了32.9%，API调用次数减少了24.5%。这种节省幅度相当惊人，就像让一个过度谨慎的司机改变驾驶习惯后，油耗立即大幅下降。
更重要的是，这种大幅的资源节省只伴随着很小的成功率下降。这意味着在许多情况下，AI助手花费在测试编写上的大量资源可能并没有带来相应的回报，就像在餐厅里花费大量时间精心摆盘可能并不会显著提升食物的味道，但确实会增加制作成本和时间。
这个发现对于实际应用具有重要意义。在资源有限的情况下，过度的测试编写可能会消耗宝贵的token额度，而这些额度本可以用于更核心的问题分析和解决方案开发。这就像在时间有限的考试中，过度检查某几道题目可能会挤占解答其他题目的时间，最终影响整体表现。
五、这些发现意味着什么
研究团队的发现揭示了一个颇为反直觉的现象：在AI助手的世界里，测试代码更像是一种"工作风格"而不是"效率工具"。就像有些人习惯在做决定前反复权衡，而另一些人更倾向于快速决策，这两种风格可能都能达到相似的结果，关键在于匹配合适的场景。
这种现象的根本原因可能在于AI助手编写的测试代码与传统软件开发中的测试有着本质不同。传统测试通常基于明确的规格说明和预期行为，就像按照标准食谱检验菜品是否合格。但AI助手在解决GitHub问题时，往往面临的是规格不明确、预期行为不清晰的情况，此时测试更像是探索性的"试探"而非验证性的"检查"。
从实用角度来看，这个发现为AI助手的优化使用提供了重要指导。对于那些资源受限或追求效率的应用场景，适度减少测试编写可能是一个明智的选择，就像在紧急情况下，医生可能需要更多依靠经验和直觉，而不是完成所有标准检查程序。
同时，这个研究也提醒我们，AI助手的行为模式往往反映了训练数据中的人类习惯，而这些习惯在新的应用场景中未必都是最优的。就像人类在新环境中需要调整原有的行为模式一样，AI助手的使用策略也需要根据具体需求进行优化。
研究团队的工作还为未来的AI助手开发指明了方向。与其简单地模仿人类开发者的所有习惯，更好的approach可能是让AI助手学会根据具体情况动态调整其工作策略，包括何时编写测试、编写什么类型的测试、以及如何在探索和验证之间找到平衡。
说到底，这项研究告诉我们，在AI助手快速发展的今天，我们需要更加理性地看待这些工具的行为模式。不是所有看起来"专业"的行为都必然带来更好的结果，有时候简洁和高效可能比复杂和全面更有价值。就像在现实生活中，最好的解决方案往往不是最复杂的那个，而是最适合具体情况的那个。对于使用AI助手的开发者来说，理解这一点可能比盲目追求"最佳实践"更重要。
Q&A
Q1：为什么AI编程助手编写的测试代码对解决问题效果有限？
A：研究发现AI助手编写的测试代码主要用于观察程序运行状态，而不是严格验证程序正确性。这些测试中打印语句远多于断言语句，更像探索性调试而非系统性验证。而且即使大幅改变测试编写习惯，问题解决成功率变化也很小，平均83.2%的任务结果保持不变。
Q2：不同AI模型在编写测试代码方面有什么差异？
A：AI模型的测试编写习惯差异巨大。minimax-m2和kimi-k2-thinking在98.6%和97.4%的任务中都会编写测试，像"测试狂魔"；而gpt-5.2几乎从不写测试，500个任务中只写了3次。但有趣的是，gpt-5.2的问题解决率(71.8%)与测试频繁的claude-opus-4.5(74.4%)相差无几。
Q3：编写测试代码会带来什么额外成本？
A：测试编写虽然对解决效果影响有限，但会显著增加资源消耗。鼓励gpt-5.2写测试后，API调用增加5.5%，输出token增加19.8%。相反，阻止高频测试模型写测试能大幅节省资源，kimi-k2-thinking的输入token减少49.0%，API调用减少35.4%，但成功率仅下降2.6%。
热门跟贴