有用的 GitHub Issue，最好在錯誤還留在畫面上時寫。操作順序還記得，異常的主控台行也看得見，哪個暫時解法失敗、最近一次版本後哪裡改變，都能說清楚。
可是打開 Issue 編輯器後，回報往往只剩下「Safari 無法登入」。
語音輸入能減少的，就是這類資訊流失。它不會自動把模糊觀察變精準，但能讓已知的證據、順序與限制，在被壓縮成標題加一句話之前，更容易完整留下。
GitHub Issue 可以追蹤錯誤、改善、工作項目和其他專案資訊。正文使用 GitHub Flavored Markdown，支援標題、工作清單、連結與程式碼區塊。因此，Issue 不只是留言，而是一份讓其他人能檢查、重現並判斷何時關閉的小型工作紀錄。
固定結構交給範本，會變動的事實用語音補上
許多團隊需要的欄位早已固定：
- 摘要
- 重現步驟
- 預期結果
- 實際結果
- 環境
- 驗收條件
輸入這些標題不算費力。真正耗時的是重新整理每一欄下面發生了什麼。
實用的分工，是把 Markdown Issue 範本放在儲存庫裡，再用語音填入每次變動的證據。GitHub 支援 Markdown 範本與 Issue 表單，所以打開編輯器時，固定問題已經可以先出現。語音負責補上今天的事實：第四次點擊、瀏覽器版本、舊權杖、意外出現的畫面，以及修正後應通過的測試。
範本也能避免口述變成冗長而沒有結構的回報。框架由範本維持，錄音只填補空白。
重現步驟需要順序，也需要明確的偏離點
「上傳有時失敗」會留下太多未知。是哪個檔案？哪個頁面？登入前還是登入後？重試有沒有用？失敗時畫面出現了什麼？
按順序說出步驟，並標示觀察到的行為第一次偏離預期的位置：
- 從已知狀態開始。
- 說明執行的操作。
- 說明重要操作後出現了什麼。
- 在第一個錯誤結果處停下。
- 補充錯誤是否能重複發生。
例如：
從一個已登入且沒有大頭貼的帳號開始。打開設定，選擇超過五 MB 的 PNG，然後只按一次儲存。進度列到百分之百後，沒有錯誤訊息，頁面卻回到原本的大頭貼。重新整理後仍看不到新圖片。改用較小的 PNG 重複操作則會成功。
這一段包含對照案例、可見結果與可重複性。趕著打字時，這些資訊最容易先被刪掉。
把觀察和解釋分開
如果把推測寫成證據，Issue 會更難調查。
「快取失效機制壞了」可能正確，但這是診斷。「上傳端點回傳 200 後，第二個請求仍回傳舊的大頭貼 URL」才是觀察。就算最後原因在別處，後一句仍然可以驗證。
口述時，可以直接標出界線：
- 用「我觀察到……」描述可見行為。
- 用「我原本預期……」描述依賴的規則。
- 用「目前的推測是……」描述假設。
- 用「尚未確認的是……」描述仍開放的問題。
說話時很容易把自己的解釋一起帶進去。明確稱為推測，即使後來證明錯誤，Issue 仍然有用。
精確字串用鍵盤輸入，它們的意義用語音說明
語音適合講時間順序與原因。不適合每一個字元都重要的內容。
以下內容應使用鍵盤輸入或直接貼上：
- commit hash 與 Issue 編號
- 檔案路徑與識別名稱
- 帶查詢參數的 URL
- Shell 指令與正規表示式
- 堆疊追蹤與日誌片段
- 只差一個數字的版本號
日誌與程式碼不要朗讀，直接放進圍欄程式碼區塊。GitHub 會顯示這些區塊，加入語言標識後還能套用語法醒目提示。空白、標點和行順序都可能是證據，所以短小的原始片段通常比口頭改述更可靠。
接著再用語音說明精確字串周圍的脈絡：日誌來自哪裡、哪個操作產生它、哪一行最重要。鍵盤保留證據，語音保留意義。
驗收條件替 Issue 建立可檢查的終點
Issue 可以準確描述錯誤，卻仍然很難關閉。「修正大頭貼上傳」沒有說明成功究竟是顯示錯誤、接受更大的檔案、自動重試，還是立即更新圖片。
加入修改後可以檢查的驗收條件。GitHub 工作清單使用 Markdown 核取方塊，因此工作進行時，條件也能持續保持可見。
以上傳範例來說：
- 支援的圖片不需手動重新整理，就會顯示新的大頭貼。
- 不支援的檔案大小會顯示明確錯誤。
- 上傳失敗不會取代現有大頭貼。
- 回歸測試涵蓋發生錯誤的大小邊界。
口述這些條件通常更容易，因為只要回答一個直接問題：「看到什麼結果，我才會同意問題已修正？」除非實作方式本身就是需求，清單應描述結果，而不是指定做法。
Clean 忠實保留回報，Raw 保留整段發言
TalkTalkType 會在按住 Option-Space 時錄音，放開後把結果送回錄音開始時取得焦點的輸入框。在 GitHub Issue 編輯器裡，可以一邊看儲存庫脈絡、範本與既有留言，一邊說話。
Clean 會進行忠實的輕度整理。它保留所有說出的詞、順序、語氣與原本想要的簡短程度，只刪除意義明確且不會改變內容的猶豫詞，並回傳一行文字。它不會悄悄把回報改成另一種錯誤範本，也不會補造缺少的事實。
Raw 不做整理，會保留包含錯誤開頭在內的完整轉寫。準備大幅手動編輯，或內容中有容易被整理步驟改動的少見專有名詞時，可以使用 Raw。
無論哪種模式，都不能讓精確技術文字適合直接口述。送出前讀一遍草稿，把不確定的版本、名稱、路徑與數字換成複製的原值。可在 Mac 任意 App 使用的聽寫說明了聚焦輸入框投遞與剪貼簿備援路徑。
輸入方便，不代表秘密資訊適合進入 Issue
錯誤回報可能位於公開儲存庫、公司的私人儲存庫，或未來會公開的專案。輸入目標本身就是資料邊界的一部分。
不要口述 API 金鑰、工作階段 Cookie、存取權杖、客戶隱私資料或正式環境憑證。貼上日誌時也要先遮蔽。語音輸入只降低輸入負擔，不會改變最終 Issue 的可見範圍。
TalkTalkType 不會把音訊、原始轉寫或整理後文字保存成伺服器端歷史，但建立 Issue 時，最終文字會送往 GitHub。Mac 上的私密聽寫介紹了此前各階段中錄音與文字的流向。
從那個原本會被延後的 Issue 開始
趁錯誤還能重現，打開儲存庫的 Issue 範本。標題與精確識別名稱用鍵盤輸入，接著一次說完起始狀態、按順序執行的操作、第一個錯誤結果、可重複性、預期行為與目前的不確定之處。
讀一遍，貼上最小但有用的日誌片段，再加入定義完成狀態的清單。
目標不是寫出更長的 Issue，而是把當時的資訊保留得足夠完整，讓其他人在現場已經消失後仍能繼續行動。