Markdown 引用區塊：引文、多段落與清單

Markdown 引用區塊以 > 加一個空格開頭。在每一行被引用內容的開頭都加上這個標記，可以讓原始碼更易閱讀和編輯。

> 修訂後的安裝指南已準備好，可以開始審閱。

結果是一個引用段落，而不是程式碼區塊。它的框線、縮排和色彩取決於頁面或文件佈景主題。引文中的文字仍然是普通 Markdown，因此可以包含強調、連結、清單和其他文件結構。

使用 Markdown 檢視器試驗這些範例；需要一份可編輯的審閱副本時，再透過 Markdown 轉 Word 轉換器匯出文件。

用多行原始碼引用一個段落

對於較長的引文，請重複使用標記：

> 修訂後的安裝指南已準備好，可以開始審閱。
> 核准發行之前，請檢查必要條件。

在本站預覽中，這兩行原始碼會組成一個段落。原始碼中的換行不一定會強制在顯示時換行。如果文字必須分成兩行，請加入明確的換行標記：

> 文件審閱\
> 指派給發行負責人

反斜線放在換行字元之前；下一行仍以引用標記開頭。強制換行和段落分隔的差異，請參閱 Markdown 換行指南。

在段落之間原本為空的那一行上放一個引用標記：

> 第一版草稿介紹安裝流程。
>
> 第二版草稿補充疑難排解步驟和範例。

這會產生一個包含兩個段落的引用區塊。在分隔行保留 >，可以清楚表明這些內容屬於同一組，尤其方便其他人日後編輯。

要繼續寫自己的正文，請留一個空白行，然後在不加引用標記的情況下繼續：

> 審閱意見要求縮短安裝章節。

我們已將詳細的設定說明移到附錄。

不要在沒有加入空白行的情況下，直接刪掉接續行前的 >。某些 Markdown 剖析器會把它視為引用段落的惰性延續。CommonMark 引用區塊規範說明了這種行為。明確的標記和清楚的空白行更有利於協作者維護文件。

引用區塊內容可以使用一般行內格式：

> **審閱意見：** 移轉步驟需要一個可執行的範例。
> 請參閱[發行檢查清單](https://example.com/checklist)。
>
> 來自 2026 年 9 月文件審閱的回饋。

Markdown 不會為最後一行賦予特殊的引文來源角色。它只是引用區塊中的普通段落內容。需要時請註明來源、作者和連結；轉載他人的文字之前，請確認使用權限。

引用區塊也不會自動加入字面上的引號。如果最終文件需要引號，請自行輸入。如果只是在自己的句子中嵌入一小段引文，直接使用普通引號可能就足夠，無需建立獨立的區塊。

對於外層引文中的引用內容，再增加一級 >：

> 審閱者整理了先前的要求：
>
> > 加入一個完整的設定檔範例。
>
> 更新後的草稿現在已包含該範例。

報告中的巢狀層級應盡量少。過深的引用巢狀結構會壓縮文字可用寬度，使 PDF 和 Word 的版面更難閱讀。

引用區塊內的清單需要在每一行都保留標記：

> 審閱指出了兩項修改：
>
> - 說明所需權限。
> - 加入疑難排解章節。

反過來，如果要在清單中加入引用，請將引用縮排到清單項目正文下方：

- 文件回饋

  > 發行之前加入疑難排解章節。
- 發行檢查清單

如果引用顯示在清單項目之外，請對照 Markdown 縮排指南中的範例檢查縮排。

GitHub 支援基於引用語法的特殊提示框，包括以下形式：

> [!NOTE]
> 修改設定之前，請先備份。

GitHub 在提示框參考文件中列出了支援的類型。提示框的色彩和圖示屬於平台功能，並不是所有 Markdown 引文都具有的特性。

本站轉譯器不會加入 GitHub 的提示框樣式。這個範例仍會顯示為引用區塊，並保留可見的 [!NOTE] 標籤。對於需要在不同目標平台上都清楚易讀的文件，請使用明確的粗體標籤：

> **注意：** 修改設定之前，請先備份。

這樣即使沒有特殊的提示框擴充功能，也能理解內容的含義。同樣的方式也適用於警告、審閱決議或編輯註記。

如果 > 原樣顯示，請檢查範例是否位於反引號、圍欄程式碼區塊或縮排程式碼區塊中。這些環境本來就是用來展示原始碼。在標記前加上反斜線也會將其跳脫。

如果過多文字被納入引用，請在應該恢復到引用區塊之外的段落前加一個空白行。如果巢狀內容難以理解，請減少巢狀層級，並把來源說明寫成普通段落。

最後，開啟匯出的 DOCX，檢查長引文以及引用區塊中的清單。瀏覽器中的左側框線可能與 Word 文件的段落樣式不同。當需要區分原始碼格式問題和匯出樣式問題時，可以使用 Markdown 轉 HTML 工具檢查中間結構。