AI 寫得比我快，我卻學會更慢地思考：Vibe Coding 的真實體驗

AI 生成程式碼的速度愈來愈快，許多開發者開始驚嘆於它產出的規模與效率。但實際使用之後才發現，這些程式碼常常無法直接上線。它們可能邏輯模糊、測試困難，甚至一部署就出錯。看起來很完美的函式，一放進專案就出現預期外的 bug，甚至連基本的測試環境都跑不起來。AI 生成的速度越快，修復與理解的成本反而可能越高。

對新手來說，錯誤訊息像天書，連該查什麼都不知道，只能困在 prompt 與紅字的迴圈裡。對資深工程師而言，這些來路不明的黑盒 output 難以信任。寧可自己從零開始，也不想接手無法追蹤的程式碼。不同經驗層級的工程師，在使用 AI 開發時產生的落差愈來愈大，反而讓團隊協作變得更斷裂。

但這些困境，其實不是因為 AI 技術不夠成熟。真正需要被調整的，是我們對開發流程的認知方式。當 AI 成為開發的一部分，我們不能再用舊有的方式理解程式的產生與維護。我們需要新的工作節奏、溝通語言與決策架構，讓這些自動生成的程式碼，不只跑得快，也能真的跑得穩。開發這件事，從來不只是寫程式而已。尤其當 AI 開始幫你寫，你才會發現：你到底會不會說話，決定了它能幫上多少忙。

問題不在 AI，而在我們是否會發問

All famous AI chat apps like Character.AI, Perplexity, Claude, Copilot, Chat GPT, Deepseek, Gemini with Appstore icon on an iphone screen. (Saradasish Pradhan)

AI 產生的程式碼，從來都不是最終答案，而只是開發過程的起點。真正決定 output 品質的，是工程師能否持續發問、追蹤細節、勇於糾錯，直到產出符合自己邏輯與需求的成品。這就像在與一位資深助理對話，你要不斷調整問題、給出明確的限制，才能逐步收斂出正確結果。

很多人以為 prompt 只是輸入一句指令，其實更像是持續對話與反覆澄清需求的過程。每一次追問，都會讓 AI 理解你想要的是什麼，也會暴露出它誤解之處。經過多輪修正後，程式碼會越來越貼近你的設計思路，最後才能放心納入專案。

讓我們以經典的「費波那契數列」作為 iterative refinement（反覆優化思維）的範例，來展現如何透過多輪提問與回饋，把一個簡單的程式設計問題，逐步精煉成高效又實用的解法。

步驟一：最直觀的遞迴解法

初學者常會這樣向 AI 提問：「請寫一個回傳第 n 個費波那契數的函數。」AI 會給出最直接、易懂（但效率極低）的遞迴版本：

// 原始版本：純遞迴
function fib(n: number): number {
  if (n <= 1) return n;
  return fib(n - 1) + fib(n - 2);
}

這個寫法充分體現了費波那契數列的定義，但每次呼叫都會重複計算大量重疊的子問題。當 n 很大時，計算時間會呈指數級爆炸，幾乎無法實用。

步驟二：追問效能瓶頸，改寫為迴圈法

於是你可以進一步追問：「這樣寫太慢了，有沒有更快的方法？」AI 這時會建議用 迴圈（動態規劃） 來消除重複計算：

// 迴圈版：動態規劃
function fib(n: number): number {
  if (n <= 1) return n;
  let a = 0, b = 1;
  for (let i = 2; i <= n; i++) {
    const temp = a + b;
    a = b;
    b = temp;
  }
  return b;
}

這種寫法只需線性時間，每個數字只算一次，而且空間複雜度 O(1)，非常適合大數運算與實務需求。

步驟三：進一步思考可讀性與記憶化

你可能會問：「如果我還是偏愛遞迴，有沒有辦法讓它又快又可讀？」這時 AI 會推薦 記憶化（memoization），讓遞迴也能享有動態規劃的效能：

// 記憶化版：遞迴 + memoization
function fib(n: number, memo: Record<number, number> = {}): number {
  if (n in memo) return memo[n];
  if (n <= 1) return n;
  memo[n] = fib(n - 1, memo) + fib(n - 2, memo);
  return memo[n];
}

這種寫法利用物件暫存已算過的結果，不僅維持遞迴的結構清晰，也能大幅提升效率。適合喜歡用遞迴解題、但又在意效能的開發者。

我們可以整理一下三種常見解法在效能與適用場景上的差異：

這個簡單的數列問題，實際上就是一個「持續優化提問」的練習：每多問一個 Why，就能讓 AI 產生更貼合需求的 output，讓你學會如何拆解問題、選擇最佳解法。Vibe Coding 的核心精神，就是這種有意識地反覆修正、精進的創作流程。讓程式設計不只是實作，更是思考與溝通的藝術。

從「怎麼做」到「為什麼要做」

Gary Butterfield (Gary Butterfield)

成為獨立開發者之後，我發現自己對專案的思考方式產生了巨大的變化。過去接到任務時，總是習慣直接動手寫程式，思考資料結構、挑選框架，彷彿只要技術到位，任何問題都能迎刃而解。但當所有產品決策、技術選型都由自己負責時，我開始反思：「這個功能真的有必要嗎？」、「做完這件事，產品會變得更好嗎？」

有好幾次，我原本打算實作一個看似炫酷的 API 或自動化腳本，但在動手前仔細想想：這件事真的會節省我的時間，還是只是技術上的自我感動？比如說，為自己的 side project 加上即時推播功能，表面上很有成就感，但實際用戶根本不在意。結果往往是花了大量時間優化細節，卻無法提升產品的核心價值。

AI 工具開始協助開發以後，這種「先質疑、再實作」的習慣變得更加徹底。AI 可以省下我查文件、寫 boilerplate code 的時間，但它不會告訴我「這樣做有沒有價值」。每次產生新想法時，我都會停下來問自己：「這個需求解決了什麼痛點？有沒有更簡單的替代方案？」很多時候，最好的選擇其實是「不做」。

我逐漸學會把精力集中在真正有意義的功能上，主動排除那些「只是因為可以做」的開發衝動。像是自動化部署、數據備份這些重複性高又容易出錯的流程，我會優先用 AI 生成腳本來解決，減少發生人為錯誤的機會。反而那些難以定義、需要創意解決的核心功能，才值得花時間深究。

這種轉變讓我更能專注於產品的本質——解決實際問題，而不是技術炫技。現在的我，每次開始一個新專案，都會先用白紙把用戶流程、主要痛點寫下來，再決定哪些功能值得投入。AI 是我的輔助夥伴，但最終判斷什麼該做、怎麼做，還是要靠自己不停地自問：「這一行程式碼，真的讓我的產品更好嗎？」

我發現，獨立開發的最大收穫不是學會了多少新技術，而是更懂得取捨、更善於自我審視。只要持續保持這種質疑和反思的習慣，不管身處什麼技術浪潮，都能走出屬於自己的開發道路。

保持開放心態，重新學習語言作為開發工具

A panorama view of Monaco (Tom S)

我深刻體會到，只要善用 AI，學習 Go 這類原本看似遙不可及的系統語言，其實可以非常直觀且高效。最初接觸 Go 的時候，光是 goroutine、channel 這些並發機制就讓我感到有點壓力，還有錯誤處理、型別系統、指標等，和我熟悉的 JavaScript/TypeScript 差異極大。但隨著 AI 協作工具的進步，這些技術門檻變得不再那麼可怕。

我的做法是：每當有想法或需求時，會先用自然語言把目標和預期流程拆解得越細越好，例如：「我要寫一個 Go CLI 工具，需要支援參數解析、能夠讀寫 YAML 設定檔、具備多執行緒下載功能，並且要有清楚的錯誤提示。」接著把這些需求丟給 AI，請它幫我產生 scaffold code。遇到不懂的語法、錯誤訊息或設計模式時，也會直接問 AI：「這個 context.Context 的用途是什麼？」、「為什麼要這樣寫 error handling？」甚至「有沒有更 idiomatic 的 Go 作法？」這樣的互動大大加速了我的學習曲線。

AI 不只是在寫程式碼的時候提供幫助，連很多 Go 生態圈的慣例、最佳實踐，甚至是 CI/CD、單元測試、效能優化，也能即時解釋並舉例。像是我用 Go 開發網路工具時，會問 AI：「怎麼用 goroutine 實現大量 HTTP 請求但不會打爆記憶體？」AI 不只會給出程式碼，還會解釋背後的資源管理原理，讓我更容易理解為什麼要這樣設計。

更重要的是，Go 的簡潔語法和極佳的可讀性，讓我每次從 AI 那裡拿到程式碼後，都能快速地理解每一行的用途，進一步調整成最適合自己專案的結構。即使遇到複雜的第三方套件或框架，也能靠著 prompt 一步步拆解細節，問到自己完全明白為止。

現在的我，已經不會再害怕「換語言」這件事。Go 對我來說，就是一個直接把想法落地的強大工具，只要能清楚描述問題和需求，AI 就能補足我在語法、標準庫甚至設計思維上的不足。語言本身已經不再是學習路上的絆腳石，而是我探索更高效開發模式的橋樑。AI 讓我敢於主動面對未知，不斷突破自己的技術邊界。

總結：Vibe Coding 不是放棄專業，而是重構流程

Shirakawa Lane (Calpa Liu)

一開始我以為，AI 會讓開發變得更快。只要下一行 prompt，就能產出整套 UI、串接 API，甚至補好錯誤處理。效率看起來提高了，產出看起來也更豐富。但我很快發現，這些「看起來不錯」的結果，其實沒解決什麼真正的問題。那時我開始懷疑，問題從來不在 AI 的能力，而是在我是否真的知道自己在做什麼。我沒有慢下來問清楚需求，也沒有釐清每個步驟的必要性，只是順著生成繼續往前。

直到某天，我開始刻意把 prompt 寫得更慢、更細，甚至在送出前先問自己一句話：這是我真正想要的嗎？AI 不再只是工具，而變成一面鏡子，照見我的猶豫、含糊、甚至逃避。它沒有責備我，只是誠實地給出根據我語言所理解的結果。每一次對話，都像是一場交叉檢查。當我開始反覆重構 prompt，補充上下文，釐清邏輯，我才意識到，我其實是在重新設計整個思考流程。不是為了讓 AI 更聰明，而是讓我自己更誠實。

現在的我，比以前更慢也更穩。我不再用 AI 來證明我能做多少，而是用它來幫助我判斷什麼值得做。技術力不是我最想強調的事情，思考力才是。我學會用語言提問、拆解、驗證，也學會在每次選擇的交叉口上停下來，問自己一句：這一行程式碼，真的讓使用者得到幫助了嗎？如果沒有，那我寧可不寫。這才是我心中的 Vibe Coding，一種與自己對話的節奏，也是一種誠實的開發方式。