用語音輸入寫出清楚的 Pull Request 說明

修改已經完成，Pull Request 的說明欄卻還只有「更新文件」四個字。你記得為什麼要改、哪裡需要第二個人的意見，也知道自己檢查過什麼，但把這些背景打成文字，又像是另一項工作。

可以先用語音輸入，像向旁邊的同事說明一樣，把修改的重點講出來，再整理成方便閱讀的文字。GitHub 的審查指南（英文）也強調交代修改背景。以下是一套從口述到 PR 草稿的實用流程。

1. 看著實際修改，再開始說明

在 Mac 上並排開啟修改的檔案與草稿文件，或直接開啟 PR 說明欄。先閱讀差異，確認要說的是這次提交的內容，而不是今天原本打算完成的所有事情。

先用一句話描述結果，例如：「這次在貢獻者指南中加入環境準備清單。」精確的檔名、議題編號與指令可以留到編輯時複製貼上，不必逐字念出。

2. 用五個問題整理口述內容

每次說一小段，在不同項目之間稍作停頓：

• 改了什麼？ 描述修改後的結果，而非每一次編輯操作。
• 為什麼要改？ 說明原本的問題或缺少的資訊。
• 從哪裡開始看？ 指出最需要審查的部分。
• 檢查過什麼？ 說明已完成的檢查及實際結果。
• 還有哪些未完成事項？ 分開列出疑問、未驗證情境與不在本次範圍內的工作。

如果儲存庫已有 PR 範本，就沿用原本的標題。語音輸入是幫你填寫草稿，不需要改變團隊的格式。

3. 將口述草稿整理成審查指引

以下是虛構的文件修改案例，並非 TypeFree 的功能說明：

原本的貢獻者指南假設讀者已經準備好環境，所以我加了準備清單。請先看前置條件那一節。我在預覽裡開過連結，都能到正確頁面，但還沒有用全新環境完整走過設定流程。想請人確認前置條件是否齊全。安裝指令沒有改。

編輯後，可以整理成：

修改摘要： 在貢獻者指南中新增環境準備清單，安裝指令維持不變。

修改原因： 讓第一次參與的人清楚知道需要先完成哪些準備。

審查重點： 前置條件一節是否遺漏必要步驟。

已完成檢查： 從文件預覽開啟清單中的各個連結，均前往預期頁面。

尚未驗證： 在全新環境中，從頭到尾完成設定流程。

這是寫法示例，不是可以直接套用的測試結果。請把檢查內容換成自己實際取得的結果。「之後會測試」應放在待辦事項，不應列為已完成驗證。

4. 精確資訊留到編輯時核對

從原始資料複製檔名與連結，再確認它們確實對應這次修改。也要留意語意：「修改了指令」與「沒有修改指令」代表完全不同的範圍，少一個否定詞就會改變意思。

除非有助於解釋重要決策，否則不必保留每次嘗試的過程。審查者需要的是最終方案的理由，不是整個下午的工作逐字稿。尚未解決的疑問也要保留下來，不要為了讓文章流暢而改寫成肯定句。

5. 用具體問題提出審查需求

把「有什麼想法嗎？」改成「這份前置條件清單，有涵蓋新貢獻者需要的所有準備嗎？」分享之前，再對照實際差異與檢查結果讀一次。

其他開發寫作情境，也可以參考用語音輸入寫清楚的錯誤回報，以及更快完成文件草稿。

TypeFree讓你用簡單的方式，把說話轉成可編輯文字，更快完成寫作。下一次寫 PR 說明時，先說出修改的來龍去脈，再補上精確的參照資訊，確認內容後才送出。