Alternatives zh TW

其他選擇

English · 繁體中文

Taiga CLI 不是用機器操作 Taiga 的唯一方式，而且對某些工作它不是最好的選擇。這頁談的是哪個工具適合哪種問題， 不是誰比較好。

直接用 curl 和 jq 打 Taiga REST API

這是誠實的基準線，而且單一呼叫的情境它就是贏：不用安裝、沒有版本要追、你和請求之間沒有任何東西。

但腳本一旦要做超過一件事就不好玩了。你會開始寫、然後長期維護那些不是你工作重點的部分：

• 找出部署在子路徑下的站台其 API 位置，然後把 token 放在某個不是純文字檔的地方。
• 把名稱解析成 ID。Taiga 講的是 ID，人和 CI 設定講的是 "In progress" 和 alice。每個欄位都是一次查詢 加一次歧義判斷。
• 每次寫入前讀取目前的 version，並決定被拒絕代表什麼。
• 分辨四種失敗：被拒絕、找不到、被限流，以及連線斷了而且它可能已經生效。

Taiga CLI 就是那層黏合程式碼，外加一份契約。如果你的腳本只是 curl 加一個 jq filter，就繼續用 curl。

其他 Taiga 命令列工具

還有別的，包括 NuGet 上的 .NET taiga-cli、一個 Rust 版本，以及 npm 上的套件。它們涵蓋同樣的名詞： 專案、Epic、Story、Task、Issue。

差別在於各自最佳化的目標。多數提供方便的終端介面與乾淨的輸出，給人或語言模型閱讀。Taiga CLI 則優先把命令列 當成一個有版本的自動化 API：宣告式的 JSON contract、依失敗種類分流的 exit code、帶有 safety 與 idempotency 的 JSON Schema descriptor，以及拒絕用猜的寫入語意。代價是人不需要的囉嗦，換到的是腳本可以 依賴的行為。

請依這個軸線選擇。如果你只是想在終端機看 backlog，好幾個工具都做得不錯。

MCP server

當 agent 本來就講 MCP、你希望工具在該協定內被探索與呼叫、並由 server 集中保管多位使用者的憑證時， MCP 是更好的選擇。

CLI 的適用面不同。它不需要常駐服務，任何有 shell 的地方都能用 —— CI runner、cron job、Dockerfile、 SSH 連線 —— 而且人也一樣能用。Agent 可以透過它既有的任何 shell 工具使用它，而 taiga schema <command> --json 提供的機器可讀契約，和 MCP 的 tool definition 是同一件事。

兩者並不互斥。MCP server 完全可以呼叫 Taiga CLI，並繼承它的寫入語意。

Taiga CLI 不適合的情況

• 你要的是介面。 它沒有互動模式、沒有 TUI、不會畫看板。
• 你需要 Taiga API 沒有提供的東西。 project archive 會回報 unsupported_capability 而不是假裝做得到， REST contract 沒開放的其他功能也一樣。
• 你用的是 TaigaNext。 API 不同，沒有相容層。見 COMPATIBILITY.zh-TW.md。
• 你需要批次設定每筆不同的欄位。 Taiga 原生 bulk endpoint 只吃一串 subject，所以不同的 description 或 assignee 只能逐筆呼叫。
• 一行 curl 就夠了的時候。 為了省四行而多一個相依，是不划算的交換。