你以为写代码就是改代码?2026 这篇 66 页论文说:还得跑、得点、得截图,才算"做完一个 bug"

  • 关联论文:2609.32600

想象一下这个场景:

你让 AI agent 修一个 bug。代码改完,你按 PRD 走验收——结果 bug 还在运行时 UI 里,得让用户点开某个菜单才能复现。代码 diff 看着对,但软件实际跑起来就是错的。

这场景每个用过代码 agent 的人都撞过。问题是:没人专门测过这条"改代码 + 跑命令 + 点 UI + 看截图"端到端闭环的能力。

2026 年 9 月 arXiv 上的一篇 66 页论文 CUA-SWE(arXiv 2609.32600)填补了这件事:

给同一只 agent 同一道任务,要求它既改源码、又跑命令、又操作 UI、又看截图,然后用 deterministic 测试断言"软件是否真的满足规格、是否保留指定行为"——首次系统度量"视觉反馈 + GUI 交互 + 源码编辑"三者协同的 SWE 能力。

换句话说:真正的开发者会的事,agent 终于要学全套了——而不只是"git diff 看着对"。

一、为什么这件事对今天的产品经理、工程师都关键

如果你做以下任何一类工作,你都需要读这篇:

  • AI 产品经理:你做的 agent 在真实业务里跑的时候,UI 反馈是不是被低估的维度?
  • SWE agent / Cursor 类开发者工具:评测集是不是只覆盖"diff 对",没覆盖"软件跑对"?
  • Computer-Use Agent(操作电脑的 AI):你的模型在"看完还得回去改代码"这件事上有数据吗?
  • 企业内部 Agent 团队:很多内部 SaaS 没 API、没文档,agent 只能 UI 走一遍——CUA-SWE 把这类任务形式化了。

二、解决什么真问题

现有 SWE-bench 类评测几乎全部依赖「静态仓库 diff」:给 agent 一个 issue,让它改文件,用仓库自带的测试判对错。但真实开发里:

  • 应用可能没文档,规格只写在 UI 文案 / 弹窗 / 状态栏里;
  • bug 只在运行时显现,agent 必须启动应用、操作 UI、截图比对才能定位;
  • 修复后又得跑一遍 UI 才能确认视觉行为没退化。

把这三件事分开做,会出现三个评测盲区:

  1. Coding agent 单独评测:给它 issue,它只能改文件,无法验证运行时行为。
  2. Computer-use agent 单独评测:让它操作应用,但不评估它能不能读源码改源码。
  3. Multimodal VQA 评测:能看图,但不去操作 UI,也不改代码。

CUA-SWE 一次性把这三件事绑在一个任务里。

三、CUA-SWE 怎么干的——任务四件套

每件任务包含:

  • 改源码 / 配置:agent 必须修改代码或配置
  • 跑命令:构建、测试、运行
  • 操作 UI:点击、输入、滚动
  • 看截图:作为视觉反馈
  • 通过 deterministic、task-specific 测试:断言「软件是否满足规格、是否保留指定行为」

伪代码:

for task in cua_swe_tasks:
    state = boot_app(task.repo, task.config)
    for step in range(max_steps):
        screenshot = capture_screen(state)
        action = frontier_agent.act(
            prompt=task.description,
            screenshot=screenshot,
            codebase=task.repo,
        )
        state = apply(action, state)   # 代码改动 / shell 命令 / UI 操作
    score = run_task_specific_tests(task, state)

四、三类度量维度

论文考察三类,比单一 leaderboard 信息量大:

  • 跨域性能:4 个 SE 域之间,frontier agents 的差异。
  • 按任务信息需求划分的性能:哪些任务需要 UI-only 信息、哪些可从 spec 文档读到。
  • 与成功修复相关的「开发行为」:agent 怎么用 GUI 反馈、怎么把视觉观察连到代码。

第三类特别有意思:「开发行为分析」把 evaluation 从「结果」往「过程」拉——以后调试 agent 不止看 leaderboard,还要看「agent 在每步用了什么信号 → 修好概率」的关系图。

「按任务信息需求」也是关键维度:把任务分为 (i) 信息在 spec/文档里、(ii) 信息在 UI 里、(iii) 信息在运行时状态(截图、运行日志)里。Frontier agents 在这三类上的差异很大——理论上 CUA 能力强的模型在(ii)上占优,纯 coding agent 强的模型在(i)上占优。这一分类让 benchmark 不再是一个单点分数,而是一组「能力画像」。

五、为什么这件事"难"

坑 1:截图带高 DPI、动态主题、深色模式切换 - 现象:agent 看到的截图与人类开发者看到的差别很大。 - 影响:UI 操作识别错位、点击坐标偏移。 - 修复:标准化截图分辨率与主题;坐标归一化到 viewport 比例而非像素。

坑 2:任务级 deterministic tests 覆盖不足 - 现象:测试覆盖了 happy path,但没覆盖交互边界(按钮 disabled、loading、modal)。 - 影响:agent 跑通测试却遇到真实环境卡死。 - 修复:补充 task-specific tests 的边界用例;引入回归测试集。

坑 3:agent 同时操作源码与 UI,状态一致性难维护 - 现象:改了源码但 UI 没刷新,或 UI 改了但源码没同步。 - 影响:cross-modal 状态错位,agent 在错误状态上下决策。 - 修复:每步显式做「源码 → reload 应用 → 重新截图」的硬 reset 流程。

坑 4:截图里含隐私敏感信息 - 现象:用户数据、token、密钥可能直接出现在截图里。 - 影响:评测数据直接喂给 frontier agent 即泄露。 - 修复:截图前做 OCR + 敏感信息 mask;评测数据走合成或脱敏流水线。

坑 5:Pass@1 vs Pass@K 不明 - 现象:frontier agent 在 CUA-SWE 上 Pass@1 可能高,但 Pass@K(多次采样取最佳)仍未明确给出。 - 影响:真实场景下 agent 通常只跑一次,低 Pass@1 直接不能用。 - 修复:内部评测同时报告 Pass@1 与 Pass@K(K=4 或 8)。

坑 6:任务设计本身是人力成本中心 - 现象:deterministic test 必须人工理解行为后编写,无法自动生成。 - 影响:种子任务 <10 个时统计功效不足,基准建设成本远超预期。 - 修复:优先复用已有 e2e 测试框架的软件(如 Chromium 的 browser tests);自研任务走「人工操作 + 录制 → 脚本化」路径,评测员即测试设计者。

六、对工程落地的 3 个启示

  1. 内部 SWE agent 评测可借鉴设计:把任务拆成「代码 + 命令 + UI + 截图」四元组,加 deterministic tests,是落地团队可以拿走的最小结构。

  2. 「视觉作为唯一信息源」类任务:在企业内部系统里常见——很多内部 SaaS 没 API、没文档,agent 只能 UI 走一遍。CUA-SWE 把这类任务形式化。

  3. 任务设计模板可复用:把任务形式化成「描述(prompt)+ 截图 + 源码 + 测试集」四元组,是把企业内部 SE 任务形式化做基准的最小工程模板。

七、边界声明

  • ⚠️ 66 页 PDF 本轮未通读,数字以 abstract 为准。
  • ⚠️ 4 SE 域具体名称缺失:abstract 仅用「spans four software engineering domains」表述,未列出具体四域名称,需翻 PDF 附录核实;跨域性能对比数字本质依赖这四域是哪四个。
  • ⚠️ GitHub / 项目页未 fetch:arxiv.org/abs/2609.32600 对应仓库是否公开、deterministic test 脚本是否开源、任务集是否公开,本轮未验证。
  • ⚠️ frontier agents 名单不明:仅说「frontier agents」但未列出具体模型(GPT-5 / Claude / Gemini 还是具体子集未明示),Pass@1/Pass@K 数字无法与现役模型做精确对比。
  • ⚠️ v1 提交(2026-09-26),同行评审尚未启动。

八、一句话总结

arXiv 2609.32600 提出 CUA-SWE benchmark:把"改代码 + 跑命令 + 操作 UI + 看截图"端到端闭环做成统一评测,覆盖 4 SE 域、用 deterministic 测试做最终判分、按"任务信息需求 + 开发行为"双维度分析——首次系统度量视觉反馈与代码修复的协同能力,66 页篇幅是 2026 年 SWE + 视觉交叉方向的代表工作,但具体域、frontier 选型、Pass@K 数字需翻 PDF 附录确认。

论文 arXiv:https://arxiv.org/abs/2609.32600

三个标题变体

反直觉版:写代码不是"改 diff":2026 这篇 66 页论文让 SWE benchmark 必须会点 UI、看截图 数字钩子版:4 个 SE 域 × deterministic 测试:首个强制 agent "改+跑+点+看"全闭环的 SWE 评测基准 类比版:AI agent 的"完整开发者"考试:CUA-SWE 把"会改代码"升级为"会跑应用"

📱 小红书风格卡片文案(可直接发布)

🤖 你以为写代码就是改 diff?这篇论文说还得会跑、会点、会看截图

📍 论文:arXiv 2609.32600 · CUA-SWE
📍 长度:66 页,2026 年 9 月发布

你让 AI agent 修一个 bug——
代码 diff 看着对,但软件跑起来还是错的,因为 bug 在运行时 UI 里。

🤯 CUA-SWE 首次把"改代码 + 跑命令 + 操作 UI + 看截图"做成端到端 benchmark,4 SE 域 + deterministic 测试判分。

🔍 这篇论文干了什么反常识的事? - 不止测"diff 对不对",还测"软件跑起来对不对" - 任务四件套 = 改源码 + 跑命令 + 操作 UI + 看截图 - 判分不用文本相似度,用 task-specific deterministic tests - 按"信息需求 + 开发行为"双维度分析,不止 leaderboard,还有"agent 在每步用了什么 → 修好概率"的关系图

💡 3 个让工程圈沉默的洞察: 1️⃣ 现有评测盲区:coding agent 单独评 / CUA agent 单独评 / VQA 单独评,没人测三者协同 2️⃣ "视觉作为唯一信息源"形式化:企业内部 SaaS 没 API、没文档时常见 3️⃣ 行为分析是 SWE 评测的下一步:不止看结果,要看「过程动作 → 修好概率」

📌 对今天的硬约束: - ⚠️ 4 SE 域具体名称未在 abstract 列出,需翻 PDF 附录 - ⚠️ frontier agents 名单不明,Pass@K 数字未给 - ⚠️ GitHub / 项目页本轮未 fetch,落盘前需验证仓库是否公开 - ⚠️ 66 页 PDF 未通读,具体数字需补核 - ⚠️ v1 提交(2026-09-26),被引 0,同行评审尚未启动

🔗 arXiv:https://arxiv.org/abs/2609.32600

AI #SWE #ComputerUse #Agent #Benchmark #AI产品经理 #LLMAgent #CodingAgent #论文解读 #代码Agent #CUA