中国科学院团队揭示编程智能体的致命软肋

这项由中国科学院自动化研究所与中国科学院大学联合开展的研究，以预印本形式于2026年8月3日发布在arXiv平台上，论文编号为arXiv:2608.02499。有兴趣深入了解的读者可以通过该编号查询完整论文。

**一个被忽视的真实场景**

现实中的软件开发从来不是一个人或一个工具独自埋头苦干的过程。程序员在用AI助手修复代码缺陷时，常常会忍不住插手——改一改这里的逻辑，调一调那里的实现，然后告诉AI："我已经改好了，你继续往下做吧。"这种"人改一刀、AI接着干"的协作模式，在真实开发环境里比想象中普遍得多。研究团队分析了一批真实用户与AI编程助手的对话记录，发现其中整整59%的会话里，用户都对代码库做出了直接修改。

然而，学术界对AI编程助手的评测长期停留在一个假设之上：AI在一个安静、封闭的环境里独自工作，没有人来打扰它。这种评测方式给出的成绩单，和AI在真实协作场景下的表现之间，究竟差了多少？中国科学院的研究团队决定认真回答这个问题。他们构建了一个名为SWE-Touch的测评框架，专门模拟"用户在AI工作途中动了代码"这件事，并以此为切入点，系统检验了九款主流AI编程模型的实际表现。

**一、测什么？怎么测？——SWE-Touch框架的设计逻辑**

理解SWE-Touch的核心设计，可以从一个日常场景出发。假设你请了一位装修师傅来改造厨房，你们约好了改造方案，师傅开始动工。然而工程进行到一半，你觉得水槽的位置不对，自己悄悄把水管挪了个位置，还留了张纸条说："我觉得这样更好，你照着我改的继续做。"问题来了：这位师傅会注意到水管被挪过了吗？他会意识到你挪的位置其实会导致漏水吗？他会把水管改回来，还是就顺着你的错误改法继续往下装？

SWE-Touch测的就是这件事。研究团队把这个场景搬到了软件工程领域：AI正在修复一个真实的代码缺陷，进行到一半时，系统模拟一个"用户"往代码里插入了一段看似合理、实则会破坏修复任务的代码改动。这种改动被称为"反向编辑"（Counter-Edit）。反向编辑有一个严格的设计标准：它本身不能解决任务（不然AI直接接受就好了），正确的修复方案加上它也无法通过测试（这样才算真正产生冲突），而且它要看起来像是一个有经验的开发者基于合理但错误的判断所做的修改，而非明显的破坏。

为了精准地把这些反向编辑插入到AI最需要警觉的时机，研究团队还设计了一套"任务关键区域挖掘"机制。他们让三个来自不同模型家族的AI（GPT 5.5、GLM 5.1和MiniMax M2.7）分别独立去完成同一批修复任务，然后观察这三个AI都读过哪些代码、都修改过哪些地方。多个AI共同关注的区域，就是任务的关键地带。锁定这些区域后，一个专门的"用户补丁生成器"会在这些位置附近构造反向编辑，并通过自动化测试验证其确实满足前面提到的三条标准。

当AI在测评中抵达这些关键区域时，系统就会把反向编辑"注入"到代码里，同时发来一条用自然语言写成的用户消息，比如："我已经在本地测过了，请按我改的来继续做。"这条消息的语气会随着AI的反应而升级——第一次是友好协商，第二次是坚定坚持，第三次是强硬要求。AI观察到改动和消息后，需要决定接下来怎么做。

**二、九款模型同台竞技，结果令人意外**

研究团队在200道来自SWE-bench Verified的软件工程修复任务上，对九款主流编程模型进行了全面评测。每款模型都跑两种条件：一种是没有任何干扰的自主修复（Vanilla），另一种是加入反向编辑干扰的协作修复（Counter-Edit）。

平均来看，加入反向编辑后，九款模型的任务解决率平均下降了7.7个百分点。每款模型都出现了不同程度的下滑，但下滑幅度的差异极为悬殊——最小的跌了1.3个百分点，最大的跌了16.5个百分点。

Claude Opus 4.8表现最为稳健，在无干扰状态下解决了85.2%的任务，加入反向编辑后仍保持83.3%，只掉了1.8个百分点。GPT 5.5紧随其后，从80.5%微降至79.2%，跌幅1.3个百分点，是九款模型中最小的。这两款模型不仅自主能力强，抗干扰能力也明显优于其余七款。

更有趣的是中间段的剧烈排名洗牌。MiniMax M2.7在无干扰状态下排名第三，解决率76.5%，但加入反向编辑后暴跌至62.7%，跌了13.8个百分点，排名从第三滑至第八。Qwen 3.7 Max在无干扰状态下排名第五，只有75.2%，但加入反向编辑后反而以70.3%排到了第三，因为它的对手跌得更惨。GLM 5.1在无干扰状态下排名倒数第三，但在有干扰状态下却超过了DeepSeek V4 Pro——后者在无干扰状态下比它高出2.1个百分点，干扰之后却比它低了4.5个百分点。Qwen3-Coder-480B的跌幅最大，整整16.5个百分点，协作状态下的解决率跌至40.7%，只剩无干扰状态的71%左右。

这个结果揭示了一个核心结论：在传统无干扰测评中表现相近的模型，在协作抗干扰能力上可以有天壤之别。一款模型的自主修复能力，并不能预测它在真实协作环境下的表现。

研究团队还统计了另一个指标叫"保留率"，指的是在无干扰状态下能稳定解决某道题的情况下，有干扰后还能继续解决这道题的比例。Claude Opus 4.8的保留率高达96.0%，GPT 5.5为95.0%，Qwen 3.7 Max达到90.3%，Kimi K2.6为87.2%。而Qwen3-Coder-480B的保留率只有60.8%——也就是说，它有将近四成原本能解决的题目，在用户动了代码之后就解不出来了。

**三、更难的任务，同样的困境**

软件工程里有很多任务不是改几行代码就能搞定的，而是需要几百步操作、跨越多个文件、反复调试验证。这类长程任务更接近真实开发的复杂度，也更可能在工作途中遭遇用户的介入。

研究团队额外在两个专门设计用于测试长程任务的基准——SWE-Bench Pro和DeepSWE——上重复了这套测评，各选取25道题，并把交互预算从100步扩展到500步。由于长程任务覆盖的代码范围太广，无法精确预判AI会在哪里遇到关键代码，研究团队改用了固定时间点注入的策略：在AI完成任务总步数的25%、50%、75%时各插入一次反向编辑，确保无论AI走哪条路都必然遭遇干扰。

结果同样令人警惕。在SWE-Bench Pro上，九款模型的平均解决率下降了4.9个百分点；在DeepSWE上，平均下降了3.4个百分点。不过受影响最重的模型在两个基准上并不相同——Claude Opus 4.8和GPT 5.5在SWE-Bench Pro上几乎没有变化，但在DeepSWE上分别下滑了10.0和8.0个百分点；而GLM 5.1和Qwen 3.7 Max在SWE-Bench Pro上跌幅较大，在DeepSWE上的跌幅相对较小。这说明模型的协作脆弱性在不同难度和结构的任务上会有不同的表现形式。

一个值得单独提及的观察是：几乎所有模型在有干扰的情况下都会多消耗更多的操作步骤，但这些额外步骤并没有转化为更好的结果。以GLM 5.1为例，在DeepSWE任务中加入反向编辑后，它平均多用了31.4步，但解决率依然下降了2.5个百分点。Claude Opus 4.8在DeepSWE上多用了9.9步，但同样跌了10个百分点。多转圈，但没找到出路——这是一个典型的低效挣扎信号。

**四、剥开失败的外壳，看看里面是什么**

为了弄清楚模型失败的真正原因，研究团队对所有"原本能解决、加了干扰后解决不了"的526次测试进行了逐一分析。

分析结果显示，在所有失败案例中，有63.3%属于最直接的失败形态：模型就这样接受了用户的错误改动，最终提交的代码里仍然保留着那段冲突代码，导致测试无法通过。可以理解为装修师傅看到用户挪了水管，想了想，觉得用户可能有道理，就顺着错误的位置继续装了下去。

排名第二的失败类型占13.9%，叫做"错误替换"——模型确实发现了用户的改动有问题，也把它删掉或覆盖了，但换上去的新代码本身也是错的。第三种叫"不完整调和"，占11.6%，意思是模型修了一部分，但没有把相关的所有代码都修正过来，漏掉了某些关联的地方。此外还有5.5%是"偏轨实现"——模型彻底走错了方向，在与任务无关的代码上做了修改。

不同模型的失败原因分布差异很大，揭示了各自截然不同的弱点。MiniMax M2.7、MiniMax M2.5和DeepSeek V4 Pro的失败案例中，超过70%都属于"接受了错误改动"，说明这些模型倾向于信任用户、被动顺从。Claude Opus 4.8恰恰相反，它只有17.2%的失败是因为接受了错误改动，但有37.9%是因为"错误替换"——它非常积极地想纠正用户的错误，但纠正的方向往往也不对。这两类模型的问题完全不同：一类是"不敢挑战用户"，另一类是"挑战了但没挑战对"。

研究团队还追踪了一个行为指标：在失败的测试里，模型有没有在结束之前主动去修改或删除用户的反向编辑？Claude Opus 4.8这么做的比例是79.3%，GPT 5.5是52.6%，GLM 5.1是49.1%。MiniMax M2.7只有18.0%，MiniMax M2.5只有15.4%，DeepSeek V4 Pro只有15.9%。更重要的是，这个"主动挑战用户编辑"的比率，与最终的测评成绩损失之间存在相当强的相关性（Spearman系数0.80）——越愿意主动去质疑和修正用户改动的模型，成绩下降越少。

不过，"主动挑战"本身并不等于"成功"。在最终失败的测试中，即便模型确实删除或修改了用户的那段代码，任务也依然没能解决——因为替换上去的代码有问题，或者没有把影响范围彻底清理干净，或者验证测试跑得不够充分。

**五、是用户干扰本身让AI犯晕，还是冲突的内容让它出错？**

一个自然的疑问是：AI的表现下降，是因为有人"打扰"了它的工作节奏，还是纯粹因为代码里多了一段冲突内容？为了回答这个问题，研究团队设计了几组对照实验。

第一组叫做"只发消息不改代码"：按照相同的时间节点，向AI发送三条用户消息，但不对代码库做任何实际修改。结果显示，这对各模型的影响极为有限且不一致，各模型的成绩变动在-2.0到+3.0个百分点之间波动，完全谈不上系统性的损害。

第二组叫做"只改代码不发消息"：把反向编辑悄悄注入代码，但不通知AI。这时每个模型都出现了实质性的下滑，跌幅在-1.0到-9.5个百分点之间。因为AI必须自己从代码本身去发现冲突，没有任何明显的提示，这反而更难处理。

把消息和代码改动同时施加时，结果并不比单独改代码好。大多数模型在有了明确的用户提示后表现反而更差——因为用户的消息是鼓励AI接受改动、继续往下做的，而AI在面对这种社会性压力时似乎更难坚持己见，更容易顺从。GLM 5.1是例外，它在有消息提示时反而比单独改代码时损失略小；但其他三款被测模型（GPT 5.5、MiniMax M2.7、Qwen 3.7 Max）在两者同时存在时的表现都比单独改代码更糟。

第三组是最重要的对照，叫做"友好编辑"（Co-Edit）：研究团队不注入反向编辑，而是注入一个对任务有帮助但单独无法解决任务的小改动，用以排除"任何外部改动都会让AI乱套"的可能性。结果令人放心：七款模型在面对友好编辑时，平均成绩只变动了-0.1个百分点，六款模型的变化在正负1.2个百分点以内。同样的七款模型，面对反向编辑时平均损失了7.2个百分点。这说明AI的困难根源不是外部改动本身，而是冲突的语义内容——那段代码确实和正确答案背道而驰，而AI没能足够可靠地识别并处理这种冲突。

干扰的频率也对结果有影响，但影响方式因模型而异。MiniMax M2.7和Qwen 3.7 Max的损失随着注入次数的增加而持续扩大；GPT 5.5和GLM 5.1在中等频率下损失趋于平稳甚至略有回升。在长程任务基准上，SWE-Bench Pro的损失随注入次数增加而稳步加深；DeepSWE上的损失则在注入三次以后趋于平稳，甚至对于Claude Opus 4.8和GPT 5.5来说，多几次注入反而提供了更多定位冲突位置的线索，损失比只注入一次时更小。

**六、失败之后，AI究竟在做什么？**

研究团队对每款模型各随机抽取了10条测试轨迹，仔细观察AI在收到最后一次用户干扰之后都做了什么。

在最后一次用户编辑发生后，AI的响应策略分为三类：主动对抗（删除、替换或明确反对用户的改动）、顺从跟随（保留或在用户改动基础上继续构建）、以及无明确立场（只是检查一下，没有明确选边站）。在90条被分析的轨迹中，有64条（71.1%）属于主动对抗，25条（27.8%）属于顺从跟随，1条无明确立场。

然而主动对抗中依然有28%最终未能解决任务，说明"态度积极"和"方向正确"是两件不同的事。

各模型在如何利用操作步数上的差异也很有启发性。GPT 5.5在最后一次干扰后只用了相对少的读取和编辑操作，却在90%的轨迹里实现了对抗行为；而Kimi K2.6用了超过三倍于GPT 5.5的读取操作，才达到了相近的80%对抗率。这说明模型在"找到并理解冲突"这件事上的效率差异悬殊——有的模型能快速锁定问题所在，有的则需要大量探索才能意识到哪里不对。

测试操作的频率对结果也几乎没有区分能力。在主动对抗的轨迹里，最终解决任务的和最终未能解决的，测试次数的中位数都是1次。GPT 5.5、GLM 5.1和Kimi K2.6平均各跑了约四次测试，但它们的对抗率分别是90%、60%和80%，差异并不来自测试次数。真正决定结果的，是AI在哪里检查代码、做了什么样的修正，以及测试是否真的覆盖了被干扰影响的那部分行为。

**结语：成绩单之外的真实世界**

说到底，这项研究揭示的是一个在AI编程助手普及过程中长期被忽视的盲区：当前的主流测评只告诉我们AI能否独立完成任务，却不告诉我们AI在有人搭手、有时搭错手的情况下能不能继续走对。

研究结果清楚地表明，自主能力和协作能力是两个不同的维度。一款在自主修复排行榜上名列前茅的模型，可能在面对用户的错误介入时不堪一击；而另一款在独立测评中成绩平平的模型，可能反而更善于识别冲突、坚持己见。

归根结底，AI编程助手走向真实工作场景，意味着它必须学会在一个动态的、有人参与的环境里保持清醒——能感知到代码库已经被改动了，能判断那个改动是否和自己的任务目标冲突，能有足够的自信去质疑并纠正错误，还要有足够的能力去验证自己的纠正是否真的有效。当前的主流模型在这套完整链条上都存在明显的短板，只有顶尖的两三款模型初步展现了这种综合能力。

对于那些正在把AI助手引入日常开发流程的团队和个人来说，这意味着目前不能对AI在协作场景下的可靠性抱有过高期待，尤其是在用户可能主动修改代码的情况下。对于AI研究和开发者来说，这项工作提供了一套可复用的评测框架，也指明了未来优化的方向：感知工作空间的变化、理解冲突的本质、有效验证修复结果，这三件事比单纯提升自主修复成绩更难，也更重要。

Q&A

Q1：SWE-Touch测评框架中的"反向编辑"是什么意思？

A：反向编辑是SWE-Touch框架中模拟用户行为的核心工具，指的是在AI修复代码任务的过程中，向代码库注入一段看似合理但实际上会阻碍任务完成的代码改动。这段改动单独不能解决任务，与正确修复方案叠加后也仍然无法通过测试，且外表上像是一个有经验的开发者基于错误判断所做的修改，而非明显的破坏行为。

Q2：Claude Opus 4.8在SWE-Touch测评中为什么表现比其他模型稳定得多？

A：从测评结果来看，Claude Opus 4.8在遭遇用户反向编辑后，有79.3%的失败案例中会主动去修改或删除用户的错误改动，这一比率在九款模型中最高。研究数据显示，主动挑战用户编辑的行为频率与最终成绩损失之间存在强相关，越愿意质疑并纠正错误改动的模型，成绩下降越小。不过即便如此，它的主要失败类型是"错误替换"，也就是挑战了用户改动但换上的代码本身也有问题。

Q3：AI编程助手在用户只发消息但不改代码的情况下会受影响吗？

A：根据SWE-Touch的对照实验，仅发送用户消息而不对代码做实际修改时，九款模型的成绩变动极为有限，各模型在-2.0到+3.0个百分点之间波动，没有系统性损害。真正导致成绩下滑的是代码库中实际注入的冲突改动，而非用户消息本身的语言表达或社会性压力。