academic-pdf-to-gfm

学术 PDF → GitHub GFM 转换

经过实战检验的工作流，可将学术／研究类 PDF 论文转换为可在 GitHub 上渲染的 GFM Markdown，包含内嵌图表、数学表达正确的 LaTeX，以及经过验证的输出。

实战检验案例：López de Prado（2026）《How to Use the Sharpe Ratio》——51 页、82 个公式、8 张图。

自我演进技能：此技能会在使用过程中不断改进。如果说明有误、参数发生偏移或需要变通方案，请立即修复此文件，不要拖延。仅针对真实且可复现的问题进行更新。

快速开始——逐页路由工作流

切勿尝试对整个 PDF 使用单一提取方法。 现代学术论文混合了文本、表格和图表，应逐页进行路由。

步骤 1：以 300 DPI 渲染所有页面

# Generate PNG for every page at 300 DPI
uv run --python 3.14 --with pymupdf python3 << 'EOF'
import fitz, os
doc = fitz.open('paper.pdf')
os.makedirs("pages", exist_ok=True)
for i in range(len(doc)):
    pix = doc[i].get_pixmap(matrix=fitz.Matrix(300/72, 300/72), alpha=False)
    pix.save(f"pages/page{i:04d}.png")
    print(f"Page {i}: {pix.width}×{pix.height}")
EOF

步骤 2：检测每页的类型

# Locate the Unlimited-OCR script. If installed via marketplace, it will be in the cc-skills plugin directory.
# If running from the cc-skills repo directly:
S=${S:-~/eon/cc-skills/plugins/unlimited-ocr/scripts/unlimited_ocr.py}

# For each page, run Unlimited-OCR and inspect the <|det|> markers
for img in pages/page*.png; do
    echo "=== $(basename $img) ==="
    uv run --no-project $S parse --input "$img" --collapse-math-spacing --quiet 2>&1 | \
        grep "<|det|>" | cut -d'>' -f2 | cut -d' ' -f1 | sort | uniq -c
done

步骤 3：路由每一页

根据检测到的 <|det|> 标记：

检测结果	路由至	命令
仅有 text（无 equation、image、chart）	pymupdf4llm 或 pdftotext	参见下文的工具比较
存在 equation 或 table	Unlimited-OCR（使用 --table-format pipe）	uv run --no-project $S parse --input page.png
存在 image 或 chart	分割并描述	使用 unlimited-ocr-segment-figure 技能 + 视觉模型
混合（table + image）	表格用 Unlimited-OCR，图像用分割	拆分输出，单独路由图像

步骤 4：组装并验证

# Concatenate all page outputs
cat pages/page*.md > paper-raw.md

# Extract embedded images (optional)
uv run --python 3.14 --with pymupdf python3 references/extract-images.py paper.pdf

# Validate math before pushing
node references/validate-math.mjs paper-raw.md --fix

---

工具比较（按页面类型）

单份学术 PDF 通常大多数页面都是原生数字文本，但少数页面公式密集或图表密集。 将整份文档视为单一类型会浪费工具能力，并在不知不觉中丢失内容。

逐页路由策略

对于 PDF 中的每一页：

1. 以 300 DPI 渲染为 PNG（这是确保 Unlimited-OCR 准确性的必要条件；150 DPI 会悄无声息地产生幻觉）
2. 检测页面类型，在本地运行 Unlimited-OCR（Apple Silicon 上每页约 2.4 秒）
3. 根据模型发现的内容进行路由：
   • 纯文本页面（无数学内容、无图表）：使用 pymupdf4llm 或 pdftotext 提取（成本更低，且能保留结构）
   • 包含公式的页面：使用 Unlimited-OCR 输出（返回真正的 LaTeX，例如 \left\{ \begin{array} ... \end{array} \right\}）
   • 包含图表的页面：使用 Unlimited-OCR 分割，并将每个面板交给视觉模型进行描述（已于 2026-07-31 验证：Unlimited-OCR 对图表返回空文本）
   • 回退方案：如果页面文本层提取的内容过少，则使用 Unlimited-OCR 重新处理

逐页路由为何重要

无声失败。 Unlimited-OCR 能以完美的边界框定位图表，但返回的框内字符数为零。如果用户将整份文档都路由为“类型 C，使用 Unlimited-OCR”，而输入中图表较多，就会丢失所有图表内容，却仍得到格式良好的结果，因此在检查输出之前看不出任何问题。

已验证（2026-07-31）：Unlimited-OCR 能检测图表（通过 <|det|>chart 标记），并返回完美的边界框，但框内没有文本。仅包含图表（没有文本、公式或表格）的页面确实会渲染为空；逐页路由可以发现这一问题，并将这些页面改用文本层提取或手动检查。

页面类型检测（在 300 DPI 下测量）

对每一页运行 Unlimited-OCR，并检查 <|det|> 标记：

如果输出包含	推断	路由到
text 区域，没有 equation 或 chart	纯文本页面	pymupdf4llm 或 pdftotext（备用方案：Unlimited-OCR）
equation 区域	含数学内容的页面	Unlimited-OCR（返回真实 LaTeX）
chart 区域	含图表的页面	分割并描述（使用 unlimited-ocr-segment-figure，然后交给图表读取模型）
输出为空（零字符，没有区域）	文本层可能无法处理该页面	使用 Unlimited-OCR 重试，或手动检查

示例：TimeMixer（ICLR 2024，28 页）

已于 2026-07-31 在 /Users/<you>/eon/<project>/data/papers/<hash>.pdf 上验证：

第 0 页 — 含摘要的标题页（路由到文本提取）

# Render at 300 DPI
uv run --python 3.14 --with pymupdf python3 -c "
import fitz
doc = fitz.open('timemixer-iclr-2024.pdf')
pix = doc[0].get_pixmap(matrix=fitz.Matrix(300/72, 300/72), alpha=False)
pix.save('page0.png')
"

# Detect structure
S=~/eon/cc-skills/plugins/unlimited-ocr/scripts/unlimited_ocr.py
uv run --no-project $S parse --input page0.png --collapse-math-spacing --quiet 2>&1 | head -15

输出（实际）：

<|det|>header [173, 33, 482, 49]<|/det|>Published as a conference paper at ICLR 2024
<|det|>title [172, 99, 818, 149]<|/det|>TIMEMIXER: DECOMPOSABLE MULTISCALE MIXING FOR TIME SERIES FORECASTING
<|det|>text [181, 170, 777, 200]<|/det|>Shiyu Wang \( ^{1,*} \) , Haixu Wu \( ^{2,*} \) , Xiaoming Shi \( ^{1} \) , Tengge Hu \( ^{2} \) , Huakun Luo \( ^{2} \) , Lintao Ma \( ^{1✉} \) , James Y. Zhang \( ^{1} \) , Jun Zhou \( ^{1✉} \)
<|det|>text [182, 200, 781, 243]<|/det|>\( ^{1} \) Ant Group, Hangzhou, China  \( ^{2} \) Tsinghua University, Beijing, China {weiming.wsy,lintao.mlt,peter.sxm,james.z,jun.zhoujun}@antgroup.com, {wuhx23,htg21,luhk19}@mails.tsinghua.edu.cn
<|det|>title [452, 279, 547, 293]<|/det|>ABSTRACT
<|det|>text [230, 311, 770, 575]<|/det|>Time series forecasting is widely used in extensive applications, such as traffic planning…

**路由决策：**仅检测到 header、title、text 区域。没有 equation，没有 chart → 路由到 pymupdf4llm 或 pdftotext（速度更快，且能保留结构）。

第 6 页 — 基准测试表格（路由到 Unlimited-OCR）

uv run --no-project $S parse --input page6.png --collapse-math-spacing --quiet 2>&1 | head -20

输出（实际）：

<|det|>text [187, 114, 812, 129]<|/det|>Table 1: Summary of benchmarks. Forecastability is one minus the entropy of Fourier domain.
<|det|>table [175, 131, 825, 287]<|/det|>| Tasks | Dataset | Variate | Predict Length | Frequency | Forecastability | Information |
| Long-term forecasting | ETT (4 subsets) | 7 | 96~720 | 15 mins | 0.46 | Temperature |
| Weather | 21 | 96~720 | 10 mins | 0.75 | Weather |
| Solar-Energy | 137 | 96~720 | 10min | 0.33 | Electricity |
…

**路由决策：**检测到 table → 保留 Unlimited-OCR 输出（已采用管道式 Markdown 格式，--table-format pipe 会将任何 HTML 转换为 Markdown）。

第 7 页 — 图和表格混合（仅将表格路由到 Unlimited-OCR）

uv run --no-project $S parse --input page7.png --collapse-math-spacing --quiet 2>&1 | head -30

输出（实际）：

<|det|>table [186, 174, 819, 384]<|/det|>| Case | Decompose | Past mixing | Future mixing | M4 | PEMS04 | ETTm1 |
…

**注意：**PDF 中的第 7 页包含 6 个嵌入的图像对象（已通过 PyMuPDF 验证），但 Unlimited-OCR 的 300-DPI 截图渲染未检测到 image 或 image_caption 区域。请通过 references/extract-images.py 单独提取图像，并交给视觉模型进行描述。

**路由决策：**检测到 table → 保留 Unlimited-OCR 输出；单独提取嵌入的图像，并交给视觉模型进行描述（参见 unlimited-ocr-segment-figure 技能）。

类型分类（历史资料，保留供参考）

类型 A — Word 生成的 PDF（类型 A：大多数现代学术论文）

特征：嵌入字体、文本可复制、复制粘贴时会出现 Unicode 数学字符（∑、π、α、β、γ、→）

数学编码：数学内容是 PDF 流中的 Unicode 文本——不是图像，也不是字形映射

结果：marker-pdf 等 OCR 工具无法提取 LaTeX——它们看到的是“γ₄”这样的文本，而不是 \gamma_4。它们可能返回空输出，或静默崩溃。

类型 B — LaTeX 生成的 PDF

特征：Computer Modern 字体、精确的数学间距、可找到 arxiv.org 源文件

数学编码：字形映射——可部分提取其结构

类型 C — 扫描件/图像 PDF

特征：所有页面都是光栅图像，没有可复制的文本

表格格式说明

Unlimited-OCR 返回的表格采用 HTML <table> 标记（根据百度测量，约占真实表格的 88%）。CLI 默认会将其转换为管道式 Markdown（--table-format pipe），适用于 Markdown 文档。如果要比较不同读取器的输出，管道式 Markdown 是规范格式。

---

工具对比

工具	页面类型	安装	优点	缺点
pymupdf4llm	纯文本，原生文本层	uv run --with pymupdf4llm	最能保留结构，速度快	数学公式以 Unicode 呈现，而非 LaTeX
pdftotext	纯文本，纯文本提取	brew install poppler	速度非常快，依赖极少	表格结构会完全丢失
Unlimited-OCR	表格、数学公式、混合页面	uv run --no-project (no install)	可生成真正的 LaTeX 公式、以 pipe-markdown 格式呈现的表格、布局框，精度达 300 DPI	图表会返回空文本；对此类内容请使用 segment-figure
markitdown	纯文本替代方案	uv run --with 'markitdown[pdf]'	结构保留效果不错	间距略大；数学公式限制与 pymupdf4llm 相同
marker-pdf	扫描版 PDF（仅限 Type C）	pip install marker-pdf	可处理扫描图像	切勿用于 Type A/B — 会静默失败（Unicode 文本错误）

建议：按页面分别选择工具：

• 纯文本页面 → pymupdf4llm（保留格式）或 pdftotext（速度快）
• 表格/数学公式页面 → Unlimited-OCR（返回真正的 LaTeX 和 pipe-markdown 表格）
• 包含图表的页面 → Unlimited-OCR（可检测图表，但会返回空文本；转交给 segment-figure 技能和视觉模型生成描述）
• 混合页面 → Unlimited-OCR（一次处理表格和布局检测；单独分割图像）

---

图像提取

保存为 references/extract-images.py：

import fitz, os, sys

doc = fitz.open(sys.argv[1])
os.makedirs("references/media", exist_ok=True)
saved = []
for page_num in range(len(doc)):
    for img_idx, img in enumerate(doc[page_num].get_images(full=True)):
        xref = img[0]
        base_image = doc.extract_image(xref)
        img_bytes = base_image["image"]
        if len(img_bytes) < 2048:   # skip icons/logos/watermarks/rules
            continue
        ext = base_image["ext"]
        fname = f"fig-p{page_num+1:02d}-{img_idx+1:02d}.{ext}"
        with open(f"references/media/{fname}", "wb") as f:
            f.write(img_bytes)
        saved.append((page_num+1, fname, base_image.get("width"), base_image.get("height")))
        print(f"Saved: {fname} ({len(img_bytes)//1024}KB, {base_image.get('width')}×{base_image.get('height')})")
doc.close()
print(f"\n{len(saved)} images saved to references/media/")

命名：fig-p{page:02d}-{idx:02d}.{ext} — 文件名中包含页码，便于匹配位置。

大小筛选：跳过 < 2 KB（这会筛出图标、水印和水平线）。检查所有 ≥ 2 KB 的图像——其中一些是装饰元素，但大多数是插图。

插入 Markdown：

![Figure 1: Variance of Sharpe ratio estimates](./media/fig-p12-01.png)

将其放在最邻近的章节标题或提及该插图的段落之后。

---

GitHub GFM 数学公式渲染规则

$$ 与 ```math ``` 的选择——根本原因

GitHub 的 Markdown 预处理器会在数学公式渲染器运行之前执行。 它会将 \\ 视为转义反斜杠，并将其折叠为 \。这会破坏显示数学公式中的 LaTeX 换行。

规则很简单：

公式类型	使用	原因
单行显示公式	$$...$$	不含 \\ → 对预处理器安全
多行（包含 \\、\begin{aligned}、矩阵）	```math ```	预处理器不会处理代码围栏
行内	$...$	标准

# BROKEN on GitHub — \\ stripped by pre-processor:

$$
\begin{aligned}
a &= b + c \\
d &= e + f
\end{aligned}
$$

# CORRECT on GitHub:

```math
\begin{aligned}
a &= b + c \\
d &= e + f
\end{aligned}
```

### Display Block Formatting Rules

- `$$` must be on its **own line** — not `$$formula$$` on one line
- **Blank line required** before AND after every `$$` block
- **Blank line required between consecutive** `$$` blocks
- These rules do NOT apply to `` ```math ``` `` blocks

### Supported/Unsupported LaTeX

See [references/github-math-support-table.md](./references/github-math-support-table.md) for the full table.

**Key things to avoid**:

| Command | Problem | Fix |
|---------|---------|-----|
| `\begin{align}` | ❌ Not supported by GitHub | Use `\begin{aligned}` |
| `\boxed{}` | ⚠️ Can cause raw LaTeX passthrough | Remove or use bold text |
| `\operatorname{}` | ⚠️ Active GitHub bug, inconsistent | Use `\text{}` or `\mathrm{}` |
| `\newcommand` | ❌ Was briefly available, then pulled | Expand all macros inline |
| `x^_y` | Superscript immediately before subscript | Write `x^{*}_{i}` with braces |

### Common Gotchas

- `\\[8pt]` vertical spacing inside `$$` → eaten by pre-processor → move to `` ```math ``` ``
- `\frac{1}{T}:\left(` → spurious colon after fraction → remove colon
- Pearson vs excess kurtosis: most finance formulas need Pearson (γ₄ = 3 for Gaussian), not excess. **Always document the kurtosis convention in the formula comment.**
- `\begin{pmatrix}` with `\\` → must use `` ```math ``` ``
- `\begin{cases}` with multiple rows → must use `` ```math ``` ``

---

## GitLab: No Workarounds Needed

**Empirically verified 2026-03-15** on GitLab CE 18.9.2. Confirmed by Comrak source code analysis.

GitLab uses the **Comrak** Rust parser with `math_dollars: true`. When Comrak encounters `$$`, it calls `handle_dollars` which slices the raw input buffer directly and stores it as a `NodeMath` AST node — CommonMark's backslash handler is never invoked on math content. The raw LaTeX is passed to KaTeX via `<span data-math-style="display/inline">` unchanged.

**Every GitHub workaround is unnecessary on GitLab:**

| GitHub problem | GitHub fix required | GitLab |
|----------------|---------------------|--------|
| `\\` in `$$` stripped → broken multiline | Use ` ```math ``` ` | `$$` works with `\\` |
| `\left\{` → `\left{` (delimiter error) | Use `\left\lbrace` | `\left\{` works |
| `\{...\}` set notation → invisible braces | Use `\lbrace...\rbrace` | `\{...\}` works |
| `\,` in `$$` → literal comma | Remove `\,` | `\,` works |
| `\,` in inline `$` → literal comma | Remove `\,` | `\,` works |

On GitLab you can write standard LaTeX without any platform-specific workarounds. If you're targeting GitLab (or hosting your own GitLab CE), skip all the `\lbrace`/`\rbrace` substitutions and ` ```math ``` ` conversions — plain `$$` with standard LaTeX is correct.

### GitLab.com Has a Hard 50-Span Per-Page Limit

**GitLab.com (SaaS) enforces a limit of 50 total math spans per page** (display + inline combined). After the 50th span, all subsequent equations silently fall back to raw LaTeX text. This limit exists to prevent DoS attacks and cannot be overridden on GitLab.com.

| Document math density | gitlab.com | Self-hosted CE |
|---|---|---|
| ≤ 50 total spans | ✅ Renders fully | ✅ |
| 51–100 spans | ⚠️ Partial render | ✅ |
| 100+ spans (academic papers) | ❌ Most equations raw text | ✅ Disable with `math_rendering_limits_enabled: false` |

**Validated on**: Sharpe ratio paper (341 spans) — breaks at span 51 on gitlab.com, renders fully on local CE.

**The W6 check in `validate-math.mjs`** warns when a file exceeds the limit.

**Summary: which platform to use**:
- **GitHub.com**: No math span limit. Use `\lbrace`/`\rbrace` workarounds (handled by `--fix`).
- **Self-hosted GitLab CE**: No limit (disable math_rendering_limits_enabled). No workarounds needed.
- **GitLab.com**: Only suitable for documents with ≤ 50 math spans.

### Self-hosting GitLab CE for Math-Heavy Documents

GitLab CE is free and runs on a single machine. On a 61 GB workstation with slim config:
- Memory footprint: ~3 GB (`puma['worker_processes'] = 2`, `sidekiq['concurrency'] = 5`, monitoring disabled)
- Push mirroring to GitHub: free on CE (syncs within 5 min)
- `glab` CLI: first-party, comparable to `gh`

```yaml
# docker-compose.yml — slim GitLab CE
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: unless-stopped
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://YOUR_IP:8929'
        puma['worker_processes'] = 2
        sidekiq['concurrency'] = 5
        prometheus_monitoring['enable'] = false
        alertmanager['enable'] = false
        node_exporter['enable'] = false
        redis_exporter['enable'] = false
        postgres_exporter['enable'] = false
        gitlab_exporter['enable'] = false
    ports: ["8929:8929", "8922:22"]
    volumes:
      - /srv/gitlab/config:/etc/gitlab
      - /srv/gitlab/logs:/var/log/gitlab
      - /srv/gitlab/data:/var/opt/gitlab
```

---

## Validation Pipeline

### Step 1: Install KaTeX Validator

```bash
bun add -g katex   # Bun-first per project policy
# or: npm install -g katex

第 2 步：每次推送前运行

# Validate only (exit 1 on errors)
node references/validate-math.mjs your-file.md

# Validate + auto-fix correctable issues
node references/validate-math.mjs your-file.md --fix

脚本位于 references/validate-math.mjs。它分两层运行：

第 1 层 — KaTeX 语法：解析 $、$$、```math ``` 块中的错误 第 2 层 — GFM 结构（KaTeX 能通过，但 GitHub 会出问题）：

代码	严重性	问题	自动修复
E0	错误	$$ 块中的 \! \, \; \{ \} — 预处理器会移除反斜杠 → 连锁解析错误	✅ 移除间距命令；\{→\lbrace
E0b	警告	行内 $...$ 中的 \{ \} \, — 隐形花括号或正文中的逗号字面量	✅ → \lbrace/\rbrace；移除 \,
E1	错误	含有 \\ 的 $$ 块 — GitHub 预处理器会移除反斜杠	✅ → ```math ```
E2	错误	连续的 $$ 块之间没有空行 — 分隔符会引发连锁错误	✅ 添加空行
W1	警告	$$ 或 $ 块中的裸 ^* — Markdown 斜体配对会吞掉 *	✅ → ^{\ast}
W2	警告	\begin{align} — GitHub 不支持	✗ 手动
W3	警告	\boxed{} — 可能导致原始 LaTeX 直接透传	✗ 手动
W4	警告	\operatorname{} — GitHub 支持情况不一致	✗ 手动

E0 最危险：只要一个 $$ 块出错，其 $$ 分隔符就会作为字面文本显示，产生一个孤立的 $，导致后续所有行内 $...$ 配对错位。一个损坏的公式就会影响整篇文档。

\{/\} 陷阱：在 $$ 块中，\left\{ 会变成 \left{（无效的 KaTeX 定界符 → “缺少或无法识别的定界符”），而 \{...\} 集合表示法会变成不可见的分组。修复方法：使用 \lbrace/\rbrace（基于字母，不受 CommonMark 影响）。这会影响每个使用集合表示法的公式，例如 \{\hat{SR}_k\} 或 \min_T\left\{...\right\}。

遇到错误时退出码为 1（适用于 CI）。警告不会阻止 CI，但应进行检查。

本地预览工具

# GitHub-accurate hot-reload preview
bun add -g @hyrious/gfm
gfm your-file.md --serve

# Offline binary (gh extension)
gh extension install thiagokokada/gh-gfm-preview
gh gfm-preview your-file.md

VS Code 扩展：

• shd101wyy.markdown-preview-enhanced — 最接近 GitHub 渲染效果
• bierner.markdown-preview-github-styles — GitHub CSS 样式

---

多 Agent 对抗式公式验证

对于包含 10 个以上公式的论文，请使用以下多 Agent 模式：

阶段 1 — 并行提取

• Agent A：使用 pymupdf4llm 提取正文，从 PDF 截图转录数学内容
• Agent B：提取并分类所有图片

阶段 2 — 并行验证

• Agent C：根据参考实现验证公式（如果存在代码/仓库）
• Agent D：数值抽查 — 计算论文中的示例值并进行比较

阶段 3 — 处理差异

• 对每项差异：写入 /tmp/paper-discrepancy/eq-{N}.md
• 启动解析 Agent，在网上搜索权威的第三方来源
• 权威性规则：暂定认为论文比代码实现更权威；若结论不一致，则以第三个独立来源裁定

阶段 4 — 谨慎应用

• 仅将高置信度修复应用于 Markdown
• 对于中置信度修复：先启动独立审查 Agent，再修改文件
• 即使未修复，也要记录所有差异 — 未来读者需要了解这些情况

---

反模式

反模式	失败原因	修复方法
在 $$ 块中使用 \!\left( 或 \,	GH 预处理器会在 KaTeX 之前将 \! 去掉→!——!\left( 会导致 KaTeX 崩溃，进而影响所有内容	删除 \!、\,、\;（它们只用于调整间距）——或使用 ```math ```
在 $$/$ 块中使用 \left\{ 或 \{...\}	\{→{（CommonMark 转义），因此 \left\{→\left{ =“Missing delimiter”错误，而 \{x\} 渲染时不会显示大括号	替换为 \left\lbrace、\right\rbrace、\lbrace、\rbrace
$$\begin{aligned}...\\...\end{aligned}$$	GH 预处理器会去掉 \\	使用 ```math ```
在 Word PDF 上依赖 marker-pdf	不返回任何输出或不包含公式（Unicode 错误）	将其作为截图读取，手动转录
在显示数学公式中使用 \begin{align}	GitHub 不支持	替换为 \begin{aligned}
\operatorname{Cov}	GH 当前存在的错误——有时会直接显示原始代码	使用 \text{Cov} 或 \mathrm{Cov}
仅进行 KaTeX 验证，不转换为 ```math ```	KaTeX 验证通过，但 GH 预处理器仍会破坏 \\	还要转换所有多行块
使用 \boxed{} 突出显示	可能导致 GitHub 直接显示原始 LaTeX	使用粗体文本或引用块提示
在期望使用 Pearson 定义的公式中使用超额峰度	方差公式会无提示地低估约 50%	始终注明所用定义；使用 scipy.stats.kurtosis(fisher=False)
连续的 $$ 块之间没有空行	GitHub 会将它们合并成一个错误的块	在每个块之间添加空行
推送后才运行验证	错误会出现在公开仓库中	每次推送前都在本地验证（--fix 会自动修正 E0/E1/E2）

---

参考资料

文件	用途
validate-math.mjs	用于 GFM 文件的 KaTeX 批量验证器
pdf-type-detection.md	检测 PDF 类型的详细指南
github-math-support-table.md	完整的 LaTeX 支持/不支持情况表

---

相关技能

技能	关联说明
unlimited-ocr-parse-document	在本地从 PDF 中提取文本/数学内容（A/C 类 PDF，约 2.4 秒/页）
unlimited-ocr-segment-figure	裁剪多面板图（图表、示意图），供下游模型使用
pandoc-pdf-generation	反向转换：markdown → PDF
documentation-standards	GFM 格式规范
quant-research:opendeviation-eval-metrics	实例演示：references/how-to-use-the-sharpe-ratio-2026.md

执行后复盘

此技能完成后，请在结束任务前进行复盘：

0. 确认自身位置。 — 在编辑前找到此 SKILL.md 的规范路径。
1. 哪里失败了？ — 修复导致问题的指令。
2. 哪些方面比预期更有效？ — 将其列为推荐做法。
3. 哪里出现了偏差？ — 修复任何与实际情况不符的脚本、参考资料或依赖项。
4. 记录下来。 — 在演进日志中记录触发原因、修复内容和证据。

请勿推迟。下一次调用将继承你留下的内容。