Claude Code 的 /buddy 被官方刪掉那一週，GitHub 上有一則 issue 滾到 #45596——社群請願把寵物帶回來。三天後 talkvalue 這個人丟出 Swift 寫的 Buddi，比官方版還多了權限审批、session 監控、API 配額追蹤，順便把它塞進 MacBook 瀏海那塊一般人覺得「設計缺陷」的黑色區域。

反直覺的地方不是寵物被救回來，是瀏海原來可以當控制台。

那塊 130 像素高、橫過螢幕正中央的黑色區域，自從 2021 年 iPhone 把瀏海搬到 Mac 之後，就是工業設計上的爭論焦點。大部分 app 把它當成要躲開的障礙物——選單列往兩邊擠、全螢幕時硬切掉那段。Buddi 走相反方向：既然這塊黑色永遠都在，乾脆拿它做 Claude Code 的儀表板。ASCII 寵物在裡面走來走去，狀態切換就切換動畫，Claude 要權限就從瀏海裡展開 Allow/Deny 按鈕。

先把角色定位講清楚：它不是 Anthropic 出的官方工具。Anthropic 把 /buddy 當成愚人節彩蛋做了一版，社群上頭之後被砍掉，然後就有人自己用 Swift 把它放大重寫。Buddi 目前還在 v0.1.0，macOS 15+ 專屬，GPLv3 授權。

它到底在做什麼

ASCII 寵物看起來像玩具，但資料流其實很嚴肅。Claude Code 的 hooks 系統每觸發一個事件——UserPromptSubmit、PreToolUse、PostToolUse、PermissionRequest、SessionStart 這些——都會執行一個 Python hook 腳本，把事件資料透過 Unix Socket（/tmp/buddi.sock）傳給 Buddi app，Buddi 再用 SwiftUI 更新 UI。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Claude Code
    │  Hook Events (UserPromptSubmit / PreToolUse / ...)
    ▼
buddi-hook.py     ← Python 腳本
    │  JSON payload
    ▼
Unix Socket       ← /tmp/buddi.sock，permission 0600
    │
    ▼
HookSocketServer  ← Swift actor，常駐 app 內
    │
    ▼
SessionStore      ← 中央狀態機（Swift Actor，thread-safe）
    │
    ▼
SwiftUI Notch UI  ← 你看到的 ASCII 寵物與按鈕

比較聰明的設計在權限审批這段。一般 hook 跑完就結束，但 Buddi 的權限 hook 會把 socket 連線保持住，等使用者在 UI 上點 Allow 或 Deny，結果回傳給 hook，hook 再 stdout 給 Claude Code——整段流程你沒離開 IDE 也沒切到 terminal。

類比一下：這很像電話總機。Claude Code 是打電話進來的客戶，hook 是總機小姐，Buddi 是董事長。總機不會直接掛客戶電話，而是 hold 住線路等董事長決定，董事長回答後總機再轉回去。Unix Socket 就是那條不會掉的電話線。

安裝走一次

Homebrew 最快：

1
brew install --cask talkvalue/buddi/buddi

不用 Homebrew 就去 Releases 下載 DMG。

首次啟動會跑一段 onboarding，授權輔助使用（偵測視窗焦點）和通知（session 狀態提醒），選一個音樂控制器（Apple Music / Spotify / YouTube Music），完成後瀏海就會長出一隻 ASCII 生物。

這段過程它會自動幫你安裝 Claude Code 的 hooks。驗證兩條指令：

1
2
ls -la ~/.claude/hooks/buddi-hook.py
grep -c "buddi-hook" ~/.claude/settings.json

兩個都有輸出就搞定了。如果你已經有其他 hooks，Buddi 是 append 不是 overwrite——不會覆蓋你的設定，但會在既有 hooks 後面追加。這個行為值得注意，因為如果你手動維護過 settings.json，要去看一下它加了什麼進去。

瀏海能幹嘛

用起來最有感的是權限审批不用離開 IDE。以前 Claude Code 要跑 bash 指令，你得切到 terminal 按 y；現在瀏海直接展開 Allow / Deny，點一下就好。工作流沒中斷是關鍵——每多一次 context switch，你腦袋的 L1 cache 就被 evict 一輪。

寫 code 時瞄一眼瀏海看 Claude 狀態是第二個實用點。Buddy 有六個狀態動畫：

狀態 情境 動畫效果
idle 閒置 偶爾眨眼
working Claude 處理中 游標閃爍 `
reading 讀取檔案 眼睛左右移動
waiting 等待权限审批 漸進圓點 ...
compacting Context 壓縮中 波浪 ~ ~~
sleeping 睡眠狀態 zzz 閉眼

這個設計有點像老式機械停車場的標示燈。你不用知道停車場裡發生什麼事，看燈號就知道「有位」「沒位」「快滿」。同樣的，你不用切到 terminal 看日誌，看瀏海的動畫就知道 Claude 現在在幹嘛。

同時跑多個 Claude Code session 的人會喜歡 ClaudeSessionMonitor。它從 ~/.claude/projects/*/conversations/*.jsonl 解析每個 session 的完整聊天歷史、工具呼叫狀態、當前階段，然後在同一個面板裡排序——processing 和 approval 排最上面，idle 排最下面。需要你注意的永遠浮到頂端。

物種系統其實藏著確定性雜湊

跟原版 /buddy 一樣，Buddi 讀 ~/.claude.json 裡的 userId，用 Wyhash + Mulberry32 PRNG roll 出你的 buddy——同一個帳號永遠得到同一隻。18 種物種、5 個稀有度，機率是這樣：

稀有度 機率權重 屬性下限
Common ★ 60 5
Uncommon ★★ 25 15
Rare ★★★ 10 25
Epic ★★★★ 4 35
Legendary ★★★★★ 1 50

原版 /buddy 想刷 Legendary 要繞開 accountUuid 優先權、改環境變數、重設 userId，社群甚至寫了暴力搜尋 salt 的工具。Buddi 把這套全部省掉——直接在 Settings 裡手動覆寫 species、eye、hat、rarity 就好，不動 userId，不破壞原始 roll 結果。

這個設計細節很 Paul Graham 風格：原版把 userId 當成 roll 的隨機源是為了「每個人有自己獨一無二的寵物」，聽起來很浪漫。但實際結果是人人都想要 Legendary Shiny，所以寫了一堆繞圈子的工具。Buddi 的解法是承認需求本身——你就是想要自己挑——然後提供一個不破壞系統的出口。

API 用量追蹤這塊有個條件

UsageService 用 Anthropic OAuth API 輪詢配額，顯示 5 小時和 7 天的使用率，輪詢間隔 5 分鐘，遇到 rate limit 指數退避到 30 分鐘。本地快取在 ~/Library/Application Support/Buddi/usage-cache.json，token 從 macOS Keychain 讀。

但這個功能需要 OAuth 登入。如果你用 API key 而不是 OAuth 登入 Claude Code，這段直接不會生效——因為 https://api.anthropic.com/api/oauth/usage 這個 endpoint 只吃 OAuth token。這是個容易踩的坑：你看不到配額數字的時候，先檢查自己是哪種登入方式，不是 Buddi 壞了。

背後的設計選擇

Buddi 不是從零開始寫的。它組合了兩個開源專案：

  • boring.notch 提供 notch UI 框架（音樂控制、行事曆、電池、音量 HUD、檔案暫存架）
  • Claude Island 提供 Claude Code session 監控和 buddy 角色系統

這個組合方式有意思。如果你看過 SICP，會覺得這很像 Scheme 的 composition——兩個獨立的抽象用簡單的介面接起來，變出一個新東西。boring.notch 負責「怎麼把東西顯示在瀏海上」，Claude Island 負責「Claude Code 在幹嘛」，Buddi 把前者當畫布、後者當顏料，不自己重造輪子。

程式碼核心是 4 個 Singleton：

  • BuddyManager.shared — buddy 身份與動畫
  • HookSocketServer.shared — Unix Socket 伺服器
  • SessionStore.shared — 狀態中心，用 Swift Actor 保證 thread-safe
  • UsageService.shared — 用量追蹤

Swift Actor 是這段程式碼的點睛之筆。多個 hook event 可能同時進來，多個 SwiftUI view 可能同時讀狀態，用 Actor 包起來就不用手寫 lock。寫 Objective-C 的人看到這個會嫉妒。

幾個要留意的限制

專案才 2026 年 4 月 8 日建立，目前只有 v0.1.0 一個 release。穩定性還沒有大樣本驗證，功能完整但不要在關鍵開發日程裡才第一次裝它。

macOS 15 Sequoia 以上才能用。Windows 和 Linux 使用者暫時沒戲——畢竟 Windows 筆電沒瀏海這個概念。

Socket 路徑硬編碼在 /tmp/buddi.sock，權限 0600，跟其他類似工具不會衝突但也沒辦法改。這個設計在單人 Mac 沒問題，多使用者系統（理論上 macOS 也支援）要小心同名衝突。

cmux 使用者要在 cmux 設定中打開 “Automation mode”，不然 Tmux/cmux 按鍵模擬的權限审批會失效。這個設定跟 Buddi 沒關係，是 cmux 自己的 autopilot 開關。

GPLv3 授權。你可以 fork 改 code，但改完分發出去必須以相同授權公開原始碼。商用團隊要注意這條。

這個專案真正有趣的地方

回到開頭那個反直覺——瀏海可以當控制台。

Buddi 背後的命題其實不是「給 Claude Code 加個寵物」，是「工具應該塞進使用者本來就盯著的地方，而不是讓使用者切換到工具的地方」。寫 code 的時候你本來就盯著 IDE 和螢幕正中央，瀏海就在你的視野正中心偏上，不用轉頭不用開新視窗。這比把功能塞進 menu bar icon、dock badge、或彈出式通知都更符合你的實際視線。

這件事真正的問題其實不是瀏海該不該用，是你願意讓多少「環境細節」被你的 AI 工具用來溝通。過去十年的開發工具一直在把訊號往外推——桌面通知、Dock 跳動、menu bar 閃爍、聲音提示——但都是「中斷你」的模式。Buddi 試的是另一條路：把資訊融進你本來就不會看的地方，有狀態變化時才抓你眼角餘光。

背後就兩條線——工具該在你視線裡當背景常駐，還是在你注意力外當通知彈出？選前者，你就會開始研究瀏海能做什麼、menu bar 能做什麼、狀態列能做什麼。選後者，你會繼續被 desktop notification 轟炸。Buddi 選了前者，而且做得不只是裝飾。

如果你用 Claude Code 又剛好有一台 MacBook，花 5 分鐘裝它跑一下。你會發現瀏海不是設計缺陷，是一塊沒人認真用的螢幕不動產。

相關連結