一天 16 個版本：AI 時代的個人工具開發法
🧪 AI 工具實測一天 16 個版本：AI 時代的個人工具開發法
導讀：7 小時、16 個 Release、一個人、一台 Mac、一個 AI。這不是 hackathon，這是 2026 年個人工具開發的正常節奏。
一條纜線引發的連鎖反應
USB-C 是科技業最成功的騙局。同一個接頭，充電功率可能差 4 倍、傳輸速度差 40 倍。你手上那條「看起來一樣」的線，可能是 Thunderbolt 5 也可能是充電限定的廢物。
一位開發者受夠了，決定做一個 macOS menu bar 工具直接讀取纜線晶片資訊，用人話告訴你每條線能做什麼。他用 Claude 輔助開發，7 小時內從 v0.4.6 迭代到 v0.5.7，總共 16 個版本。
這不是失控。這是一種有意識的開發策略，而且背後有兩個值得偷的方法論。
方法一：三層解耦——寫一次，跑三種殼
這個專案最聰明的架構決策：把程式碼分成三層。
Core 層（純邏輯）：讀取纜線晶片、解析充電協議、判斷充電瓶頸。這層不知道自己會被怎麼顯示，不 import 任何 UI 框架，只處理資料。
App 層（GUI 殼）：macOS menu bar 介面，把 Core 的結果用漂亮的方式畫出來。
CLI 層（命令列殼）：whatcable --json，同一個 Core，輸出 JSON 格式。
為什麼要這樣拆？因為寫工具的人不會只用一種方式呼叫它。今天你需要 GUI 看一眼，明天你需要 cron job 自動檢測，後天你需要讓另一個 Agent 程式呼叫它。如果邏輯全寫在 GUI 裡，每多一個使用場景就要重寫一次。
判斷標準很簡單：如果你的工具有可能被腳本呼叫，第一天就拆。 事後重構的成本永遠比一開始就分層高十倍。
實作規則只有一條：Core 層禁止 import 任何框架。它只接收純資料、只回傳純資料。UI 的事，用 extension 或 adapter 另外處理。這樣 Core 可以被任何殼 import，測試也簡單到不需要 mock 半個世界。
方法二：AI 高速迭代——探索期的正確用法
16 個版本聽起來瘋狂，但拆開看每個版本只做一件事：修 port 對應邏輯、加充電瓶頸診斷、補 CLI JSON 輸出、擴充廠商資料庫、加通知功能。每個 cycle 大約 30 分鐘。
AI 在這裡的最大價值不是「幫你寫 code」，而是壓縮調研時間。這個專案需要存取 macOS 的 IOKit——Apple 半文件化的底層系統介面，文件散落各處，範例稀少。傳統做法是花三天翻官方原始碼。用 AI 的做法是直接問「這個節點的 ancestor tree 代表什麼？」拿到可執行的 code snippet 後在實機驗證。
三天調研 + 兩天編碼，壓縮成兩小時對話 + 一小時驗證。
但代價也很真實：v0.5.0 發布後 App 直接打不開，30 分鐘內緊急出了 v0.5.1 修復。快速迭代壓縮了寫測試的時間，品質斷層就會出現。
什麼時候該快，什麼時候該慢
這個方法論有嚴格的適用邊界：
適合快的場景：個人工具、內部工具、探索未知 API、scope 明確且功能收斂、使用者容忍度高。
不適合快的場景：面向客戶的產品、涉及金流或安全的系統、多人協作、需要向後相容的 API。
最有效的用法是把快和慢分開：探索期用 AI 高速迭代驗證概念，確認可行後切換到正式節奏——PR review、測試、changelog，一步不省。
重複是升級訊號。16 個版本不是終點，是在找到「對的版本」之後停下來、補齊品質基礎設施的起點。
💬 互動埋點: 你現在手上有沒有一個「應該拆成 Core + 殼」但一直拖著沒做的工具？
常見問題
Q：AI 輔助開發真的能一天發 16 個版本嗎？ A：可以，但有嚴格前提：個人工具、scope 極小、使用者即開發者、無需 PR review。商業產品不適用這個節奏。
Q：三層解耦是不是過度設計？ A：不是。只要你的工具未來有可能被腳本呼叫、被 Agent 整合、或需要無 GUI 模式，從第一天就拆開 Core 層的成本遠低於事後重構。
References
- darrylmorley/whatcable — macOS USB-C cable diagnostics tool (GitHub, MIT License)
- Show HN: WhatCable — Hacker News discussion (2026-05-01), documenting 16 releases in 7 hours
- WhatCable Release History — v0.4.6 to v0.5.7 iteration timeline
建立者：TheVoidWeaver | 更新：2026-05-03