RepoRevenant 用验证闭环修复旧代码

旧仓库跑不起来，未必是算法过时，也可能只是 Python 升级后，导入路径、标准库和语法不再兼容。RepoRevenant 想把这类修复做成一条可检查的流水线：先提取代码证据、记录测试失败，再让本地模型提出补丁，最后用测试验收。

它最值得程序员借鉴的，是给 AI 安排的位置：事实由规则和执行结果提供，模型负责解释与修复建议。不过，原文展示的是项目方案和受控样例，还不足以证明它能可靠接手任意老仓库。

修旧代码，为什么先让规则出场

RepoRevenant 是面向 Hacktoberfest Open-Source AI Challenge Week 4「Ghost in the Machine」的开源软件取证与仓库修复平台。所谓「取证」，就是先留下可复查的证据，回答代码在哪里不兼容、运行时究竟报了什么错。

作者关注的是运行环境变迁造成的失效：例如 2017 年的仓库，在 Python 3.12+ 环境里可能遇到模块缺失、collections.abc 迁移以及 Python 2 的 print 语法问题。原文把 imp、cgi、pipes 的移除放在 PEP 594 的叙述下，但没有逐项区分移除依据与生效版本，不能直接拿这段话当兼容性清单。

项目先扫描仓库结构，解析 requirements.txt、setup.py，发现测试套件并识别语言组成，再通过抽象语法树（AST）检查 Python 代码。AST 可以理解为代码经过语法解析后的结构，程序能据此识别导入和语句，不必让模型阅读整份文件后猜测。

能由规则确认的问题，就不交给模型裁定。

这个分工缩小了模型的任务：规则指出可疑位置，模型结合源码片段解释原因，再提出修复。它也划定了能力边界：原文明确列出的检测项集中在 Python 兼容性，不能据此推断它已经覆盖任意语言或复杂依赖冲突。

七个阶段，怎样把补丁变成可检查的结果

后端使用 Python / FastAPI，七个阶段依次处理输入、检查、分析、验证、AI 推理、补丁和报告。

入口只接受经过校验的 HTTPS Git URL，并声称提供服务端请求伪造（SSRF）防护，阻止 RFC 1918 私有地址和 169.254.169.254。接收一个仓库地址，实际会触发服务器访问网络，因此 URL 校验属于执行边界的一部分。

随后，Verifier 在独立临时沙箱里执行基线 pytest，清理环境变量，设置 30s 超时。基线的用途是保存修改前的失败记录，方便判断后续补丁究竟改变了什么。

AI Engine 将 AST 证据和源码片段发给本地 Ollama，支持 llama3:8b、mistral:7b、codellama:7b，生成原因假设和修复内容。Patcher 使用 ast.parse() 检查生成代码的语法，创建回滚备份，并在人类批准后应用补丁。最后重新执行测试，以退出码 0 作为通过信号。

这里有两层检查：ast.parse() 只能证明代码能被解析；测试通过说明已有断言没有失败。两者都不能单独证明业务行为完整正确。

报告阶段会导出 .md 格式的 Resurrection Certificate、.json 遥测数据和 .patch 差异文件。SQLite 保存 investigations、findings、patches、test runs，让修复过程留下记录，而非只剩一份改好的源码。

实现入口也比较清楚：backend/app/main.py 编排流水线，backend/app/engine/ 放分析器、AI 引擎和补丁器，backend/app/db.py 定义数据结构。需要审查工具时，可以从这些位置追踪证据如何进入补丁。

本地模型解决了隐私问题，但演示范围仍然有限

作者选择本地开放权重模型，理由是旧仓库可能包含私有算法、知识产权和商业秘密。通过 Ollama 在本机推理，可以避免把待修复源码发送给第三方模型服务；MODEL_PROVIDER 环境变量则用于替换兼容 OpenAI 接口的本地端点。

原文还提供确定性引擎的隔离网络降级路径，可以在零神经网络 API 调用下工作。不过，这只能支持「规则检测不依赖模型服务」的判断，不能推导出所有 AI 修复功能都能离线完成。完整离线流程如何准备仓库、依赖和模型，文章没有展开。

部署方式也要分开看。在线演示由 Vercel 承载前端，代理到受保护后端，只开放两个受控仓库：

• sample-pyvault 是旧版 secrets manager，用来展示 imp、cgi 相关问题。
• sample-math-matrix 是 2016 年的线性代数库，用来展示 collections.Mapping 迁移问题。

这两个样例便于观察流程，但原文没有提供更多仓库的成功率、误修率或不同模型的对照结果。

以下是原文给出的本地完整运行命令，用于启动前后端：

git clone https://github.com/divyanshigupta786/Repo-Revenant.git
cd Repo-Revenant
npm install
python -m venv .venv && .venv\Scripts\activate
pip install -r backend/requirements.txt
npm run backend   # FastAPI on :8000
npm run dev       # Next.js on :3000

要留意虚拟环境激活那一行采用 Windows 路径写法，其他系统不能照抄；这组命令也没有包含 Ollama 和模型的准备步骤。

前端使用 Next.js、Three.js、Anime.js 和 Lenis，通过 Ctrl+K 命令面板导航、启动调查和切换推理提供方。components/HeroAnimations.jsx 承载复活动画，Lenis 滚动遵循 prefers-reduced-motion。这些设计能帮助呈现过程，但动画完成与修复正确是两回事。

我的判断

我认同它把确定性检测、模型建议和执行验证串起来的方向。相比直接让 AI「修好整个仓库」，有证据、有基线、有可审查差异的流程，更容易定位错误，也方便回退。对于已经能被规则准确识别的问题，直接使用规则修复或迁移脚本同样值得考虑；模型的价值应体现在需要上下文判断的部分。

但作者没有给出与人工修复、规则工具或不同模型的对照数据，所以目前只能把效果判断看作方案主张和经验之谈。

测试退出码为 0，是验收证据，不是完整正确性的证明。

旧仓库可能测试缺失、覆盖不足，或连依赖都无法安装。临时目录、环境变量清理和超时也不足以单独说明沙箱隔离强度，原文没有交代网络、文件和进程权限边界。此外，开放权重支持本地部署，并不自动等于所有模型都满足相同的开源许可与审计条件。

能拿来做什么

• 修复老 Python 仓库时，先保存原始 pytest 输出，再让 AI 根据具体失败和相关源码提出补丁，避免失去修改前后的比较依据。
• 搭建日常 AI 编程流程时，可以借鉴「规则定位、模型建议、人工审查、执行验证」的顺序，并保留 .patch 与测试记录，方便复查和回滚。
• 评估 RepoRevenant 时，先用它明确覆盖的兼容性问题验证完整流程，再尝试自己的旧仓库；遇到缺测试的项目，应先补上关键行为断言。
• 处理私有代码时，可以研究 Ollama 与 MODEL_PROVIDER 的本地替换方式，同时核查实际端点、依赖获取和日志路径，确认部署符合预期的数据流向。