aide：量測 AI 編程工作階段

METR 研究發現開發者認為 AI 讓自己快了 20%。實際量測：慢了 19%。我想要自己使用情況的資料，於是做了一個在本機執行的效能工具。

這是什麼

aide 會把 Claude Code 與 Codex 的工作階段日誌（JSONL）匯入 SQLite，呈現各專案的狀況：成本、token 使用量、工作階段模式、效能趨勢、審查佇列，以及重複出現的工作流程摩擦。

它也會把重複出現的發現轉成建議的專案知識。你要先審查並接受這些產出，它們才會成為未來人類或代理人工作的操作手冊或開場簡報。

零 LLM 呼叫。執行成本為零。所有資料都留在本機。

~/.claude/projects/**/*.jsonl → Claude parser → SQLite → aide
~/.codex/sessions/**/*.jsonl  → Codex parser  → SQLite → aide

Claude Code 與 Codex 會產生詳盡的本機日誌：訊息、工具呼叫、token 計數、時間戳記、指令與中繼資料。檔案就放在 ~/.claude/projects/ 與 ~/.codex/sessions/，卻沒人去看。

每個人對 AI 編程工具值不值得都有意見，卻沒人有資料。我隨著時間有變得更有效率嗎？哪些專案吃掉最多 token？工作階段反覆在哪裡出錯？更好的指示或操作手冊真的減少了摩擦嗎？

真正有用的視角是你所有工作階段的個人趨勢，再加上一個把重複錯誤轉成更好未來脈絡的回饋迴圈。單一份工作階段逐字記錄兩者都看不出來。

所有成本都以目前的 API 費率估算。訂閱制使用者（Pro/Max）可以切換開關，改看以 token 為基礎的指標而非金額。

摘要卡片、效能指標（快取命中率、編輯比例、壓縮率、錯誤率）、趨勢圖表、每週工作區塊數。

含效能指標與趨勢圖表的總覽頁

專案與供應商彙總會把最近 30 天與前一個 30 天相比：每個工作階段的平均成本、活躍時間、審查佇列比率、編輯歸屬，以及工具錯誤率。

行動摘要會把重複出現的調查訊號歸類，例如沒有編輯的工作、專案歸屬薄弱、缺少前綴規則，以及編輯歸屬缺口。每項行動都可以連回造成它的那些工作階段。

深入任一工作階段：token 拆解、工具使用、經手檔案及其讀取／編輯／寫入次數、工作區塊時間軸、錯誤分類。

顯示 token、工具與檔案的工作階段細節

首次提示的成效、成本集中度、時間模式、模型使用、工具序列、思考區塊分析、權限摩擦，以及調查行動。

含首次提示分析與時間模式的洞察頁

工作階段驗屍 - aide autopsy <session-id> 會產生單一工作階段的診斷報告：成本拆解、脈絡視窗分析、壓縮偵測，以及專案指示的改進建議。
產出審查 - 重複出現的發現會變成建議的語意產出。被接受的產出會餵進操作手冊與任務簡報。
訂閱模式 - 讓 Pro/Max 訂閱者在 API 成本檢視與以 token 為基礎的指標之間切換。
CLI 統計 - aide stats 會直接在終端機印出快速摘要，不必打開網頁瀏覽器。

JSONL 裡的一個「工作階段」不過是一個終端機視窗一直開著。從週一橫跨到週三、中間還睡了覺的工作階段會被讀成 48 小時，讓「時長」完全沒有意義。

訊息之間的間隔分布是雙峰的：大多數間隔在 5 分鐘以內（正在工作），另有一小群超過 30 分鐘（人不在）。以 30 分鐘為門檻可以乾淨地分開這兩個模式。

每個工作階段都會切成工作區塊，也就是連續的編程時段。「35 個工作階段共 119 個工作區塊」比「35 個工作階段」告訴你更多。

工具錯誤會自動分類：測試（pytest、jest）、Lint（ruff、eslint）、建置（pip、npm）、Git、編輯不符、檔案存取。大部分「錯誤」其實是正常的迭代（編輯－測試－修正循環中的測試失敗）。儀表板會把迭代與真正的錯誤分開。

AI 編程日誌是一座金礦。 每一次工具呼叫、token 計數、時間戳記與指令形態都在裡面。難的是決定哪些指標真的重要。

工作區塊改變了一切。 原始的工作階段時長讓每張圖表都失真。以閒置間隔切分後，資料才誠實。資料清理比花俏的視覺化更重要。

零 LLM 呼叫是正確的限制。 每個指標都是啟發式的。沒有 API 呼叫，沒有邊際成本。想重新匯入與重建幾次都可以。