Writing Tools：把系統層級的 LLM 改寫塞進 ctrl+space
The world's smartest system-wide grammar assistant; a better version of the Apple Intelligence Writing Tools. Works on Windows, Linux, & macOS, with the free Gemini API, local LLMs, & more.
秒懂
- 它是什麼？
- 這個專案用一個全域快捷鍵在任何應用程式裡改寫選取文字，後端可以接免費 Gemini API 或本機 LLM。它解決的是真實痛點，但 Windows/Linux 與 macOS 兩套實作、以及 GPL-3.0 的授權邊界，是採用前必須先弄清楚的事。
- 適合誰用？
- 如果你要的是「在任何應用程式裡選取文字、按一下就改寫」，而且能接受把文字送到第三方 API 或自己跑本機模型，Writing Tools 是少數直接針對這個場景做的開源選項，Windows 使用者尤其適合先從 Releases 的 Writing.Tools.zip 試起。不該採用的情況同樣明確：Linux 版在 README 裡仍標示為 work-in-progress，需要穩定產出的環境不應把它當正式工具；企業若要把程式碼併入自家產品，GPL-3.0 的傳染性必須先由法務確認。
- 可以商用嗎？
- 可以，但有條件。GPL-3.0 是 copyleft 授權：如果你散布包含它的軟體，就必須以同一授權公開該軟體的原始碼。只在內部執行、不對外散布，則不會觸發這項義務。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 28 天前。
- 用什麼語言寫的？
- 主要是 Swift（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是「切換視窗」這件事，不是文法檢查本身
市面上的寫作輔助工具大多以瀏覽器擴充或獨立編輯器形式存在，問題在於使用者的文字往往不在那些地方。回信在郵件客戶端、貼文在社群網頁、程式碼在 IDE、字幕在剪輯軟體，要請 AI 改一段話，就得先複製、切到另一個視窗、貼上、等回覆、再複製回來。這個來回本身就是成本。
Writing Tools 的定位是把這個流程壓縮成一次按鍵。README 的說明是：在電腦上選取任何文字，用 ctrl+space 呼叫，接著選 Proofread、Rewrite、Friendly、Professional、Concise，或直接輸入自訂指令，例如把文字轉成 title case、翻譯成法文、或替程式碼加上註解。改寫後的結果會直接取代原本選取的文字，按 ctrl+z 可以還原。
目標使用者輪廓相當清楚：需要在多個應用程式之間來回寫字的人。README 特別強調它不碰剪貼簿，這一點對照上述流程就能理解，因為一旦動用剪貼簿，使用者原本複製的內容就會被覆蓋。它也提到在沒有選取文字時按 ctrl+space 會開啟對話視窗，而且視窗關閉時聊天紀錄會刪除。
作者自述是來自 Bangalore 的高中生 Jesai，macOS 版本由 Arya Mirsepasi 建置。這個背景不影響技術判斷，但可以解釋為什麼專案的說明文件與發佈節奏帶有明顯的個人專案特徵。
運作機制：全域快捷鍵、選取文字、替換回去
從 README 能確認的資料流只有三段：使用者選取文字、按下全域快捷鍵、AI 回傳的內容取代原本選取範圍。中間如何取得其他應用程式的選取文字、如何把結果寫回去，README 並沒有描述，因此無法從現有材料判斷它是模擬鍵盤事件、透過系統輔助功能 API，還是其他做法。這一點在評估時要誠實面對：它決定了工具在不同應用程式裡的可靠度。
後端是可替換的。README 列出三條路徑：免費的 Gemini API 搭配 Gemini 2.0、透過 Ollama 或 llama.cpp、KoboldCPP、TabbyAPI、vLLM 等本機 LLM、以及透過 OpenAI API 相容介接的雲端服務如 ChatGPT、Mistral AI。也就是說這個專案本身不是模型，而是模型前面的介面層。
摘要功能走的是另一條路徑。README 描述的做法是先用 ctrl+a 選取整份網頁或文件，或選取 YouTube 影片說明欄裡的逐字稿，再選 Summary、Key Points 或 Table，結果會以 Markdown 渲染成彈出視窗，並且可以對摘要繼續提問。這裡值得注意的是輸入來源是「選取範圍」而不是網址解析，所以能不能摘要一支影片，取決於你能不能先拿到它的逐字稿文字。
自訂按鈕是同一套機制的延伸。README 把它描述成使用者自己定義的按鈕，實際上就是預先寫好的指令集，省去每次重新輸入提示詞。
安裝與設定：Windows 解壓即用，Linux 還在路上
Windows 的安裝步驟在 README 裡寫得很短：到 Releases 頁面下載最新的 Writing.Tools.zip，解壓到指定位置，執行 Writing Tools.exe。建議放在 Documents 或 App Data/Local。
這裡有一個容易踩到的細節。README 明確指出 Writing Tools 是可攜式應用程式，如果解壓到受保護的資料夾例如 Program Files，首次啟動必須以系統管理員身分執行，因為它需要在與 exe 同一個資料夾內建立和編輯設定檔。換句話說，設定檔的位置跟著執行檔走，這對備份和遷移是好事，但也意味著放在唯讀目錄會直接失效。
開機自動啟動不是預設行為，README 說要從工作列右下角的系統匣圖示進入 Settings 開啟。快捷鍵本身可以自訂，README 在自訂化段落提到可以設定自己的 hotkey。
本機 LLM 的路徑以 Ollama 為代表，README 指向 v7 之後的 Windows/Linux 說明。免費雲端路徑則是 Gemini API。兩者的取捨很直接：本機模型資料不出裝置、可離線，但需要自己處理模型下載與推論資源；雲端 API 免安裝，但文字會離開你的機器。
Linux 版本在 README 中標示為 work-in-progress，這是採用決策裡最硬的一條限制，後面會再談。
兩套實作：Swift 寫的 macOS 版與另一條 Windows/Linux 路線
專案的主要語言標示為 Swift，但 macOS 版是後來才由 Arya Mirsepasi 建置的獨立移植。README 開頭就放了一個分流提示，請 Mac 使用者直接跳到 macOS (Native Swift Port) 段落。這件事的意義是：這個專案實際上不是單一程式碼庫，而是至少兩套針對不同平台的實作並行維護。
發佈命名也反映了這一點。最近的版本標籤是 Win_v9+mac_OS_v6.1、Win_v8+mac_OS_v6.1、Win_v8+mac_OS_v6.0，Windows 與 macOS 的版號各自演進，不是同一個號碼。對使用者的實際影響是：同一個功能在不同平台上的可用性與行為可能不一致，遇到問題時要確認你查的是哪一邊的文件。
README 裡有一句值得注意的說法，它聲稱這是唯一能在 Intel Mac 或歐盟地區使用類似 Apple Writing Tools 功能的途徑。這類獨佔性宣稱無法從現有材料驗證，讀者應該把它當成專案方的定位陳述，而不是已核實的事實。
維護成本方面，材料只支持一個觀察：README 提到作者是高中生，並公開列出貢獻者名單，其中 momokrono 貢獻甚多。這代表專案的持續性依賴少數人的投入，而不是有組織的維護團隊。這不是缺點判決，但對於要把工具放進日常工作流程的人來說，是一個需要納入考量的現實。
真正的限制：Linux 未完成，以及被誇大的效能說法
README 對 Linux 的標示是 work-in-progress，段落甚至沒有寫完就被截斷。這不是文件疏漏，而是狀態陳述：如果你在 Linux 上工作，這個專案目前不是可以放心依賴的工具。相較之下 Windows 有完整的安裝步驟與版本發佈節奏，macOS 有獨立移植，Linux 處於兩者之間。
第二個要打折的地方是效能敘述。README 寫著「即使正在使用也佔用約 0% CPU」。這句話在架構上可以理解，因為推論發生在 Gemini 或本機 LLM 那一端，客戶端本身只負責送出請求與接收結果。但把它當成量測數據是錯的，它是一個行銷式的近似說法，而且不涵蓋本機 LLM 路徑，因為那條路徑的推論成本完全落在你自己的機器上。
第三個是模型比較。README 對比 Apple 使用 3B 參數模型、Gemini 2.0 Flash 約 30B，並說 Grammarly 的規則式 NLP 無法與 LLM 競爭。這些數字來自專案方，沒有附上評測方法。參數量的差異是真實的架構差異，但它不直接等於輸出品質的差距，尤其是在校對這種需要精確度的任務上。
最後是適用邊界。這個工具本質上是把選取文字送出去、拿改寫結果回來。如果你的工作涉及不能外流的內容，又沒有設定本機 LLM，那它就不適合你。這不是缺陷，而是這類架構的固有前提。
對照組：為什麼不直接用瀏覽器擴充或 IDE 外掛
最直接的替代方案是編輯器或瀏覽器內的 AI 擴充。以 IDE 的 AI 助理外掛為例，它對程式碼的處理通常更深入，能讀取整個專案結構、理解型別與相依關係，而不只是你選取的那一段。相對地，Writing Tools 對程式碼的支援就是把你選取的片段當成純文字送給 LLM，README 舉的例子是加註解、改進、翻譯。
這個差異決定了選擇。你要修一段跨檔案重構的邏輯，IDE 外掛是對的工具。你要把一封已經寫好的信改成更專業的語氣，而且信在郵件客戶端裡，那外掛幫不上忙，因為它不在那個應用程式裡。Writing Tools 的價值正好落在後者：它不綁定任何應用程式，代價是它對內容的理解只限於你選取的那一段。
另一個對照是作業系統內建功能。macOS 上的 Apple Intelligence Writing Tools 就是這個專案明確參照的對象，README 自稱是「更好的版本」。差異在後端：內建功能用系統指定的模型，Writing Tools 讓你換成 Gemini、本機 Ollama 或任何 OpenAI API 相容服務。這個可替換性是它最主要的架構優勢，也是它需要你自行設定 API key 或模型的原因。
Grammarly 走的是完全不同的路線，以規則與統計為基礎，優點是低延遲與可預測，缺點是無法處理「把這段話改成給客戶看的語氣」這種開放式指令。兩者解決的不是同一個問題。
授權與維護：GPL-3.0 意味著什麼
專案採用 GPL-3.0。對個人使用者來說，這個授權幾乎不構成任何限制，你可以自由使用、研究、修改。真正的影響出現在你要把它的程式碼放進自己的產品時：GPL-3.0 具有傳染性，衍生作品通常也必須以相同授權釋出。如果你的產品需要維持專有，這是一條紅線。具體的法律後果請諮詢法務，這裡只指出授權條款的存在與大致方向。
升級成本則取決於你走哪條路徑。Windows 的可攜式版本是解壓覆蓋，設定檔與執行檔同目錄，所以升級時要留意不要把設定一起蓋掉。從發佈紀錄看，Windows 與 macOS 的版號分開演進，因此跨平台的團隊無法用單一版本號溝通，這在內部部署時會增加一點協調成本。
README 承諾這個專案會永遠保持完全免費與開源。這是一個意圖聲明，不是保證，而且專案由個人維護，未來的發展取決於維護者的時間。把它放進關鍵工作流程之前，值得先確認你能接受在某個時間點需要自己接手維護或尋找替代方案。
編輯結論
如果你要的是「在任何應用程式裡選取文字、按一下就改寫」，而且能接受把文字送到第三方 API 或自己跑本機模型，Writing Tools 是少數直接針對這個場景做的開源選項，Windows 使用者尤其適合先從 Releases 的 Writing.Tools.zip 試起。不該採用的情況同樣明確：Linux 版在 README 裡仍標示為 work-in-progress，需要穩定產出的環境不應把它當正式工具；企業若要把程式碼併入自家產品，GPL-3.0 的傳染性必須先由法務確認。採用前請先驗證三件事：你的 LLM 後端是否真的回傳可用結果、全域快捷鍵是否與現有軟體衝突、以及設定檔實際落在哪個目錄，因為可攜版的行為取決於它有沒有寫入權限。
社群筆記