別再讓 AI 盯著螢幕點滑鼠了：CLI-Anything 替每個軟體配一條命令列

看著 AI agent 操作桌面軟體，會生出一種特別的絕望感。它先截一張圖，猜菜單在哪，點下去，點空了，再截一張。二十秒過去，它把一個滑桿挪了兩個像素，什麼都沒學到。

來自香港大學數據智能實驗室（HKUDS）的 CLI-Anything 主張：這套做法從根本就走錯了。別教 agent 看螢幕，給軟體一條命令列，讓 agent 自己敲。

它的口號只有一句：讓所有軟體都變成 agent-native。實作方式沒那麼花俏，卻更有意思——只要你手上有某個應用的原始碼，把一條命令指向它，一條七階段管線就會替它生成結構化的 CLI 封裝，測試、文件、用 pip 就能安裝的套件，一應俱全。

七個階段

整條管線跑在編碼 agent 裡，用 /cli-anything <source path or repo> 呼叫。分析：掃描原始碼，把 GUI 操作對應到 API 呼叫。設計：決定命令分組、狀態模型、輸出格式。實作：搭一個以 Click 為基礎的 CLI，附 REPL、JSON 輸出與復原/重做。規劃測試：把測試計畫寫進 TEST.md。寫測試：把測試套件實作出來。寫文件：把結果記回同一個檔案。發佈：產生 setup.py，把命令裝進你的 PATH。

另外還有一個第 6.5 階段，會產生 SKILL.md，讓產出的 CLI 能被 agent 當成一個 skill 發現，不必由人來接線。此外還有 /cli-anything:refine 命令，做落差分析，一步步把覆蓋範圍擴上去。

命名規則是刻意定死的：命令放在 cli_anything.<software> 命名空間下，套件一律叫 cli-anything-<software>。無聊的慣例才讓工具鏈能互相拼裝，而這個專案顯然已經在想像一個存在好幾百個這種封裝器的世界了。

真後端，不是玩具級重寫

真正把這東西和週末專案區分開的細節是：這些封裝器驅動的是軟體本尊。LibreOffice 產出的是真 PDF，Blender 算圖的是真 3D 場景，GIMP 對圖片做的事就是 GIMP 會做的事。另一條路——用 Python 重寫應用的一部分行為——做出來的東西看起來能用，直到你需要某個被重寫時跳過的功能。

代價是你得把這些應用裝起來。好處是產出和人類操作員做出來的東西沒有差別，因為用的是同一個引擎。

每條命令在被要求時都會吐出 JSON，這就是「agent 能解析的 CLI」和「agent 得瞇著眼看的 CLI」之間的差別。有帶狀態的 REPL 做互動式操作，也有普通子命令給腳本用，另外還有持久的專案狀態與復原/重做。

它涵蓋了什麼

範圍是刻意做寬的，讀起來像一份「大家一直想自動化、一直沒成功」的軟體清單：GIMP、Blender、Kdenlive 做創意；LibreOffice 處理辦公文件；Godot 和 s&box 做 3D 與遊戲；QGIS、FreeCAD 面向科學與工程；AI 這邊是 ComfyUI 和 Ollama；除錯則有 LLDB、RenderDoc、Nsight。

如果你做影像相關的工作，ComfyUI 這一項值得停下來多看兩眼。ComfyUI 本來就有 API，但那是圖 API——節點、連線，外加一坨 JSON blob，而它的 schema 取決於你裝了哪些自訂節點。一個暴露意圖級命令、有明確狀態模型和 JSON 輸出的 CLI 封裝，正是 agent 需要的東西：不必去反推某人的 workflow 檔，就能跑一條影像管線。

關於測試的那個說法

儲存庫報告了約 2,461 個測試：1,732 個單元測試、579 個端到端、19 個 Node.js 測試，聲稱 100% 通過。E2E 那一層跑在真實後端上，在這裡這是唯一有意義的 E2E。如果 LibreOffice 不再產出 PDF，測試就會掛掉，你會在 agent 生出四十個壞檔案之前知道。

把「100%」當成一張快照，而不是一份保證。生成出來的測試套件有個老毛病：會把生成器自己的假設一併寫進去。但那個四層結構——單元、原生 E2E、真實後端 E2E、CLI 子行程——形狀是對的。

誠實列出來的限制

README 裡列了，這是個好兆頭。

它依賴前沿模型。Claude Opus 4.6 或 Sonnet 4.6、GPT-5.4 這個等級。模型弱一點，產出的 CLI 就不完整，或者乾脆是錯的，需要大量人工修補——也就是說，這工具好不好用，綁在一份你未必有的訂閱上。

它依賴原始碼。管線分析的是原始碼；如果你手上只有編譯好的二進位檔，品質和覆蓋率會明顯下降。這就悄悄排除了大部分商業軟體，而人們真正想自動化的，大部分恰恰是這些。

一次執行很少能涵蓋全部。做好心理準備，得跑好幾遍 /refine，harness 才能到生產級。有些 CLI 要求上游應用已安裝。各平台成熟度也不一樣——Goose、OpenCode、Codex、Hermes、Reasonix 都標著實驗性，Windows 使用者還會撞上 bash 和 cygpath 的相容性問題。

沒人願意問的維護問題

生成的封裝器是一份承諾。你一旦採用 cli-anything-libreoffice，就在 agent 和應用之間加了一層，而這一層必須在 LibreOffice 改動文件模型、或者 Blender 幫某個 operator 改名之後，繼續能用。

落到實務上就是三件事。生成的 harness 要放在你自己的儲存庫裡，別依賴別人的，這樣你才能打補丁。升級底層應用時要重跑管線，並 diff 結果。還有，把 TEST.md 當成契約——測試是你能在 agent 產出四十個畸形檔案之前發現問題的唯一原因。

經濟上算得過來，因為重新生成很便宜。這才是真正的洞見：封裝器不必永遠完美，因為生成它的東西可以再生成一次。傳統 SDK 維護成本高，是因為那是人寫的。這個不是。

CLI-Hub 這一注

專案裡有個套件管理器 cli-anything-hub，用來瀏覽和安裝社群做的封裝器。這是整件事上行空間最大、風險也最明顯的一塊。一個生成式 CLI 的 hub，就是一個以你的權限執行、會碰你檔案的程式碼 hub。

它會變成有用的生態，還是變成一樁供應鏈事故，完全取決於專案是否把審查當成發佈的一部分。目前的答案是「部分如此」：測試是生成的，文件是生成的，審查則是社群愛怎麼做就怎麼做。

為什麼這件事不只關乎這個儲存庫

兩年來，computer use 一直是業界最愛的 demo、最不愛做的產品。demo 能成，是因為有人精心寫好了任務腳本。產品卡住，是因為像素級控制在骨子裡就是脆的，而這種脆弱永遠不會真正消失。

CLI-Anything 提出了另一種分工：與其讓 agent 更擅長當人，不如讓軟體更擅長當機器。每一棵有原始碼樹的應用程式都成了生成介面的候選者，而這種介面是可測試的——截圖迴圈永遠做不到這一點。

取捨是真實的。生成的 CLI 只和寫它的模型一樣好，而且上游應用一變，總得有人來管這個封裝器。但方向是對的。一個 agent 敲下 cli-anything-blender render --scene scene.blend --out frame.png 並拿到確定性輸出，做的事從根本上就比一個在視窗裡亂點、然後祈禱的 agent 有用得多。