Wei Builds：AI 與自動化

讓 AI 代理自動批准指令有多危險：Pixel Crew 的 Bash 圍欄是怎麼補的

weiwei — Tue, 27 Oct 2026 00:00:00 GMT

Pixel Crew 是我做的本機工具，把多個 Claude Code 與 Codex session 放進一間像素辦公室，最多同時 20 個。這種用法下自動批准一定要開，不然 20 個代理每做一件事都要你按一次允許，等於沒有自動化。但自動批准的另一面是，代理一旦被餵了惡意內容，或者單純判斷錯誤，它跑的指令不會再經過你。10 月 7 日我對這塊做了一次完整審視，抓到八種繞過，當天全部修掉。這篇一個一個講：怎麼繞、為什麼會漏、怎麼補。程式碼都在公開 repo，連結放在各段。

沒開自動批准的樣子：NPC 停在原地等你按。20 個 NPC 都這樣，你一整天就在按允許。

先講結論：白名單放行，黑名單只負責說理由

第一版的想法很直覺，列一張危險指令清單，rm -rf、sudo、mkfs、curl | bash，沒命中就放行。審視之後整個反過來：自動批准只靠一張很窄的白名單，只放行認得出來的唯讀指令；危險指令清單還在，但它的工作變成「被拒絕的時候把理由講清楚」。

原因很簡單。黑名單只能擋你想得到的形狀，shell 能表達同一件事的方法太多了。下面八個洞，有六個都是「這條指令長得不像危險指令，但做的事是」。

Pixel Crew 現在有四檔：

模式	行為
off	每件事都問
safe	只放行白名單裡的唯讀指令，其餘都問
full	預設放行，只擋黑名單命中的毀滅性指令
invincible	什麼都不擋，等於 Claude Code 的 `--dangerously-skip-permissions`

full 有一件事要講明：非 Bash 的工具呼叫，包括每一台接上來的 MCP server 的每一個工具，在 full 模式是無條件放行的。沒有逐工具的風險分級。所以 full 的意思不是「對 shell 寬鬆一點」，是「MCP server 能做的事都不再問」。這句話我寫在程式碼註解裡，也要求所有介面文案照這個意思寫。

safe 模式一條 Bash 指令要連過五關才會自動放行，任何一關沒過就回到問你。後面八個洞裡有五個，都是其中某一關原本漏了：

safe 模式的五關。虛線是任一關沒過的去向。

洞一：唯讀指令配上旗標就會寫檔或執行程式

白名單一開始認的是指令前綴：git diff、git status、rg、ls、cat 這些。問題是同一個指令配上某些旗標，就不唯讀了。實測過的兩個：

git diff --output=/tmp/outside.txt   # 會把外部檔案截斷成空檔
rg --pre ./evil.sh TODO              # 會對每個檔案執行 evil.sh

修法是在前綴比對之後再比對一張「寫入或執行旗標」的表，而且比對前先把引號跟反斜線剝掉，因為在 shell 裡 "--output=x"、--out""put=x、\--output 都等於 --output=x。tsc 的選項名稱不分大小寫，--OUTDIR 一樣有效，所以那條要忽略大小寫。npm、pnpm、yarn 的 --script-shell、--node-options、--prefix 也在表上。

sed 乾脆不用前綴放行。就算是 sed -n，也能用 w 指令寫檔、用 e 指令執行外部命令，例如 echo x | sed -n "w /path"。白名單只收 Codex 讀檔時慣用的那一種整句形式，sed -n '1,200p' 檔案，腳本只能是行號範圍加 p，檔案參數不能是選項、不能有萬用字元。

洞二：zsh 不需要分號就能執行另一個指令

白名單原本用一組 shell 中繼字元判斷「這條指令有沒有夾帶別的東西」：換行、;、&、|、<、>、反引號、$(、${。這在 bash 大致夠用，但 macOS 的預設 shell 是 zsh，Claude 的 Bash 工具也跑在上面，zsh 多了幾種不需要任何中繼字元的寫法：

ls *(e:'touch pwned':)    # glob qualifier，列檔案的同時執行 touch
cat =(cmd)                # process substitution
git diff --out{put,}=x    # brace expansion 拼出上面擋掉的旗標

修法：引號外出現 (、)、{、} 任何一個，就不算白名單安全指令。

洞三：萬用字元會展開成檔名，檔名可以長得像旗標

rg TODO *.ts 看起來無害。但 *.ts 會在執行前被 shell 展開成目錄裡的檔名，而檔名可以就叫 --pre=x.ts。洞一那張旗標表是在展開前比對的，看不到展開後才出現的選項。

修法只對有危險旗標的工具收緊：git、rg、eslint、tsc、npm、pnpm、yarn 這幾個，引號外出現 *、?、[ 就不自動放行。ls *.ts、cat *.md 這類沒有能寫檔或執行的旗標，照舊可以用萬用字元，不然白名單會窄到沒人想用。

洞四：寫入重導向有很多種寫法

Pixel Crew 對檔案工具有一道圍欄：寫入目標逃出 workspace 就硬擋。Bash 沒有結構化的路徑參數，所以另外做了一個函式，掃出指令裡「寫入型重導向」的字面目標，逃出 workspace 就回 true。第一版只認 > 跟 >>。審視時補上的：

cmd 1> /etc/x        # 帶 fd 編號
cmd 2>> ~/.zshrc     # fd 加 append，目標還要先展開 ~
cmd &> $HOME/x       # stdout 跟 stderr 一起寫，$HOME 在雙引號內會展開、單引號內不會
cmd >| /tmp/x        # 強制覆寫，zsh 也認 >!
cmd >& /tmp/x        # >& 後面接檔名就是寫檔，不是 fd 編號

同時要排除不是寫檔的：2>&1、>&2、>&- 是 fd 複製或關閉，/dev/null、/dev/stdout 是丟棄輸出。~user、~+ 這類靜態判定不了的，一律當成逃逸。

這個函式的註解我寫得很白：刻意不做完整 shell 解析，這是防禦縱深，不是圍牆。它只認字面重導向目標，對變數展開（p=/etc; echo > $p）、子殼、python -c "open(...)"、cp、mv、tee 的目的地，一律「認不出等於不擋」。測試檔裡有一個案例叫 documented residual bypasses are NOT flagged，專門確認這些繞過真的不會被擋，免得哪天有人以為圍欄比實際上厚。

寫入重導向圍欄的兩邊。右邊是刻意不處理、但明講的部分。

洞五：檢查看的是卡片文字，不是完整指令

核准卡片顯示的指令有長度上限，20,000 字元。原本的檢查是對卡片上的文字跑，所以在危險片段前面塞兩萬個字的填充，檢查就只看得到無害的開頭。

修法兩條：危險指令的比對一律對完整指令跑；長度超過上限的指令不自動放行，直接交給人，理由寫「指令超過 20,000 字元，無法完整顯示與檢查」。卡片顯示不完整的東西，本來就不該有人幫你按允許。

洞六：Windows 的防線根本沒接上

黑名單有 Unix 的 rm、mkfs、dd，卻漏了 Windows 的對等指令，而 Windows 是 Pixel Crew 的主要平台之一。補上的：

Remove-Item -Recurse -Force C:\repo\dist
Remove-Item build -r -fo        # PowerShell 參數可以縮寫
rd /s /q C:\repo\dist
del /f /s /q *.log
format D: /q

幾個細節。del、erase、rd、rmdir、ri 都是 Remove-Item 的別名，要一起認。format 後面要直接接磁碟代號才算，不然會誤中到處都是的 --format 旗標。Windows 的指令與別名解析不分大小寫，Git Push --Force 跟 git push --force 一樣，所以整組比對都要忽略大小寫。

路徑也有 Windows 專屬的洞。判斷「目標有沒有逃出 workspace」用的是 path.relative()，看結果是不是 .. 開頭。但跨磁碟（D:\）、UNC（\\server\share）、\\?\ 路徑跟 workspace 沒有共同的根，relative() 會直接回傳目標的絕對路徑，不是 .. 開頭，第一版就放過去了。修法多一個條件：結果是絕對路徑也算逃逸。

洞七：對外提供檔案的目錄不能是 symlink

每個 NPC 有一個 outbox 目錄，裡面的檔案可以從網頁下載。路徑檢查會擋 ..，但如果 outbox 本身是個 symlink 指到別處，檢查過了、讀到的卻是別的地方的檔案。修法是提供檔案前先確認 outbox 目錄不經過 symlink，workspace 裡的路徑檢查本來就會逐層 lstat，這裡補成一致。

洞八：Read 跟 WebFetch 不該預先放行

為了少跳提示，第一版把 Read、Glob、Grep、WebSearch、WebFetch 當成唯讀工具預先放行。問題是 Read 可以讀 workspace 外的檔案，WebFetch 可以抓任意網址，前者外洩，後者是把外部內容餵給代理的入口。現在這兩個在 safe 模式一樣要經過批准，只有讀 workspace 內的檔案才直接過。

還有一個不是洞的坑：Codex 的指令外面包了一層殼

Codex CLI 回報的每一條指令都包成 /bin/zsh -lc <cmd>，內層有單引號時改用雙引號、單字時不加引號。前綴白名單永遠對不上這個外殼，等於 Codex 在 safe 模式什麼都要問。修法是只拆「一層」，而且只拆引號內不可能有跳脫或展開的形式；拆不乾淨就回 null，照一般判定走，不會因此多放行任何東西。

修完之後的規則

自動放行只看窄白名單；黑名單負責拒絕理由。
白名單比對指令名、也比對旗標；比對前剝引號與反斜線。
引號外出現 (){} 或對旗標敏感的工具遇到萬用字元，不放行。
串接指令逐段檢查，每一段都唯讀才整條放行；只容忍 2>&1、2>/dev/null 這類丟棄輸出。
寫入重導向逃出 workspace 就擋，認不出的形狀不擋，但寫在文件裡。
看完整指令，超過 20,000 字元交給人。
Windows 的刪除與格式化指令、跨磁碟與 UNC 路徑，跟 Unix 同等待遇。
只有使用者親手切換才能進 full 與 invincible，介面要說清楚 full 對 MCP 工具是全放行。

殘餘的風險我也列在文件裡：變數展開、子殼、直譯器內的檔案操作、tee 與 cp 的目的地，這些在 full 模式下會過。開 full 的人要知道自己換到的是什麼。

改到的檔案：dangerousCommand.ts、bashWriteFence.ts、safeLocalPath.ts，以及對應的測試。發現繞過請走私密弱點回報，七天內回覆。

Mac 本機轉錄中文會議誰準：Breeze ASR 25、Qwen3-ASR、macOS 內建實測，還有預設為什麼不選最準的

weiwei — Tue, 27 Oct 2026 00:00:00 GMT

拾音是我做的 Mac 會議紀錄工具，錄 Zoom、Meet、Teams 不用機器人，轉錄在本機跑，不把錄音送出去。本機轉錄的模型從第一版起就是聯發科的 Breeze ASR 25，走 whisper.cpp。10 月 24 日那次評估我把 Qwen3-ASR、TEA-ASR 和 macOS 內建辨識一起拉進來比，結果 Qwen3-ASR 1.7B 在六人遠距收音的中文會議上字錯誤率 17.5%，Breeze 25.7%。4.1 版把 Qwen 放進設定裡當選項，預設沒換。這篇把資料集、數字、換模型要多做的事，還有為什麼預設不選最準的，一次寫清楚。評估腳本和資料集清單都在公開 repo。

拿什麼量

轉錄準不準，要看拿什麼錄音量。乾淨的朗讀句子每個模型都 2% 上下，拉不開差距，會議才會。我用的錄音：

錄音	內容	量什麼
AISHELL-4 M_R003S01C01	中文會議，6 人，38 分鐘，遠距麥克風陣列收音	多人搶話、遠距收音的中文
AMI ES2004a	英文會議，4 人	英文、同時說話
TaiMECS	100 句台灣國語中英夾雜，20 句真人、80 句聲音複製	中英夾雜的句子
合成的中英夾雜會議	91 秒，塞了 6 個產品名、系統名	專有名詞（關鍵詞）對幾個
台大機器學習 2021 課程	前 15 分鐘	單人講課；Breeze 和 TEA 都拿它訓練過，只當參考
日本眾議院 AI 法案專家聽證	兩段，約 15 分鐘與 10 分鐘，各 6 位說話者	日文

算分之前先正規化：去標點和空白、中文統一成繁體（AISHELL-4 的答案是簡體）、數字寫法和常見異體字統一。中文算字錯誤率（CER），英文算詞錯誤率（WER），另外算插入、刪除、替換各佔多少，才知道錯的是哪一種。下面的表都是去掉語助詞後的數字，因為 Whisper 系的模型會「整理」口語，把「嗯」「那個」丟掉，算進去會把漏字跟聽錯混在一起。含語助詞的原始數字我也留著，AISHELL-4 上 Breeze 約 29%、macOS 內建約 25%、Qwen 約 18%。

機器是 M3 Pro。評估跑的是 app 真正的轉錄流程，不是另外寫的腳本，所以說話者辨識、分段、詞彙表提示全部照實際使用時的設定來。

拾音的逐字稿分頁。示範錄音就是 AMI 的 ES2004a，這篇英文的數字都從它來。

數字

中文會議拉開 8 個百分點，英文會議大家一樣爛，錯的都是同時說話的地方。

完整的表：

去語助詞錯誤率	合成中英夾雜	TaiMECS	台大課程	AISHELL-4	AMI 英文	日文聽證	速度
Breeze ASR 25 q8_0	5.2	2.0	3.8	25.7	32.6	9.0（turbo）	9 倍速
Qwen3-ASR 1.7B q8_0，30 秒一段	2.0	1.8		16.2	31.6	17.1	17 倍速
Qwen3-ASR 0.6B q8_0，30 秒一段	2.0	2.5	6.7	17.0	32.4		36 倍速
TEA-ASR 1.1 q8_0，30 秒一段	2.8	2.4	3.4	34.8	36.3	22.2	15 倍速
Qwen3-ASR 1.7B，拾音的實作（預設分段）	2.0	1.8	6.6	17.5	31.3		12 倍速

速度是音訊長度除以轉錄時間，9 倍速就是 38 分鐘的會議轉 4 分多鐘。macOS 內建辨識沒放進表裡，它在 AISHELL-4 上含語助詞約 25%，跟 Breeze 差不多，而且快 160 倍、不用下載模型；但合成的中英夾雜會議裡六個關鍵詞它只對一個，Breeze 加詞彙表對五個。台灣公司的會議就是中英夾雜，所以它一直是選項，不是預設。

台大課程那欄 Breeze 比 Qwen 好，是因為那份錄音在 Breeze 的訓練資料裡。Qwen 在那裡的「錯」多半是向量名稱的寫法，標準答案寫 a1、a4，它寫 a one、a 四，替換的 136 個字裡約 40 個是這種，不是聽錯。會議的結論以 AISHELL、AMI、TaiMECS 為準。

Breeze 的錯是哪一種

換模型之前先確定不是參數沒調好。用評分腳本的混淆統計看 Breeze 在 AISHELL-4 漏掉的字，35% 落在多人同時說話的地方，另一大塊是語助詞和兒化音，真正聽錯而替換的多是同音字。

然後掃解碼參數：關掉 context、不做降溫重試、beam 開到 8、提示詞改成自然句。每一種跟預設差距都在 1% 以內，不做降溫重試還讓日文從 9.0% 變差到 12.6%。參數沒有空間了，瓶頸是模型。

候選怎麼篩

三個候選各有一個致命傷。

TEA-ASR 1.1 是台灣微調版，原生輸出繁體，乾淨錄音最好（TaiMECS 2.4%）。但吵雜的多人錄音會跳針，「那那那那」一路到被截斷，還會整段漏，AISHELL-4 34.8%，比 Breeze 還差。Q4_K_M 量化更糟，TaiMECS 掉到 31%。日文會把漢字改成繁體，「国」變「國」。

Qwen3-ASR 0.6B 快到 36 倍速，AISHELL-4 也有 17.0%，但單人講課 6.7%，TaiMECS 2.5%，比 1.7B 差一截。省下的時間在會議紀錄這個場景沒意義，反正轉錄是背景跑的。

Qwen3-ASR 1.7B 完全不跳針，數字最好，兩個問題：只輸出簡體，用 context 怎麼導都導不成繁體；而且不輸出時間點。這兩個問題拾音自己處理，下面兩段講。

沒有時間點，段落自己切

whisper 的流程是整段丟進去，它吐出帶時間的段落，再拿段落去配說話者。Qwen3-ASR 整段一次轉（官方最長 20 分鐘）出來是一整坨字，沒有時間，說話者標不了。所以順序要反過來，先辨識說話者，再依說話者的片段切段轉錄。

怎麼切影響很大。我試過的：

照標準答案的說話者片段切：重疊處的話被切掉，AISHELL-4 從 16.2% 退到 22.2%，AMI 45.9%。
固定長度：10／15／30／60 秒一段，AISHELL-4 是 17.1／16.3／16.2／15.7%，長一點準一點。但 AMI 在 15 秒掉到 39.6%，30 秒是 31.6%。
在換人處的安靜點切、每段最長 15 秒：AISHELL-4 17.7%，說話者標對 95.5%。AMI 卻是 40.0%，多出來的 228 個字是短而吵的段落自己編出來的整段話，有一段 19 秒冒出一整段天氣預報。

最後一種加上幻覺防線才能用。每一段「有聲音的秒數」能講的字有上限，英文每秒 5 個字加 3，中日文每秒 8 個字加 4，輸出超過就是在編。超過的段落換一組溫度和種子再解一次，兩次相似度低於 0.6 就丟掉，差不多就留短的那次並標低信心。加上這條，AMI 從 40.0% 回到 32.7%，多出的字從 228 個變 18 個。

拾音接 Qwen3-ASR 的流程。框線是紫色的兩步決定了 AMI 的數字能不能看。

還有一條：真的說話者辨識比標準答案粗得多，AISHELL-4 的 38 分鐘只抓到 88 次換人，所以「換人處的安靜點」很少真的切到。補救是一段裡第二多的說話者超過 1.5 秒而且超過這段的 25% 時，照說話者片段的起點再切一次。理想的說話者辨識下 AISHELL-4 說話者標對從 95.5% 到 98.2%，AMI 從 92.4% 到 97.5%，錯誤率各多 0.3 跟 1 個百分點。這是現在的預設。

跳針的處理放在同一段流程裡。結果到達 max_tokens、壓縮比超過 2.4、或同一個一到六字的片段連續出現五次以上就算壞掉。先加重複懲罰、降溫重試；還壞而且這段超過 6 秒就在最安靜處切成兩半各自再來，最多三層；再壞就留壓縮比較低的那次，連續重複縮成三次，標低信心。

簡體轉台灣用字，不帶 OpenCC

Qwen 只出簡體。ICU 的 Hans-Hant 是逐字轉，「頭發」「皇後」這種一對多的字會錯。帶 OpenCC 的 C++ 程式庫要為 Mac 和 Windows 各包一次。最後是拿 OpenCC 的字表自己寫：詞組表 49,238 條、單字表 4,012 條、台灣異體字 40 條，只留每個鍵的第一個候選，約 1 MB。演算法從左到右，先在詞組表找最長匹配（最長 16 字），沒有就查單字，查不到原樣保留，最後套異體字，「臺」寫成「台」。

一個要留意的點：鍵和值相同的詞組要保留。「公里」「皇后」這些條目看起來沒用，是拿來擋逐字轉換的，拿掉之後「公里」會變「公裡」。

用語替換（軟件→軟體）沒做。辨識結果寫的是說話者說出口的詞，人家說「軟件」就寫「軟件」。繁簡也算錯的時候 TaiMECS 2.0%、合成會議 2.0%，還是比原生繁體的 TEA 好。

預設為什麼不換

數字擺在那裡，Qwen3-ASR 1.7B 在中文會議上少 8 個百分點，速度 12 倍對 9 倍，記憶體 2.6 GB 對 2.8 GB，都比 Breeze 好。

預設沒換，是因為拾音的使用者是台灣的公司，阿里巴巴的模型在那個環境裡會有顧慮。這是產品定位，跟準確度無關。10 月 24 日決定 Breeze 維持預設，Qwen 放在「設定 → 錄音與轉錄 → 正式轉錄」當第二個選項，說明文字寫明是阿里巴巴開源的模型、全程在這台 Mac 上跑、不連網、要下載約 2.5 GB。沒選它的人不會下載任何東西，流程跟 4.0.0 一模一樣。

Breeze 還有兩個地方比較好。說話者標對率它是 97.2%／96.1%，Qwen 的實作是 96.3%／93.8%，因為 Qwen 的段落最長 15 秒，比 whisper 的粗，搶話多的會議標錯的比例高一些。另一個是中英夾雜的訓練資料就是針對台灣，單人講課 3.8% 對 6.6%。

日文另外一套

日文會議三個模型都試過。Breeze 會把片假名外來語寫成英文。kotoba-whisper v2.0 在 whisper.cpp 上會亂輸出、整句漏掉。Qwen3-ASR 日文聽證 17.1%。最後用 Whisper large-v3-turbo q5_0（574 MB），國會聽證 9.2%／7.7%，合成會議 4.5%，而且標準答案用的國會會議錄本身刪掉了語助詞，實際錯誤率會比這個低。只有第一次轉錄日文會議時才下載。

語言偵測也不能用 Breeze，它會把英文判成中文。偵測用 Whisper base q5_1，60 MB，錄音開始後收滿 10 秒有聲音的片段就判一次。

詞彙表當提示詞有多大用

這是 Breeze 從第一版就在用的做法，詞彙表以「、」隔開塞進 initial_prompt，中文 150 字、英文 400 個字元以內。合成的中英夾雜會議裡六個關鍵詞，加詞彙表對五個，不加的 macOS 內建辨識對一個，CER 3.2% 對 5.8%。Qwen 接上後用同一份詞彙表當 context，上限一樣。

試過但沒採用的

轉錄前的語音活動偵測（VAD）：whisper.cpp 內建的那個，開了之後 AISHELL-4 從 30.5% 惡化到 38.4% 到 47.8%，只有乾淨的合成錄音變好。它想解決的「安靜時憑空產生文字」，事後過濾已經擋掉大部分。
麥克風跟電腦聲音分聲道各自轉錄：只在戴耳機的線上會議有幫助，錯誤率少約 3 個百分點；有回音時沒有比較好，說話者標對率還從 95% 掉到 79%～88%，速度減半。設定裡沒開放，要測得用 defaults 寫隱藏鍵。
只調 Breeze 的參數：上面講過，差不到 1%。

自己重跑

拾音 DEBUG 版的 shiyinctl transcribe-eval <錄音> <設定.json> <輸出.json> 走 app 真正的轉錄流程，不建會議、不寫資料庫，設定可以指定引擎、語言、詞彙表、分聲道、回音處理。評分用 asr-score.swift，正規化規則和混淆統計都在裡面。資料集的來源、授權和下載位置在 docs/design.md 第 32 節。AISHELL-4 和 AMI 都是公開語料，TaiMECS 是 CC BY 4.0。

數字是 2026 年 10 月 24 日的，模型版本是 Breeze ASR 25 q8_0、Qwen3-ASR 1.7B q8_0（ggml-org/Qwen3-ASR-1.7B-GGUF）、llama.cpp b8769 之後的版本。模型更新了數字會變，重跑比引用快。