為何我們選擇 Pi，而非 OpenCode、Goose 與第一方工具

我們是一間精簡、由資深開發人員主導的產品工作室。AI 不是團隊本身，而是加速器。在選擇日常使用的編碼工具時，我們認真評估了五個選項：OpenCode、Oh-My-Pi（Pi/OMP）、Codename Goose、OpenAI Codex CLI 與 Claude Code。最終的選擇必須滿足三個非妥協條件：人類對架構的掌控、日常工作的低阻力，以及隨規模增長仍可預測的成本。

以下是我們的比較過程，以及最終選擇 Pi 的原因。

決策標準

我們不是在找一個「配合既有習慣」的工具，而是在找一個「符合我們刻意選擇的工作方式」的工具：

我們要快速的終端原生回饋迴路。 我們堅持在 Neovim、Herdr 與 git 旁邊工作，因為輕量 TUI 能讓人類保持在決策圈內，也省去桌面 GUI 的摩擦。
我們堅持明確的規劃關卡。 任何代理在沒有和我們達成藍圖共識前，都不能修改客戶代碼庫。資深審查先於執行，而不是等出錯後才補救。
我們要求模型彈性。 深度推理用一個模型，快速編輯用另一個；我們拒絕被單一供應商鎖定，尤其是在 Kimi 3 等開放模型已具競爭力的情況下。
我們設計 skill 按需載入。 可重複使用的規則與慣例只應在相關時才進入上下文，而不是塞進每個提示。
我們讓 spec-driven 流程保持原生。 OpenSpec 透過標準指令運作；我們不會為了新工具而用膠帶拼裝現有流程。
我們拒絕強制專案骨架。 我們穿梭於數十個代碼庫之間，因此選擇一個無需 `/init` 即可在任何目錄運作的工具。

競品比較

OpenCode：結構化、宣告式、有主見

OpenCode 受歡迎是有道理的。它內建角色型 sub-agent、`.opencode/skills/` 與 `.opencode/commands/` 檔案、專屬規劃代理，以及快速的終端 UI。憑藉超過 160k GitHub stars，它是一套成熟且支援完善的工具。

對於想要現成護欄的團隊來說，它很棒。對我們而言，同樣的特色卻成了阻力。skill 檔案會膨脹上下文；sub-agent 的角色扮演設定在 2026 年已大致過時；而 `.opencode/` 專案骨架假設了一種我們不一定會遵循的工作流程。我們想要的是一個可以擴展的核心，而不是一個必須遷就的框架。

Goose：自主性優先、MCP 優先、系統級

Codename Goose（由 Block 開發，現歸 Linux Foundation 管理）是另一種類型的工具。它把你的電腦當作作業系統：70 多個 MCP 伺服器、桌面 GUI 加上 CLI，能在單一自主循環中跨程式碼、資料庫、issue tracker 與雲端 API 運作。它還支援 ACP，可把現有消費者訂閱直接當作模型後端。

這種能力伴隨代價。自主循環會快速燒掉 token；「食譜」式的規劃優先流程，在只需要一次小型、有範圍的編輯時反而顯得累贅。若沒有嚴格的範圍邊界，它可能會動到你沒要求的檔案。對於按成果計費而非按小時計費的工作室，不可預測的 API 支出是實質風險。

Pi / Oh-My-Pi：輕量、可擴展的核心

我們選擇 Pi，不是因為它功能最多，而是因為它最不礙事。

Base Pi 的 TUI 只有不到 600 行。系統提示小、渲染快、消耗的上下文 token 與系統資源極少。這種極簡核心是有意為之：與其內建厚重流程，Pi 提供 TypeScript 擴充 API，讓我們按自己的流程塑形。

為何它適合我們：

類 Neovim 的極簡主義。 快速的終端原生工具，貼近鍵盤，不會搶佔畫面或注意力。
擴充驅動的工作流程。 我們不依賴內建規劃模式或角色預設，而是按需加入護欄——例如腦力激盪鎖、模型路由、規劃審批門檻——全都以小型 TypeScript 擴充實現。
低 token 與資源開銷。 系統提示小、skill 按需載入，讓 API 成本可預測，TUI 即使長時間運作也保持流暢。
不臃腫的並行處理。 擴充系統讓我們把獨立工作分發給 sub-agent，而無需厚重的協調框架。
billion-context-pi 擴充功能。 這是關鍵因素。它提供我們所需的長上下文處理能力，卻沒有圍繞單一模型打造的第一方工具那樣的成本與複雜度。
無綁定、無強制設定。 若客戶帶來 OpenCode skill 或 MCP 設定，OMP 也能讀取；而且沒有 `/init` 步驟。我們保持工具中立與代碼庫中立。

為何排除第一方工具

OpenAI Codex CLI 與 Claude Code 精緻、快速，並與自家模型深度整合。它們是顯而易見的商業替代方案。三個顧慮讓它們沒進入我們的工具鏈。

1. 模型綁定。 Codex 圍繞 OpenAI 模型打造；Claude Code 圍繞 Anthropic 模型打造。若你確定只使用單一供應商，這沒問題；但模型能力每季都在變。我們希望把正確任務路由到正確模型——今天可能是 Claude 3.7 Sonnet 做深度推理，明天可能是 Kimi 3 或 DeepSeek V4 做快速編輯。第一方工具讓這種路由更困難，且通常更昂貴。

2. 一次性執行對品牌導向的專案有風險。 這些工具被設計成接收提示後全自動運作：規劃、開發、測試、迭代，一氣呵成。對於全新實驗這很驚人；但對於字體、動畫時間、語調、轉換流程都必須符合品牌的客戶專案，「先求快、後修補」的成本反而更高。我們花了太多時間撤銷那些偏離品牌的過度熱心切換。

3. 開放模型已縮小品質差距。 開放取用模型如 Kimi 2.7 與 Kimi 3，在我們關心的編碼任務上已能媲美頂尖閉源模型。當模型層商品化，工具層就成為差異化關鍵。我們寧可押注在開放、可擴展的工具上，而非單一廠商的包裝器。

我們需要的是一個輕量、開放的工具，能讓我們把功能切成小而可審查的區塊、在人類監督下並行運作多個區塊，並讓每個決定都與品牌一致。Pi 與 OpenCode 都符合這個理念；Pi 在速度與 token 開銷上勝出。

為何 Pi 勝出

這個決定直接對應客戶選擇我們的五個原因：

資深執行力。 12 年以上的實戰交付經驗告訴我們，AI 在哪裡有幫助、在哪裡會礙事。Pi 讓資深開發人員掌控全局，把 AI 用在樣板代碼，而非架構。
AI 是加速器，不是替代品。 Pi 的極簡核心與擴充 API 放大判斷力，而不是將其自動化。我們只加入需要的護欄、保持低 token 成本，並在人類監督下並行推進。
工具中立，沒有先決條件。 Pi 能讀取 OpenCode skill、OpenCode MCP 設定與標準 agent skill 佈局。正確的工具就是能服務專案的那個。
策略且務實。 我們把工作切成可審查的區塊、透過小型擴充按專案自訂工具，且絕不讓工作流程凌駕交付。
全面且端到端負責。 單一連續的 session tree 承載從探索到實作的上下文。沒有遺失狀態，沒有交接斷層。

對您項目的實際影響

實務上這代表：

每週 demo build 保持完整，因為程式碼被碰觸前藍圖已達成共識。
API 成本可預測，因為輕量工具保持上下文緊湊，並由擴充功能把任務導向最便宜的合適模型。
功能以細分區塊交付。 我們把工作切成可審查的小塊，而非要求代理一次規劃並開發完整功能。這避免了品牌導向專案中來回修正所消耗的預算。
並行軌道仍有人類監督。 輕量開源工具讓我們同時推進多個功能分支，而不失去監督。資深開發人員會在每個區塊落地前審查。
架構決定仍由人類掌握，因為 Pi 的預設模式是對話與同意，而非自主循環執行。
既有代碼庫更安全，因為 skill 與提示承載專案特定規則，而無需重寫代碼庫。

準備實現您的願景？

AI 應該加速執行，而非取代背後的判斷。如果您想要一個在嚴格人類控制下使用正確工具的資深主導團隊，歡迎與我們聊聊。

與我們討論您的項目