content/skills/academic-skills/paper-replication/SKILL.md
深度学习论文复现技能。将学术论文中的模型架构转化为工业级 PyTorch 代码,包含论文解构、架构可视化(Mermaid)、代码实现和模块文档生成。当用户提供深度学习论文(PDF/文本)需要复现、实现模型、理解网络架构时使用。触发场景:帮我复现这篇论文、论文复现、实现这个模型、replicate this paper、reproduce this paper、implement this architecture、把论文里的网络写成代码。即使用户没有明确说复现,只要提供了深度学习论文并希望得到代码实现,也应触发此技能。
npx skillsauth add bahayonghang/my-claude-code-settings paper-replicationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
读取深度学习论文(PDF 或文本),将论文中的数学描述、网络结构和实现细节转化为可运行、可验证、可维护的 PyTorch 代码与配套文档。
根据用户需求和论文复杂度,选择合适的执行模式:
对于简单模型(如 MLP、单层网络),自动简化:
输出最小但完整的解构结果:
推荐输出骨架:
## 论文概述
**问题 (Problem)**: ...
**核心创新 (Contribution)**:
1. ...
2. ...
## 数学原理
### 核心公式
$$ ... $$
### Loss Function
$$ ... $$
## 架构细节
| 组件 | 参数 | 值 | 来源 |
|------|------|-----|------|
使用 Mermaid 展示论文的数据流,至少覆盖:
[B, C, H, W]、[B, N, D] 等标准符号。颜色规范:
#e1f5fe:输入/输出节点。#fff3e0:核心处理模块。#e8f5e9:特征提取或缓存模块。#fce4ec:注意力机制。#f3e5f5:Loss 或聚合节点。简单模型可使用简化图;复杂模型优先画模块关系图,再补张量形状变化图。
实现代码时遵循以下要点:
torch.nn.Module,并给核心类加清晰 docstring。modules/ 子文件。_init_weights 或等价初始化逻辑,并注明来源。set_seed 或等价可复现性配置。Paper did not specify,同时写明推荐值、参考来源、备选值和潜在影响。完整编码规范、验证模板和 Paper did not specify 协议见
references/CODING_STANDARD.md。
为每个核心模块生成技术文档,包含:
详细文档规范和 Mermaid 模板见 references/DOCUMENTATION_GUIDE.md。
整个复现过程统一使用以下维度符号:
| 符号 | 含义 |
|------|------|
| B | Batch size |
| C | Channels |
| H, W | Height / Width |
| T | Time or sequence length |
| D | Feature dimension |
| N | Number of elements / tokens |
| E | Embedding dimension |
| K | Kernel size |
注释格式统一为:
# x: [B, C, H, W] <- Input tensor
# x: [B, 64, H//2, W//2] <- Conv2d(C, 64, k=3, s=2, p=1)
根据模型复杂度自适应调整输出结构:
简单模型(单文件即可表达,如 MLP、简单 CNN):
output/
├── model.py
└── README.md
中等模型(需要子模块拆分):
output/
├── model.py
├── modules/
└── README.md
复杂模型(完整复现,如 Transformer、检测网络):
output/
├── README.md
├── docs/
├── model.py
├── modules/
├── config.py
└── requirements.txt
如果论文存在训练、推理、配置三条明显边界,可以进一步拆出 train.py、infer.py、configs/,但仅在复杂度确实需要时这样做。
Reference: Supplementary Section X。更多 PDF 阅读要点和常见陷阱见 references/COMMON_PITFALLS.md。
einops(可选)timm(可选)在结束前确认:
nn.Module。references/CODING_STANDARD.md
何时读取:开始写代码前,或需要补全验证模板时。references/DOCUMENTATION_GUIDE.md
何时读取:需要生成 docs/、模块文档或 Mermaid 模板时。references/COMMON_PITFALLS.md
何时读取:读取 PDF、比对论文与代码、处理框架差异、查缺失细节时。development
Implement safe, behavior-preserving code refactors after inspecting the existing project. Use when the user asks to refactor code, split large files or modules, extract functions or methods, reduce duplicated logic, rename confusing classes/functions/variables, improve code comments, remove unused or dead code, or says 重构代码, 拆分模块, 提取方法, 减少重复代码, 优化命名, 优化注释, 删除未调用代码. For broad refactor requests, plan safe slices and wait for approval; for narrow scoped requests, directly implement the smallest verifiable slice.
development
Use only when the user explicitly asks for swarm, subagents, parallel agents, dynamic workflow, multi-agent orchestration, 多智能体编排, or when the task truly needs coordinated research plus implementation plus review plus verification packets. Do not use for ordinary code review, planning-only work, single-line bugfixes, routine audits, or migrations unless orchestration is requested or at least two independent workflow dimensions are present.
development
Run a code quality review focused on maintainability, structure, abstraction quality, file growth, branching complexity, boundary cleanliness, and refactoring opportunities. Use when the user asks for code quality review, code review, maintainability review, architecture quality review, PR code quality feedback, 代码质量审查, 代码质量 review, 可维护性审查, 架构质量审查, or review comments about code structure. Do not use for pure security review, formatting-only review, performance profiling, or implementation tasks unless the user also asks for a code quality review.
development
Plan-first brainstorming workflow that turns an idea into an approved Markdown implementation plan by default. Use when the user wants to brainstorm, design, scope, or plan a feature/spec before implementation. Spark explores project context, asks only blocking questions, writes the plan under the project root's .plannings/YYYY-MM-DD-feature-slug.md path, self-reviews it, and waits for user approval. Create an HTML or visual plan/spec only when the user explicitly asks for HTML, browser-viewable, or visual output; save the paired .html beside the Markdown plan.