拆解网页，逆向出题

1问题

想象你是一名程序员，接手了一个半成品网页：菜单按钮有了，但点下去没反应；登录框在了，但提交后提示错误。在传统的编程评估中，你会拿到一份详细的“需求文档”，上面写着“点击菜单应下拉显示列表”，你照着做就行。但在真实世界或更高级的测试中，没有文档，只有一个能完美运行的参照版本（Reference App）和一个残缺的目标版本。主角就是这些 coding agents（编程智能体），它们的困境是：如何从那个能跑的参照版本中，“看”出该补什么功能？如果解不开，智能体就只能在黑盒里乱撞，无法通过自动化手段精准评估其逆向工程和代码生成能力，导致我们不知道哪些模型真的理解软件逻辑，哪些只是运气好蒙对了。

2翻译

故事的转折在于，作者不再让智能体去猜“用户想要什么”，而是直接告诉它“参照版有什么，你要复刻什么”。他们设计了一套叫 "mine-craft-patch" 的流程，像拆炸弹一样把完整的网页应用拆解成一个个独立的“行为单元”。

具体来说，这个过程分为三步。第一步，让一个“矿工”智能体去操作那个能跑的参照应用，记录下每一帧的操作和状态变化，比如“点击按钮A，界面变成状态B”。第二步，把这些记录提取出来，翻译成具体的代码补丁（Patch），也就是修改那行关键代码就能实现的行为。第三步，把这些补丁反过来应用到残缺版本上，验证是否能成功恢复对应功能。如果能跑通，这个行为就被确认为一个有效的“任务”。

这就好比把一个大蛋糕切成小块，每块都标明了配料和做法。对于外行来说，最直观的差异在于任务生成的规模和数据的质量。传统方法人工编写100个测试题可能需要几周，而这套流程自动生成了4,063个任务，覆盖26个不同的应用。关键数字对比如下：

• 总任务数：4,063个（全自动生成，零人工干预）
• 验证过的行为：1,975个（每个都经过回放确认无误）
• 应用数量：26个不同功能的Web应用

这里有一个反直觉的发现：随着需要修复的代码深度增加（从改一行到改多层嵌套逻辑），顶尖智能体的成功率断崖式下跌。比如GPT-6 Astra在简单修复时成功率近半，但在深度为8的复杂重构中，成功率虽未给出具体数值，但趋势显示其难以应对深层依赖。这意味着，当前最强的模型并非全能，它们在处理“牵一发而动全身”的局部修改时显得笨拙。

3核心概念

为了让故事落地，我们需要拆解主角手里的三个核心工具：

1. 可回放行为（Replayable Behaviors）：这是任务的原子单位。它不是抽象的描述，而是一组确定的输入（用户点击了哪里）和输出（界面变成了什么样）。它的价值在于“可验证性”——只要代码改了，再运行一遍同样的点击序列，就能立刻知道对错，无需人类裁判。

2. 金标准补丁（Gold Patch）：这是达成目标的最小代码改动集合。作者不关心大段重写，只关心“哪几行代码变了会导致功能出现”。这就像找茬游戏里的差异点，精准定位了因果链条。它是连接“观察到的现象”和“底层代码”的桥梁。

3. 粒度因子化（Granularity Factorization）：这是设计的灵魂。作者没有把应用看作整体，而是将其分解为不同粒度的特征。有的特征是“全局搜索”，有的是“单页表单验证”。这种分层允许测试既考察微调能力，也考察大规模重构能力，从而构建出一个难度可控的课程表（Curriculum），而不是随机扔给模型一堆难题。

4洞见

真正的智能不是背诵指令，而是能从完整系统中逆向推导局部缺失的逻辑；评估编程能力的未来不在“写多少新代码”，而在“补多少旧系统”。

5博导审稿

选题眼光不错，切中了当前SWE-bench等基准过于静态、缺乏动态交互数据的痛点。方法成熟度较高，特别是“挖掘-验证”闭环的设计，解决了自动化标注最难的可信度问题。实验诚意值得肯定，4000多个任务量级可观，且明确指出了随复杂度增加性能下降的趋势，数据经得起追问。写作功力中规中矩，清晰直白。

但是，有一个根本预设需要警惕：论文假设“参照应用的功能”完全等同于“目标应用应具备的功能”。在现实中，残缺应用可能是因为安全限制、架构演进或商业决策而故意移除某些功能。如果盲目录制并还原，可能会引入不必要的技术债务或安全风险。此外，仅靠前端交互录制可能遗漏后端逻辑的变更，这点未在文中充分讨论。

判决：Strong Accept。理由：方法论创新性强，数据集规模与质量兼具，为后续基于课程的强化训练提供了极佳的基石，尽管有边界假设的局限，但不影响其核心价值。

6启发

这意味着你可以___1. 迁移：将你现有的静态代码库评估转化为动态交互测试，利用类似的“录制-回放”机制生成更多样化的测试用例，特别是在UI驱动的后端逻辑验证上。2. 混搭：结合你们已有的强化学习奖励函数，将ProgramDistill中的“金标准补丁”作为稀疏奖励的信号源，指导智能体在接近完成时的策略调整。3. 反转：默认假设是“先有需求后有代码”，这里反转成“先有完整系统，反向生成需求”。你可以尝试将此思路用于老系统的自动化文档生成或遗留代码迁移前的功能审计。