開發者的語音輸入：語音寫程式碼、AI Prompt 與終端機命令
開發者每天會花很多時間寫那些“不是程式碼”的東西，而且這個時間往往比想象中更多： Pull Request 描述、Code Review 評論、解釋架構決策的 Slack 訊息、文件、 Commit message，以及給 ChatGPT、Claude 或 Copilot Chat 的 AI prompt。
這些東西本質上都是自然語言。每次你都得從“寫程式碼”的腦內狀態切換到“寫 prose”， 這種上下文切換會打斷編碼流。而且，它們幾乎都比打字更適合直接說出來。
上下文切換的問題
你正在深挖一個除錯現場，終於找到了根因，想順手留一條程式碼註釋， 解釋為什麼這個修復成立，好讓未來的自己會感謝現在的自己。 但從“讀彙編”的思維模式切到“寫英文”是有成本的。於是你最後只寫了一句敷衍註釋， 或者乾脆不寫。
語音輸入會直接消除這層摩擦。按住一個鍵，把你腦子裡的東西說出來，鬆開。 註釋就出現了。你不需要離開編輯器，不需要把手從鍵盤上挪開超過一秒， 也不需要中斷思路。
語音輸入在開發者工作流裡的位置
程式碼註釋和文件
好的程式碼註釋解釋的是 why，而不是 what。 但 “why” 註釋要求你把推理說清楚，而這恰恰是語音最擅長的事。 像 “we retry here because the upstream API returns 503 during deployments, which happen every Tuesday at 3am UTC” 這樣的註釋， 說出來比打出來快，而且產出的文件品質也明顯高於一句 “retry on failure”。
AI prompt
如果你在用 ChatGPT、Claude、Cursor 之類的工具，你其實一直都在寫 prompt。 好的 prompt 往往很長，包含上下文、約束、示例和具體指令。 打一段 200 詞的 prompt 通常要兩三分鐘，說出來大約只要 45 秒。
OnType 的 Compose 模式在這裡特別有用。你可以自然地把 prompt 說出來， 包括中途修正和補充說明，AI 改寫引擎會把它整理成結構清晰、表達明確的 prompt。 場景檢測還會識別你目前處在 AI 對話介面裡，並針對 prompt 品質最佳化輸出：分離上下文和指令、顯式寫出約束、移除口語痕跡。
Git commit message 和 PR 描述
“fix bug” 這種提交資訊，本質上就是不想做上下文切換的產物。 有了語音輸入，你可以輕鬆口述一條真正有資訊量的 message： “fix race condition in the connection pool where two goroutines could acquire the same connection if the health check timed out during a resize event.” 這句話說完只要四秒。
Slack 和非同步溝通
在 Slack 裡解釋一個技術決策，經常要寫三段話。語音輸入能把這件事壓縮成 30 秒口述。 OnType 的 Compose 模式在這裡同樣好用：你可以把原始解釋連同岔開的思路和改口一併說出來， 改寫引擎會把它整理成一條幹淨、結構化的訊息。
終端機和 CLI 輸入
OnType 可以直接在終端機模擬器裡工作，比如 iTerm2、系統 Terminal、Warp 等。 這意味著你可以口述長命令引數、heredoc 內容，甚至互動式 prompt 的輸入。 文字會像在其他應用裡一樣，直接出現在目前游標位置。
為什麼它必須是系統級的
有些語音工具只能在自己的視窗裡工作，或者只支援特定應用。 對開發者來說，這種限制基本等於失去意義。整個價值點就是你不需要離開目前上下文： 編輯器、終端機、或者已經開啟 GitHub PR 的瀏覽器頁面。
OnType 是系統級可用的。你在 VS Code 裡按熱鍵，文字就進 VS Code。 你在 iTerm2 裡按熱鍵，文字就進 iTerm2。你在 Firefox 的 GitHub 評論框裡按熱鍵，文字也會出現在那裡。不需要從單獨聽寫視窗複製貼上，也不用切應用。
為什麼它必須是裝置端的
開發者經常處理專有程式碼、內部文件和保密專案細節。 如果你把討論實作細節的語音送給雲端服務，相當於平白多造了一個資料暴露面。
OnType 的預設引擎完全執行在你的 Apple Silicon Mac 上。 你的音訊，包括所有內部 API 名稱、架構決策討論和未釋出功能代號， 都會留在你的裝置裡。
開始使用
如果你每天有超過一小時在寫那些“不是程式碼”的內容， 就去下載 OnType，試一週。裝置端引擎是免費的。 工作流的變化是立刻可感知的：按住鍵、說話、鬆開、繼續寫程式碼。