如何將 GitHub 儲存庫、Issue 和 PR 儲存為 Markdown（2026 指南）

GitHub 的內容分散在 README、Issue、PR、Discussion 和 Gist 中 --- 把其中任何一個餵給 LLM 都是痛苦的，除非它是 Markdown 格式。README 已經在那兒了，沒錯，但你真正需要的部分是那個有 80 則留言的 Issue 串，裡面有人終於找出了解決方法；或者那個解釋了 breaking change 的 PR；或者那個解釋了 API 為什麼這樣設計的 Discussion。這些東西，沒有一個是離「可用的 Claude 上下文」只有一鍵之距的。

本指南涵蓋將 GitHub 內容轉換為乾淨 Markdown 的所有方法 --- 從單個 README 到漫長的 PR 討論，再到整個儲存庫。

為什麼要把 GitHub 內容儲存為 Markdown？

Markdown 是這種格式：無論程式碼知識需要去往何處，它都能運作：

• 餵給 LLM --- Claude、ChatGPT、Gemini 和本地模型都原生地把 Markdown 讀作上下文，程式碼區塊和語言識別字都被保留
• 放進 Obsidian 或 Notion --- 每個 Issue 或儲存庫一個檔案，完全可搜尋，標題正確
• 在貼文被鎖定或刪除前封存 --- 維護者關閉 Issue，儲存庫變成私有，你的筆記不應該依賴 GitHub 的可用時間
• 建構離線文件 --- 把多個儲存庫的 README 編譯成一個參考
• 在長串中引用特定留言 --- 在 200 則留言的 Issue 裡跳回那則唯一有用的回覆只差一次搜尋

2026 年驅動大部分 GitHub-到-Markdown 流量的使用案例是第一個：開發者想就一個函式庫、一個 bug 或一個設計決策問 LLM，而貼上 URL 並不會把模型需要的東西給它。

方法 1：Save（最快，一鍵）

Save 是一個 Chrome 擴充功能，一鍵就能把任意 GitHub 頁面轉換為 Markdown 檔案。它讀取渲染後的頁面，在可能的情況下重建原始 Markdown，產生可以直接落入 Claude、Obsidian 或你的文件資料夾的東西。

運作原理：

1. 在 Chrome 中開啟 GitHub 頁面 --- 儲存庫、Issue、PR、Discussion、Gist 或 wiki
2. 點擊工具列中的 Save 擴充功能圖示
3. .md 檔案立刻下載（如果連接了 Save Vault，則落入其中）

你將獲得：

• 程式碼區塊、表格和標題完好的 README
• Issue 和 PR 的標題、本文、狀態、巢狀留言
• 巢狀結構正確的 Discussion 串
• 連結的引用 Issue 和 @mentions 都被保留
• 標籤、里程碑、負責人作為 frontmatter
• 程式碼區塊保留其語言識別字（這樣 Markdown 檢視器中的語法突顯才能運作）
• 支援 Gist（單檔案和多檔案）
• 包含儲存庫、作者、日期、URL 和狀態（open/closed/merged）的 frontmatter

會被去除的：

• GitHub 導覽、側邊欄和頁尾
• 每則留言下方的反應表情列
• 「X hidden items」摺疊（Save 會展開並包含它們）
• 來自 CI、dependabot 和 stale-bot 的機器人留言（可切換）
• 僅重複前一則留言的引用回覆

最適合： 用 AI 偵錯的開發者、編寫文件的技術作家、封存討論串的研究者、任何建構個人知識庫，記錄函式庫在實際使用中如何運作的人。如果你需要乾淨的 Markdown，要貼上到 Claude 或在 Obsidian 中閱讀，這是最乾淨的路徑。

輸出範例

儲存一個 Issue 串會產生：

---
title: "Memory leak when using streaming with large responses"
repo: anthropics/anthropic-sdk-python
number: 412
author: alice-dev
state: closed
labels: ["bug", "streaming", "memory"]
assignees: ["bob-maintainer"]
milestone: "v0.34.0"
created: 2026-03-12
closed: 2026-03-18
url: https://github.com/anthropics/anthropic-sdk-python/issues/412
---

## Issue

When streaming responses larger than ~50MB, memory grows linearly and is
never released. Reproduced on Python 3.11 and 3.12, macOS and Linux.

**Reproduction:**

\`\`\`python
from anthropic import Anthropic

client = Anthropic()
with client.messages.stream(...) as stream:
    for text in stream.text_stream:
        print(text, end="")
\`\`\`

After the loop ends, `tracemalloc` shows the buffer is still resident.

## Comments

### bob-maintainer (maintainer) --- 2026-03-13

Confirmed. The internal buffer in `_streaming.py` isn't being cleared on
context exit. Looking at it now.

### alice-dev --- 2026-03-14

Thanks. Workaround for anyone hitting this: call `stream.close()`
explicitly before the `with` block exits. References #389.

### bob-maintainer (maintainer) --- 2026-03-18

Fixed in #418, released in v0.34.0. Closing.

那個檔案離「成為可用的 Claude 上下文」只差一次貼上，離「成為永久的 Obsidian 筆記」只差一次按鍵。

方法 2：GitHub 的 API + 指令碼

GitHub 的 REST 和 GraphQL API 公開了一切 --- README、Issue、留言、PR diff。你可以寫一個指令碼來取得並轉換。

gh api repos/OWNER/REPO/issues/412 --jq '.body' > issue-412.md
gh api repos/OWNER/REPO/issues/412/comments --jq '.[].body' >> issue-412.md

最適合： 建構文件管道的工程團隊，以及在多個儲存庫間指令碼化批次匯出 Issue 或 PR 的人。

這種方法的問題：

• API 回傳原始的 Markdown 內文，但把標題 + 內文 + 留言 + 中繼資料縫合成一個可讀檔案，這是你自己的問題
• Frontmatter（標籤、里程碑、負責人、狀態）需要多次 API 呼叫和手動組裝
• 留言排序、作者歸屬和巢狀回覆鏈需要自訂邏輯
• 大儲存庫很快就會觸發速率限制（已驗證 5,000 請求/小時）
• Discussion 位於 GraphQL API 後面，不是 REST，所以指令碼變成了兩個管道
• PR diff 和 review 留言又是獨立的端點

如果你在建構管道，這是正確的方法。對於單個 Issue 來說是大材小用。

方法 3：Clone + 本地轉換（用於整個儲存庫）

對於 README 和儲存庫內文件，最簡單的方法是複製並直接讀取檔案 --- 它們在磁碟上已經是 Markdown。

git clone https://github.com/OWNER/REPO.git
cd REPO
cat README.md docs/*.md > combined.md

最適合： 想要離線存取儲存庫文件的開發者，或者需要把整個文件樹餵給長上下文 LLM 的人。

這種方法的問題：

• 只對儲存在儲存庫中的內容有效（README、/docs、單獨複製的 wiki）
• 無法擷取 Issue、PR 或 Discussion --- 那些活在 GitHub 的資料庫裡，不在 git 樹裡
• 文件和 Issue 之間的交叉引用會失效（#412 不會在本地解析）
• README 中的圖片 URL 經常指向 user-attachments.githubusercontent.com，離線使用時需要重寫
• 如果你想要單一檔案，仍然需要一個指令碼來合併和清理

適合「我想要離線文件。」對「我想要這個有 80 則留言的 Issue 串」來說，這是錯的工具。

方法 4：從瀏覽器手動複製

蠻力法：開啟頁面，全選，貼上到 Markdown 編輯器中，清理。

步驟：

1. 在瀏覽器中開啟 Issue 或 PR
2. 選擇相關部分（或整個頁面）
3. 貼上到 Obsidian、VS Code 或另一個 Markdown 編輯器
4. 手動剝離 UI 雜訊（反應、導覽、側邊欄）
5. 重新加入程式碼圍欄，修正留言順序，加入 frontmatter

這種方法的問題：

• 程式碼區塊失去了語言識別字和語法突顯
• 留言的作者身分和時間戳記最終成為自由格式的文字，而不是結構化的 frontmatter
• README 中的表格常以製表符分隔的純文字形式貼上
• 反應列（+1 heart rocket）滲入內文
• 巢狀的 Discussion 巢狀塌縮成扁平文字
• 長串要花 10 分鐘；乘以你儲存的每一個 Issue

對短 README 有效。對真正的 Issue 串就崩了。

你該用哪種方法？

情境	最佳方法
把 Issue 或 PR 貼上到 Claude	Save --- 一鍵，結構化輸出
封存長的 Discussion 串	Save --- 巢狀和中繼資料都被保留
建構儲存庫文件的離線副本	git clone --- README 已經是 Markdown
在多個儲存庫間批次匯出 Issue	GitHub API + 指令碼 --- 程式化
快速儲存單個 README	Save --- 跳過複製步驟
個人筆記用的一次性快速參考	手動複製 --- 適用於短頁面

對大多數開發者來說 --- 特別是任何把 GitHub 內容用作 AI 上下文的人 --- Save 就是答案。它零設定就能產生最乾淨的 Markdown，處理長 Issue 串的速度與 README 相同。

Save 處理的邊緣情況

• 私有儲存庫。 Save 使用你已登入的瀏覽器工作階段。如果你的 GitHub 帳號能看到儲存庫，Save 就能讀取。無需設定 API token。
• 自架 GitHub Enterprise。 在任何 github.* 網域樣式下運作。Save 讀取渲染後的頁面，所以只要 UI 是 GitHub 的標準版面，轉換就有效。
• GitHub Discussions vs Issues。 兩者都支援。Discussion 取得其類別作為 frontmatter（category: Q&A、category: Announcements），巢狀回覆作為串結構。
• PR diff 和檔案變更。 相關時保留。PR 內文、review 留言和檔案層級對話都被包含。原始 diff 本身被總結而不是傾倒 --- 你通常不想在 LLM 上下文中有 5,000 行的 diff。
• 反應表情列。 剝離。每則留言下的 +1、heart、rocket 列，對除了趨勢分析以外的一切都是雜訊。
• 非常長的 Issue 串。 對於有數百則留言的串，Save 保留 Issue 內文、維護者回應、解決留言和一個 「Other comments: N omitted」 標記。如果你需要每則回覆，可切換為完整包含。
• Wiki 頁面。 支援儲存庫 Wiki。每頁變成一個 Markdown 檔案，內部 Wiki 連結被重寫為相對路徑。
• 專案看板。 專案看板檢視被擷取為結構化清單：欄 → 卡片標題 → 連結的 Issue/PR。在 sprint 關閉前封存很有用。
• 機器人留言。 Dependabot、stale-bot、CodeQL、GitHub Actions --- 都被偵測到並可切換。預設關閉，因為它們幾乎總是增加雜訊。
• 帶語言識別字的程式碼區塊。 三反引號語言標籤（```python、```rust）被保留，這樣任何 Markdown 渲染器或 LLM 都能取得語法突顯提示。
• Gist。 單檔案和多檔案 Gist 都支援。多檔案 Gist 變成單個 Markdown 檔案，每個檔案作為一節。

把它和你的工作流配對

Markdown 輸出在你需要的任何地方都能運作：

• Claude / ChatGPT / Gemini --- 把檔案貼上進去，問「這個 Issue 為什麼被關閉？」或「總結這個 PR 中的設計決策」
• Obsidian --- 丟進你的 vault，把 Issue 連結到相關筆記，在每個你儲存過的函式庫中搜尋
• Notion --- 直接貼上，標題、表格和程式碼區塊都能正確渲染
• Cursor / Claude Code --- 把檔案丟到專案中，AI 在建議修正時現在有了上游上下文
• Save Vault --- 如果你連接了一個，每次 GitHub 儲存都會自動落在那裡，儲存庫作為標籤，並有指向其他已儲存串的反向連結

常見問題

Save 能在私有儲存庫上運作嗎？ 是的。它使用你已登入的瀏覽器工作階段，所以你的 GitHub 帳號能看到的任何東西，Save 都能儲存。不需要 PAT 或 OAuth 設定。

它能在 GitHub Enterprise（自架）上運作嗎？ 是的。任何 GitHub UI 都被支援，與網域無關。如果你公司執行 github.acme-corp.com，Save 在那裡也運作。

它能擷取 500 則留言串中的每一則留言嗎？ 預設情況下，Save 保留 Issue 內文、維護者回應和解決方案。要取得完整串，請在儲存前在擴充功能選單中切換 「Include all comments」。

程式碼區塊格式化正確嗎？ 是的。三反引號圍欄和語言識別字被完全保留。```python 保持 ```python，這樣任何 LLM 或 Markdown 檢視器都能取得語法突顯。

它能處理 PR diff 嗎？ PR 內文、review 留言和檔案內聯對話都被包含。原始 diff 按檔案總結，而不是整體傾倒 --- 通常是你想要的 LLM 上下文。如果你需要完整修補，請切換 「Include raw diff」。

那 GitHub Discussions 呢？ 完全支援。類別、巢狀回覆和標記為已回答狀態全部以結構化 Markdown 形式出現。

它保留 @mentions 和交叉引用嗎？ 是的。@username 提及保持為純文字提及，#123 Issue 引用按原樣保留。如果你想要它們作為返回 GitHub 的超連結，擴充功能可以在儲存時重寫它們。

它能在 GitHub 行動站點上運作嗎？ 擴充功能僅適用於桌面 Chrome。在行動端，複製 URL 在桌面開啟，或者分享到 Mac 上的 Save Vault。

費用是多少？ Save 有免費層，你可以在幾個儲存庫和 Issue 上試用。在那之後，一個小額訂閱涵蓋更重的使用。

相關的 Save 指南

• 將 Stack Overflow 答案儲存為 Markdown --- 已採納的答案，含程式碼區塊和留言
• 將 ChatGPT 對話儲存為 Markdown --- 每一輪，程式碼區塊完好
• 將 Claude 對話儲存為 Markdown --- artifacts、程式碼和推理都被保留
• 將 YouTube 影片儲存為 Markdown --- 字幕、摘要、時間戳記、章節標記