做深度学习论文复现的时候，最让人头疼的事情之一就是：跑完一个命令之后，你根本说不清它到底跑没跑通。日志里一堆输出，有报错、有警告、有数字，但你很难用一种标准化的方式告诉别人“这个结果是可以信任的”或者“这个步骤卡住了”。更麻烦的是，如果你为了让它跑起来改了几行代码——改了什么、为什么改、改完之后对结果有没有影响——这些信息往往散落在聊天记录里，事后根本无从追溯。
minimal-run-and-audit 就是为这个场景设计的。它是 lllllllama 开发的 RigorPilot Skills 套件中的一个子技能。截至 2026 年 8 月，这个技能在 Learn Skills 平台上的安装量已接近 14 万次。
这个技能能做什么
minimal-run-and-audit 的核心任务很明确：执行一个短命令，然后把执行结果整理成标准化的、可审计的证据文件。
它不是命令执行器，也不是环境配置工具。它的全部工作就是把“跑了一次命令”这件事——从输入到输出到中间发生的所有变化——用一种标准化的格式记录下来。
具体来说，它做以下几件事。
执行选定的命令：技能会运行你指定的命令——可以是冒烟测试（smoke test）、文档中记录的推理命令、评估命令，或者其他短的非训练验证命令。训练启动、恢复或长时间运行的训练状态不在它的管辖范围内，这些交给专门的 run-train 技能。
标准化输出文件：执行完成后，技能会把结果写入标准化的 repro_outputs/ 目录。这个目录是复现流程中所有证据的集中存放处，方便后续查阅和审计。
记录代码变更：如果在执行过程中仓库文件发生了变化，技能会生成 PATCHES.md，记录每一次修改的细节。改了什么、为什么改、改之前什么样——这些信息都会被保留下来，而不是悄无声息地消失。
区分状态，不简单报“通过/失败”：这是 minimal-run-and-audit 跟普通脚本最大的区别。它不会只告诉你“跑通了”或者“报错了”，而是把执行结果分成三种状态——已验证（verified） 、部分完成（partial） 和 被阻断（blocked） 。这三种状态分别对应：命令完整执行且结果可信、命令执行了一部分但没跑完、命令因为环境或依赖问题根本没跑起来。
科学变更日志：如果修改涉及评估逻辑、预处理、检查点或度量指标等可能改变科学结论的内容，技能会生成 SCIENTIFIC_CHANGELOG.md。同时还会生成 COMPARABILITY_REPORT.md，说明当前执行结果与 README、论文原文和基准线的可比性。
安装方法
minimal-run-and-audit 支持 Claude Code、Codex、Cursor、Windsurf 等多种 AI 编程助手。
通过 npx skills 安装（推荐） ：
在项目根目录打开终端，执行以下命令：
npx skills add https://github.com/lllllllama/ai-paper-reproduction-skill --skill minimal-run-and-audit
指定 Agent 安装：
如果只想为某个特定的 AI 助手安装，可以用 --agent 参数指定：
npx skills add lllllllama/rigorpilot-skills --skill minimal-run-and-audit --agent claude-code
这条命令会把技能安装到当前项目的 .claude/skills/ 目录下。
通过 skillsauth 全局安装：
npx skillsauth add aiskillstore/marketplace minimal-run-and-audit前置条件：
安装完成后，技能会自动配置到你的 AI 编程环境中，slug 保持为 minimal-run-and-audit 以确保兼容性。
什么时候该用它
minimal-run-and-audit 的使用边界非常清晰。
应该使用的情况：
不应该使用的情况：
使用案例
案例一：跑通官方推理命令，记录结果
你按照 README 的说明，找到了一个推理命令 python infer.py --model resnet50 --image test.jpg。你想跑一下看看效果，同时把这次执行的结果规范地记录下来，方便后续对比。
你告诉 AI 助手：“帮我跑一下这个推理命令，然后把结果记录下来。”
minimal-run-and-audit 会执行命令，捕获输出，把结果写入 repro_outputs/ 目录，并生成一份执行结果摘要——命令是什么、输出是什么、状态是 verified 还是 partial 还是 blocked——全部一目了然。
案例二：为了跑通改了代码，需要记录修改
你跑 README 里的评估命令时发现一个小 Bug——某个路径写错了。你让 AI 助手修改了代码，然后重新运行。这次跑通了。
如果你只是口头说“我改了一下代码”，三个月后没人记得改了什么。minimal-run-and-audit 会生成 PATCHES.md，记录你改了什么文件、改了什么内容、为什么改。同时，如果这次修改涉及评估逻辑或度量指标的计算方式，技能还会生成 SCIENTIFIC_CHANGELOG.md，明确标注科学含义发生了变化。
案例三：命令跑不通，需要区分“卡在哪了”
你按照 README 执行一个命令，结果报错了——缺少某个依赖包。普通的做法是“跑不通，换一个”。但 minimal-run-and-audit 会把这次执行标记为 blocked（被阻断） ，并记录阻断原因。这样你就知道：不是命令本身有问题，是环境还没准备好。等装好依赖之后再跑一次，状态就会变成 verified 或 partial。
案例四：对比不同版本的执行结果
你先后跑了两次推理命令——第一次用的是 README 默认的配置，第二次换了另一个 checkpoint。两次的输出都保存在 repro_outputs/ 目录下，格式完全一致。你可以直接对比这两个结果，而不需要去翻两次不同的日志文件。
几个值得注意的细节
“通过/失败”太粗糙了：这个技能最核心的设计理念就是——不简单地报“通过”或“失败”。一个命令可能跑了一半卡住（partial），也可能根本没跑起来（blocked），这两种情况对复现工作的意义完全不同。把状态细分，才能让后续的排查和决策有据可依。
科学变更必须被标记：技能有一条硬性规定——不能隐藏会改变评估逻辑、预处理、检查点、度量指标或其他科学含义的修改。如果你为了跑通命令修改了评估代码，这个修改必须被记录在 SCIENTIFIC_CHANGELOG.md 里，不能悄悄带过去。
不改代码是常态，改了要有记录：大多数情况下，你不需要修改仓库代码就能跑通命令。但如果确实需要改——不管是修 Bug 还是适配环境——PATCHES.md 就是用来记录这些修改的。改了什么、为什么改，都要写清楚。
不负责选目标，只负责执行和报告：minimal-run-and-audit 不会自己决定“这次应该跑哪个命令”。它只负责执行你已经选好的命令，然后把结果标准化地记录下来。选哪个命令、选哪个作为主要复现目标——这些决策由主编排器或用户自己来做。
◯ 评论 0