avoid-ai-writing：把「AI 腔」當成可稽查的清單，而不是一句模糊的提示

它解決的不是文筆問題，而是「無法驗證」的問題

多數人叫 AI 改寫文字時，只會說「讓它聽起來更像人寫的」。這句話沒有操作定義，代理也只能憑感覺亂猜。avoid-ai-writing 把這件事變成一份可稽查的清單：74 類模式、112 條替換詞表、10 個 Tier 3 片語。它不問「這段話順不順」，而是問「這段話有沒有出現 delve、tapestry、in order to 這類頻率標記」。這個轉變很關鍵。因為模式是可以列舉、可以檢查、可以反覆驗證的。你不需要相信代理的判斷，你可以看它回報的引文、替換前後、以及第二輪稽核結果。對編輯或工程師來說，這比「我感覺更自然了」有用得多。它的目標使用者不是一般寫作者，而是已經把寫作流程交給代理、卻對輸出品質沒有把關機制的人。

三層替換表與兩次掃描：它如何避免「越改越 AI」

專案最值得看的設計是它的分級替換邏輯。Tier 1 分成 1A 與 1B：1A 是頻率標記，例如 delve、tapestry，這類詞出現本身就暗示文字可能由 LLM 產生；1B 是清晰度編輯，例如 in order to、utilize，屬於字詞冗長問題。重點在於，只有 1A 能作為「這段文字是 AI 寫的」的證據，1B 的權重較低，所以一個單純的冗詞修正不會把整份文件推向 AI 分類。這個區分很實際，因為很多正常的人類草稿也會有 in order to，但不會有人類用 tapestry 來形容一個新創公司。Tier 2 的詞要成群出現才會觸發旗標，Tier 3 的片語則看重複次數或是否在同一篇裡堆疊三個以上。後者捕捉的是 LLM 自我變異的習慣：它會用不同片語表達同樣的陳腔濫調。另外，改寫後會跑第二遍掃描，專門抓第一輪漏掉的過場詞、殘留的誇大語氣、以及偷渡的 copula 替換。這等於承認單次改寫不夠，所以才需要內部驗證。

三種模式對應三種工作情境，edit 模式拒絕碰程式碼

預設的 rewrite 模式會直接改寫文字，並回報改了什麼。detect 模式只標記不改寫，而且會區分哪些旗標是真正的問題、哪些只是判斷題。這個設計對審稿很有用，例如你懷疑某段文字有 AI 腔，但不想讓代理擅自更動。edit 模式則是用 Edit 工具對散文檔做最小變更，保留已經很自然的段落。它明確拒絕處理原始碼、設定檔與產生的資料，理由是散文改寫可能破壞結構化內容。這個限制是正確的，因為很多類似的工具會無差別地對程式註解或 JSON 字串動手，結果造成語法錯誤。但這也意味著，如果你的內容是 Markdown 表格或含大量程式碼區塊的技術文件，edit 模式可能無法勝任，因為它判斷「結構化」的標準並未在 README 中詳細說明。

安裝路徑與單檔版：目錄結構比你想的更嚴格

安裝方式有幾種，但都圍繞一個核心要求：SKILL.md 必須與 references/patterns.md 放在一起，因為入口檔案在稽核前會載入模式目錄。README 特別警告，不要只複製精簡的入口檔，舊的安裝方式若只抓根目錄的 SKILL.md 會漏掉必要參考。在 Claude Code 中，你可以用 git clone 到 ~/.claude/skills/avoid-ai-writing，或下載 dist/avoid-ai-writing.md 這個單檔版本。後者包含所有規則與設定檔，並提供命令不可用時的手動替代方案。你也可以把它做成 slash command，在 CLAUDE.md 裡用 $ARGUMENTS 傳入文字。如果你用 Claude Cowork，情況就不同了，Cowork 只從已安裝的外掛載入技能，不會掃描 ~/.claude/skills/，所以裸 clone 不會被發現。這個平台差異很容易踩雷，安裝前最好先確認你的代理是哪一種。

voice profile 與偵測的界線：它判斷的是「模式」不是「品質」

除了三種模式，它還提供 voice profile，可選 casual、professional、technical、warm、blunt。這個設定與受眾脈絡分開，意思是你可以指定語氣，但不必重新描述讀者是誰。這對技術文件或行銷文案的分工很方便。但要注意，voice profile 只是讓代理知道該怎麼改寫，它不改變偵測邏輯。偵測引擎依然以模式比對為核心，這代表它對「AI 腔」的定義是統計性的，不是語意性的。一段文字如果完全避開常見 AI 詞彙，但讀起來空洞、缺乏具體細節，它可能不會被標記。反之，如果你刻意使用「leverage」來強調某個技術動作，而該詞不在例外清單中，它就會被替換成 use，即使這裡的語意更精準。README 中的範例展示了它如何抓到 chatbot opener、promotional language、significance inflation 等 15 個以上的特徵，但這些都屬於可列舉的模式。

真實限制：誤判、結構化內容與「人味」的哲學問題

最大的限制在於它無法區分「有意的風格」與「無意的 AI 腔」。detect 模式雖然會標記哪些是 judgment calls，但最終還是要靠人來決定。如果你寫的是諷刺文或角色對話，裡面的「Certainly!」或「the future looks bright」可能是故意的，但 rewrite 模式不會知道。第二個限制是它拒絕處理程式碼與設定檔，這對純散文沒問題，但對含大量程式碼的技術部落格就是障礙。第三個限制更根本：它把「AI 寫作」定義為一組可偵測的模式，但實際上很多 AI 生成的文字已經學會避開這些模式。也就是說，這個技能可能追得上目前的 LLM 習慣，但無法保證未來。它的兩次掃描只能捕捉殘留的模式，不能保證改寫後的文字真的像人類。最後，README 沒有提供任何關於偵測準確率的量化數據，例如誤報率或召回率，所以使用前最好自己跑一次 detect 模式，看看它對你的文體會產生多少雜訊。

替代方案與比較：提示詞、其他技能與人工編輯

最直接的替代方案就是不用技能，只寫一個「請讓這段話聽起來更自然」的提示詞。差別在於，提示詞沒有結構化回報，你無法知道代理改了什麼、為什麼改。avoid-ai-writing 的回報包含引文、替換、變更摘要與二次稽核，這讓你可以驗證它的工作。另一個替代是使用 Grammarly 或 ProWritingAid 這類文法檢查工具，它們擅長找出被動語態或冗詞，但它們不是為 LLM 模式設計的，不會偵測「Certainly!」開場或「experts believe」這類模糊歸因。還有一個方向是人工編輯，這永遠是最可靠的，但成本高，而且如果你的內容量很大，代理可以加速初稿清理。比較實際的做法是，先用 detect 模式讓代理標記，再由人決定哪些要改，這比完全自動 rewrite 更安全。

編輯結論

如果你的工作流程是讓 Claude Code、OpenClaw 或任何 agentskills.io 相容代理處理大量散文，而且你受夠了「請寫得更像人類」這種沒有驗證的指令，avoid-ai-writing 值得一試。它把主觀感受轉成可引用的模式清單，並提供 detect 模式讓你在改寫前先判斷哪些旗標是真的問題。但如果你寫的是程式碼、設定檔或任何結構化內容，請直接跳過，因為它明確拒絕處理這類文字。若你只需要偶爾手動清理一段文字，也不必安裝整個目錄，下載 dist/avoid-ai-writing.md 即可。安裝前先確認你的代理是否支援目錄式技能，特別是 Cowork 只從已安裝的外掛載入，不會掃描 ~/.claude/skills/。最後，請記住它的偵測依據是模式比對，不是語意理解，所以它可能漏掉真正拙劣但沒有典型 AI 特徵的文字，也可能把刻意使用的詞彙誤判為 AI 腔。先跑一次 detect 模式，看看它對你的文體會產生多少誤報，再決定是否要讓它自動改寫。

官方來源

1. conorbronsdon/avoid-ai-writing on GitHub
2. License: MIT
3. Project website
4. README
5. Releases