想像一下，你想要建立一個新的應用程式。
在過去，你會打開程式碼編輯器，選擇一個框架，開始撰寫檔案，然後花上幾個小時除錯和調整。
今天，你可以用一句話就開始：
我想要一個具備登入、儀表板，以及顯示每月支出圖表的支出管理應用程式。
然後讓 AI 開始工作。
它撰寫程式碼。
它建立檔案。
它執行專案。
它偵測錯誤。
然後修改它寫出來的東西。
那你呢？
與其自己撰寫每一行程式碼，你成為了描述需求、審查成果的那個人。
這就是 Vibe Coding 的本質。
但在這裡，有一個值得停下來思考的問題浮現了：
如果 AI 能撰寫程式碼……程式設計師的角色變成了什麼？
📌 從現在開始收藏這篇文章，因為我們談的不只是一種撰寫程式碼的新方式，而是軟體本身被建構方式的改變。
最終最重要的問題不會是：AI 能撰寫程式碼嗎？
而是：
你知道什麼應該被建構、為什麼，以及建構出來的成果是否值得你信任嗎？
Vibe Coding 到底是什麼？
Vibe Coding 這個詞聽起來可能像一種新的程式設計方法，但它實際上描述了軟體本身建構方式的一個更大轉變。
在傳統程式設計中，你先思考解決方案，然後把它轉換成程式碼。
你決定架構（Architecture）。
你選擇函式庫（Libraries）。
你撰寫函式（Functions）。
你處理錯誤。
而且你測試每個部分。
在 Vibe Coding 中，你從一個不同的起點開始：
你描述你想要建構的東西，然後讓 AI 處理將描述轉換成程式碼的大部分工作。
舉例來說，你可能會從這樣開始：
我想要一個簡單的登入頁面，支援手機響應式設計，使用電子郵件和密碼。
AI 生成程式碼。
你執行它。
你發現你不喜歡這個設計。
於是你說：
把設計改得更簡單，並在輸入錯誤資料時加上清楚的提示訊息。
它修改程式碼。
然後你發現另一個問題。
你請它修正。
接著你新增一個新功能（Feature）。
於是，一個與程式設計師習慣的方式完全不同的循環就此展開。
真正的差異不在於 AI 撰寫程式碼
這裡有一個非常重要的重點。
AI 已經有能力撰寫程式碼一段時間了。
那為什麼 Vibe Coding 會成為一個不同的話題？
因為這個想法不是：
「AI 幫我寫程式碼。」
而是：
「我把 AI 當成執行大部分程式設計流程的人，而我負責指揮它並審查結果。」
這是一個根本性的差異。
在第一種情況中，你仍然是主要的程式設計師，而 AI 幫助你。
在第二種情況中，你更像是定義需求、測試結果，並決定需要改變什麼的那個人。
🤯
Vibe Coding 不只是加快撰寫程式碼的速度……它改變了作為程式設計師的意義。
在這裡，更宏觀的視野開始浮現。
因為當你減少了撰寫程式碼的時間，你會發現你的時間轉移到其他事情上：
思考產品。
定義應該建構什麼。
測試建構出來的成果。
發現哪裡有問題。
以及決定需要改變什麼。
這就是為什麼 Vibe Coding 不只是一種更快的撰寫程式碼方式。
它是在嘗試改變軟體建構過程中每個步驟由誰執行。
現在的問題不是 AI 能否寫一個應用程式……
這已經很清楚了。
更困難的問題是：
當應用程式開始運作，但你並不完全知道它是如何被建構出來的時候，會發生什麼事？
從撰寫程式碼到描述你想要什麼
為了更了解 Vibe Coding，比較一下程式設計師過去的工作方式，以及他們今天可以如何工作。
在傳統程式設計中，你從一個想法開始：
我想要一個支出管理系統。
但光是這個想法還不夠。
你必須把它變成需求，然後選擇合適的技術，設計資料庫，建構介面，撰寫 API，把各部分串聯起來，然後測試系統並修正錯誤。
每一步都需要技術決策。
有了 Vibe Coding，你可以從同一個想法開始，但不用自己把它轉換成數百個程式設計細節，而是向 AI 描述你希望產品做什麼。
然後它就開始把這個描述轉換成實作。
傳統程式設計
想法 → 需求 → 架構 → 撰寫程式碼 → 除錯 → 系統測試 → 部署
傳統程式設計
Vibe Coding
想法 → 描述需求 → AI 建構 → 執行與體驗 → 回饋 → AI 修改 → 測試與審查
注意其中的差異。
在第一種方法中，程式碼是你想法與產品之間的主要媒介。
在第二種方法中，描述、體驗和審查成為流程中更大的部分，而 AI 負責將想法轉換成程式碼的大部分工作。
在這裡，Vibe Coding 中最重要的轉變之一出現了：
你不再需要永遠知道如何撰寫所有東西……但你必須知道如何定義什麼應該存在。
這不代表技術知識已經變得沒有價值。
恰恰相反。
產出程式碼變得越容易，評估它並理解其影響的能力就變得越重要。
因為到最後，你不會只是問：
應用程式能用嗎？
相反地，你需要問：
它是以正確的方式被建構出來的嗎？
當程式碼只是手段
這裡正在發生一件重要的事情。
在傳統程式設計中，很多時間都花在把想法轉換成電腦理解的指令上。
你知道你想要建構什麼，但你必須自己把這個想法轉換成：
函式（Functions）、元件（Components）、API、資料庫查詢（Database Queries）、狀態管理（State Management）等等。
這部分就是讓學習程式設計需要花很長時間的原因。
但 Vibe Coding 試圖縮短這段距離。
你的主要任務不再是：
我怎麼寫這段程式碼？
而是變成：
我想要發生什麼事？
這是詞語上的小小改變，但在思考方式上卻是巨大的改變。
想像你想在應用程式中加入一個搜尋功能。
傳統程式設計師可能會開始思考：
Endpoint 是什麼？
我要如何處理 State？
我應該使用 Debouncing 嗎？
我要如何撰寫 Query？
我要如何處理 Pagination？
我要如何顯示 Loading State？
我要如何處理錯誤？
在 Vibe Coding 中，你可以從更高的層次開始：
為商品加入一個快速的搜尋功能，要有即時結果、載入狀態，以及找不到結果時的清楚提示。
AI 會嘗試把這個描述轉換成技術細節。
在這裡，程式設計師的價值更多地與首先知道應該存在哪些細節的能力相關。
💡
當撰寫程式碼變得更便宜時，知道該寫什麼變得比知道怎麼寫更重要。
但在這裡藏著一個大陷阱。
因為如果你不知道你在找什麼……
你就不會知道 AI 是否選擇了正確的解決方案。
它可能會給你可以運作的程式碼。
它可能看起來很棒。
而且執行應用程式時可能不會出現任何錯誤。
然而，這段程式碼背後的工程決策可能是糟糕的。
在這裡，Vibe Coding 的真正問題開始了。
讓 AI 撰寫程式碼，比判斷它寫的程式碼是否值得保留容易得多。
程式碼可以運作……但它好嗎？
在這裡，開始出現第一次實驗中不會浮現的問題。
你可能會請 AI 建立一個登入系統，它寫好程式碼，你執行了應用程式，然後發現一切正常。
你註冊了一個帳號。
你登入。
你登出。
然後你又回來。
一切看起來都很完美。
你對自己說：
我們完成了。
但如果有一個你的測試中沒有出現的安全性漏洞呢？
如果資料庫查詢沒有被最佳化呢？
如果當使用者數量從 100 變成 100,000 時才會出現問題呢？
如果 AI 使用了舊的函式庫或某種結構，導致幾個月後開發專案變得更困難呢？
在這裡，我們觸及了一個根本性的差異：
讓程式碼可以運作是一回事……而建立一個好的程式是另一回事。
想像你請 AI：
在應用程式中加入付款系統。
而且，它確實建立了付款頁面並連接到 API，測試時一切正常。
但你驗證過了嗎：
- 如果付款過程中連線中斷會發生什麼事？
- 這個流程會不會被不小心執行兩次？
- 金額是否在伺服器端被驗證過？
- 敏感資料是否有受到保護？
- 如果扣款後付款失敗會發生什麼事？
- 使用者能不能竄改請求？
這些不是關於撰寫程式碼的問題。
這些是關於軟體工程的問題。
在這裡，人類經驗的價值浮現了。
⚠️
AI 寫出最危險的程式碼，不是包含錯誤的程式碼……而是運作正常、但你不知道它有問題的程式碼。
這就是為什麼 Vibe Coding 不代表程式設計師不再需要理解程式設計。
它可能意味著完全相反的事。
產出程式碼變得越容易，發現糟糕程式碼的能力就變得越重要。
AI 可以在幾分鐘內給你第一個版本。
但它無法永遠獨自回答的問題是：
這是建構這個系統的正確方式嗎？
Vibe Coding 會扼殺程式設計嗎？
在這裡，真正的辯論開始了。
因為 Vibe Coding 的出現，讓一個老問題看起來更加迫切：
如果 AI 能撰寫程式碼，我為什麼還要學習程式設計？
快速的答案可能是：
因為 AI 仍然會需要程式設計師。
但光是這個答案還不夠。
因為事實是，程式設計師過去做的部分工作已經開始轉移到 AI 身上。
撰寫 Boilerplate？
變得更簡單了。
建立 Components？
變得更快了。
撰寫 CRUD API？
變得更快了。
把設計轉換成介面？
變得更簡單了。
撰寫初始測試？
變得更快了。
所以我們不能說什麼都沒變。
它確實改變了。
但錯誤在於把程式設計等同於撰寫程式碼。
程式設計師賣給公司的，不是他們能撰寫的行數。
公司不需要 10,000 行程式碼。
它需要一個能解決問題的系統。
這是一個巨大的差異。
如果 AI 可以在一小時內寫出 10,000 行，但系統充滿了錯誤……
我們什麼也沒得到。
但如果一個程式設計師能用 1,000 行建立正確的系統，具備良好的架構、安全性和測試……
這才是真正的價值。
⚔️ 程式設計師的角色會發生什麼變化？
這種轉變可以簡化如下：
傳統程式設計
程式設計師直接負責撰寫程式碼、實作技術細節、搜尋正確的語法（Syntax）、手動處理錯誤，以及從零開始建構系統的各個部分。他們大部分的時間都花在把想法轉換成電腦理解的指令上。
有了 Vibe Coding
程式設計師變得更專注於定義需求、做出技術決策、分析問題、指揮 AI，然後審查和修改建構出來的成果。與其專注於自己實作每個細節，他們更多的注意力轉移到最終結果和正在建構的系統品質上。
這不代表程式設計師會完全離開程式碼。
這意味著程式碼可能不再是他們提供的價值中最大的部分。
🤯
Vibe Coding 不會消滅程式設計師……但它降低了他們工作中依賴手動撰寫程式碼那部分的價值。
在這裡，問題變得更精確了：
只會撰寫程式碼的程式設計師，仍然足夠嗎？
很有可能……
不夠。
因為只懂語法的人，很大程度上可以被擅長這項技能的 AI 取代。
但那些理解以下問題的人：
我們為什麼要建構這個系統？
它應該如何運作？
存在哪些風險？
我們如何測試它？
以及當它失敗時會發生什麼事？
他們的經驗仍然有非常巨大的價值。
事實上，當產出程式碼本身變得更容易時，這些技能可能會變得更重要。
Vibe Coding 適合所有人嗎？
在這裡，我們必須區分使用 Vibe Coding 的可能性和善用它的能力。
是的，沒有太多程式設計經驗的人，現在已經有可能用 AI 建立一個簡單的應用程式。
而這非常重要。
因為嘗試新想法的門檻已經大幅降低。
一個有小專案想法的人，不再一定要先學會所有程式設計細節，才能看到自己想法的第一個版本。
他們可以在建構的過程中開始、實驗、修改和學習。
但問題始於從這個階段：
我想嘗試一個想法
過渡到：
我想建立一個人們依賴的真正系統。
的時候。
在這裡，情況完全不同。
想像有人用 Vibe Coding 建立了一個完整的電子商務商店。
介面正常運作。
商品可以顯示。
購物車可以運作。
登入也可以運作。
這個專案看起來可能很成功。
但當他們需要改變價格計算方式時會發生什麼事？
或者當出現一個他們無法重現的 Bug 時？
或者當兩個函式庫衝突時？
或者當他們發現資料庫設計不合適時？
在這種時候，只對 AI 說以下這些話是不夠的：
把這個修好
因為你首先需要理解問題本身。
這就是把 Vibe Coding 當作幫助你建構的工具……
和把它當作理解你所建構事物之完全替代品之間的差異。
💡
Vibe Coding 降低了程式設計的起步成本，但沒有消除理解的成本。
事實上，它可能讓理解變得更重要了。
因為理解正在發生什麼事的人，可以把 AI 當作一個巨大的槓桿。
至於不理解正在發生什麼事的人，他們也許能快速建構出某些東西……
但他們可能不知道它為什麼可以運作、什麼時候會停止運作，以及當它失敗時要如何修復。
Vibe Coding 什麼時候是絕佳選擇……什麼時候會變成風險？
Vibe Coding 不是所有類型軟體的合適替代方案。
在某些情況下，它可以說是從想法到可用模型之間最快的途徑之一。
想建立一個原型（Prototype）？
太好了。
想在投入大量時間和金錢之前先嘗試一個想法？
太好了。
想建立一個登陸頁面（Landing Page）、簡單的內部工具或個人專案？
在這裡，Vibe Coding 提供的速度可以成為一個巨大的優勢。
與其花上好幾天設定專案和撰寫重複的部分，你可以在短時間內達到一個初始版本，然後開始測試想法本身。
這是一個非常重要的觀點：
有時候你不需要完美的程式碼……你首先需要知道這個想法是否值得建構。
但當程式要負責處理敏感事物時，情況就改變了。
處理付款的系統。
儲存個人資料的應用程式。
醫療系統。
金融平台。
身份驗證（Authentication）系統。
或任何一個小錯誤就可能導致金錢損失、資料外洩或服務中斷的程式。
在這裡，只說以下這句話是不夠的：
「這個應用程式可以運作。」
相反地，你必須知道它是如何運作的、為什麼可以運作，以及當有人試圖以你預期之外的方式使用它時，會發生什麼事。
⚔️ 簡單的規則
錯誤的代價越高，你能在沒有真正工程審查的情況下依賴 Vibe Coding 的程度就越低。
如果你是在為自己建立一個小工具，速度可能比完美更重要。
但如果你在建構一個數千名使用者會依賴的系統，架構、安全性、測試和審查就不是可以碰運氣的事情。
在這裡，應對 Vibe Coding 的最佳方式浮現了：
不要用它取代軟體工程。
用它來加速軟體工程。
而這是一個巨大的差異。
如何正確地使用 Vibe Coding？
一個人用 Vibe Coding 建構真正有用的東西，和另一個人只是點開 AI 然後接受第一個結果，兩者之間的差異不在於他們使用的工具。
差異在於工作方式。
最大的錯誤是給 AI 一個龐大的想法，然後要求它一次建構整個專案。
例如：
「幫我建立一個完整的電子商務商店，包含登入、付款、儀表板、通知和物流系統。」
你確實可能會得到一個可以運作的專案。
但任務越大，就越難知道裡面發生了什麼事，而發現和修正錯誤也會變得更複雜。
最好的方式是分階段處理專案。
從目標開始。
然後請 AI 制定一個計畫。
之後，建構一個功能（Feature）。
執行它。
測試它。
審查程式碼。
然後進入下一個功能。
這樣一來，你不是讓 AI 取代你建構專案……
而是讓它一步一步地和你一起建構。
📊 Vibe Coding 的簡單工作流程
🎯 目標 → 📝 計畫 → 🤖 AI 建構 → ▶️ 執行與體驗 → 🔍 審查 → 🐛 發現錯誤 → 🤖 AI 修改 → ✅ 測試 → 🚀 進入下一步
Vibe Coding 的簡單工作流程
最重要的是：
在系統的重要部分中，不要接受你不了解其功能的程式碼。
你不需要記住 AI 寫的每一行程式碼。
但你必須知道架構中發生了什麼事、資料如何流動、弱點在哪裡，以及如何處理錯誤。
💡
用 AI 來提升你的速度，而不是取代你的理解。
當你以這種方式使用 Vibe Coding 時，AI 給你的速度就會成為真正的優勢。
因為你不是讓它主導專案……
你主導，而它執行。
如果你使用 Vibe Coding，還需要學習程式設計嗎？
在這裡，Vibe Coding 最常被問到的問題之一出現了：
如果 AI 能撰寫程式碼，我為什麼還要學習程式設計？
答案不是每個人都應該成為專業的軟體工程師。
但如果你想從只是嘗試一個想法，進階到建立真正的程式並依賴它們，理解程式設計仍然非常重要。
但不一定是舊的那種方式。
你不需要在建構第一個專案之前，記住數百行的語法。
你也不需要自己撰寫所有的 Boilerplate。
但你必須理解那些讓你能夠判斷 AI 產出的事物。
例如：
- API 如何運作。
- 應用程式如何處理資料庫。
- 資料如何在系統各部分之間流動。
- Authentication 和 Authorization 代表什麼意思。
- 如何發現 Bug。
- 測試如何運作。
- 架構（Architecture）是什麼意思。
- 安全性問題可能出現在哪裡。
因為當你具備這些基礎知識時，你才能看著 AI 寫的程式碼，並提出正確的問題。
如果你不了解這些，你可能會看到一個漂亮的專案在你面前運作……
然後就認為它很好。
在這裡，學習程式設計本身的方式也可以改變。
與其在建構任何專案之前花很長時間試圖記住一切，你可以在建構的過程中學習。
想知道 API 如何運作嗎？
用 AI 建構一個，然後請它解釋。
想了解資料庫嗎？
建立一個資料表、撰寫查詢，然後觀察資料如何流動。
想了解 Authentication 嗎？
實作它，然後試著理解背後發生的每一個步驟。
這樣一來，AI 就同時變成了老師、助手和加速器。
但有一條你絕對不能打破的規則：
⚠️
不要讓 AI 代替你學習程式設計。用它來更快地學習程式設計。
因為兩者之間的差異，會在第一次出現 Prompt 無法解決的問題時浮現。
程式設計師會怎麼樣？
也許這就是讓 Vibe Coding 有別於只是另一個新工具的問題。
因為我們談的不只是一個幫助你更快撰寫程式碼的工具，而是程式設計師工作本身的型態發生改變的可能性。
在過去，程式設計師一天中的很大一部分時間都花在把需求轉換成程式碼上。
閱讀需求。
搜尋解決方案。
撰寫程式碼。
測試它。
修正錯誤。
然後再次重複這個循環。
當 AI 可以接管這些任務中的很大一部分時，程式設計師的注意力自然會轉移到其他事情上。
問題會變得比較少關於：
我怎麼寫這個？
而更多關於：
建構這個的最佳方式是什麼？
而這是一個巨大的差異。
想像一個程式設計師面對一個新專案。
與其從撰寫第一個檔案開始，他們可能會從定義需求開始，然後請 AI 建議一個架構、討論選項、建立原型，並撰寫初始測試。
然後他們開始審查這些決策。
發現一個問題。
改變設計。
要求調整。
測試結果。
最後決定什麼要進入正式環境（Production）。
在這種情況下，程式設計師並沒有消失。
但他們的工作重心已經轉移了。
從撰寫每個細節……
到做出塑造產品的決策。
這可能會讓某些技能相對變得不那麼重要，同時其他技能的價值上升。
手動依賴程度可能降低的技能
- 撰寫 Boilerplate。
- 建立重複性的元件。
- 撰寫傳統的 CRUD。
- 把簡單的設計轉換成程式碼。
- 為每個小問題搜尋語法。
變得更重要的技能
- 系統設計（System Design）。
- 架構（Architecture）。
- 除錯（Debugging）。
- 安全性（Security）。
- 測試（Testing）。
- 理解商業邏輯（Business Logic）。
- 程式碼審查（Code Review）。
- 準確定義問題的能力。
- 判斷解決方案品質的能力。
💡
產出程式碼變得越容易，程式碼背後的決策就越有價值。
因此，程式設計師的未來可能不是撰寫更多程式碼。
而是用更少的程式碼、更多的工具和更精準的決策，來建構更好的系統。
在這裡，我們來到一個非常重要的觀點：
把 Vibe Coding 當作逃避理解程式設計之方式的程式設計師，可能會發現自己陷入困境。
至於把它當作提升自己生產力之手段的程式設計師……
他們可能會比單靠傳統方式工作的程式設計師強大得多。
Vibe Coding 中沒人談論的危險
還有另一個問題，可能比 AI 寫出糟糕的程式碼更危險。
那就是它寫出的程式碼夠好……好到讓你停止學習。
而這是一個重要的差異。
你可能會用 Vibe Coding 開始你的第一個專案，然後發現你能在幾小時內而不是幾天內，建立一個完整的介面。
你感到興奮。
然後你建立了第二個專案。
接著是第三個。
每一次，當你遇到問題時，你都會問 AI。
它解釋。
它修復。
它建議。
它撰寫。
隨著時間推移，你可能會發現自己能夠在不深入理解原理的情況下，建造出許多東西。
這裡出現了一個奇怪的矛盾：
你變得更擅長建構程式... 但你不一定變得更擅長程式設計。
想像你有一個運作完美的應用程式。
然後 Production 環境發生了一個問題。
API 變慢了。
有些使用者拿到了錯誤的資料。
而你不知道原因。
你問 AI：
修復這個問題。
它建議了一個調整。
你試了。
問題仍然存在。
你要求再調整一次。
然後第三次。
突然間，你發現自己陷入了一連串嘗試的迴圈中，因為你對系統內部發生的事情沒有一個清晰的思維模型。
這裡的問題不是 AI 不夠強。
問題在於你不知道你應該問它什麼。
⚠️
完全依賴 Vibe Coding 可能會讓你擅長產生程式碼... 卻不擅長理解它。
因此，兩者之間存在差異：有人說：
AI 為我打造了這個應用程式。
而有人說：
我用 AI 打造了這個應用程式，但我理解它的架構，而且我知道如何測試、修復和開發它。
前者擁有一個產品。
後者擁有一種能力。
而這種能力，即使你今天使用的工具消失了、明天出現新工具，它仍然會留在你身邊。
因此，應對 Vibe Coding 的最佳方式，不是讓 AI 替你思考，而是讓它擴展你的思考和建構能力。
因為最終的目標，不是成為那個能讓 AI 寫最多程式碼的人。
目標是成為那個知道該建構什麼，以及如何確保建構出來的東西值得推向世界的人。
請注意：Vibe Coding 不代表什麼都用 AI 建構
這裡我們需要釐清一個非常常見的誤解。
當有人聽到 Vibe Coding 這個詞時，他們可能會想像理想的方式是打開一個 AI 工具，請它把整個專案建構出來，然後等待結果。
但這通常不是這個理念的最佳用法。
真正的力量出現在當你知道建構過程中哪一部分值得交給 AI，哪一部分應該留給自己。
例如，你可以讓 AI 處理：
- 建立 Boilerplate（樣板程式碼）。
- 建構重複性的元件。
- 撰寫初始測試。
- 將設計轉換為程式碼。
- 針對特定問題建議解決方案。
- 分析錯誤。
- 執行重構。
- 為專案的部分內容撰寫文件。
相對地，你把需要理解脈絡的決策留給自己：
- 選擇架構。
- 定義商業邏輯。
- 安全性決策。
- 設計敏感系統。
- 審查重要的程式碼。
- 決定什麼可以進入 Production。
- 判斷建議的解決方案是否從一開始就合適。
🤯 最重要的想法
Vibe Coding 不是讓 AI 取代你工作。
而是讓 AI 處理那些不需要消耗你時間和經驗的部分，讓你能專注於那些真正需要你經驗的部分。
在這裡，程式設計師變得像一個流程的領導者。
指引方向。
設定限制。
審查結果。
當有無法交給機器決定的事時，介入處理。
最好的 Vibe Coding，不是讓 AI 寫最多程式碼的那種... 而是讓程式設計師專注於值得思考的事情上的那種。
這或許是使用 Vibe Coding 作為程式設計的捷徑...
與使用它作為建構軟體的新方式之間，最重要的區別。
在 Vibe Coding 的時代，程式設計師應該學什麼？
如果撰寫程式碼變得更容易、更快速，這並不代表程式設計師需要的技能變少了。
而是意味著他們需要的技能類型已經開始轉變。
目標不再是成為最會寫語法（Syntax）的人。
AI 可以幫你做到這一點。
最重要的是成為那個能從高處俯瞰問題、理解系統，並發現 AI 建議的解決方案是否真正合適的人。
因此，有一組技能將變得明顯更加重要。
1 - 理解程式設計基礎
你不需要記住所有東西。
但你必須理解事物如何運作：
變數、函式、API、資料庫、驗證（Authentication）、HTTP、Git。
因為沒有這些基礎，當 AI 犯錯時，你會很難知道發生了什麼。
2 - 系統設計與架構
建構元件變得越容易，將這些元件連結在一起的方式就越重要。
資料庫設計正確嗎？
API 合適嗎？
系統具有擴展性嗎？
技術選型合理嗎？
這些都是無法簡化為只是撰寫程式碼的決策。
3 - 發現並修復錯誤
請 AI 修復錯誤很容易。
但強大的程式設計師是能理解的人：
問題的原因是什麼？
發生在哪裡？
為什麼會發生？
然後利用 AI 更快地達成解決方案。
4 - 軟體測試
當 AI 能快速撰寫程式碼時，測試這些程式碼就變得更加重要。
只說：
「在我這裡可以運作。」
是不夠的。
你必須問：
「當條件改變時，它還能運作嗎？」
這就是單元測試、整合測試和邊界案例的重要性所在。
5 - 軟體安全
這是最危險的點之一。
AI 可以在短時間內撰寫驗證、金流和 API。
但程式碼的存在並不代表它是安全的。
你至少要理解基本原則，讓你能夠發現漏洞和危險的做法。
💡
在 Vibe Coding 的時代，你的價值不在於你能寫出每一行程式碼的能力... 而在於你能否知道哪一行從一開始就值得寫。
這不代表學習程式設計變得不重要了。
事實上，對於那些想要從「我能做出能運作的東西」階段，進階到「我能做出值得信賴的東西」階段的人來說，它可能變得更加重要。
程式設計師會變得更不重要，還是更重要？
這或許是 Vibe Coding 時代最大的矛盾。
乍看之下，AI 似乎正在接管程式設計師的大部分工作。
但同時，它也為程式設計師打開了大門，讓他們能完成以前需要更多時間和更大團隊才能做到的事情。
過去花數小時撰寫重複程式碼的程式設計師，現在可以把時間用來理解產品。
而卡在一個小技術問題上的程式設計師，可以快速嘗試多種解決方案。
需要數天才能建立原型的程式設計師，可以在短時間內達到可測試的版本。
所以問題不是：
程式設計師會消失嗎？
更好的問題是：
哪一種程式設計師會變得更有價值？
那些主要優勢僅在於撰寫程式碼速度的人，其價值可能會下降。
因為這種速度已經變成 AI 可以大幅倍增的東西。
但那種能理解問題、設計系統、發現錯誤、做出正確決策，並審查 AI 產出的程式設計師...
其價值可能會上升更多。
因為 AI 可以快速產生許多選項。
但還是需要有人來決定：
哪個選項最好？
🤯
AI 越擅長寫程式碼，優秀的程式設計師就越不需要依賴寫程式碼，而更加依賴理解它。
這裡，「程式設計師」的定義可能會發生重要轉變。
也許未來的程式設計師，不再只是那個坐在程式碼編輯器前數小時的人。
而是那個能將真實問題轉化為可運作的系統、將 AI 作為建構過程的一部分，然後為最終結果承擔責任的人。
程式碼仍然會存在。
但達到它的方式...
可能會徹底改變。
速度在哪裡結束，責任從哪裡開始？
有一些東西讓 Vibe Coding 不同於單純使用一個新工具。
速度幾乎對所有人來說都唾手可得。
但光有速度並不保證好的結果。
兩個人可以使用相同的工具，要求建構相同的應用程式，卻得到完全不同的結果。
第一個人問：
幫我建一個庫存管理應用程式。
然後接受第一個結果。
而第二個人從定義需求開始，拆分專案，測試每個部分，審查重要的決策，並在認為專案完成之前確保安全性與效能。
工具是同一個。
但使用方式完全不同。
這就是程式設計師的責任所在。
當你讓 AI 撰寫大部分程式碼時，這並不代表你放棄了對這些程式碼的責任。
如果 Production 環境發生錯誤，答案不會是：
是 AI 寫的。
使用者不在乎誰寫的程式碼。
他們在乎產品能不能用。
而公司不能對客戶說：
問題出在 AI。
因為責任最終在於決定使用並發布這些程式碼的團隊。
⚠️
AI 的執行能力越強，決定該執行什麼的人就越重要。
這為 Vibe Coding 設定了一個非常重要的規則：
不要因為你把執行交給了 AI，就把責任也交給它。
你可以讓它寫程式碼。
你可以讓它建議架構。
你可以讓它尋找錯誤。
你可以讓它撰寫測試。
但最終...
你才是那個決定什麼值得交給使用者的人。
正是在這裡，Vibe Coding 從只是一種快速撰寫程式的方式...
轉變為對程式設計師思考、審查和決策能力的真正考驗。
Vibe Coding 之後，程式設計師還剩下什麼？
Vibe Coding 並沒有讓程式設計變得沒有價值，但它改變了價值的所在。
程式碼變得更容易產生，但理解問題、設計解決方案、審查結果、發現錯誤以及為產品承擔責任，變得更加重要。
能從這個轉變中受益的程式設計師，不是那些試圖與 AI 比拼撰寫程式碼速度的人。
而是那些知道何時使用它、該要求它做什麼，以及如何審查它產出的人。
💡
未來不屬於那些寫程式碼比 AI 快的程式設計師... 而屬於那些知道該建構什麼、為什麼要建構的人。
最終，也許問題不再是：
AI 會搶走程式設計師的工作嗎？
而是變成了：
程式設計師準備好以新的方式工作了嗎？
結論：程式設計師沒有消失... 但他們正在改變
Vibe Coding 不代表程式設計的終結。
也不代表每個人向 AI 描述一個想法，就能成為軟體工程師。
改變的是人類在建構過程中的位置。
AI 已經能夠撰寫大部分的程式碼、建立原型、修復錯誤，以及執行重複性任務。
但仍然有一些無法忽略的問題：
我們在建構什麼？
我們為什麼要建構它？
這是一個正確的架構嗎？
系統安全嗎？
它能被依賴嗎？
當它失敗時會發生什麼？
在這裡，程式設計師的價值出現了。
不是作為那個獨自撰寫每一行程式碼的人...
而是作為那個理解問題、領導建構過程、審查 AI 產出，並為結果承擔責任的人。
🔥
也許程式設計的未來不是寫更多程式碼... 而是用更少的程式碼建構出更好的東西。
Vibe Coding 不會讓每個人變成程式設計師。
但它會讓懂得如何正確使用它的程式設計師，比以前更快、更有能力。
而真正的問題不再是：
AI 會寫程式碼嗎？
它已經證明它可以。
現在的問題是：
你知道它應該建構什麼嗎？
正是在這裡，開始區分出誰只是使用 Vibe Coding...
以及誰是真正用它來建構的人。
📌 在你關掉這篇文章之前... 記住這個原則
如果你要使用 Vibe Coding，不要把它當作擺脫程式設計的方式。
把它當作一種提升你建構能力的方式。
從想法開始，釐清需求，讓 AI 協助你執行，然後審查並測試所有重要的東西。
而且永遠記得：
速度不等於品質。
能運作的程式碼不一定是好程式碼。
而能建構的 AI，不一定知道該建構什麼。
因此，你的 AI 使用能力越強，同時也要確保提升你理解、審查和決策的能力。
在 Vibe Coding 中，你花在撰寫程式碼的時間可能會減少... 但別讓它減少你花在思考上的時間。
📌 如果你覺得這篇文章改變了你的思考方式，把它存到你的書籤（Bookmarks）吧。
不只是因為它解釋了一個新工具...
而是因為它解釋了軟體建構方式的轉變，以及隨著 Vibe Coding 的普及，程式設計師的角色如何改變。
如果你有不同的意見，或者你認為 Vibe Coding 會以我沒有提到的方式改變程式設計，歡迎在留言區告訴我。我會很高興閱讀並與你討論。
準備與撰寫： Adel Ahmed
💙 如果你從這篇文章中受益，別忘了將它存起來 （書籤），並分享給對程式設計與 AI 有興趣的朋友，因為這篇文章可能是理解軟體建構方式正在改變、而不只是撰寫程式碼方式在改變的一個起點。
