若要記錄您使用字型配對產生器時的步驟，請建立一份簡短的紀錄，內容包含您所選的字型配對、您輸入的範例文字、您複製的精確 CSS2 樣式表連結，以及關於隱私、授權與效能的任何審查註記。一份有效的紀錄能回答四個問題：您選擇了哪一組標題與內文字型、您測試了哪些實際的產品或標題文字、您貼進專案的是哪一段程式碼，以及您針對後備字型、語言涵蓋範圍與第三方請求做出了什麼決定。Google Fonts Pair Finder 將配對選擇與程式碼片段產生功能保留在瀏覽器本機執行，只有即時預覽會向 Google Fonts 發出網路請求以取得所選的字重。這道界線讓您能撰寫一份乾淨的紀錄，而不會將私密的範例文字暴露在所產生的網址中，因為您在預覽中輸入的內容永遠不會隨著產生的請求一起傳出，而同一份紀錄也能在設計師、開發人員與審查人員之間傳遞，無需重新輸入整個工作流程。空白輸入也會使用可見的本機占位符，而不會當機，因此紀錄永遠能反映團隊實際看到的同一段程式碼。八組精選配對涵蓋了多種對比類型，每一組僅從 Google Fonts 資料庫請求一個經過稽核的字重，因此您儲存的參考資料就是該工具用來建立程式碼片段的同一份參考資料。
字型配對工作流程紀錄中應包含哪些內容
一份文件紀錄在同時擷取設計決策與實際產生的具體產出時最為實用。針對字型配對工作流程，有四項資訊會一起傳遞：配對標籤、您輸入的代表文字、您選擇複製的輸出內容，以及描述您在合規、效能與語言涵蓋範圍上所做決定的審查欄位。若只儲存最終的 CSS 而未儲存背後的理由，會讓這份紀錄在設計審查中無法被有效辯護；反之，若只儲存預覽的螢幕截圖，則會讓下一位接手的人無法重現相同的結果。
Google Fonts Pair Finder 會輸出三項產出物，紀錄中應分別加以引用。第一項是一個 Google Fonts CSS2 樣式表連結，其中每個字型系列各有一個 family 參數，並附帶 display=swap 指令，您可以對照官方的 Google Fonts CSS2 說明文件 來確認請求語法是否正確。第二項是兩個可重複使用的 CSS 類別，分別將所選字重套用至標題規則與內文規則，每個類別後方皆接有一個通用的 serif 或 sans-serif 後備字型。第三項則是一個完整的程式碼片段，會將 link 元素與 style 區塊結合在一起。這三項產出物在專案中各有不同的歸屬位置，紀錄中應標明實際交付的是哪一項。
如何使用 Google Fonts Pair Finder 記錄您的步驟
記錄一份字型配對工作流程僅需幾個步驟，但每個步驟都會擷取不同的產出物；只要略過任何一步，就會讓下一位審查人員必須自行猜測。Google Fonts Pair Finder 是圍繞著三個複製動作所建構的，因此文件記錄也應依照相同順序對應這三個動作，讓紀錄能依實際作業發生的先後順序由上往下閱讀。下列步驟假設您是從單一 wiki 頁面或共用文件進行操作，但同樣適用於設計系統儲存庫中的 Markdown 檔案。
- 開啟 Google Fonts Pair Finder，從八組精選配對中挑選一組作為紀錄的起點，然後在紀錄項目頂端寫下所選的配對名稱，以便日後每位審查人員都能找到這項決策。
- 將代表性的標題或產品文字輸入至預覽欄位，最多 240 個字元，並將該字串原封不動地複製到紀錄中，讓審查人員日後能在無須猜測測試內容的情況下，重新執行相同的比較。
- 在即時預覽中比較標題與內文的節奏，接著透過想像緩慢或遭封鎖的字型請求來測試後備行為，並逐一檢視專案所支援的每種文字與語言，讓紀錄能在同一句話中註記任何混合的後備設定。
- 從產生器中複製連結、CSS 或完整的程式碼片段，並將各項產出物分別貼入文件中各自標示的區段。連結會放入 HTML 的 head 中，兩個 CSS 類別會放入樣式表內，而完整程式碼片段則應放在審查人員預期能同時看到兩者的位置。
- 在將該項目標記為可交付之前，加入隱私、授權、CSP 與效能的審查欄位。這些註記說明的是決策本身，而非工具本身，也是紀錄在倉促完成時最常被略過的部分。
- 一併儲存剪貼簿的後備路徑：若瀏覽器或嵌入政策拒絕剪貼簿存取權限，同一段文字仍會保持可見以便手動選取，因此文件記錄中應註明這些複製按鈕屬於盡力而為，並不保證一定成功。
值得儲存在紀錄中的配對參考資料
工具中的八組配對各自擁有明確的字型系列與字重紀錄，取自 Google Fonts 資料庫並在 Fontsource 中經過交叉核對。產生器僅請求各字型系列所顯示的單一字重，因此紀錄可以直接逐字引用這些字重，而無須虛構額外的請求。將參考資料儲存在紀錄中能避免團隊日後出現偏差，因為審查人員有時會在假設「愈粗愈好」的情況下自行新增字重值。
| 配對類別 | 範例參考資料 | 涵蓋內容 |
|---|---|---|
| 編輯型對比 | Playfair Display 700 + Source Sans 3 400 | 襯線展示字搭配中性無襯線內文字 |
| 幾何 + 文學 | 幾何展示字搭配文學風格內文 | 現代標題對比表現力豐富的段落 |
| 壓縮 + 襯線 | 壓縮型展示字重搭配襯線內文字 | 緊湊的海報標題搭配易讀的內文 |
| 全無襯線產品 | 兩個為產品 UI 調校過的無襯線字型系列 | 不使用襯線內文的單一風格介面 |
| 海報與公用 | 以 Bebas Neue 400 取代無法取得的粗體 | 單一字重的展示標籤與公用文字 |
每組配對上的風格標籤（例如 classic 或 modern）屬於編輯建議而非字型設計法則，文件記錄應將其視為一段情境說明，而非具拘束力的規則。適用於某個品牌、語言、視窗或內容密度的配對，在其他情境下可能會失效，因此紀錄中應永遠註明實際測試時所採用的特定品牌、內容類型與視窗大小。
合規、隱私與效能審查
一份有用的紀錄會將複製後的審查視為工作流程的一部分，而非獨立的稽核環節。每一個項目皆應列出相同的四個審查欄位，即便內容簡短亦然，因為日後加入的審查人員並不想從零重建整段對話。這四個欄位恰好對應即時預覽無法為您回答的問題。
| 欄位 | 應填寫內容 | 重要性 |
|---|---|---|
| 隱私 | 訪客的瀏覽器是否會連線至 Google 所控管的端點 | 部分司法管轄區與同意機制設計要求設置第三方請求閘道 |
| 授權 | 每個選定字型系列所適用之精確開放授權，並依專案逐一驗證 | 開放授權條款會因字型系列與版本而異，嵌入式或再散布的模板則負有更嚴格的義務 |
| CSP | 樣式表主機與字型檔案主機是否符合政策規範 | 遠端字型遭封鎖是正式環境中後備字型啟動的最常見原因 |
| 效能 | 採用所選配對對實際頁面進行量測，而非僅憑預覽判斷 | 兩個字型系列的請求並不必然比系統字型堆疊更快 |
該產生器不會重現授權文字、不會承諾商標使用權限，亦不會追蹤後續的中繼資料變更，因此紀錄在標示為完成之前，必須回頭指向官方的字型系列頁面或儲存庫。自託管屬於另一條獨立的合規路徑：此工具不會下載檔案，也不會建立 @font-face 規則，因此任何將字型檔案鏡像至自有來源的決定，皆應以獨立理由記載於紀錄中，而非併入原始的紀錄項目內。
效能審查值得另闢一段說明，因為預覽無法告訴您，在實際專案中，雙字型系列請求是否比系統字型堆疊更快。請在訪客實際面臨的條件下量測真實頁面，包括慢速網路與離線狀態，並將結果回寫至紀錄中。display=swap 能在字型載入期間保持後備文字可見，但後備字型與指定字型之間的度量差異仍會造成版面位移，因此文件記錄中應說明版面尺寸是如何被穩定下來的。
一份可重複使用的紀錄範本
範本能讓紀錄的維護成本低廉，而這也是它能跨越第一個專案持續存活下去的唯一方式。最簡單的形式，就是一份文件或 wiki 頁面，讓每個項目都採用相同的標題結構：所選配對、測試文字、已交付的產出物、審查欄位與審查人員註記。由於 Google Fonts Pair Finder 僅公開三項輸出產出物，範本可以將這三項產出物分別對應為三個核取方塊或三段程式碼區塊，這能避免審查人員自行發明命名規則。
有兩個小習慣能讓範本保持誠實。第一，請分別貼上連結、CSS 類別與完整程式碼片段，而非將它們合併，因為每項產出物會歸入專案中不同的檔案。第二，請以純文字形式附加審查人員註記，而非將其置於程式碼區塊內，這樣它們才能在程式碼格式與搜尋索引中存活下來。養成這兩個習慣之後，紀錄便能同時兼任設計理由、程式碼參考與稽核軌跡，而相同的理念也會在 如何避免字型配對產生器的常見錯誤 一文中的較長檢查清單中再次出現。
若想進一步了解，請參閱 如何修正看起來不對的字型配對結果。