語音即開發：當你可以在廚房 Coding

當煮飯同寫 Code 可以同時發生

我朝早習慣一邊煮咖啡一邊睇 GitHub Issues。以前呢個「同時」係偽命題——你要嘛專心剷蛋，要嘛盯住螢幕。但過去半年，我發現自己愈來愈多時間喺廚房完成 coding task：用 OpenTypeless 口述 PR description、回覆 code review comments，再用 OpenVoiceUI 叫 AI agent 開新 branch、改 file、甚至生成一個 dashboard 嘅 HTML 雛形。全程冇掂過 keyboard。

2026 年的今天，語音開發唔再係 demo-only 嘅噱頭。開源社群已經有兩件完成度極高嘅工具——OpenVoiceUI 同 OpenTypeless——各自搵到唔同嘅切入點，夾埋覆蓋咗成條「由 voice 到 production code」嘅 pipeline。呢篇文唔係推銷，而係一個香港 indie hacker 用咗幾個月之後嘅真實觀察。

OpenTypeless：將語音變成打字嘅 bridge

OpenTypeless 嘅核心邏輯好簡單：你㩒一個 global hotkey (預設 Ctrl+Shift+Space)，講嘢，佢用你揀嘅 STT provider 做 transcription，再用你揀嘅 LLM 做 polishing，最後直接模擬 keyboard 輸出到你而家 active 嘅 app 度。

聽落冇咩特別？但佢做啱咗幾件好重要嘅事。

第一，佢支援 6 個 STT provider 同 11 個 LLM provider，而且係「bring your own key」模式。我用 Groq Whisper 做 transcription（快，latency 低），OpenAI 做 polish，總成本每個月唔使一蚊美金。第二，佢有 custom dictionary——呢個對 developer 嚟講係 killer feature。你可以 predefine 啲 project-specific terms（例如 useReducer、Monorepo、Idempotent），語音辨識會準好多。第三，佢嘅「scene」系統可以設定唔同嘅 prompt template：寫 code comment 用一個 prompt、寫 Slack message 用另一個、寫 Git commit message 又另一個。

我用佢最大嘅場景係「喺 mobile 睇住 code 然後用把口覆」。迫火車嗰陣攞住電話睇到個 bug，唔使等到返公司—用 AirPods 講低 fix 方案，OpenTypeless 幫我 polish 好然後直入 GitHub comment box。呢種 latency 由「等到有 keyboard」變「即時」，係好大嘅 workflow shift。

OpenVoiceUI：唔使打字嘅 AI Computer

如果 OpenTypeless 係把聲變 keyboard input，OpenVoiceUI 就係成個開發環境嘅 voice-first 介面。佢係一個 open source (MIT) 嘅語音 AI assistant platform，裝好之後開 browser 去 localhost:5001，你講嘢，佢直接 call LLM 然後 render 結果喺一個 live canvas 上面。

我認為佢最有價值嘅功能係「Live Canvas」。你講一句「Build me a dashboard that shows my server metrics」，佢會用 OpenClaw 嘅 tool system generate 一個完整嘅 HTML 頁面，save 落 filesystem，然後 render 喺 canvas 上。呢個唔係 mockup——係一個真正行得嘅 web page。對於 prototyping、data exploration、internal tool 呢類場景，voice-to-app 嘅速度遠遠快過 manual coding。

佢嘅 plugin system 亦值得留意。因為係基於 OpenClaw，任何 Claude Code 或者 OpenClaw 嘅 skill 都可以掛上去。我寫咗一個 plugin 俾佢直接 call 我個 server 嘅 health check API，然後用 voice report 返結果。成件事嘅 developer experience 係：寫一次 plugin，之後所有 interaction 都係 voice-driven。

當然，OpenVoiceUI 唔係萬能。佢 current 嘅強項係「generate and display」，即係一次性生成某個 artifact。對於需要反覆 iterate、debug、改幾行 code 嘅工作，佢仲未夠順暢。呢個位正正係 OpenTypeless 嘅強項——兩者其實互補多過競爭。

真正嘅瓶頸：Voice Coding 唔係技術問題

用咗幾個月語音開發之後，我最大嘅體會係：技術上已經 ready 咗，真正嘅 bottleneck 係 mental model。

第一，我哋習慣咗「寫 code = 打字」呢個等式太耐。當你要「講 code」嘅時候，思維方式完全唔同。function 嘅命名、控制 flow 嘅結構、even 變數 scope——呢啲設計上嘅決定，平時喺 typing 嘅過程中自然會 handle 到，但用講嘅時候你要 pre-think 得更加清晰。呢個反而係好事——迫你 design 先行，唔畀你靠 typing 嘅肌肉記憶亂撞。

第二，香港 developer 嘅 bilingual 環境係一個挑戰。我寫 code comment 用英文、傾 workflow 用廣東話、睇 documentation 中英夾雜。STT 對 mixed-language 嘅準確度仍然有進步空間。OpenTypeless 嘅「先 transcribe 再 polish」嘅 pipeline 喺呢度有幫助——你可以用任何語言講，然後叫 LLM 幫你 translate 做 target language output。

第三，open space 嘅噪音問題。唔係個個都有 private office。我嘅解法係用骨傳導耳機（Shokz 之類）加 noise gate microphone，normal conversation volume 已經可以準確 capture 語音。OpenVoiceUI 嘅 push-to-talk mode 亦減少咗 background noise 嘅誤觸。

行動建議：點樣開始

如果你有興趣試，我會建議行一個「hybrid workflow」：

先裝 OpenTypeless，set 好你最常用嘅 STT + LLM provider，由 low-stakes 嘅場景開始：寫 email、寫 code comment、寫 PR description。等大腦習慣 voice-to-text 嘅 latency 同 rhythm。
然後裝 OpenVoiceUI（npx openvoiceui setup），用佢嚟做 prototyping 同 data exploration。講一句「Generate a React component that fetches from this API」——睇下佢生咗咩出嚟，然後 refine。
最關鍵嘅一步：找出你 workflow 入面邊啲環節係「睇多過打」嘅——code review、documentation reading、architecture planning——呢啲就係 voice-driven 嘅 sweet spot。唔好強求用 voice 寫 business logic（至少而家未係時候），但用 voice 處理 communication 同 exploration 層面嘅工作，已經可以慳返好多時間。

廚房 coding 唔係終點。終點係我哋開始重新思考：如果雙手唔受 keyboard 綁住，我哋可以點樣做 software development？答案可能唔係「講得快過打」，而係「喺打字唔方便嘅時候，仍然可以 maintain 生產力」。呢個 flexibility，本身就係一個 breakthrough。