Vibe Coding 心得 - Sparkfit-Lab 開發日誌

我的 Sparkfit-Lab 開發日誌:一場與 AI 協作的 Vibe Coding 實驗

最近我完成了一個名為 Sparkfit Lab 的前端專案,這不僅是一次技術實踐,更是一場關於「Vibe Coding」與 AI 協同開發的深度探索。在這篇文章中,我想與大家分享我是如何利用 Gemini CLI、Cursor AI 等工具,以前所未有的效率打造專案,以及在這趟旅程中的心得與反思。

緣起:用 AI 定義專案的「Vibe」

專案的起點,並非一行程式碼,而是一段與 AI 的對話。我首先打開 Gemini,透過對話的方式,共同撰寫了一份詳細的 spec.md (規格文件)。這不僅是定義功能,更是在設定整個專案的「Vibe」——我希望它帶給使用者什麼樣的感覺?是充滿活力的、激勵人心的,還是專業而簡潔的?

接著,我將這份充滿「Vibe」的規格文件與特製的 Prompt 交給了 Gemini CLI。這一步,是整個開發流程的魔術時刻。

我的 AI 協作工作流:從建築師到雕刻家

我的開發流程像一場由不同樂器組成的協奏曲,每個工具各司其職:

  1. Gemini CLI:專案的建築師

    我讓 Gemini CLI 讀取 spec.md 與我的核心 Prompt,它便為我搭建起整個專案的基礎框架與核心架構。無論是建立大型功能模組,還是進行結構性的修改,Gemini CLI 就像一位經驗豐富的架構師,快速而準確地將我的藍圖化為實體。

  2. Cursor AI:細節的雕刻家

    當大的框架底定後,我便轉向 Cursor AI 進行微調。Cursor 如同一把精巧的雕刻刀,非常適合處理具體的、小範圍的修改。例如,當我想調整某個區塊的版面佈局時,只需在 Cursor 中圈選對應的程式碼,下達「幫我把這裡的排版改成…」之類的明確指令,它便能心領神會地完成任務。

  3. 手動編碼:最後的守門員

    AI 並非萬能。當 AI 的建議陷入死胡同,或者需要進行一些細微的設定調整時(例如:在特定條件下隱藏某個按鈕),就輪到我的雙手登場了。這時候,開發者自身的技術底蘊就成了專案品質的最後一道防線。

旅程中的重要心得

1. AI 間的「狀態同步」:新時代的開發挑戰


我遇到一個經典問題:我在 Cursor 中做了一個重要修改(將計數器動畫改為嵌入 YouTube 影片),但忘了「知會」Gemini CLI。結果,當我下一次請 Gemini CLI 進行大範圍更新時,它因為不知道這個異動,又把舊的動畫功能加了回來!

這點出了 AI 協作中的一個核心挑戰:狀態管理 (State Management)。我們的程式碼庫是「唯一事實來源 (Single Source of Truth)」,但每個 AI 工具在自己的會話中都維護了一份對程式碼的「記憶」。當多個 AI 同時工作時,如何確保它們的記憶與最新的程式碼庫同步,成了一項新課題。

解法:

  • 強制刷新記憶: 如您所說,使用 /memory refresh 或類似指令,強制 AI 重新讀取專案。

  • 跨平台溝通: 將一個 AI 的決策(如對話紀錄)導入另一個 AI,讓它們「知道」彼此的工作。

2. 前端開發的 Vibe:有畫面,好溝通

這次經驗再次印證了前端專案的優勢:視覺化的回饋極為即時。我可以馬上看到 AI 修改後的畫面效果,直觀地判斷這個「Vibe」對不對。這種「所見即所得」的開發循環,讓我和 AI 的溝通變得異常高效。

3. 技術底子是 AI 時代的加速器,而非替代品


有人可能認為 AI 會降低技術門檻,但在我看來,AI 反而對開發者自身的技術能力提出了更高的要求,只是要求的面向改變了:

  • 從「寫作者」到「總編輯」: 您需要具備極強的 Code Review 能力,快速判斷 AI 產出的程式碼是否高效、安全、可維護。

  • 從「建築工」到「設計師」: 您需要更懂系統架構與設計模式,才能給出高品質的 Prompt,引導 AI 搭建出優良的結構,而非一堆程式碼的集合。

  • 除錯能力的躍升: 修正自己寫的 Bug 是一回事,修正一個你不完全熟悉、由 AI 寫出的複雜 Bug,則是另一回事。這需要更深厚的除錯功力。

進階思考:從「寫」程式到「指揮」程式


除了上述心得,這次經驗也引發了我更深層的思考:

觀點一:開發者的角色轉移 — AI 的「指揮家」

我的工作內容,正從「逐行編碼」轉變為「下達指令、審核結果、整合系統」。我花在撰寫 for 迴圈的時間變少了,但花在思考如何用精準的自然語言描述需求、設計高品質 Prompt 的時間變多了。我們正從工程師 (Engineer) 轉變為 AI 指揮家 (AI Orchestrator)。

觀點二:警惕「AI 生成的技術債」

AI 優化的是「當下任務的完成度」,它不一定會為你考慮程式碼的長期可維護性。如果不加以引導和審核,AI 可能會生成大量看似能動、實則難以維護的「義大利麵式程式碼 (Spaghetti Code)」。身為開發者,我們必須成為品質的守門員,在享受速度的同時,主動管理和重構 AI 產出的程式碼,避免未來留下技術債。

觀點三:Prompt Engineering — 新時代的核心技能

這次經驗讓我深刻體會到,「問對問題」比「會寫答案」更加重要。如何將一個模糊的「Vibe」或複雜的業務邏輯,轉化成 AI 能理解、能執行、且能產出高品質結果的 Prompt,這本身就是一門專業技術,也就是所謂的「提示工程 (Prompt Engineering)」。

結論:效率的倍數級提升

總體而言,這套 AI 協作流程讓我的開發效率提升了數倍。它將我從繁瑣的樣板程式碼 (boilerplate) 中解放出來,讓我能更專注於專案的靈魂——也就是「Vibe」的塑造與使用者體驗的設計。

這是一次令人興奮的嘗試,也讓我對未來的軟體開發充滿期待。它不是要取代開發者,而是賦予我們更強大的力量,讓我們能將精力集中在更高層次的創造與思考上。

留言

這個網誌中的熱門文章

Google Map 單車路徑計算坡度和角度小工具

angular 如何Http 如何設定 CORS (Cross-Origin Resource Sharing)

10月24日 「方程式編輯器」讓你用Word打數學算式、根號、平方