GitHub 儲存庫、Issue、PR 轉 Markdown

#github#markdown#developers#code#issues#pull-requests#ai#claude#obsidian

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：Minibase（最快，一鍵）

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

運作原理：

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

你將獲得：

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

會被去除的：

  • GitHub 導覽、側邊欄和頁尾
  • 每則留言下方的反應表情列
  • 「X hidden items」摺疊（Minibase 會展開並包含它們）
  • 來自 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 貼上到 ClaudeMinibase --- 一鍵，結構化輸出
封存長的 Discussion 串Minibase --- 巢狀和中繼資料都被保留
建構儲存庫文件的離線副本git clone --- README 已經是 Markdown
在多個儲存庫間批次匯出 IssueGitHub API + 指令碼 --- 程式化
快速儲存單個 READMEMinibase --- 跳過複製步驟
個人筆記用的一次性快速參考手動複製 --- 適用於短頁面

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

Minibase 處理的邊緣情況

  • 私有儲存庫。 Minibase 使用你已登入的瀏覽器工作階段。如果你的 GitHub 帳號能看到儲存庫，Minibase 就能讀取。無需設定 API token。
  • 自架 GitHub Enterprise。 在任何 github.* 網域樣式下運作。Minibase 讀取渲染後的頁面，所以只要 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 串。 對於有數百則留言的串，Minibase 保留 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 在建議修正時現在有了上游上下文
  • Minibase Vault --- 如果你連接了一個，每次 GitHub 儲存都會自動落在那裡，儲存庫作為標籤，並有指向其他已儲存串的反向連結

常見問題

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

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

它能擷取 500 則留言串中的每一則留言嗎？ 預設情況下，Minibase 保留 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 上的 Minibase Vault。

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

相關的 Minibase 指南

Continue reading

準備好更智慧地儲存了嗎？

一鍵將任意網頁轉換為 Markdown。

新增到 Chrome