这项由中国科学院自动化研究所与中国科学院大学联合开展的研究以预印本形式于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最需要警觉的时机研究团队还设计了一套任务关键区域挖掘机制。他们让三个来自不同模型家族的AIGPT 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研究和开发者来说这项工作提供了一套可复用的评测框架也指明了未来优化的方向感知工作空间的变化、理解冲突的本质、有效验证修复结果这三件事比单纯提升自主修复成绩更难也更重要。---QAQ1SWE-Touch测评框架中的反向编辑是什么意思A反向编辑是SWE-Touch框架中模拟用户行为的核心工具指的是在AI修复代码任务的过程中向代码库注入一段看似合理但实际上会阻碍任务完成的代码改动。这段改动单独不能解决任务与正确修复方案叠加后也仍然无法通过测试且外表上像是一个有经验的开发者基于错误判断所做的修改而非明显的破坏行为。Q2Claude Opus 4.8在SWE-Touch测评中为什么表现比其他模型稳定得多A从测评结果来看Claude Opus 4.8在遭遇用户反向编辑后有79.3%的失败案例中会主动去修改或删除用户的错误改动这一比率在九款模型中最高。研究数据显示主动挑战用户编辑的行为频率与最终成绩损失之间存在强相关越愿意质疑并纠正错误改动的模型成绩下降越小。不过即便如此它的主要失败类型是错误替换也就是挑战了用户改动但换上的代码本身也有问题。Q3AI编程助手在用户只发消息但不改代码的情况下会受影响吗A根据SWE-Touch的对照实验仅发送用户消息而不对代码做实际修改时九款模型的成绩变动极为有限各模型在-2.0到3.0个百分点之间波动没有系统性损害。真正导致成绩下滑的是代码库中实际注入的冲突改动而非用户消息本身的语言表达或社会性压力。