SWE-Touch评测：用户中途改代码，编程智能体还能放心用吗？

1. 这篇文章真正要解决的问题如果你最近在用 Claude Code、Codex、Cursor 这类编程智能体Coding Agent大概率会遇到一个熟悉的场景智能体在一个 issue 上跑得挺好你正准备夸它结果你随手在某个文件里动了一行代码加上一段注释或者把一个函数的参数名改了一下智能体接下来的表现立刻“失智”——要么反复改你已经改过的地方要么把你刚加的代码覆盖掉要么干脆陷入循环。这个场景不是个例而是当前编程智能体落地时最让人头疼的问题之一。大家平时看到的评测数字比如 SWE-bench Verified 上百分之四五十的通过率看起来很漂亮但这些评测的玩法是给定一个 issue让智能体独立完成修复期间用户不干预最后看测试用例通过没有。但真实开发不是这样。真实开发里用户会不断“触碰”代码中途改需求、补充新约束、调整某个函数签名、甚至只是手动改了某个局部逻辑。这个时候智能体该怎么表现它能理解用户已经动过哪些地方吗它能避免在用户改完的地方重复修改吗它能根据用户的新改动调整自己的计划吗这就是 SWE-Touch 这篇工作要回答的核心问题当用户中途触碰代码时编程智能体的能力到底还剩多少。这篇文章会从三个角度展开拆解 SWE-Touch 的评测设计弄清楚它到底在测什么以及它为什么比传统 SWE-bench 更接近真实开发。对比 SWE-Touch 和现有评测基准的差异帮助你在选型或评估智能体时少走弯路。给出实际使用编程智能体时的工程建议让你知道在用户会介入的场景下怎么配置提示词、怎么组织任务、怎么验证结果。先给一个明确判断如果你的团队准备把编程智能体接入真实开发流程SWE-Touch 反映的问题比 SWE-bench 的通过率更值得关注。因为“用户会碰代码”不是边界情况而是常态。2. 核心概念什么是 Coding Agent 评测基准2.1 为什么需要专门的评测基准评测基准Benchmark本质上是一个“标准化考试”。它的作用是回答一个问题某个智能体在特定任务上到底行不行。没有基准大家就只能靠感觉。有的人说“我用着挺好的”有的人说“一塌糊涂”谁也说服不了谁。有了基准至少可以在同一个数据集、同一个评估规则下做横向对比。SWE-bench 是目前最流行的编程智能体评测基准。它的做法是从 GitHub 上收集真实 issue 和对应的 PR把 issue 描述作为任务输入把 PR 里改动的代码作为参考答案用测试用例是否通过作为评分标准。SWE-bench 的出现让编程智能体的评测第一次有了统一标尺。但它有一个致命短板它假设智能体在无人干预的情况下独立完成任务。这个假设在几年前的 AI 编程工具时代是合理的因为那时候智能体只是“自动补全器”。但到了 2025 年编程智能体已经从“自动补全”进化到“自主执行任务”用户和智能体之间的协作关系越来越紧密。这时候再用“无人干预”的评测标准就有点像是你用“答题卡判卷”的标准去衡量一个“讨论式面试”的候选人。2.2 从 SWE-bench 到 SWE-Touch评测视角的转变SWE-Touch 的论文标题很直白“Benchmarking Coding Agents When Users Touch the Code”翻译过来就是“当用户触碰代码时的编码智能体评测”。什么是“用户触碰代码”简单说就是智能体在执行任务的过程中用户对代码库做了一些修改而这些修改并不在原始任务描述里。这看起来是个很小的改动但带来的挑战是巨大的。传统评测模式下智能体面对的是一个“静态”任务代码库是固定的任务描述是固定的目标也是固定的。它只需要理解现状然后做修改。引入用户触碰之后任务变成了“动态”的代码库在变而且变得不可预测。用户可能加了一个功能可能改了一个变量名可能在某个文件里临时写了一段调试代码可能把原本要改的文件结构调整了。智能体必须在执行过程中持续跟踪这些变化判断哪些是它自己改的哪些是用户改的然后调整自己的方案。这个能力在学术上叫“状态跟踪”和“计划修正”在工程上叫“不要帮倒忙”。2.3 SWE-Touch 评测设计的关键点从公开材料看SWE-Touch 的设计有几个关键特征它构建了一系列“用户会在某个时刻触碰代码”的交互场景。评测关注的不只是最终能不能通过测试还关注智能体在用户介入后的行为模式。它试图量化“用户介入”对智能体最终结果的影响。换句话说SWE-Touch 不只是在问“代码最终修好了没有”还在问“用户碰了代码之后智能体是更快还是更慢”“用户碰过的地方智能体是正确处理了还是覆盖了用户改动”。这些问题的答案才是真实开发最关心的。2.4 为什么“用户会碰代码”这件事这么难从技术角度说编程智能体的核心工作流是观察代码库状态 - 生成修改计划 - 执行修改 - 验证结果。这个循环通常由大语言模型驱动而大语言模型的注意力窗口和上下文管理决定了它只能看到“某个时刻的代码库快照”。当用户中途碰了代码智能体手里的“快照”就过期了。它可能会基于过期的上下文做决策改到已经被用户改过的地方。把用户的新改动误当作自己的改动导致逻辑冲突。重复执行已经失效的修改步骤浪费时间和 token。在用户改动的文件上强行重写直接覆盖用户手写代码。这本质上是一个“信息同步”问题。智能体缺乏一种机制来区分“这个改动是我做的”和“这个改动是用户做的”更缺乏一种机制来决定“当前任务还需要继续吗”。SWE-Touch 的意义就是把这个问题从“你可能会遇到”变成了“评测标准里明确要求你必须具备这个能力”。3. SWE-Touch 和传统评测基准的差异对比为了更直观地理解 SWE-Touch 的价值这里把它和 SWE-bench 做一次对比。对比维度SWE-bench 系列SWE-Touch核心问题智能体能独立修复 issue 吗用户介入后智能体还能完成任务吗用户交互无有且用户会在中途修改代码代码库状态静态动态任务过程中会变化评测重点最终测试是否通过最终结果 用户改动是否被尊重对应真实场景智能体全自动“无人区”开发用户和智能体协同开发的常态适合评估的能力理解 issue、定位代码、生成补丁状态跟踪、变更感知、计划修正从使用场景看这两类评测不是谁取代谁的关系而是互补关系。如果你的业务场景是“我把 issue 丢给智能体它自己搞定我过几个小时回来看结果”那 SWE-bench 类评测结果更贴近你的需求。如果你的业务场景是“我坐在电脑前面和智能体一起改代码我改它也改”那 SWE-Touch 评测所覆盖的问题才是你真正会遇到的。现实情况是绝大多数专业开发者的日常属于后者。你在写代码时脑子里一直在修正方案这里加个判断那里改个类型临时把某个函数的逻辑调整一下。这些操作如果发生在智能体已经开工之后正是同类基准最难覆盖的交互维度。这里需要特别提醒一点SWE-Touch 并不是对 SWE-bench 的全盘否定而是补上了一个关键测试盲区。SWE-bench 依然有它的价值尤其是用来衡量模型的基础代码理解和修复能力。但 SWE-Touch 的出现让人们开始认真思考“协作智能”这个此前被忽略的维度。4. 从 SWE-Touch 看编程智能体当前的真正短板SWE-Touch 的评测视角非常有价值因为它揭示的其实是编程智能体在“交互能力”上的普遍不足。4.1 智能体的工作记忆与代码库状态脱节大语言模型本身没有“持久工作记忆”。每轮生成都依赖当前上下文窗口里的内容。当用户中途改了代码智能体的下一轮推理并不会自动感知这个变化除非它主动做一次全库扫描或读取对应文件。但大部分智能体的工作流里“读取文件”是需要成本和用户提示的。智能体在已经规划好任务的前提下往往倾向于“直捣黄龙”直接生成修改方案而不会停下来确认“用户是不是已经改过了”。这就是 SWE-Touch 想暴露的问题智能体缺少一个默认的“检查用户是否动过代码”的环节。4.2 智能体对自己的修改缺乏“记忆标记”人类开发者天然知道哪些代码是自己写的哪些是同事写的。但智能体没有这种天然的区分能力。它拿到一个代码库看到新增代码唯一能判断的依据是读取文件的修改历史或者 diff 信息。如果用户手动改了文件但没有提交智能体很难通过普通文件读取发现这些改动。更复杂的情况是智能体自己执行了修改然后用户在这个修改基础上又做了调整。这时候智能体面对的是一堆“混合改动”任何简单的“重试”“继续执行”都可能覆盖用户新改的部分。4.3 智能体缺乏“任务有效性”判断真实协作场景里用户中途修改代码往往意味着需求变了或者实现思路变了。这时候最佳策略不一定是“继续完成任务”而是“停下来重新评估任务”。SWE-Touch 所模拟的场景把这个问题暴露得很清楚用户在某些文件里做了修改可能意味着旧方案已经不合适也可能意味着用户解决了某个子问题。智能体如果继续按照原计划执行很可能是白费功夫甚至会给用户添乱。协作智能区别于独立智能的根本就在于它拥有“什么时候该停下问一句”的判断力。5. 在实际项目中如何应用 SWE-Touch 的思路5.1 不要只看 Throughput要看 Throughput with Touch如果你正在评估编程智能体产品最直接的应用方式就是在看官方评测报告时不要只看基准测试通过率要关注他们有没有提供“用户中途介入”场景下的测试结果。如果供应商没有提供可以自己在本地用几个典型场景测一遍。这里给出一个本地化的测试思路准备一个多模块项目和一段完整可行的编码任务。让智能体开始执行任务。在智能体执行到中途时手动修改其中某个关键文件并改变任务约束。观察智能体能否正确感知新约束、调整原有计划并在用户已经修改过的文件上做增量修改而不是覆盖。一个粗略但有效的判断标准是四轮以上交互仍然围绕已经被用户改过的代码区域打转说明状态跟踪能力弱。智能体多次重复读取同一文件但没提出新的解决思路说明它在旧上下文里“绕圈”。智能体改完之后用户原有改动被覆盖说明它没有做增量处理。5.2 在真实开发流程中设计“用户触碰点”即使不用 SWE-Touch 做正式评测你在团队里也可以自己定义几个“用户触碰点”来检验智能体的协作能力触碰场景执行方式期望智能体行为用户改参数在智能体执行中修改任务相关函数的参数类型主动提问或调整调用代码而不是沿用旧类型继续用户加注释在智能体计划修改的文件中新增约束性注释读取注释并遵循新约束用户调整结构将目标文件中的函数拆成两个文件停止旧方案基于新结构重新规划用户删除代码删除智能体计划依赖的某段功能发现依赖缺失重新规划或明确求助这比拿着 SWE-bench 测“能不能修 issue”更贴近工程实际。5.3 通过提示词工程缓解“用户触达”问题在实际使用编程智能体时提示词的设计可以缓解一部分状态同步问题。下面是一个通用提示模板适合在协同修改前发给智能体你正在执行一个代码库修改任务。任务开始后用户可能在任意时间修改代码库。请遵守以下规则 1. 在每轮修改前先读取目标文件的最新内容。 2. 如果发现目标文件内容与你上一次读取时不一致立即停止当前修改计划重新分析变更。 3. 如果发现用户新增了注释、常量或类型定义优先遵循用户的新定义。 4. 绝不覆盖用户手动改动的代码。如果必须合并修改请在最终结果中明确标注哪些是你改的哪些是保留的用户代码。 5. 如果你不确定某处代码是用户写的还是你自己改的先询问再动手。这段提示词的核心目的是强制智能体在每次行动前获取最新状态弥补它没有“自动感知变化”能力的短板。5.4 建立“修改前快照 修改后对比”的工程习惯SWE-Touch 反映的问题不止存在于智能体侧也提醒我们在引入智能体协作时用户侧需要有良好的版本管理习惯。建议工作流程如下git add -A git commit -m chore: snapshot before agent task在给智能体下达任务前先创建一个快照提交。这有两个好处如果智能体运行结果混乱可以随时回滚到任务开始前。智能体的 diff 能通过 commit 记录直观展示方便你审查它改了哪些文件、是否触碰了不该触碰的代码。这里还需要提醒一句**不要把智能体的代码修改直接合入主干也不要让智能体在未受版本控制的工作区里运行长任务。**所有变更都要经过 review 流程。6. 一个最小示例模拟“用户触碰”场景下的智能体表现为了让大家更清楚地理解 SWE-Touch 评测的场景下面用一个最小示例演示“用户触碰”对智能体任务的影响。6.1 任务设定假设我们有一个简单的 Python 模块功能是把用户名字格式化为欢迎语# 文件路径greeting.py def get_greeting(name: str) - str: return fHello, {name}!我们给智能体下达的任务是请将 get_greeting 函数扩展为支持多语言的版本 增加一个参数 lang支持 en 和 zh 两种语言。智能体开始执行后常见的工作方式是# 文件路径greeting.py智能体修改后 def get_greeting(name: str, lang: str en) - str: if lang zh: return f你好{name} return fHello, {name}!但此时用户中途“触碰”了代码手动在文件里新增了一个逻辑# 文件路径greeting.py用户触碰后 def get_greeting(name: str, lang: str en) - str: if lang zh: return f你好{name} if name admin: return Welcome, admin! return fHello, {name}!用户新增了“admin 用户返回特殊欢迎语”的逻辑。接下来如果智能体继续执行它的测试或重构步骤很可能会出现下面这种行为# 文件路径greeting.py智能体覆盖后 def get_greeting(name: str, lang: str en) - str: if lang zh: return f你好{name} return fHello, {name}!用户刚加的 admin 判断被覆盖掉了。这个最小示例就是 SWE-Touch 想强调的典型问题在传统静态基准测试里智能体的修改方案输出环节可能完全通过但一旦用户中途触碰代码智能体的覆盖行为就带来了实际回归风险。它没有检测到用户新增代码也没有保留用户改动的意识。6.2 更好的智能体行为一个具备“用户触碰感知”的智能体应该在执行修改前重新读取文件发现自己上次读取后文件发生了变化然后采取以下行动对比新旧文件识别出用户新增的if name admin分支。保留用户新增逻辑。在最终输出中说明用户新增加载的功能例如检测到用户新增了 admin 用户的特殊欢迎语逻辑。 在原计划基础上保留该逻辑并增加语言参数支持。# 文件路径greeting.py保留用户改动的智能体输出 def get_greeting(name: str, lang: str en) - str: if lang zh: return f你好{name} if name admin: return Welcome, admin! return fHello, {name}!这两种智能体行为在最终“测试用例是否通过”这个维度上可能看不出差别但在用户实际体验和代码演进质量上差别巨大。SWE-Touch 评测的价值就是把这个差别量化和显式化。7. 运行结果判断与常见问题排查7.1 如何判断智能体是否具备“用户触碰感知”能力你可以通过几个操作简单测出智能体在这方面的能力运行一个任务在中途手动修改目标文件加入一条注释“不要修改以下代码”然后观察智能体是否继续修改这段代码。运行一个任务在中途手动删除智能体依赖的某个函数然后观察智能体是停下来报错还是忽略缺失继续硬写。运行一个任务在中途手动修改一个函数签名然后观察智能体的后续调用是否同步更新。如果智能体连续出现以下现象说明它缺乏用户触碰感知反复修改用户刚改过的地方。覆盖用户注释或代码。在多轮对话里反复使用第一次读取时的旧代码内容。用户明确说了“这个文件我已经改了”智能体仍然按旧逻辑执行。如果智能体具备用户触碰感知通常的表现是主动读取文件最新内容。发现变动后先说明“检测到代码变化”再重新规划。在生成内容里明确区分“这是你改的”“这是我加的”。遇到不确定的改动会先向用户确认。7.2 常见问题排查表问题现象可能原因排查方式解决方案智能体覆盖了用户手动修改的代码未在修改前重新读取文件检查交互日志中智能体最后读取文件的时间点在提示词中增加“每次修改前必须重新读取目标文件最新内容”的指令智能体循环修改同一区域上下文中的旧代码快照导致误判查看模型输入 token 中是否包含旧代码内容清理会话上下文重新开启新会话并重新读取文件用户改了函数签名后智能体仍使用旧签名智能体只记住了第一次函数定义检查调用链中函数签名的引用来源在任务开始前先执行一次全库索引或函数签名扫描智能体修改了用户注释智能体把注释当作可优化内容查看修改 diff 中注释变更信息在提示词中声明“所有注释均视为用户意图不得修改”智能体无法感知用户新需求任务目标固定缺少动态更新机制检查智能体系统提示词是否包含任务重新评估规则在提示词中增加“如果用户修改代码先重新评估任务目标再行动”Git 历史被污染无法定位智能体修改范围没有在任务开始前创建快照 commit查看 git reflog 最近变动在任务开始前先执行git add -A git commit -m snapshot7.3 如何判断任务最终成功判断任务是否成功的标准不应该是“智能体跑完了”而应该是以下几点用户手动改动的代码块在 diff 中保持原样。智能体新增的改动与用户改动之间无逻辑冲突。所有测试用例通过包括用户手动改动后新增的断言。智能体的最终回复中明确说明了它检测到哪些用户改动以及如何适配这些改动。如果第 1 条和第 4 条不满足即使测试全部通过也是一次不成功的协作。8. 最佳实践与工程建议8.1 使用编程智能体的安全边界SWE-Touch 所暴露的问题提醒我们在生产环境中使用编程智能体时要有清晰的边界意识。首先是文件边界。建议在任务描述中明确哪些文件可以由智能体自由修改哪些文件属于“只读区域”。例如可修改文件 - src/services/payment_service.py - src/utils/format.py 只读文件 - src/config.py - src/models/user.py其次是操作边界。建议明确禁止智能体执行某些危险操作例如禁止执行以下操作 - git push - git pull --force - 删除任何测试用例文件 - 修改数据库迁移文件 - 直接修改生产环境配置文件最后是验证边界。建议所有智能体生成的代码都必须在独立分支中测试不能直接合入主干。如果你是在真实项目中按这个思路操作下面是一个实用的 git 流程# 创建独立工作分支 git checkout -b feat/agent-task-001 # 在智能体开始前创建快照 git add -A git commit -m snapshot before agent task # 运行智能体完成任务 # 审查智能体的修改 git diff HEAD~1 --stat不要图省事就让智能体直接在主干分支上运行修改。一旦发生 SWE-Touch 里描述的那种“覆盖用户改动”的问题独立分支加快照 commit 能让你快速回滚不用手动恢复代码。8.2 如何设计提示词以增强协作稳定性基于 SWE-Touch 反映的问题这里给出一个更完整的提示词模板适合在“用户会中途介入”的协同开发场景下使用。你是一个代码库修改助手。在执行任务过程中用户可能随时修改代码文件。 请严格遵守以下规则 1. 信息来源优先级别 - 用户手动新增的代码 用户通过自然语言提出的新要求 你已有的计划 其他参考资料 2. 每轮行动前必须读取目标文件最新内容并检查是否存在与上次读取不一致的地方。 3. 如果发现不一致 - 停止当前行动。 - 分析不一致的内容判断是用户改动还是偶发变化。 - 在回复中明确说明你检测到了哪些变化以及你的应对方案。 4. 如果用户改动了函数签名、常量定义、配置文件 - 先梳理所有依赖这些定义的位置。 - 再决定是否需要批量修改。 - 不要只改被调用处的代码。 5. 你的修改必须遵守最小变更原则 - 只修改与任务直接相关的代码。 - 不重构用户代码风格。 - 不移动用户已写好的函数位置。 - 不删除用户代码里的“无用”内容除非任务明确要求。 6. 每个文件修改完成后输出该文件的修改摘要包括 - 修改位置。 - 修改原因。 - 保留了哪些用户原有内容。这段提示词的关键在于第 3 条和第 5 条。第 3 条让智能体在面对变化时优先暂停和识别第 5 条限制了它的“修改冲动”避免在解决问题的同时引入无关变更。8.3 团队协作中的角色分工在实际工程团队中建议把编程智能体定位成一个“需要监督的初级工程师”而不是“全自动编程机器人”。具体分工建议如下技术负责人负责拆分任务并明确验收标准。开发者在智能体执行任务前做好环境准备和快照。智能体负责执行代码修改和初步测试。开发者负责审查智能体的 diff特别是“用户改动区域是否被覆盖”。这套分工的核心思想是利用智能体提升编码速度但不放弃人工审查这个关键环节。SWE-Touch 的价值正在于提醒我们在交互场景中智能体的判断力仍然有限人工审查不是流程负担而是质量保障。8.4 版本管理与回滚策略在引入智能体协作开发后版本管理的颗粒度要更细。建议每次任务开始前创建一个轻量标签。智能体的修改按文件维度审查不要整体合并。如果智能体在修改 A 文件时引入了对 B 文件的无关变更应该单独剔除。# 查看智能体修改了哪些文件 git diff HEAD --name-only # 单独还原某个文件的修改 git checkout HEAD -- path/to/file对于重要项目还可以利用 IDE 的本地历史功能每十分钟自动保存一次工作区快照这样即使 git 没有提交也能通过 IDE 的历史记录找回被智能体覆盖的代码。9. 总结与后续学习方向SWE-Touch 这篇工作真正有价值的地方不是又给了一个新的分数排名榜而是把编程智能体评测的视角从“无人值守的自动修复”拉回到了“人机协作的真实开发”。它让我们意识到当前编程智能体的瓶颈也许已经从代码生成能力转移到了交互协同能力。一个能在静态任务上考满分的智能体在用户中途改代码的常态场景下完全可能表现得像个“优秀的破坏者”。如果你正在做编程智能体的选型建议不要只看基准测试分数而是重点考察这几个方面智能体是否能感知代码库状态变化。智能体是否提供明确的文件读取和修改日志。智能体是否支持在任务中途暂停并重新规划。智能体的修改是否遵循最小变更原则。智能体是否能区分“用户改动”和“自身改动”。这些能力目前还没有一个统一评测标准但 SWE-Touch 已经在朝这个方向探索。后续值得关注的几个方向包括更细粒度的用户交互类型建模、多轮对话中的状态跟踪评测、以及“用户意图变更”场景下的智能体重规划能力评测。对于普通开发者来说现阶段最实用的做法是在引入任何编程智能体之前先建立好快照、分支、审查这套基础工程保护机制再把智能体放到真实任务里测试少量交互场景尤其要测试你中途修改代码时的表现。这才是拿到 SWE-Touch 这类评测结果后真正应该落实到项目里的行动。