TL;DR
Vibe Coding 讓個人開發效率暴增，但缺乏系統設計會導致技術債失控。Andrej Karpathy 在 2026 年提出 Agentic Engineering：工程師設計可循環的框架，讓 AI 自主執行 99% 的工作，人類負責系統設計與最終把關。從「寫程式的人」進化為「系統設計者」，是 AI 開發的下一步。
這篇文章適合：
- 已經在用 AI 寫程式，但發現程式碼越來越亂、越來越難維護的開發者
- 想知道 Vibe Coding 之後「下一步該怎麼走」的中階工程師
- 第一次聽到「Agentic Engineering」，想搞懂它跟 Vibe Coding 差在哪裡的人
- 正在考慮把 AI 工作流系統化的個人或團隊
這是我最常被問到的問題之一。
「我們用 ChatGPT 寫程式碼已經快一年了，為什麼程式碼越來越難改？」
這個場景太熟悉了——prompt 堆 prompt，修補接著修補，沒人能完全說清楚為什麼要這樣寫。那個問題的答案，把我帶到了 Karpathy 在 2026 年初說的一件事。
Vibe Coding 的天花板在哪裡？
小美是個獨立開發者，2024 年開始用 ChatGPT 做一個活動報名網站。前三個月，她感覺像開掛——功能一個一個長出來，速度是以前的三倍。方法很簡單：有需求，就寫 prompt；有 bug，就再寫一個 prompt。
然後，問題開始出現。不是 AI 的問題。是累積的問題。
她改一個報名表單的欄位，赫然發現「這個改動影響到了後台的報表邏輯」。她再寫一個 prompt 修補，修補的程式碼又影響到了通知系統。改來改去，她漸漸發現自己已經不能清楚地解釋，為什麼程式碼要長成現在這個樣子了。
這不是小美個人的問題。這是 Vibe Coding 的天花板。
如果你還在評估 Vibe Coding 值不值得學，可以先看看 Vibe Coding 的風險與上手方式。
Vibe Coding（氛圍程式設計） 是 Andrej Karpathy 在 2025 年提出的概念，指的是開發者不直接寫程式碼，而是透過自然語言 prompt 描述需求，讓 AI 生成程式碼。它對個人效率非常有效——你不需要懂所有細節，只需要描述你想要什麼。
但問題在於，每一個 prompt 都是一次「臨時決策」。沒有整體設計，沒有系統結構，沒有人知道這些決策之間的邏輯是什麼。時間久了，程式碼開始出現工程師稱為「AI slop」的現象——程式能動，但沒有人能解釋它，更沒有人敢動它。
數據也開始說話了。根據 Apiiro 2025 年的安全研究報告，分析財富 50 大企業的 62,000 個程式碼庫後發現，AI 輔助開發導致安全漏洞月均增加 10 倍（2024 年 12 月至 2025 年 6 月）。MIT NANDA 計畫《The GenAI Divide》報告（2025 年 8 月）則指出，95% 的企業生成 AI 試點未能產生可衡量的財務回報。
這不是說 AI 沒有用。是說在沒有系統設計的情況下，AI 的速度優勢會被維護成本吃掉。
為什麼會這樣？
Vibe Coding 的崩壞循環長這樣：
flowchart TD
A[有了新功能需求] --> B[丟 prompt 給 AI]
B --> C[程式碼能動了]
C --> D[下次有需求，再丟 prompt]
D --> E[改動 A 影響到 B]
E --> F[再丟 prompt 補救]
F --> G[補救程式碼影響到 C]
G --> H[沒有人能解釋為什麼要這樣寫]
H --> D問題不在於 AI 不夠強，而在於沒有人設計整個系統。每個 prompt 都是對局部問題的局部回答，沒有人對全局負責。
Agentic Engineering 是什麼？
Agentic Engineering（代理式工程） 是工程師設計可循環的框架，讓 AI Agent 在框架內自主執行任務，人類負責系統設計、品質標準與最終決策的開發方法論。
2026 年 2 月 4 日，Andrej Karpathy 在 X（原 Twitter）上發了一則推文，正式提出這個概念。Karpathy 是 OpenAI 共同創辦人、前 Tesla AI 部門總監，AI 領域最具代表性的技術聲音之一。有趣的是，他也是 2025 年提出「Vibe Coding」這個詞的人——同一個人，一年前發明了 Vibe Coding，一年後說它不夠用了。
他在推文裡寫道：
"Agentic — because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. Engineering — because there is a level of expertise required to use agentic workflows for meaningful code production that does not jeopardize the code quality."
— Andrej Karpathy, 2026.02.04
翻譯成白話文：你 99% 的時間不再直接寫程式，而是設計一個讓 AI 能自主執行的框架，然後做最後的監督和把關。這個轉變的核心不是技術能力，而是角色定位。工程師不再是「寫程式的人」，而是「設計系統的人」。
Agentic Engineering 不是什麼？
- 不是「更厲害的 Vibe Coding」——它的思維模式完全不同
- 不是「AI 全自動，人類完全放手」——人類仍然是系統設計者和最終決策者
- 不是「只有大公司才能做的複雜工程」——任何有清晰流程的工作都可以
三個核心要素
Agentic Engineering 能運作，靠三個要素形成的循環：
flowchart LR
A[清晰的目標與約束] --> B[AI 自主執行]
B --> C[可驗證的輸出]
C --> D[回饋迴路]
D --> A- 清晰的目標與約束：AI 知道要做什麼、邊界在哪裡、什麼算成功
- 可驗證的輸出：每個步驟都有明確的檢查點，能判斷輸出是否符合標準
- 回饋迴路：AI 的輸出不符合標準時，系統能告訴它哪裡要修改，並重試
三個要素缺一不可。沒有清晰目標，AI 會亂跑；沒有可驗證的輸出，你不知道結果對不對；沒有回饋迴路，失敗了就只能重頭 prompt。
Vibe Coding 和 Agentic Engineering 有什麼差別？
阿凱也是個開發者，在 Brickverse 負責設計一套 Blog 編輯流水線。
小美聽說了他的工作方式，問他：「你怎麼用 AI 寫文章？也是一直 prompt 嗎？」
「不，」阿凱說，「我花了一段時間定義每個環節要做什麼、輸出什麼、怎麼驗證。現在 AI 跑完大半的工作，我只做最後決策。」
小美：「但這樣不是要花很多時間在前期設計？」
「對，前期確實花了時間。但現在寫一篇文章，我不需要每次都從頭 prompt。規則定好了，AI 按規則跑，我確認結果就好。」
這就是核心差別——不是誰用的工具更厲害，而是有沒有設計整套系統。
| 面向 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 工作流 | Prompt → 結果 → 修補 Prompt | 規則定義 → AI 自動執行 → 驗證 |
| 工程師角色 | 執行者（寫程式的人） | 系統設計者（設計框架的人） |
| 技術債 | 高（每個 prompt 都是局部決策） | 低（系統有整體設計） |
| 可複製性 | 低（下次還要重新調） | 高（規則可重用） |
| 品質穩定性 | 依賴運氣 | 依賴機制 |
你可能已經在做 Agentic Engineering 了
Brickverse 的 Blog 編輯流水線是一個真實的案例。
flowchart LR
A[選題] --> B[研究]
B --> C[寫作]
C --> D[審校]
D --> E[發布]每個節點都有清晰的輸入、輸出和驗證規則。AI 負責大部分的執行工作，工程師做系統設計和最後的決策把關。
這篇文章本身，就是這條流水線跑出來的。
如果你想看這套流水線的完整架構，可以參考 我如何用 8 個 Agent Skill 打造 Blog 編輯流水線。
重點不在於用了什麼厲害的工具。重點是：任何重複性的工作，只要你能清楚描述每個步驟，都可以這樣設計。 不需要大公司，不需要複雜的技術，只需要願意花時間把流程想清楚。
你的下一步
對照以下問題，看看你現在在哪個階段。
自我檢測：三個具體問題
1. 你的 AI 工作流，有多少步驟是自動化的？
- 每次都從一個 prompt 開始，得到結果再調——你還在 Vibe Coding 階段
- 有固定的 prompt 模板，但還是每次都要手動觸發和修正——開始有系統的雛形了
- 有多個步驟串聯，每個步驟都有明確的驗證——你已經在 Agentic Engineering 的軌道上了
2. 你能用一句話解釋你的 AI 工作流嗎？
- 不能——系統設計還不夠清晰
- 能解釋，但需要講很久——框架在，但還沒完全收斂
- 能用一句話說清楚，別人也能照做——你已經設計好了一個可重複的系統
3. 同樣的任務，你現在用 10 個 prompt，能減到 3 個嗎？
- 不能，因為每次都會遇到不同的問題——系統邊界不夠清楚
- 能，但需要花時間調整——系統的核心對了，細節還在打磨
- 能，而且結果很穩定——這就是 Agentic Engineering 在運作了
三個思維框架問題
你在設計一個「系統」，還是在寫一個「prompt」？
系統可以重複、可以被別人使用、有清楚的邊界。Prompt 是一次性的、個人的、邊界模糊的。
你對「成功」的定義是「這次快」，還是「下次也會這麼快」？
只想著這次快，你會不斷用 Vibe Coding 填補缺口。想著下次也要這麼快，你才會開始思考系統設計。
在你的工作流裡，AI 是你的「助理」，還是你「管理的員工」？
助理——有工作就叫，叫完再叫，沒有固定的職責範疇。員工——有清楚的工作說明、驗收標準、回報機制。
當你開始把 AI 當「員工」在管理，你就已經進入 Agentic Engineering 的思維了。
Vibe Coding 沒有過時。它是個好的起點，讓你快速嘗試、快速學習、快速感受到 AI 的能力。
但它有天花板。個人效率到頂之後，系統還是亂的。
Agentic Engineering 不是一個更複雜的工具，而是一個不同的視角——把自己從「執行者」重新定位成「系統設計者」。
Karpathy 同時發明了 Vibe Coding 和 Agentic Engineering 這兩個詞，大概不是巧合。前者是起點，後者是進化方向。
你現在在哪裡，沒有對錯。但如果你已經感受到了那個天花板，也許是時候開始問自己：我在設計系統，還是在寫 prompt？
你現在的 AI 工作流，比較像 Vibe Coding 還是 Agentic Engineering？有沒有已經開始系統化的部分，或是踩過類似小美的坑？歡迎在留言分享——聽聽大家走到哪了。
