昨晚失眠，把 arXiv 的 cs.SE 新提交从后往前划，划到一个标题毫无攻击性的东西：RepGen。一句话——照着缺陷报告，把深度学习项目里的那个 bug 亲手跑挂一遍，这活它交给 agent 去干了。
先交代阶段，免得有人看完就想着往生产上搬：v1，10 月 30 号挂上去的，投稿在审，投的是 ICSE 2027 的 Tool Demonstration and Data Showcase Track，DOI 还写着待注册。论文工具，不是成品。
它要解决什么，作者在动机里写得很直白：DL 的 bug 难复现，因为一次失败可能同时牵连源码、模型、数据、依赖项和运行环境，而缺陷报告往往连必要细节都没写全。这话我信。在模型库里待过的人都懂，issue 里一句“loss 变成 nan 了”配三段代码，剩下的全靠猜。
流程大致是这样：输入一份缺陷报告加一个 repo，它在代码库里探索，构建一份带学习增强的上下文，再据此拟定复现计划、生成候选脚本，然后靠静态检查和 LLM 反馈反复去改。到这一步，市面上多数同类工具就收工了——给你一段看上去挺像样的脚本，跑不跑得起来看运气。RepGen 多走一步：用户开了相关选项之后，它会准备运行环境、执行脚本，拿执行结果跟报告里描述的失败现象比对，判断到底有没有复现出来。
这一步才是脏活。写脚本干净，装环境脏，装过的人都知道。
数字方面：106 个真实 DL 缺陷，复现成功 85 个，80.19%；另有一项 27 名开发者参与的对照实验，成功率提升 23.35%，耗时减少 56.8%。都是作者自报的，我一个没验，先声明在这。
说句不太中听的：80.19% 这个数，还不如它旁边那 20% 有意思。剩下那 21 个没复现出来的，我猜多半栽在环境或者数据拿不到上——要么依赖版本早从 PyPI 上消失了，要么数据集得填表申请。纯属猜测，论文里没细看，别当结论。可要是真如此，这工具的瓶颈就不在 agent 会不会写脚本，而在“当年那套环境还能不能重建出来”。这问题 LLM 帮不上忙，得靠镜像和 lockfile 的考古学。
刷着刷着跑题了，拉回来说工程细节。
真正让我多看两眼的是它的形态：交互式 CLI，本地模型和云端托管的都能接，能设执行预算上限，产物留着可检查，另外还带一个自动处理 issue 的 GitHub Action。
预算上限这条单独说一句。跑过 agent 测试的都懂，这东西一启动就烧 token，循环刹不住，账单能让你半夜坐起来。作者把预算上限做成明面选项，说明自己被烧过。这种细节比 README 里十个 powerful 都管用。
GitHub Action 那个形态也值得说。一个论文工具做成 Action，意思很明确：作者想让它活在 issue 区，不是活在 PDF 里。这两样东西的生命周期完全是两码事。
本来我想说这工具的价值在省时间，写到上面几段觉得不对。省时间是最不值钱的那一层。它真正给的，是“这条 bug 到底还能不能复现”这个判断本身——省下的不是敲键盘的时间，是那种反复折腾三天也说不清到底谁错了的消耗。
上手门槛老实交代：我只看了论文，代码没摸到。问装起来顺不顺、文档写没写全，我答不了。按论文工具的普遍规律，artifact 跟本地那套 CUDA 能不能兼容才是第一关，这个我持保留态度。
适合谁：维护 DL 框架或模型库、issue 区三天两头有人贴“我也复现不出来”的；做 bug 复现、缺陷定位这类研究的。不适合谁：想拿它当通用 CI 使的，或者指望它顺手把业务代码里偶发的空指针也调了的——它盯的是报告里描述的那一个失败现象，不是“帮我把测试跑绿”。
还有个前提得搁明面上：输入得是一份写得还凑合的缺陷报告。报告本身缺关键信息，再好的 agent 也只能瞎猜。这是这类工具共同的天花板，不是 RepGen 一家的毛病。
候选池里还搁着一个做实验环境快照的，方向正好接在这条链的下游，等它再攒几个像样的 issue 我再说。这边能不能打，等 artifact 放出来，自己拉下来跑一圈最准。我先记下了。