AI 生成程式碼的速度愈來愈快,許多開發者開始驚嘆於它產出的規模與效率。但實際使用之後才發現,這些程式碼常常無法直接上線。它們可能邏輯模糊、測試困難,甚至一部署就出錯。看起來很完美的函式,一放進專案就出現預期外的 bug,甚至連基本的測試環境都跑不起來。AI 生成的速度越快,修復與理解的成本反而可能越高。
對新手來說,錯誤訊息像天書,連該查什麼都不知道,只能困在 prompt 與紅字的迴圈裡。對資深工程師而言,這些來路不明的黑盒 output 難以信任。寧可自己從零開始,也不想接手無法追蹤的程式碼。不同經驗層級的工程師,在使用 AI 開發時產生的落差愈來愈大,反而讓團隊協作變得更斷裂。
但這些困境,其實不是因為 AI 技術不夠成熟。真正需要被調整的,是我們對開發流程的認知方式。當 AI 成為開發的一部分,我們不能再用舊有的方式理解程式的產生與維護。我們需要新的工作節奏、溝通語言與決策架構,讓這些自動生成的程式碼,不只跑得快,也能真的跑得穩。開發這件事,從來不只是寫程式而已。尤其當 AI 開始幫你寫,你才會發現:你到底會不會說話,決定了它能幫上多少忙。
問題不在 AI,而在我們是否會發問
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];
}
這種寫法利用物件暫存已算過的結果,不僅維持遞迴的結構清晰,也能大幅提升效率。適合喜歡用遞迴解題、但又在意效能的開發者。
我們可以整理一下三種常見解法在效能與適用場景上的差異:
方法 | 時間複雜度 | 空間複雜度 | 適用場景 |
---|---|---|---|
遞迴(原始) | O(2^n) | O(n) | 適合理解演算法結構、教學、小 n |
迴圈(動態規劃) | O(n) | O(1) | 實務需求、效能要求高時 |
記憶體(memoization) | O(n) | O(n) | 遞迴需保留中間結果、強調可讀性 |
這個簡單的數列問題,實際上就是一個「持續優化提問」的練習:每多問一個 Why,就能讓 AI 產生更貼合需求的 output,讓你學會如何拆解問題、選擇最佳解法。Vibe Coding 的核心精神,就是這種有意識地反覆修正、精進的創作流程。讓程式設計不只是實作,更是思考與溝通的藝術。
從「怎麼做」到「為什麼要做」
成為獨立開發者之後,我發現自己對專案的思考方式產生了巨大的變化。過去接到任務時,總是習慣直接動手寫程式,思考資料結構、挑選框架,彷彿只要技術到位,任何問題都能迎刃而解。但當所有產品決策、技術選型都由自己負責時,我開始反思:「這個功能真的有必要嗎?」、「做完這件事,產品會變得更好嗎?」
有好幾次,我原本打算實作一個看似炫酷的 API 或自動化腳本,但在動手前仔細想想:這件事真的會節省我的時間,還是只是技術上的自我感動?比如說,為自己的 side project 加上即時推播功能,表面上很有成就感,但實際用戶根本不在意。結果往往是花了大量時間優化細節,卻無法提升產品的核心價值。
AI 工具開始協助開發以後,這種「先質疑、再實作」的習慣變得更加徹底。AI 可以省下我查文件、寫 boilerplate code 的時間,但它不會告訴我「這樣做有沒有價值」。每次產生新想法時,我都會停下來問自己:「這個需求解決了什麼痛點?有沒有更簡單的替代方案?」很多時候,最好的選擇其實是「不做」。
我逐漸學會把精力集中在真正有意義的功能上,主動排除那些「只是因為可以做」的開發衝動。像是自動化部署、數據備份這些重複性高又容易出錯的流程,我會優先用 AI 生成腳本來解決,減少發生人為錯誤的機會。反而那些難以定義、需要創意解決的核心功能,才值得花時間深究。
這種轉變讓我更能專注於產品的本質——解決實際問題,而不是技術炫技。現在的我,每次開始一個新專案,都會先用白紙把用戶流程、主要痛點寫下來,再決定哪些功能值得投入。AI 是我的輔助夥伴,但最終判斷什麼該做、怎麼做,還是要靠自己不停地自問:「這一行程式碼,真的讓我的產品更好嗎?」
我發現,獨立開發的最大收穫不是學會了多少新技術,而是更懂得取捨、更善於自我審視。只要持續保持這種質疑和反思的習慣,不管身處什麼技術浪潮,都能走出屬於自己的開發道路。
保持開放心態,重新學習語言作為開發工具
我深刻體會到,只要善用 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 不是放棄專業,而是重構流程
一開始我以為,AI 會讓開發變得更快。只要下一行 prompt,就能產出整套 UI、串接 API,甚至補好錯誤處理。效率看起來提高了,產出看起來也更豐富。但我很快發現,這些「看起來不錯」的結果,其實沒解決什麼真正的問題。那時我開始懷疑,問題從來不在 AI 的能力,而是在我是否真的知道自己在做什麼。我沒有慢下來問清楚需求,也沒有釐清每個步驟的必要性,只是順著生成繼續往前。
直到某天,我開始刻意把 prompt 寫得更慢、更細,甚至在送出前先問自己一句話:這是我真正想要的嗎?AI 不再只是工具,而變成一面鏡子,照見我的猶豫、含糊、甚至逃避。它沒有責備我,只是誠實地給出根據我語言所理解的結果。每一次對話,都像是一場交叉檢查。當我開始反覆重構 prompt,補充上下文,釐清邏輯,我才意識到,我其實是在重新設計整個思考流程。不是為了讓 AI 更聰明,而是讓我自己更誠實。
現在的我,比以前更慢也更穩。我不再用 AI 來證明我能做多少,而是用它來幫助我判斷什麼值得做。技術力不是我最想強調的事情,思考力才是。我學會用語言提問、拆解、驗證,也學會在每次選擇的交叉口上停下來,問自己一句:這一行程式碼,真的讓使用者得到幫助了嗎?如果沒有,那我寧可不寫。這才是我心中的 Vibe Coding,一種與自己對話的節奏,也是一種誠實的開發方式。
如果你有 AI 專案、網站開發或技術整合需求,歡迎來信交流: partner@calpa.me
歡迎訂閱 Calpa 的頻道,一同將想像力化為可能: