我從去年底到今年初的幾個月之間,狂熱沉迷於 vibe coding,當時陸續做了三個 MacOS 的程式,分別叫做 Histo, Promptny, 還有 Purri。
後來從 3 月開始,因為工作上也開始建構 agent system,加上大概意識到自己業餘開發的程度在哪,就緩了下來,沒再繼續迭代這幾個工具。
這篇想簡單紀錄與回顧一下,當時為何想做這三個工具、做了以後有什麼收穫、後來他們怎麼了?
第一個做的工具叫做 Promptny,當時還在 Claude Code 剛火熱起來的 2025 年 12 月,那時我還沒有什麼開發經驗,但很想要「做點什麼」,於是想到手上一個簡單的需求:用 AI 幫我強化我的 prompt。
當時我在幾次測試後意識到,在跟 AI 互動時,好的、完整的 prompt 還是可以提高回覆的品質。但要把 prompt 寫的完整、甚至超出自己想像的程度,也不是件很輕鬆的事。於是我想到的解決方案是,做一個 MacOS 桌面版的小工具,在任何一個視窗中,只要框選一段字,然後按下快捷鍵,就會呼叫我設定好的另一個改 prompt 腳本,幫我強化我選的這段 prompt,然後再貼到原本的地方給我。
我最喜歡這個設計的地方是,他可以在幾乎任何 Mac 的視窗中運作。無論是網頁、terminal、Discord、Slack、編輯器、Heptabase 裡面都可以。
我一開始推出時,有要求有興趣的人填 email,收到後,我會把它們加到 Supabase 的某個表單內,這時他們只要透過 Google 登入,email 認證通過,就可以有 50 次免費強化 prompt 的機會。
不過上線幾天後,我發現大家用量也沒有很多(從 Supabase 那邊看個別帳號的剩餘次數),大部分的人只嘗試個兩三次就不再用了。
我也很快地發現,連我自己也沒有很常用這個功能。一方面的原因是,AI 改出來的 prompt 是有額外的資訊與規則,但那些額外有時不一定會生出好的東西,反而會製造雜訊。另一方面是,我的使用情境裡面,真的會需要一次透過強力 prompt 去引導生成的機會也不多。所以後來覺得這條路大概是行不通了,就沒有積極去迭代或者推廣。
不過,我很快地發現,比起強化 prompt,我更常做的事情是「把英文段落翻譯為中文」以及「把中文晶晶體翻譯為英文」兩個需求。
我先前在 Heptabase 日常工作時蠻常需要閱讀英文的內容,包含網路文章、產品的介紹與規格、還有用戶們傳給我們的訊息。
另外,我在客服時也常常需要以英文回覆用戶。
在過去,我用過不少軟體,例如 Bob 這個翻譯軟體,或者是用 Keyboard Maestro 搭配自己做的腳本去翻譯,但有了 Promptny 後,我就想到,這些操作同樣都是「框選一段文字,然後請 AI 生成我想要的結果」。
於是我就在 Promptny 裡面支援這兩個功能。結果我幾乎每天都在用他們。(可以參考這則 Thread 的範例)
由於我一直都沒有正式上線,所以相關的訂閱機制都還沒跑通,試用的 50 次不夠了就要手動去 Supabase 改數字。我有幫幾個試用用戶加過次數,但後來發現用最兇的是我自己,大概一個禮拜就要補滿一次,最後我乾脆一次加個幾千,自己快樂地用。
我當時串的是 Google Gemini 3 flash lite,一個月下來通常只要個位數台幣,非常便宜,但讓我用得很開心。
Promptny 是我做的第一個 MacOS app,在做之前我沒有想太多,只是覺得「感覺做 Mac app 能取得的權限比較多」。結果開工後才發現,要做出一個別人可以安裝的 app,一定需要購買 Apple 的開發者資格,每年是 $99 美元。
而有了這個資格後,還要透過蘋果的開發工具 Xcode 來測試、編譯與發布上線。
當時的 Claude 還沒有那麼熟悉 Xcode,所以常常出錯或卡住,但也在一次又一次的重試後,搞定了整件事。
這讓我後續幾個 vibe coding 專案要再做 MacOS app 時都輕鬆很多。
另外,這也是我第一次串接 Supabase ,結果發現 AI 非常擅長操作他,然後完全可以把「呼叫 AI 執行某件事」的腳本部署在 Supabase 上面,讓這種小型的服務能運作起來。
我覺得雖然這個 app 幾乎不算正式推出,但我後來持續自用,加上學到不少經驗,是很棒的一次嘗試。
第二個做的 Histo 想解決的問題是:「我跟 Claude Code 討論過非常多事情,但這些紀錄很難找、很難回顧」。(取名來自 History)
當時想到的解決方向是讓他直接去讀電腦裡面 Claude Code 資料夾的原始對話紀錄,然後經過程式的處理後,只留下重要的資訊,並且透過舒適的排版與介面,呈現在 app 裡,讓我可以讀取、搜尋。
不過實際上我還做了很多「我想像中更好的體驗」,例如,可以透過 iCloud 跨裝置同步不同電腦上的 Claude Code 紀錄、或者是我自己覺得還算精美的 app 介面與畫面滾動細節等等。
做完後當然是覺得自己很棒,也在幾天內迭代了幾個版本,然後,就沒有然後了。
因為我發現我根本沒有我想像中的那麼常用他。
在高速迭代的當下,我每天幾乎就是不斷地鞭策 Claude Code 幫我處理東西。由於是短時間內的密集操作,所以某些事情為何這樣、為何那樣、為何不這樣,大致上都清楚,因此我幾乎不太有時間、也不太需要「回顧過去的對話」。
而且真的遇到問題時,直接問 Claude 通常更快。最後我發現一週大約只有一兩次想要去找某段完整的 prompt,而且那甚至也不是為了解決問題,只是想收集一下我自己覺得下的好的指令而已。
另外,要維持這個工具的穩定運作也比我想像的困難。因為它是讀取 Claude Code 的對話紀錄原始檔案,然後再處理成人類可以讀的格式。假設「來源資料」穩定,那還沒什麼問題。但當時正好處於 Claude Code 極速迭代的期間,幾乎每天都發新版,持續推出新功能、新設定,結果幾乎每天的新對話都會有某些東西跑不出來、或者跑版壞掉,甚至是某幾個用戶他們的對話才會遇到特定的格式,這導致要花很多時間重現與修復。
綜合評估後,我覺得對我來說價值不明顯、維護成本過高,我就決定不再繼續維護了。
當時多做了很多東西,例如 iCloud 同步,例如 feature toggles,甚至還設置了免費版與付費版的牆,我覺得這些東西並不是白做的,光是 iCloud 同步在測試時遇到的各種問題就學到很多。
而後續這個「讀對話紀錄」的需求仍然被我持續導入到其他專案中。現在我的重要專案都會有 Handoff 交接檔案、每次 session 結束時也會記錄一份 log ,讓未來更能找到關鍵決策。
我覺得當時做 Histo 的初衷已實現了,沒有什麼遺憾!
第三個做的 Purri 是一個語音轉文字的 MacOS app,當時應該是 Typeless 最紅的一段時間,我有試用了幾天 Typeless,但發現他處理文字起來總是有些過於激進,也有些地方不是我想要的。
加上有隱私問題&費用不低,我就開始嘗試自己做一個,目標是讓他更貼近我這樣的台灣用戶的需求。
當時有了前兩個工具的成功失敗案例後,我完全沒有打算再靠 Purri 營利了,只是想說做出來給有需要的人使用。
在做 Purri 時,我捨棄了之前兩個工具的很多功能,例如同步、付費相關機制、還有我認為的可能需要的進階功能(例如字典、自訂 prompt 等等)
我的目標就是用最快速度做出可以用的東西。
然後我也不打算再串 Supabase,改為讓用戶可以自己放自己的 API key。
所以蠻快(我記得幾天內)就弄出第一版了。我自己測試的體驗很不錯,因為 prompt 有特別處理過,所以在初步識別文字後,還會用簡單的模型去跑一遍潤飾,但又不會過於激進去亂改。
不過,正式推出後,我卻很少再打開來用。
我發現,比起用講的,我好像還是更喜歡用鍵盤輸入。
即使口語表達一定更快,我總覺得哪裡怪怪的,好像講出來的東西就是跟打出來的東西不太一樣,而我幾乎都更喜歡後者。所以推出後,我也不常使用,然後過一陣子後就完全沒再打開來過了。
在 Purri 這件事上,我學到最深刻的事情是:
不過我這幾個月一直都有想再重新啟動 Purri,主要是想擴張兩個方向的能力:
所以我應該會再找時間繼續更新 Purri。如果你對他有興趣,歡迎寄信到 hi@pjwu.me 敲碗。
在這兩三個月的密集 vibe coding 過程中,我變得非常熟悉 Claude Code,也因為跑了幾輪軟體開發的流程,還涉及了一些後端的權限驗證、資料庫、API 串接等等,這些原本算是「模糊理解」的東西都更熟悉了一層。這也讓我後來在工作上有了更多可以做的事、做起來也更有效率。
很多人會說現在的 vibe coding 幾乎都是在重複造輪子,我蠻認同的,但我覺得這件事非常好,自己想要的輪子自己造,造完一定會有收穫,而未來肯定可以造出更多輪子,甚至是以前無法想像自己能做的事。