用途
Reproducibility Audit 用于帮助用户让研究项目达到可复现的程度，使其他人或未来的自己能够重新运行实验。该技能遵循手册中的可复现性章节，涵盖精确环境、数据与代码版本控制、文档、随机种子、参数日志和备份。其输出是一份审计报告加上按优先级排序的修复清单。
何时使用
- 用户正在启动或清理研究代码库
- 用户需要向协作者交接
- 用户无法复现旧实验
- 用户正在准备论文投稿或公开发布
- 用户在本地、服务器、HPC、Docker 或 conda 环境之间迁移
工作流程
阶段 1：识别项目上下文
询问：
- 正在审计哪个仓库或文件夹？
- 这是本地、远程服务器、HPC 还是容器化环境？
- 目标是内部可复现、协作者上手，还是公开发布？
- 哪个结果必须可复现？
如果用户授予文件系统访问权限，在给出建议前先检查仓库结构。
阶段 2：审计三大支柱
检查：
环境管理
- 存在 Conda/uv/pip 环境文件
- 在需要处固定 Python/CUDA/框架版本
- 安装说明是最新的
- 如果可移植性重要，存在 Dockerfile 或容器说明
数据与代码版本控制
- Git 跟踪源代码和配置，而非生成的杂乱文件
- 数据集来源/版本/预处理有文档记录
- 大文件有明确的存储路径
- 检查点和输出命名一致
文档
- README 说明安装、数据设置、训练/评估命令
- 命令可直接复制粘贴
- 说明预期输出和运行时间
- 已知注意事项和硬件假设明确写出
阶段 3：审计实验卫生
检查：
- 随机种子
- 配置文件
- 超参数日志
- 提交哈希日志
- 指标文件
- 绘图/表格生成脚本
- 失败日志
- 结果到论文的可追溯性
阶段 4：问题分类
使用严重级别：
- Blocker：当前结果无法重新运行或验证
- High：协作者很可能无法运行
- Medium：结果可以运行但难以检查或比较
- Low：打磨或面向未来的改进
优先修复保护不可替代结果的问题。
阶段 5：产出工件
保存到 ~/phd-log/reproducibility/YYYY-MM-DD-[project].md。
报告模板包含：目标、摘要（总体状态、最大风险、首个修复）、环境检查表、数据与代码版本控制检查表、文档检查表、实验卫生检查表、问题表（严重级别、问题、修复）、按优先级排序的行动计划（Blocker/High/Medium/Low 复选框）。
语气
务实。可复现性审计应让用户得到 3-5 个高影响力修复项，而不是一堵令人内疚的最佳实践墙。
不应做的事
- 如果 conda 或 uv 对协作场景足够，不要强求 Docker
- 不要在不解释需要固定什么的情况下建议版本固定
- 不要忽视数据来源
- 不要把 README 打磨看得比可重新运行的实验更紧急
限制
该技能的具体实现细节、依赖要求、安装方式、收费模式、支持平台等信息暂未提供。