我做了一個 AI 時代的效率神器，已開源

先看視頻：

上面就是我最近日常的打字方式，在家、在公司、在咖啡廳都可以。

整個過程，我用的是這個「鍵盤」：

嗯沒錯，這是一個無線麥克風，可以拿手裏，也可以夾在衣服領口上。

顯然，它比這個鍵盤簡單多了：

因為，它就完全只有一個按鈕。

但就是這一個按鈕，我用它實現了：幾百甚至上千字的精準文字輸入。

而使用上，則是：按一下開始說話，再按一下結束，文字自動上屏，再按一下自動發送。

全程不碰電腦，不碰鍵盤。

下面來說說過程，或許你也應該有一個。

為什麼要語音輸入

如果你很 AI Native，非常擁抱 AI，那你可能會發現，你最累的已經不再是腦子，還有打字的手指。

我現在每天最大量的工作，就是跟 Claude Code、Codex 對話：描述需求、給上下文、提修改意見。

幾乎所有的事 AI 都能做，但前提是我得把想法快速傳達給它。

所以，對絕大多數人而言，打字的速度已經成為你信息輸入輸出的上限、工作效率的瓶頸、是否能捲過他人的關鍵。

而我也有幸，在大學時，因為年輕氣盛和人較勁打賭，最後真的在一週內學會了五筆打字。

可以說，用鍵盤打字這事，我的速度應該會超過 90% 的普通人。

當然，相較於專業的速記員，自然完全沒法比……我曾經現場觀摩過幾次。

但即便如此，對我而言，打字仍然是我很大的效率和信息 IO 瓶頸。

所以我很早就開始嘗試語音輸入，比如這裏就有寫：Codex 和 Claude Code，用哪個？

隨着語音識別準確性的提升和成本的大幅降低，打字這件事變成為了：

你在用鍵盤做一件嘴巴更擅長的事。

軟件選型

Wispr Flow

我最早用的是 Wispr Flow，一款基於 OpenAI Whisper 模型的語音輸入工具。

在我之前的文章中偶爾也有提到，很多朋友通過我的邀請碼註冊了，甚至因此它幫我賺了不少會員，一直用不完。

但怎麼講，它的識別效果始終還是不夠穩定，經常需要手動二次編輯，非安靜環境下尤其明顯。

以及，在開放式辦公室裏使用起來，還會有點兒尷尬。

你要是大聲說話，那你最核心的 idea 可能會被隔壁工位的同事或過客們「偷聽」。

畢竟在 AI 時代，idea 的價值比以往任何時候都重要。

大嗓門的同志們要注意，或許哪天當你跟 AI 說完「幫我寫一個能自動 XXX 」的 idea，然後整層樓的 Claude Code 們都開始工作了。

而大聲說話這事確實也會打擾到別人。

畢竟不是每個人都想在寫 Bug 的時候聽你跟 AI 談人生。

那怎麼用更小的聲音，依然拿到不錯的識別效果呢？

對比下來，確實還是 Typeless 在低音量場景下表現明顯最好（沒有 PR）。

Typeless

Typeless 並不只是簡單的語音轉文字，它的技術架構分兩層：

語音識別層，將你的語音轉為原始文本。

LLM 智能編輯層，用大語言模型理解你的意圖，自動去除口頭禪，如「嗯」「那個」「就是說」等，修正口誤，整理格式。

所以即使你說得含糊、斷斷續續，它也能「聽懂」你想表達什麼。

比如你說：

幫我寫一個……嗯……那個函數，就是把用戶的……啊不對，是把訂單的狀態改成已完成的那個

Typeless 會輸出：

幫我寫一個函數，將訂單的狀態改為已完成

乾淨準確、直接可用。

Typeless 還支持超過 100 種語言的自動識別，中英文混合輸入也完全沒問題。

這對我來說太重要了，畢竟我們說話經常是「幫我把這個 Claude Code 的 xx skill 改一下，加一個 deploy callback」這種中英夾雜的風格。

相比蘋果的語音輸入，真的是強了無數倍。

Typeless Pro 版 $12/月，並不算便宜。

有些東西，失去時才會珍惜它，但有些東西，沒用過就不知道自己需要它。

這樣的東西不多，Typeless 算一個，類似的還有蘋果電腦，還有我最近買的全自動咖啡機，用過之後就再也回不去了。

Typeless 連結（沒錯，我有的邀請碼）：https://www.typeless.com/?via=john-yin

硬件選型

軟件選好了，但還有一個物理層面的問題：Mac 自帶的麥克風收音效果還是有限，每次語音輸入時，我必須彎下高貴的頭顱，湊到 Mac 的 Mic 的位置，然後，開始說話。

而我有個小毛病是，當我在邊思考邊說話的時候，我希望要能離任何東西，包括電腦，都略遠一點兒。

我理解為我這是需要通過物理空間給自己騰出一些想象的空間，跟唱高音似的，姿勢正確也很重要。

所以，我入手了 大疆 DJI Mic Mini。

DJI Mic Mini

10 克的重量，拿在手裏，或夾在領口上基本感受不到它的重量。

而誇張到 400 米的傳輸距離，甚至能讓我在週末的整棟辦公樓裏自由活動，邊走邊說了。

同時，它的兩檔降噪在辦公室場景下，確實表現非常出色，即使周圍有人說話，也能精準拾取你的低聲耳語。

下單後次日到手，不到 200 塊。

而在換了 DJI 麥克之後，語音識別的準確率直接上了一個台階。

之前用 Mac 內置麥克風，經常會識別出奇奇怪怪的東西，比如你明明在說中文，它突然給你蹦出一個莫名其妙的英文單詞。

不知道這算不算是 bug，不然就太有點離譜了。

而當我用上 DJI Mic Mini 時，這個問題，就完全消失了。

硬件升級帶來的識別提升，比換軟件還是要明顯多太多了。

實際使用下來，發射器的續航大概 4-5 小時，半天基本就沒電了。

這時候一拖二套裝（兩個發射器 + 一個接收器）的好處就體現出來了，一個沒電換另一個，無縫銜接。

我目前就用一個發射器，偶爾充充電，倒也夠用，因為也可以邊充電邊用，一會兒就充好了。

基礎用法：5 分鐘上手

如果你只是想簡單地用起來，5 分鐘就能搞定。

連接設備

用 USB-C 線把 DJI Mic Mini 的接收器連接到 Mac，打開 System Settings → Sound → Input，選擇 「Wireless Mic Rx」 作為輸入設備。

把發射器開機（長按電源鍵），它會自動跟接收器配對。

開啓聽寫

打開 System Settings → Keyboard → Dictation，將 Dictation 設置為 On，快捷鍵保持默認的 Press 🌐 Fn Key。

開始使用

在任意文本輸入框中，按下 Fn 鍵，開始說話。再按一次 Fn，結束聽寫。

macOS 原生聽寫配合 Typeless 使用時，Typeless 會自動接管聽寫功能，提供更智能的識別和編輯效果。

到這裏，你已經可以在大部分場景下愉快地使用語音輸入了。

注意：如果你看到了這裏，本文還沒完……重點才剛開始，請繼續往下看：

進階：一鍵聽寫

到目前為止，每次輸入我都得按鍵盤上的 Fn 鍵，人還是得老老實實坐在電腦前。

尤其如果想離電腦遠一點，那就得伸長手臂去夠 Mac 左下角的 Fn 鍵，姿勢還是略有點小別扭。

所以我的想法是：把 DJI Mic Mini 發射器上的音量+按鈕，改造成聽寫開關。

這樣只需要按一下胸口的小按鈕，就能隨時隨地開始和結束聽寫。

可以離電腦遠遠的。

這需要用到 Karabiner-Elements，一個 macOS 上強大的鍵盤映射工具。

安裝

brew install --cask karabiner-elements

安裝完成後，打開 Karabiner-Elements，按照提示授予以下權限：

• Input Monitoring（輸入監控）

• Accessibility（輔助功能）

⚠️ 如果不授予 Input Monitoring 權限，Karabiner 將無法識別任何外部設備，規則也不會生效。

這是容易踩的第一個坑。

映射規則

Karabiner 的核心規則是：只攔截 DJI Mic Mini 的音量+按鍵，映射為 Fn 鍵，不影響其他設備。

通過 device_if 條件限定設備（vendor_id: 11427，product_id: 16401），通過 consumer_key_code: volume_increment 匹配音量+。

最簡單的版本就是一條規則：收到音量+ → 發送 Fn。

但還不夠，要實現後面的「自動發送」功能，需要更復雜的狀態管理。

完整的 3 條規則配置我會在下面的「自動發送」章節給出，這裏先理解基本原理。

第二個坑

DJI Mic Mini 在系統中被識別為 Consumer 設備（耳機類），而不是鍵盤。

Karabiner 默認只抓取鍵盤和鼠標設備，所以即使規則寫得完全正確，按按鈕也只會觸發系統音量。

解決方法是在 karabiner.json 的 profile 中，顯式聲明要抓取這個設備：

"devices": [{
    "identifiers": {
        "is_consumer": true,
        "product_id": 16401,
        "vendor_id": 11427
    },
    "ignore": false
}]

關鍵是 "ignore": false 和 "is_consumer": true。

告訴 Karabiner：「這個 Consumer 設備，我要攔截它的事件。」

不加這段配置，Karabiner 根本看不見 DJI 的按鈕。

添加後，你可以在 Karabiner 的日誌中確認設備已被抓取：

Wireless Mic Rx (device_id:xxx) hid queue value monitor is started (grabbed).

查 ID

如果你用的是其他型號的無線麥克風，可以用以下命令查設備的 vendor_id 和 product_id：

# 查看 USB 設備信息
ioreg -p IOUSB -l | grep -A 20 "你的設備名"

# 或者用 Karabiner 的命令行工具
karabiner_cli --list-connected-devices

驗證

配置完成後，按一下 DJI 發射器的音量+，聽寫就開始了。

再按一次，聽寫結束。

你可以離開電腦幾米遠，坐在沙發上對着領口的小麥克風說話，甚至可以走到很遠的地方，看着窗外思考，不用碰電腦。

終極：自動發送

到這裏，基本就可以用了。

但懶人如我，自然還想更進一步。

說完話之後，能不能自動幫我按一下回車？

理想的場景是這樣的：

在 iTerm2 裏用 Claude Code，按下胸口的按鈕，對着麥克風說了一段需求，再按一次結束聽寫。

然後我什麼都不用做，指令就自動發送出去了。

我可以端着咖啡，刷着手機，甚至望着窗外發一會兒呆，而我的代碼在自動生成。

這就是真正的 Vibe Coding。

哦不對，又換詞了，應該叫 Agentic Engineering.

也不對，Agentic Engineering 體現不出這 Vibe 的爽感，或許可以叫：Vibe Engineering?

問題來了：只有一個按鈕

想法很美好，現實很骨感。

DJI Mic Mini 發射器上只有一個音量+ 按鈕可用，且前面我已經把它映射成了 Fn 鍵，用來開關聽寫。

現在還想讓它同時承擔「發送回車」的職責，一個按鈕要幹兩件事，咋辦呢……

先來看看這個按鈕到底能產生哪些事件：

對電腦來說，這個按鈕只有一種事件：按下了。

試試雙擊呢？

結果我試了半天才發現，雙擊是 DJI 固件自己的事件，會觸發藍牙重新配對，根本不會傳到電腦……被官方徵用了……

而長按……也沒有任何效果。

那……三擊？

用 Karabiner EventViewer 一測，更是沒有任何動靜。

也就是說，只能獲取到一個事件：單擊。其他沒了。

那要不，咱換個設備？

畢竟 DJI 這也就不到 200 塊，不算心疼。

但話說回來，它便宜也對應着輕巧（下料少）啊，還是個很重要的優勢的。

那……要不刷固件呢？

我讓 Claude Code 查了一下，DJI Mic Mini 用的是 Actions ATS2831 芯片，固件簽名加密，完全沒有可操作空間。

硬件層面的路，也被堵死了。

核心思路：用時間創造事件

所以我不得不放棄「從硬件上獲取更多事件」這條路。

但 AI 時代，最怕的不是沒有方案，而是沒有方向。

且不能缺的還有一個：信心。

我從一開始，在內心就篤定我最後能搞定這事。

於是我開始換一個角度想：既然沒法從硬件上得到更多真實事件，那……能不能創造事件？

虛擬出我想要的事件出來！

比如通過時間戳，用狀態機的方式，把同一個按鈕在不同時間點的按下，映射成不同的含義。

也就是說：同一個按鈕，第 1 次按是「開始聽寫」，第 2 次按是「結束聽寫」，等文字出現後再按第 3 次是「發送」。

而如何區分每一下是第幾次，則是這裏的關鍵。

一個物理事件，經過時間維度的展開，變成了三個虛擬事件。

這就是我最終方案的核心思路：

利用時間、無中生有！

六輪迭代

我自認為這個想法還是比較嚴謹可行的，那麼剩下的，就是實現它了。

整個過程，我全是跟 Claude Code 對話完成，用了不對就說，哪裏不爽它幫我改，改了再試。

當然，也是用 DJI Mic Mini + Typeless 輸入的。

👆比如上面的，全是用嘴輸入的。

下面是我從第一版到最終版的迭代過程。如果你只想用不想看原理，可以直接跳到後面的「三步上手」。

第一版：15 秒倒計時

其實在這最終版之前，我還是先探索（踩坑）了一些彎路。

最初方案非常直接粗暴：結束聽寫後，腳本在後台等 15 秒，然後自動發送 Enter。

這個 15 秒，是考慮到要留給語音轉錄和我的 review 使用的。

所以我還加了個「智能取消」：通過 ioreg 檢測鍵盤空閒時間，如果發現我在手動編輯，就說明我手動介入了，需要取消掉自動發送。

倒是可以 work 了，但問題是：15 秒還是太長了，在這樣的場景下，我感覺我對 0.1 秒的等待都是能感知到的，更何況 15 秒……

所以這經常會讓我等得心煩，但縮短又怕來不及看識別結果。

更要命的是，有時候我只是想聽寫一段文字而不想發送，這個定時炸彈般的自動發送讓人很不安。

第二版：用狀態機區分意圖

於是我跟 Claude Code 說了上面的狀態機的想法：不用倒計時，用按鈕的次序來區分意圖。

腳本拆成三個命令，save、tap、enter，Karabiner 根據當前狀態決定調用哪一個：

第 1 次按  → 開始聽寫（Fn）
第 2 次按  → 結束聽寫（Fn）+ 啓動計時器
計時器到期 → 打開「發送窗口」
窗口內按   → 發送（Enter）

這樣就不會出現「說着話就自動發送」的情況了。

只有我主動按第 3 下，才會發送。

但這一版有個問題：計時器從第 1 次按下就開始了。

如果我說話說了 10 秒鐘，說到第 3 秒的時候「發送窗口」就開了，這時候我還在說話呢。

於是我讓它把邏輯拆開：第 1 次按只記錄當前 App，第 2 次按才啓動計時器。

這樣不管我說了多久，「發送窗口」只會在你停止說話之後才打開。

第三版：我怎麼知道該發了？

時間窗口能用了，但新的問題出現了：「發送窗口」打開的時候，我怎麼知道？

如果我人不在電腦前，或者在看手機，完全不知道現在能不能按第 3 下。

所以，我先讓 Claude Code 加了聲音提示：窗口打開時播放一聲系統音效 Tink。

這樣離開電腦也能靠耳朵知道，可以發送了。

但又有個問題是，我不一定開着電腦聲音，也不一定戴着耳機。

於是我又想了個很牛逼的交互：能不能讓窗口抖一下，提醒我？

就像手機震動一樣，但這裏通過視覺反饋來提示。

於是，Claude Code 用 AppleScript 實現了。

第一版抖動效果：

repeat 6 times
  set position of fw to {x + 10, y}
  delay 0.04
  set position of fw to {x - 10, y}
  delay 0.04
end repeat
set position of fw to {x, y}

能抖起來了……但嚴格來說，應該叫晃起來了……幅度巨大、頻率又慢。

我又給調成了小幅度高頻率的移動：

repeat 6 times
  set position of fw to {x + 4, y}
  delay 0.005
  set position of fw to {x - 4, y}
  delay 0.005
end repeat
set position of fw to {x, y}

效果像手機微震，輕微但足夠引起注意。

我還順手去掉了窗口關閉時的提示音，3 秒的窗口有多長，自己能估計，關閉提示反而多餘。

第四版：越抖越遠

用了幾輪之後，一切都好，唯獨有個奇怪的事是，我的窗口在慢慢漂移。

每次抖完，位置就偏一點點，抖多幾次之後窗口已經明顯錯位了。

抖得微信都跑到屏幕外面去了：

於是，Claude Code 發現原因是 delay 0.005（5 毫秒）低於 AppleScript 的定時器精度（約 16 毫秒）。每次 set position 是跨進程 IPC 調用 System Events，位置還沒改完下一條就執行了，最後的復位指令跟前面的移動撞在一起，窗口就回不到原來的位置。

再加上 osascript 跑在後台（&），如果用戶在抖動期間按了發送鍵，進程直接被 kill，復位根本不會執行。

修復方是：

去掉 &，delay 調到 0.01 秒，復位改成雙重補償，確保窗口回到原位：

repeat 6 times
  set position of fw to {x + 4, y}
  delay 0.01
  set position of fw to {x - 4, y}
  delay 0.01
end repeat
delay 0.05
set position of fw to {x, y}
delay 0.05
set position of fw to {x, y}

第五版：去掉 hard code

到這裏已經挺好用了。

但我內心總還感覺有些不安，後來發現是3 秒和 6 秒這兩個數字。

我有個習慣：任何人但凡給我報出一個數字，我都想問他為啥是這個數。

產品經理說「這個設為 4 小時」，我會問怎麼得到的，為什麼不是 5 小時，不是 4 個半小時？

程序員說「超時設為 5 分鐘」，我會問基於什麼邏輯，為什麼不是 4 分鐘，不是10分鐘，不是一小時？

所以，在面試時我也經常會問候選人這個問題。

任何 hard code 的數字都會讓我不舒服，因為通常它意味着：不嚴謹。

代表着純拍腦袋。

而現在這兩個數是我自己定的，所以我當然得，解決之！

因為這裏的問題在於，語音識別的耗時並不確定，有時候半秒就出結果，有時候要兩三秒。

固定等 3 秒再開窗口，快的時候浪費時間，慢的時候可能還沒識別完。

所以我想讓腳本自己判斷文字是否已經上屏，而不是傻等固定秒數。

於是我又試了幾個方向。

檢測鍵盤事件（ioreg HIDIdleTime）：語音輸入不經過物理鍵盤，根本檢測不到。

或者讀取光標所在輸入框內容？

倒是個辦法，但跨 App 兼容性太差。有可能這個好了，換一個 App 就不行了。

最後，我找到了一個可靠的方法：

通過 macOS Accessibility API 的 AXNumberOfCharacters，讀取當前焦點輸入框的字符數。

結束聽寫時記一個基線值，然後每 0.2 秒輪詢，字符數變了就說明文字上屏了，立刻開窗口。

# 通過 pyobjc 調用 Accessibility API
import ApplicationServices as AX
_, el = AX.AXUIElementCopyAttributeValue(ref, 'AXFocusedUIElement', None)
_, n = AX.AXUIElementCopyAttributeValue(el, 'AXNumberOfCharacters', None)

這個方案在 iTerm2、微信、飛書等多個 App 上都驗證通過。

識別快就早開窗口，可以更早開始決定要不要 Enter 發送，識別慢了就多等一會兒。

再也沒有 hard code 了。

第六版：飛書不肯抖

改完之後，iTerm2 和微信一切正常。

但飛書……死活不肯抖。

檢查日誌發現，檢測和聲音提示都觸發了，就是視覺上窗口紋絲不動。

我讓 Claude Code 列出飛書的所有窗口：

Window 0: title=WatermarkWidget  subrole=AXUnknown
Window 1: title=飛書              subrole=AXStandardWindow

原來飛書是 Electron 應用，first window 拿到的不是主窗口，而是一個透明的水印覆蓋層。

腳本一直在抖這個看不見的水印，真正的飛書窗口當然紋絲不動。

解決方法：

把 shake 從 AppleScript 改成 JXA（JavaScript for Automation），遍歷窗口列表，跳過水印層，找到真正的主窗口再抖：

for (var i = 0; i < wins.length; i++) {
  if (wins[i].subrole() === "AXStandardWindow") { fw = wins[i]; break; }
}

這裏，我順便還讓 Claude Code 給加了個細節：

抖動前先把窗口位置存到文件裏。如果用戶在抖動過程中就按了發送鍵，腳本會立刻停止抖動，強制歸位窗口，然後發送。

不會出現消息都發完了，App 還在那兒一個勁兒抖的情況。

前後折騰了十來輪，終於，打磨出了一個趁手的工具。

而這工具從第一版到最終版，全程都是我用嘴說出來的。

寫代碼是語音，調參數是語音，跟 Claude Code 討論方案是語音，整理方案也是語音。

我的手幾乎沒碰過鍵盤。

這也算是，對這套工具最好的驗證了。

最終效果

提示反饋是聲音 + 視覺雙重的：文字上屏後會播放一聲清脆的 Tink，同時當前窗口快速左右微震。

即使你的電腦沒開聲音，也能靠眼角餘光捕捉到窗口在抖。

Enter 直接發給當前最前面的窗口，不會跳轉到別的 App。

在 iTerm2 中用 write text "" 發送（繞過權限問題），其他 App 用 keystroke return。

所以這個方案不限於 iTerm2，任何接受回車的應用都能用。

完整的 Karabiner 配置和腳本代碼見開源倉庫：https://github.com/Johnixr/dji-mic-dictation

開源

實際用下來，這套方案已經覆蓋了我日常所有文字性的工作。

寫代碼用 Claude Code，回消息用微信和飛書，寫文檔用備忘錄（按一下發送就是換行，連續記錄很順手），甚至 Telegram、Slack 也能用。

任何接受文字輸入的 App 都行，全程動嘴不動手，簡直成了上海蹦迪寧。

好的東西還是要分享，所以我把它開源了出來：

https://github.com/Johnixr/dji-mic-dictation

祝你也早日成為一個動口不動手的正人君子。

而如果你發現某個 App 不兼容，歡迎到 GitHub 提 Issue 或提交 PR.

日常使用

整個過程一步步看看，但也沒啥，但從結果上看，還是挺神奇的：

電腦上打開着微信，對着領口嘀嘀咕咕幾句後，文字就會出現在輸入框裏，然後微信窗口就抖了一下，再按一下就發出去了。

全程雙手不碰一下電腦，全靠嘴。

還是有點點小魔幻的。

且過程中，微信還自己通過抖動來「提醒」我：要不要發出去？

就在上週，我們團隊已經人手一個 DJI Mic Mini，成了標配。

日常的工作場景變成了：

一屋子人各自對着領口嘀嘀咕咕，偶爾抬頭看一眼屏幕，然後繼續低聲說話。

若是不知道的你見到這個場面，你可能會想：這幫人幹啥呢？

但仔細想想，AI 時代人們的工作方式，可能就是這個樣子。

再也沒有機械鍵盤的噼裏啪啦，只有此起彼伏的嘀嘀咕咕……

我們，也算是初具雛形了。

完整流程

配置好了後，我現在的工作是這樣的：

USB-C 連接 DJI Mic Mini 接收器到 Mac，打開 iTerm2，啓動 Claude Code。

按一下胸口的音量+，聽寫開始，屏幕上出現聽寫指示器。

對着麥克風說出需求，說多久都行，不用急。

說完了，再按一下音量+，聽寫結束。

文字上屏的瞬間，聽到 Tink 一聲，窗口微微一抖，發送窗口打開了。

再按一下音量+，指令直接發送，AI 開始工作。

然後我就可以去倒杯咖啡、刷刷手機、回個消息。

當然，也可以再開個 terminal，提高並行度。

如果發現說完之後有些不太準確的想要手動修改，或者還要繼續補充些信息才發送，那就不按第 3 下，窗口幾秒後自動關閉重置。

一個按鈕，三種結果，全靠時間控制。

完全由我，遠程掌控。

現在，我可以坐在沙發上，端着咖啡，對着這個小麥克風說出想法，然後看着 AI 把它變成代碼。

鍵盤不再成為束縛。

想法才是。

三步上手

上面寫了這麼多原理和迭代過程，如果你也想要一個，只需要三步。

第一步：買個 DJI Mic Mini

京東購買連結（同樣有我的碼，方便統計）：https://u.jd.com/N61cCGv

單發射器到手不到 200 塊，10 克重量，重量上完全無感，還有着誇張的 400 米傳輸距離。

第二步：裝一個 Typeless

Typeless

免費版每週 4000 字夠日常用，Pro 版 $12/月。

也可以用我的邀請碼，你若用了我會得到些什麼好處，可能你也會有。

且 Typeless 在 macOS 聽寫之上加了一層 LLM 智能編輯，識別準確率和輸出質量都會好很多。

第三步：讓 AI 幫你配置

我已經把完整的配置和腳本都開源了，你不用重走我的老路，讓你的 AI 自己來就好了。

複製下面這段指令，直接粘貼到 Claude Code / Codex / Cursor 的對話框裏：

幫我配置 DJI Mic Mini 語音聽寫，項目在 https://github.com/Johnixr/dji-mic-dictation

它會自動幫你安裝 Karabiner、複製腳本、合併配置、授權權限。

不要手動安裝。

讓 AI 來。

如果還是不行，那十有八九是 macOS 的權限沒給全。

去系統設置 → 隱私與安全，把這幾個都打上勾：

• 輸入監控：Karabiner-Elements、karabiner_grabber

• 輔助功能：Karabiner-Elements、你的終端 App（iTerm2 / Terminal.app）

• 聽寫：系統設置 → 鍵盤 → 聽寫 → 開啓

如果發現按鈕只調音量不觸發聽寫？

那是 Karabiner 沒抓到設備。

能聽到有提示音但窗口不抖？

那是 osascript 缺輔助功能權限。

還有什麼問題的話，GitHub 倉庫的 README 裏有完整的排查清單。

扔給你的 AI，它會告訴你怎麼做。

工具清單

📎 開源地址：https://github.com/Johnixr/dji-mic-dictation 

複製這段指令粘貼給你的 AI：幫我配置 DJI Mic Mini 語音聽寫，項目在 https://github.com/Johnixr/dji-mic-dictation

本文中的配置和腳本已在 macOS Sequoia + Karabiner-Elements 15.9.0 + DJI Mic Mini 上驗證通過。如果你用的是其他設備，只需修改配置中的 vendor_id 和 product_id 即可。

最後，廣告時間

我們正在找人。

目前還只是一個小團隊，做 AI 驅動的 agentic 全球產品。

至於需要什麼樣的人？

你看完這篇文章應該能感受到了，我們要的就是，不只是會寫代碼的人，而是能讓 AI 替你寫代碼、替你解決問題的人。

比如能提出、並解決我這篇文章裏說的這類事情的人。

有興趣的話，歡迎聯繫。也可以讓你的 OpenClaw 聯繫我的 OpenClaw，見：我用 OpenClaw 做了個社交平台，讓 AI 先替我面試

歡迎來撩！

相關連結

• Typeless: https://www.typeless.com/?via=john-yin

• DJI Mic Mini: https://u.jd.com/N61cCGv

• 開源地址：https://github.com/Johnixr/dji-mic-dictation