用語音輸入更快寫出清楚的程式碼審查意見

有幫助的程式碼審查意見，不只指出哪裡看起來不對，還要說明實際行為、為什麼值得關注，以及希望作者下一步做什麼。「處理空值情況」這類短句，可能省下幾個字，卻留下更多需要追問的細節。反覆打出完整說明，又容易打斷審查時的思路。

語音輸入能讓你在推理還清楚時，先把說明寫下來。在 Mac 上保留差異檢視，開啟留言草稿，像向同事解釋問題一樣說出觀察，再編輯後送出。語音輸入負責把你的說明轉成文字，不會替你驗證程式碼或判斷修改是否正確。

1. 先整理證據，再開始說

每則意見只處理一個問題。記下相關行數或函式、觸發情境，以及已觀察到或預期的行為。若尚未執行程式，就註明這是閱讀程式碼後的疑慮，不要把可能發生的問題寫成已重現的錯誤。

也要先決定希望對方如何回應：

分類應遵循團隊的審查慣例。個人偏好不會因為語氣強硬，就自動變成合併前必須完成的事項。

依序說出三件事：「在這個情境下，我看到這種行為。它會造成這個影響。能否做這項修改或確認？」每個段落之間稍作停頓，避免一則意見塞入太多問題。

完成草稿後，再從原始碼貼入精確的識別名稱、檔案路徑與程式碼片段。符號會影響意義的內容，不要只依賴語音辨識。刪除重複說明，把焦點放在實作與影響，而不是評價寫程式的人。

以下是虛構範例，假設審查者已在本機重現問題。

原始筆記：「搜尋內容是空的時候要修一下。」

編輯後的審查意見：

必須修改 — 空白搜尋： 只輸入空白字元後送出搜尋，結果區會一直停在載入中。我已用這次修改在本機重現。使用者既看不到結果，也不知道下一步該怎麼做。

能否在開始搜尋前處理只有空白字元的輸入，並顯示已確認的未輸入內容提示？也請補上這條流程的測試，確認載入狀態會正確結束。

如果只是推測，開頭可改成「從這個分支的程式碼來看，似乎可能……」，並詢問是否已有其他流程處理。若提示內容尚未確定，就先討論預期行為，不要自行創造需求。

類型： ［必須修改／建議／提問］

情境： 在［位置或條件］下，［觀察到的行為，或明確標示為疑慮的內容］。

影響： 這會造成［具體結果］。

下一步： 能否［聚焦的修改、驗證或說明］？

依據： ［如有，附上重現步驟、相關需求或測試結果］。

這些欄位是起草提示，不必每則意見都照表填寫。小建議可能兩句話就夠了。涉及多個檔案的問題，適合放在整體審查摘要並連到相關位置，不必在每一行下方重複留言。

對照差異內容，檢查名稱、否定詞與技術用語。確認「會」沒有變成「不會」，提到的測試結果也確實存在。最後站在作者的角度讀一次：對方是否不必猜測你的意思，就知道該回覆或修改什麼？

TypeFree提供簡單的方式，將語音轉成可編輯的文字，幫助你更快完成寫作。下次審查程式碼時，先口述判斷理由，再核對細節，讓回饋真正幫助作者完成下一步。