Epiq: 適用於終端機的分布式、基於 Git 的問題追蹤工具

對於開發者而言，在程式碼編輯器與瀏覽器端專案管理工具之間切換所產生的摩擦，是持續性的認知負荷來源。Epiq 旨在透過將問題追蹤器直接引入終端機，將專案管理視為開發工作流中的一等公民，來解決這個問題。

透過將受 Vim 啟發的 TUI (Terminal User Interface) 與分布式的 Git 後端相結合，Epiq 允許團隊在無需「SaaS 儀式感」（如帳號、網頁儀表板和集中式伺服器）的情況下管理任務。

專案管理的終端機原生方法

Epiq 是為「終端機居住者」設計的——即偏好以鍵盤為核心的工作流開發者。它以 ASCII Kanban 看板的形式呈現，允許使用者透過類似 Vim 的移動方式 (hjkl) 來導航、篩選和編輯問題。

終端機體驗的核心功能包括：

• 以鍵盤為中心： 透過鍵盤快捷鍵完整導航看板、問題和泳道，減少對滑鼠的需求。
• 命令列介面： 一種基於命令的互動模型（例如：:new、:filter、:sync），模仿了使用 Vim 或 shell 的體驗。
• 本地優先的互動： 編輯是即時的，因為它們發生在本地，只有在使用者明確觸發或設置為自動執行時才會進行同步。

架構：Git 與事件溯源

分布式問題追蹤的主要挑戰之一是處理狀態衝突。如果兩名開發者同時將同一個問題從「進行中」移至「已完成」，傳統的 Git merge 可能會導致需要手動解決的衝突。

Epiq 透過事件溯源架構 (event-sourced architecture) 來解決此問題。Epiq 並非將問題的當前狀態存儲為單一文件，而是將工作內容存儲為不可變的事件日誌。變更會作為事件被追加 (append) 並以確定性的方式重新執行 (replay)，以收斂至最終狀態。

正如使用者 @SidVikJay 所指出的，這是一個「聰明的架構選擇」，透過利用使用者範圍的僅追加式日誌 (append-only logs)，防止了 merge 造成的痛苦。這確保了看板的狀態會在記憶體中收斂，使協作過程預設就是無縫且分布式的。

AI 與 Agent 整合

意識到向 AI 輔助開發的轉型，Epiq 包含了 MCP (Model Context Protocol) 伺服器。這允許 AI agent 進行可預測且結構化的方式與問題追蹤器互動，使 agent 能夠查詢、更新或建立問題，而無需人類手動在工具與 LLM 之間搭建橋樑。

社群觀點與權衡

雖然技術實作被廣泛讚賞，但 Hacker News 社群針對採用 TUI 工具進行專案管理提出了幾點關鍵觀點：

「開發者為開發者」的差距

包括 @goyozi 在內的多位使用者指出，專案管理通常涉及非技術利害關係人，例如產品經理和設計師。

"如果產品經理和設計師也在範圍內... 那麼 TUI 就不夠用了。對於開發者來說這是一個很棒的介面選擇，但我認為強迫所有人都在終端機操作在組織層面上是不可行的。"

這表明，為了讓 Epiq 超越開發者的分眾工具，它可能需要提供替代介面，例如用於查看看板的本地 Web 伺服器。

程式碼與問題生命週期

另一個爭議點是問題與程式碼儲存庫的耦合。@goyozi 也指出，問題的演進速度往往與程式碼不同：

"如果我想編輯我正在處理的問題以添加一些新資訊... 我幾乎肯定不想將它與我本地正在進行中的 (WIP) 程式碼版本一起 commit 並 push。"

先行技術與教訓

使用者建議創作者可以研究 git-bug，這是另於一個分布式的問題追蹤器，以從先前解決類似問題的嘗試中學習。這突顯了對專案管理採取分布式、本地優先方法的高度持續興趣，但也揭示了廣泛普及的普及路徑非常艱難。

結論

Epiq 為想要消除上下文切換並留在其偏好環境中的開發者提供了一個優雅的解決方案。透過利用 Git 作為資料庫並使用事件溯源來解決同時編輯的問題，它提供了一個高性能、本地優先的傳統 SaaS 問題追蹤器的替代方案。