在软件开发领域，程序员与AI编程助手的协作正成为常态。当程序员使用AI工具修复代码缺陷时，往往会主动介入修改——调整逻辑、优化实现，随后告知AI继续后续工作。这种“人机交替”的协作模式在真实开发场景中极为普遍。然而，学术界对AI编程助手的评估长期停留在“独立封闭环境”的假设下，即AI在无干扰状态下完成任务。这种评估方式与实际协作场景的差距究竟有多大？中国科学院自动化研究所与国科大的研究团队通过构建SWE-Touch测评框架，系统检验了九款主流AI编程模型在真实协作场景中的表现。
研究团队的核心创新在于模拟“用户中途修改代码”的场景。他们设计了一种名为“反向编辑”的干扰机制：在AI修复代码的过程中，系统会注入一段看似合理但实际会破坏修复任务的代码改动。这种改动需满足三个条件：单独无法解决问题、与正确方案叠加后仍无法通过测试、外观上像经验开发者基于错误判断的修改。为精准定位干扰时机，团队开发了“任务关键区域挖掘”算法，通过分析多个AI模型共同关注的代码区域，锁定最可能影响修复任务的关键位置，并在此处注入反向编辑。
在200道来自SWE-bench Verified的真实修复任务中，九款模型在两种条件下接受测试：无干扰的自主修复（Vanilla）与加入反向编辑的协作修复（Counter-Edit）。结果显示，反向编辑使模型平均任务解决率下降7.7个百分点，但不同模型的抗干扰能力差异显著。Claude Opus 4.8表现最为稳健，解决率仅下降1.8个百分点；GPT 5.5紧随其后，下降1.3个百分点。而Qwen3-Coder-480B跌幅最大，达16.5个百分点，协作状态下解决率跌至40.7%。“保留率”指标（无干扰时能解决的任务在干扰后仍能解决的比例）进一步印证了这一差异：Claude Opus 4.8保留率高达96.0%，而Qwen3-Coder-480B仅为60.8%。
长程任务测试揭示了更复杂的挑战。在需要数百步操作、跨越多个文件的复杂任务中，研究团队在AI完成总步数的25%、50%、75%时注入反向编辑。结果显示，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上跌幅较大。一个值得关注的现象是，所有模型在干扰下均增加了操作步骤，但额外步骤并未转化为更高解决率。例如，GLM 5.1在DeepSWE任务中多用了31.4步，解决率反而下降2.5个百分点。
对526次失败案例的深入分析揭示了模型崩溃的四种主要模式：63.3%的失败源于模型直接接受用户错误改动；13.9%属于“错误替换”（模型发现改动问题但替换代码仍错误）；11.6%为“不完整调和”（仅修正部分关联代码）；5.5%是“偏轨实现”（彻底修改无关代码）。不同模型的弱点差异显著：MiniMax M2.7等模型超过70%的失败源于被动接受错误改动，而Claude Opus 4.8的失败主要来自“错误替换”。进一步追踪发现，模型主动修改用户反向编辑的比例与成绩损失强相关——Claude Opus 4.8的主动挑战比例达79.3%，GPT 5.5为52.6%，而MiniMax M2.7仅18.0%。
通过分析模型在干扰后的操作轨迹，研究团队发现，71.1%的模型选择主动对抗用户改动（删除、替换或反对），27.8%选择顺从跟随，仅1条轨迹无明确立场。然而，主动对抗中仍有28%未能解决问题，凸显“方向正确”比“态度积极”更重要。不同模型在操作效率上的差异同样显著：GPT 5.5仅用少量操作即实现90%的对抗率，而Kimi K2.6需三倍操作才能达到80%对抗率。测试次数与结果无显著关联——无论测试1次还是4次，对抗轨迹的解决率均未显著提升，关键在于AI能否精准定位冲突并实施有效修正。
