Hi 大家好，我是老布～
I hope you’ve been well.
上週末去聽了一個講座，與會者由行銷、設計、工程師都分享他們在用vibe coding及自動化的經驗，演講者有提供了不少的想法及注意事項，聽起來最重要的一件事情，是先把大的項目切小切小之後，再去慢慢去找出最小可執行項目，也是開玩笑的說，如果最後還是沒有辦法自己vibe的話，那就花錢找別人vibe。
這場論壇最有印象的一句話是「想法跟執行之間不要間隔太久」由n8n的分享者Kevin，在最後提醒大家的行動力的重要性。
最後的Q&A，有很多人提問的問題有很大一類都在問「設計的未來」或「設計這個職位應該該如何受到影響」，但是其實這類問題，似乎都是落在一個職務上面的變化，而並不是考慮這個工具，如何讓設計工作加速，且其實比較好的模式，是利用這個工具去擴展不同的領域，這樣就不用擔心開職位的未來。
那設計還會不會需要？其實我個人是覺得還是會需要？
因為產品還是會需要一個讓人類可易於理解操作的介面，所以還是需要設計能力去轉譯，因此「設計」在產品開發和使用者溝通上還是需要。
如果僅將設計視為一種呈現外觀或表面形式的工作或技能，那麼它確實容易受到趨勢與潮流變化的影響。然而，若從「設計思維」的角度來學習設計，或將設計視為一份職業來發展，那麼設計所帶來的訓練與思維方式，其實可以應用在生活與職涯中的許多面向。
經過設計的教育訓練，對於解決問題及對產品的感受力會比較好。工業設計的訓練，對於手感觸覺是比較敏銳的；且做產品設計，但不一定是只能做實體產品，數位產品也是需要產品設計能力。
設計的核心能力，並不只是做出好看的成果，更在於能夠拆解問題，並提出合適的解決方案，從而滿足使用者的需求，回應問題的本質。
AI，本質上就是一種工具。它的角色應該是輔助設計師在設計過程中更有效率，而不是成為被恐懼的對象。我們不需要擔心AI能產出使用者報告，自己就會因此失去工作——那樣的想法，其實只是停留在對設計的表層理解而已。
開始第一次vibe coding
最近我也開始嘗試自己用 AI 協助撰寫程式，來開發一些個人使用的小工具。目前第一個試作的工具，是一個簡單小型的記帳軟體。
我的需求
1.這個記帳工具的出發點，其實是為了解決我在出國時的記帳困擾。當我在國外消費時，常常會因為記下的是當地貨幣，回到台灣後還需要再手動換算成台幣，導致記帳變得麻煩，有時甚至因為懶得轉換，就乾脆放棄紀錄。
2.我希望透過這個工具，能讓我在記帳的同時，就自動將當地貨幣轉換為台幣。這樣回國後就不用再進行第二次換算，也能避免因為轉換麻煩而漏掉某些消費紀錄。
3.要能隨時隨地記錄，因為出國旅行，最快的工具就是手機，所以這小工具就需要可以在手機上輸入，因此在手機上的閱讀性是需要被考量進去。
這是第一個實驗vibe coding，想解決的這些需求。
解決個人小問題的小工具
遵循很多文章及論壇強調的都是要把很大的一個服務慢慢接切小切細，然後從可執行的方面先著手，那我這一個解決的方式，就是用chatGPT及Google App script來進行試著建立該工具；
第一步：
其實自己就只是一直提問給AI，但不跟他說不要直接進入寫程式。
第二步：
然後讓AI先理解我的需求理解我的需求之後，我就把這些需求同整起來，變成是我一個基礎的SPEC，然後再讓他以基礎的SPEC，產出相對應的功能服務。
我其實驗的過程有發現到就是有時候真的不要想太多，而是先做了以後再實際的去調整，當然也有可能你的調整到最後跟你一開始想像的是不一樣，所以有可能他改一改就改壞掉了，那當然這個就是會有點沮喪。
但是當你開始實作測試，然後把前端跟後端接下來接起來的那一瞬間，其實你會感覺到自己好像學到了一些東西，那現在因為自己開始vibe coding了，野生養出了一個方式就是把覺得自己不錯的結果儲存成筆記，就是把產生出來的Code複製下來做成筆記。
如果今天我在跟AI協助的過程中改Code改到會壞掉了，那我就把之前複製下來的筆記，再貼回去恢復過去版本。這土法版控不是很聰明，沒錯，但用最簡單的方式，去實驗才會有繼續往下走可能性性，不然就會卡住卡太久。但這土法煉鋼的方法，還是得找到更有效率的方式來迭代優化。
第三步：
複製下來的結果，都會打包成一個筆記，當每次要開新的功能開發時，就把筆記轉成Markdown，餵給ChatGPT，讓它先讀過一遍後，在開始對話新的功能。
這個就變成是一個基礎，可以讓新功能偏差不會太多，也可以當作是每次溝通的開始就不用一直重新再寫SPEC跟目的，一些很根本需求的內容。
這就是這一次的實驗性vibe coding的過程，其實必須說，是可以讓程式門檻有大幅降低，讓我這小白菜雞的成就感有提升一些。
透過vibe實現大系統，還是有一段距離
不過在這次自己動手測試的過程中，我也發現一件事：如果真的想靠 AI 協助寫出一個較為複雜的程式，目前來說其實還有一段距離。
雖然知道一些大型公司已經開始導入大規模AI寫程式，實際觀察下來，大多還是從小規模的功能著手。而當要建構一個大型且複雜的系統時，仍然需要有一套完整的架構與流程規劃，否則系統很容易因為缺乏整合而突然出錯無法運作。
所以最終還是回到一個觀念：當你有一個較大的需求時，應該試著把它拆解成多個小的面向。每一個功能或模組在串接時，都要理解彼此之間的關聯與整合方式，這樣系統才不會在擴展或運行過程中出現問題。雖然這目前要實踐建立大系統，可能來有一段距離，但這問題，應該在可見的未來，會被解掉。
那時候就又回到「創意」會是核心重點，最終還是要知道需求是什麼？想要解決什麼問題？
這些工具的應用，確實能帶來更多的可能性與效率。它們可以幫助我們更輕鬆地將想法付諸實作，快速完成初步的嘗試與驗證。但最根本的問題仍然是：你使用這個工具，是為了解決什麼樣的事情？
如果缺乏這樣的思考，就很容易流於「為了應用工具而用工具」，卻不知道想要解決什麼問題。以我這次寫的記帳工具為例，最主要的目的，其實就是可希望解決在旅途中記帳與貨幣轉換的困擾，之後可以直接進行統計與分析。
這就是定義出來的「最小可行產品（MVP）」，它的核心價值非常明確。從這樣的例子可以理解到，當我們面對一個需求時，應該先去釐清它最本質的核心是什麼，然後再選擇合適的工具來解決它。
不論是什麼樣的開發或想法實踐，在開始之前都應該先了解：
真正的需求是什麼？
需求的本質問題是什麼？
有哪些工具可以協助解決這個問題？
這樣才能避免在整個過程中迷失方向，陷入不斷學習新工具的學習癌，卻始終無法真正應用，也無法轉化成有價值的成果或商業化可能。
現在看起來啟動的門檻降低了，但是啟動要做什麼？是會更顯重要的問題。
以上，這就是這一期電子報，這樣的過程分享，你也可以試試看，現在試錯的門檻降得很低。一起Vibe！