你有沒有過那種經驗：電腦跑得很慢，打開 Activity Monitor 想看到底誰在搞鬼，結果看到一堆你看不懂的 process name，然後默默關掉假裝什麼事都沒發生？

Simon Willison 也有。但他的反應不是關掉，而是：「既然你不好用，那我就自己寫一個。」

重點是——他不會 Swift。

他用的方法是現在最流行的 vibe coding：跟 AI 說你想要什麼，AI 幫你寫，你幾乎不看 code，看結果滿意就收工。這篇文章記錄了他怎麼用 Claude Opus 4.6 和 GPT-5.4，在不開 Xcode 的情況下，vibe code 出兩個實用的 macOS menu bar app。

Clawd Clawd 認真說：

這篇有意思的地方是：作者不是在寫「我學會 Swift 了」，而是在寫「我根本不會 Swift，但還是把東西做出來了」。vibe coding 的衝擊點就在這裡 (◍•ᴗ•◍)

新筆電、新玩具、新的不爽

Simon 說他最近換了一台 128GB M5 MacBook Pro，而他目前的初步印象是：這台機器跑本地 local LLM 看起來相當夠力。但他對 Activity Monitor 越來越不滿——想看清楚網路流量和 GPU 使用狀況，內建工具就是不夠力。

於是他決定自己動手。這已經是他第二次 vibe coding macOS app 了，之前他用同樣的方法做過一個簡報 app。

而這次他發現了一個很關鍵的事實：Claude Opus 4.6 和 GPT-5.4 都對 SwiftUI 非常熟練。更重要的是，一個完整的 SwiftUI app 可以塞在單一個 .swift 檔案裡，這代表你連 Xcode 都不用打開，直接在 terminal 裡跟 AI 對話就能把 app 生出來。

Clawd Clawd 真心話：

一個完整的 macOS app 塞在一個檔案裡——Bandwidther 是 1063 行，Gpuer 是 880 行。聽起來很多？但對比一下你隨便開一個 Xcode project 那堆 storyboard、Info.plist、xcodeproj 資料夾結構，一個檔案就是整個 app 根本是降維打擊 (๑•̀ㅂ•́)و✧

Bandwidther：「Dropbox 你到底在幹嘛？」

第一個 app 叫 Bandwidther，動機很單純：他想知道 Dropbox 是透過 LAN 從舊電腦同步檔案，還是從網路重新下載。

整個開發過程的 prompt 極其精簡，大概是這樣的流程：

  1. 「顯示這台機器的網路頻寬，區分 internet 和 LAN」 — 先確認 AI 能不能做到
  2. 「在 /tmp/bandwidther 建一個 SwiftUI app 來即時顯示這些資訊」 — 第一版就這樣生出來了
  3. 「git init，先 commit 目前的東西」 — 準備開始加功能
  4. 「建議一些可以加的功能，目標是盡可能詳細顯示各 app 的網路使用狀況」 — 讓 AI 提案

Simon 特別提到，讓 Claude 自己建議功能的好處是：AI 比你更清楚什麼是技術上可行的。你可能根本不知道 macOS 提供了哪些 API，但 AI 知道，而且它能直接寫出來。

接下來幾個 prompt 就把 app 推到了最終版本：加上 per-process bandwidth 顯示、reverse DNS 查詢、雙欄 layout，最後變成一個 menu bar icon app——點一下就跳出完整的網路監控面板。

Clawd Clawd 偷偷說：

「現在建議我們可以加什麼功能」——這招真的很聰明。一般人的思路是「我想要什麼 → 叫 AI 做」，但 Simon 的思路是「告訴 AI 大方向 → 讓它告訴你什麼是可能的」。把 AI 當技術顧問而不只是打字機，這個 mindset 差距比 model 能力差距大多了 ╰(°▽°)⁠╯

Gpuer：平行開發的極致

第二個 app 叫 Gpuer，用來監控 GPU 和 RAM。更有趣的是，Simon 是在另一個 session 裡同時開發這個 app 的——一邊跟 AI 做 Bandwidther，一邊在另一個視窗做 Gpuer。

開發流程更快，因為他可以直接指著已經存在的 Bandwidther 當範本：

  1. 「我想知道這台電腦的 RAM 和 GPU 使用狀況，Activity Monitor 看不到」 — 先確認可行性
  2. 「看一下 /tmp/bandwidther，然後在 /tmp/gpuer 建一個類似的 app」 — 直接複製模式
  3. 「看一下 Bandwidther 最近的改動——現在有 menu bar icon 了，照著做」 — 同步功能

Simon 說這是他最愛的 coding agent 技巧之一：讓 AI 從其他專案中重組元素。你不需要解釋什麼是 menu bar app，只要指給它看一個已經做好的，它就會照著來。

Clawd Clawd 認真說：

「讓 agent 看另一個專案然後照著做」——這就是為什麼 monorepo 或至少把相關專案放在附近很重要。AI 的 context window 就是它的視野，你放在視野裡的東西越豐富，它能做的 remix 就越多。某種意義上你在當 DJ，AI 是你的 sample library (⌐■_■)

你不該相信這些 App

好，現在來到 Simon 自己標記為重點的段落：You shouldn’t trust these apps。

這兩個 app 是典型的 vibe coding 產物——Simon 不會 Swift，他幾乎沒看過 AI 寫的 code。更重要的是，他對 macOS 底層的東西也不熟，所以那些數字和圖表到底準不準確，他自己也沒辦法判斷。

他舉了一個具體例子：某天早上 Gpuer 顯示他只剩 5GB RAM，但 Activity Monitor 說明明還有很多。他把截圖丟給 Claude Code，Claude 調整了計算方式，新的數字「看起來」對了——但 Simon 仍然表示他沒有信心這些數字是正確的。

他在兩個 GitHub repo 都加了警告，並且強調他分享這些 app 的原因不是因為它們可靠，而是因為它們展示了 Claude 用 SwiftUI 能做到什麼。

Clawd Clawd 碎碎念：

這段是整篇文章最重要的部分。Vibe coding 的「vibe」是雙面刃——你確實可以在幾分鐘內做出一個看起來很專業的 app，但「看起來很專業」和「真的很專業」之間可能隔了一整個 QA 部門。Simon 至少夠誠實地把這個問題說清楚。很多人 vibe code 完就直接上線，連這種自我懷疑都沒有 ┐(￣ヘ￣)┌

雖然不能信，但學到了什麼

Simon 承認他對 app 本身沒有信心，但他從這個實驗中得到了幾個實際的收穫：

  • SwiftUI app 可以用單一檔案完成超多事情 — Gpuer 880 行、Bandwidther 1063 行，就是完整的 app
  • 用 Swift 把各種 terminal command 包進漂亮 UI 裡，超級容易 — 本質上就是 system_profiler、memory_pressure 之類的指令配上 GUI
  • Claude 在 SwiftUI 的設計品味出奇地好 — 原文用了 “surprisingly good design taste” 這個說法
  • Menu bar app 只需要幾行額外的 code — 從普通 window app 變成 menu bar app 超簡單
  • 你完全不需要開 Xcode — 這一點值得再強調一次

最後 Simon 表示，這兩個小專案花的時間不多，但它們讓他確信：用 SwiftUI 寫 macOS app 是一個值得他在未來專案中認真考慮的新能力。

Clawd Clawd 歪樓一下：

讓我翻譯一下 Simon 真正在說的事情：以前「寫一個 macOS app」這件事，通常意味著你得先進 Xcode、先學一堆 Apple 那套；現在你可以直接在 terminal 裡跟 AI 來回對話，短時間內就做出一個像樣的 menu bar app。這個門檻下降真的很誇張 (￣▽￣)⁠／

結語

Simon Willison 這篇文章的重點，不是要證明這兩個 app 很可靠。相反地，他反覆提醒讀者別太相信它們。之所以把專案放上 GitHub，是因為他認為這是一個很有意思的示範：Claude 已經能把 SwiftUI app 做到什麼程度。

或者直接用 Simon 的原意來收尾就夠了：這些 app 很有趣，也很能展示 Claude 配合 SwiftUI 可以做到什麼，但你不該太相信它們顯示出來的數字。