直覺式開發(vide coding)時代來臨,軟體架構重要性與日俱增

直覺式開發(vide coding)時代來臨,軟體架構重要性與日俱增

最近兩個月,同溫層中興起一陣直覺式開發(vibe coding)的風潮,鼓勵大家用自然語言進行軟體開發。短時間內我就看到許多非技術背景的朋友們紛紛跳下來嘗試,也有些人真的做出一些有趣的東西。

我認為這種讓沒有技術基礎的人,也能開發軟體的概念,其實跟早些年 Windows 95 的圖形化介面,讓不懂得命令列(command line)的人也能使用電腦是相似的概念。

這是資訊科技進步的必然。再往下一階段,腦機介面的突破,還會進一步讓那些語言表達能力沒那麼好的人,也能透過腦袋中的想像來跟電腦互動,讓電腦幫忙完成程式開發。這很可能是下一波人機介面的革命。

但在這種革命發生的早期,許多的配套工具還未完善,但已經開始有大量的人投入使用。這些人寫出了一大堆無法維護,甚至無人能清楚解釋,但又運作正常的程式碼,這等同於創造了大量的技術債務。所以也有另一派人在討論,vibe coding 產出大量難以維護的程式碼,未來維護這套軟體的人將會身受其害。

從前寫程式的進入門檻較高,所以寫出來的程式再怎麼糟糕可能都還有人知道怎麼維護,所以 junior engineer 可能會寫出一些爛 code,但數量不多,且還能維護。

但現在進入門檻幾乎消失,重點是大家根本也不知道自己寫的 code 到底是怎麼運作的,更不用說要維護了。加上這些 code 其實也不大需要動腦筋,所以大家都放心的產生一大堆無法維護的程式碼。

人人都能輕易入門,這件事很棒,但輕易入門的代價則是大家會瘋狂寫出一大堆難以維護的程式碼。以前技術債的堆疊速度假設是 1,現在有可能變成 10,本來要花上 10 年才能堆出的技術債,現在可能只需要一年。

如果中間創造的價值也有 10 倍,那企業主也能心甘情願承受,可一般沒有那麼好的事情。

以砌牆為例,砌一面牆時,我們需要先明確幾件事:

  • 這面牆的目的是什麼?(防風、防盜、裝飾?)
  • 成品標準?(高度、寬度、承重力、外觀平整度)
  • 牆體結構要怎麼設計?(直線、弧形、厚度、留孔洞?)
  • 地基需不需要加強?(承載力?濕地 or 乾地?)

如果砌這面牆時,我們需要與他人協作,那我們還要進一步確認幾件事:

  • 砌磚的方式要統一(橫砌、交錯砌)
  • 磚與磚的間隙寬度、砂漿比例
  • 每一層磚的水平與垂直校正方式
  • 誰負責打地基?誰負責砌磚?誰負責監工?
  • 若有多人同時砌牆,接縫處誰負責對齊?
  • 每砌一段,要不要即時校正(level check)?

你可以想像一下,如果蓋一棟大樓時,沒有先畫好藍圖,也沒有先針對上述問題做好規劃,開工後每個人都按自己的方法去施工,最後會出什麼樣的結果?

  • 不同牆面的材質不同、承重能力不同
  • 不同牆面的高度不同、連結處不對齊也不平整

上述問題,如果是在施工過程發現,那就像 bug 在開發過程被抓出來一般,只是增加了重工的成本,不至於造成過大的風險。但如果是在蓋好後,因為地震或其他因素發現當初施工的問題,那很可能是以人命為代價。(參考:測試左移,我們該關注的是需求的 bug 數還是程式的 bug 數)

AI Coding 需要留意的事項

Cursor 的設計主管在 X 上分享過他認為使用 AI Coding 時需要注意的 12 件事

  1. 預先設置 5-10 個清晰的專案規則,以便 Cursor 瞭解您的結構和約束。簡單的說就是先設定好團隊在進行系統開發時的一些基本原則,例如 coding style。
  2. 提示要具體。像撰寫規格一樣闡明技術堆疊、行為和約束。
  3. by file 生成、測試和 review,關鍵是在「較小的範圍」內進行
  4. 首先編寫測試,鎖定測試,然後生成代碼,直到所有測試都通過。
  5. 檢查 AI 輸出並修復任何錯誤的內容,然後告訴 Cursor 原因,將這些錯誤修復作為與 Cursor 協作的範例
  6. 使用 @ file、@ folders、@ git 協助 Cursor 的注意力定位到 codebase 的正確部分
  7. 設計文件和清單保存在 .cursor/ 中,以便 AI 代理能在具有清楚脈絡的狀態下知道下一步該做什麼。
  8. 如果 Cursor 給出的代碼錯誤,就自己寫吧。Cursor 從編輯中學習的速度比從解釋中學習的速度要快
  9. 使用聊天記錄迭代舊提示,而無需重新開始。
  10. 有意識地選擇模型。要精確性用 Gemini,要廣度用 Claude。
  11. 在新的或不熟悉的堆疊中,將完整內容貼上。讓 Cursor 逐行解釋所有錯誤並修復。
  12. 讓大型專案在夜間編製索引,並限制上下文範圍以保持性能敏捷。

許多內容就是一語帶過,但我們可以推敲其背後的意涵。

規範化、明確而具體定義、小範圍、持續迭代、足夠資訊、測試先行,這些都算是軟體開發一直以來的管理重點,即便在 AI 時代,這些觀念也仍舊重要。

而這些其實都與軟體開發過程的軟體架構與開發規範有關。

在 Vibe coding 年代,人人都有能力寫些小程式,軟體功能的發展將會以飛快的速度推進,而在這樣的年代裡。

那些能做軟體架構設計,能定義開發規範的資深工程師與架構師的身價,將會水漲船高。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi
AI 在商業決策層面給我帶來的三層改變

AI 在商業決策層面給我帶來的三層改變

從二月開始,台灣就陷入一陣 AI 瘋,一堆人都開始投入龍蝦、Claude Code、Codex 等超級生產力的任務中。不寫程式的人開始寫程式,包含老闆、設計師、行銷、創作者。而其中最瘋狂的,莫過於身邊的一堆老闆們。 有人批評說:「這些老闆們放錯重點,應該好好回到自己的位置上去做出好的決策,讓專業的人來處理專業的工作,不要瞎搞。」 關於這個批評我個人極端不認同。 我的看法是老闆不多花點時間深入理解 AI,他在未來就很難做出好決策。 今天看到 Coinbase 的 CEO 在 X 上發布了裁員的消息。 而我也在 FB 寫下了我對這件事情的想法。 今年不知道第幾家公司了,幾乎都不是因為經濟不景氣,而是各家公司都在為變化儲糧。很多軟體公司之所以裁員,都是為了有更多的資本支出可以投入在 AI 的團隊、產品或基礎建設上。 扁平化只是一種不再需要「管理代理人」的訊息。現代的管理概念還是很崇尚那個一人最多管七人的科層組織管理概念。 為了「有效管理」,一個人管七個人是個看似科學,

By gipi
2026 年第一次深度復盤

2026 年第一次深度復盤

今天提早結束今天的顧問行程,中午回到住宿的飯店泡了個熱水澡,想著到底要休息還是繼續工作。但想了想,或許可以針對最近的一些想法跟經歷做一些復盤與總結。這篇文章內容比較雜一些,但都是我近期比較重要的一些想法。 重新燃起的工作熱忱 我的工作狂性格其實已經沉潛了好多年,我一直以為我對工作已經不像年輕時那麼有熱忱。沒想到工作狂性格只是悄悄地躲了起來,等待有一天再遇到讓人熱血沸騰的時機。 燃起我工作熱情的事主要有兩件,一件是方圓國際的策略長工作,另一件則是與 AI 有關的「Growth OS」計畫。 方圓的工作有一定的機密性我就不多說了,往後能揭露的內容會陸續讓大家知道,但我可以說這應該是我接觸迄今合作上最深入的案子,我覺得很開心。至於「Growth OS」是什麼?我下面會有獨立的段落跟大家說明。 但我可以先跟大家分享為什麼這兩件事會重新燃起我的工作熱忱。 我個人的工作熱忱主要來自幾個地方: * 有挑戰,這件事難不難,能否燃起我的挑戰慾望與好奇心。 * 能自我實現,我總有一些放在內心很想做的事,但可能是時機不到,又或者沒有碰到合適的場合。 * 能按自己價值觀來行事,這件事在我

By gipi
近期 AI 寫 Code 的一些想法

近期 AI 寫 Code 的一些想法

之前用 AI 寫程式,比較 free style,簡單說,就是功能能運作就好,反正就解決單點問題,就算是個商業應用,也大多設計成可以離線使用,架構很簡單。 但最近為了要完成我 Growth OS 的野望,我又回到以前工程師年代,會很在意目錄架構、資料結構、資料流、權限控制,甚至也會思考更多關於擴展性、多租戶、系統邊界設計的問題。 也因為有較深入的思考,對於 AI 參與開發這件事,我有了多一點的體悟。 Rule-baesd 模式 從前的程式開發大多是建立在有明確規格之後,演算法就像數學公式一樣,輸入什麼樣的參數,往往就能得到一個可預期的結果。 簡單的說,就是「確定性」,所以以前的測試根據的是輸入 A/B,是否得到 C 結果。 直到現在,如果我們對一個程式的執行結果,最主要看的是「確定性」,也就是執行一百次都要得到可預期的結果。那最後或許還是只有清楚的

By gipi