--- schemaVersion: 1 slug: gp-137-20260329-simonwillison-vibe-coding-swiftui-swift-macos-app ticketId: GP-137 lang: zh-tw title: Vibe Coding SwiftUI：不會 Swift 也能寫出 macOS App 的快樂與代價 summary: Simon Willison 用 Claude Opus 4.6 和 GPT-5.4 vibe code 出兩個 macOS menu bar app——一個看網路流量、一個看 GPU 狀態。整個 SwiftUI app 塞在一個檔案裡，連 Xcode 都不用開。但他自己也承認：這些 app 的數字準不準，他完全不知道。 originalDate: 2026-03-27 translatedDate: 2026-03-29 source: Simon Willison's Weblog sourceUrl: https://simonwillison.net/2026/Mar/27/vibe-coding-swiftui/ author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-137-20260329-simonwillison-vibe-coding-swiftui-swift-macos-app status: published replacementTicketId: null replacementUrl: null --- # Vibe Coding SwiftUI：不會 Swift 也能寫出 macOS App 的快樂與代價 > **來源:** [Simon Willison's Weblog](https://simonwillison.net/2026/Mar/27/vibe-coding-swiftui/) 你有沒有過那種經驗：電腦跑得很慢，打開 Activity Monitor 想看到底誰在搞鬼，結果看到一堆你看不懂的 process name，然後默默關掉假裝什麼事都沒發生？ [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 也有。但他的反應不是關掉，而是：「既然你不好用，那我就自己寫一個。」 重點是——他不會 Swift。 他用的方法是現在最流行的 vibe coding：跟 AI 說你想要什麼，AI 幫你寫，你幾乎不看 code，看結果滿意就收工。這篇文章記錄了他怎麼用 Claude Opus 4.6 和 GPT-5.4，在不開 Xcode 的情況下，vibe code 出兩個實用的 macOS menu bar app。 > **Mogu 認真說：** > > 這篇有意思的地方是：作者不是在寫「我學會 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 生出來。 > **Mogu 插嘴：** > > 一個完整的 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——點一下就跳出完整的網路監控面板。 > **Mogu OS：** > > 「現在建議我們可以加什麼功能」——這招真的很聰明。一般人的思路是「我想要什麼 → 叫 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，只要指給它看一個已經做好的，它就會照著來。 > **Mogu murmur：** > > 「讓 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](https://gu-log.vercel.app/glossary#claude-code)，Claude 調整了計算方式，新的數字「看起來」對了——但 Simon 仍然表示他沒有信心這些數字是正確的。 他在兩個 GitHub repo 都加了警告，並且強調他分享這些 app 的原因**不是因為它們可靠**，而是因為它們展示了 Claude 用 SwiftUI 能做到什麼。 > **Mogu 插嘴：** > > 這段是整篇文章最重要的部分。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 是一個值得他在未來專案中認真考慮的新能力**。 > **Mogu 歪樓一下：** > > 讓我翻譯一下 Simon 真正在說的事情：以前「寫一個 macOS app」這件事，通常意味著你得先進 Xcode、先學一堆 Apple 那套；現在你可以直接在 terminal 裡跟 AI 來回對話，短時間內就做出一個像樣的 menu bar app。這個門檻下降真的很誇張 (￣▽￣)／ --- ## 結語 Simon Willison 這篇文章的重點，不是要證明這兩個 app 很可靠。相反地，他反覆提醒讀者別太相信它們。之所以把專案放上 GitHub，是因為他認為這是一個很有意思的示範：Claude 已經能把 SwiftUI app 做到什麼程度。 或者直接用 Simon 的原意來收尾就夠了：這些 app 很有趣，也很能展示 Claude 配合 SwiftUI 可以做到什麼，但你不該太相信它們顯示出來的數字。