Vibe Coding 跟傳統開發，到底差在哪

2026 年 7 月的當下，大部分模型的最高級思考已經可以在程式的運作和資料抽象上做到無懈可擊。命題從「AI 寫的 code 對不對」變成了「AI 寫的 code 適不適合我」。這篇文章記錄我在日常開發中感受到的幾個根本變化。

方向的不同

這裡的方向不是指程式碼本身。LLM 對資料的抽象，是從大眾的程式碼中學到的最通用、可能性最大的抽象方式。但這種最大眾通用的方式，卻不一定適合你的業務。

如果開發初期沒有定下合適的方向，任憑 AI 自由發揮，它常常會和你預期的場景不一樣，導致返工。整體的開發用時因人而異，但我們確實要把時間花在性價比最大的地方——開頭的規劃與指令的詳細程度，直接決定後續的效率以及返工的頻率。

大眾共識 vs 你的需求，答案不在 AI，是你要來決定方向。

多任務之間的 context 切換

每個人的思考鏈條是有限的。進入 AI workflow 時代之後，按下 Enter，AI 要跑幾分鐘甚至十幾分鐘。這段時間你的腦子不可能盯著 terminal 發呆——又不是在賞魚。

實務上我用 Obsidian 來管理每個任務的 context。它的好處很單純：文字編輯器，沒有格式干擾；可以直接做 todo list，每個 todo 加上 [[ ]] 就能跳到新的一頁，像 Web 端的 URL 那樣。多個相關任務之間的訊息同步和快速導覽非常自然，工作區保持乾淨，想法完整寫好就能交給 AI 讀取執行。對我來說是很順手的工具。你也可以找其他適合自己的，只要能夠讓你迅速穿梭於不同的 context 之間，基本上都很合適。

不再需要刷演算法

在限定好各類條件的前提下，LLM 幾乎總能給出最佳方案。這句話在 2026 年的當下已經不是誇飾——只要不是最前沿的研究領域，基本上可以把 AI 當作老師或夥伴來討論。

想一想以前我們是怎麼做的：打開 Google，開始爬 Stack Overflow、翻官方文件、找部落格文章，然後在各種 library 之間比較——光是搞清楚哪個方案適合可能就去了半天。現在呢？直接把場景和限制條件描述清楚，AI 就能給你一個合理的方案，連 trade-off 都分析好在旁邊。出錯了也沒關係，貼回去，它會修正。就像有一個永遠在線上的資深同事，不會不耐煩，多蠢的問題都能問。

這並不是說演算法基礎不重要了。而是你現在可以把時間花在性價比更高的地方：去想架構的設計、去想使用者的場景、去想你的產品到底要解決什麼問題。查文件的時間省下來，拿去想更重要的問題——這才是 AI 時代開發者真正的競爭力所在。

大膽進入不熟悉的領域

邊做邊學，這句話在 AI 時代的意義完全不一樣了。

以前「跨領域」是一件門檻很高的事。你想切入一個新技術棧，通常要從文件的第一章開始啃，然後找 tutorial，然後踩坑，然後爬論壇——這整個過程可能要數週甚至數月，才能勉強說自己「會用」。但現在有了 AI，你可以在幾小時內就從零到做出一個能動的東西。就算卡住，也能夠馬上學習並處理。

AI 能幫你快速遷移各領域的知識，直接深入到不同技術的核心區分點。與其花時間讀整本文件的每一個章節，你更應該直接在專案中邊做邊問、邊問邊學。遇到不懂的術語就直接請 AI 解釋，看到陌生的 pattern 就讓它幫你拆解。這種「即時學習」的效率，跟傳統的文件閱讀相比，差距是非常大的。

當然，這不代表你可以永遠不讀文件。基礎理論和核心概念仍然需要花時間沉澱。但重點是：你不需要在出發前就準備好所有知識——先出發，有問題隨手丟給 AI 就行。

CI/CD 變得輕鬆

基礎設施的建制，以前對獨立開發者或小團隊來說是件苦差事。Serverless 框架、部署腳本、VSCode Tasks、GitHub Actions——這些東西的設定本身不難，但細節很多，一個 YAML 縮排沒對好就炸掉，debug 起來又特別花時間。

現在不一樣了。你可以直接把需求丟給 LLM：「幫我寫一段 GitHub Actions，在 push 的時候自動跑測試然後 deploy 到 Cloud Run」，幾秒鐘後一份可用的 workflow 檔案就出來了。就算第一次不完全對，頂多來回修個一兩次就能上線。以前需要反覆查文件、試參數的流程，現在變成了一段對話。

以我自己的 Flutter 專案為例，AppStore、GooglePlay、Web 三端的部署現在全部自動化——版號改好、push 上去，CI/CD 自己跑完測試、打包、上架。以前光是處理 Apple 的憑證和簽名就夠折騰的，現在讓 AI 幫忙把 Fastlane 和 GitHub Actions 串好，往後每一次 release 就是一行指令的事。

更進一步說，這不只是省時間的問題。當建置成本低到幾乎可以忽略的時候，你開始會願意去嘗試以前覺得太麻煩的事：加個自動化的 lint check、接上 code review 流程、多設一組 staging 環境⋯⋯這些「做了很好但以前懶得做」的事，現在隨手就能補上。基礎設施不再是一個需要專門排時間的專案，而是開發過程中順手就處理掉的一小段對話。

回看這五件事，背後其實是同一個變化：開發者的角色正在從「執行者」轉向「決策者」。AI 負責產出，你負責判斷——這東西適不適合你的場景、什麼時候該喊停、什麼時候該換方向。

開頭說，命題從「AI 寫的 code 對不對」變成了「AI 寫的 code 適不適合我」。到頭來，方向對了，code 才是你的；方向錯了，code 再漂亮也跟你無關。