從 Vibe Coding 到 Agentic Engineering：當 LLM 不只是工具，而是新的計算介面

AI 對軟體開發的影響，已經不只是「寫 code 變快」而已。從 vibe coding 到 agentic engineering，真正的轉變是：我們開始把 LLM 視為一台可編程的電腦，重新思考產品怎麼設計、工程怎麼驗證、基礎設施怎麼被 agents 使用。這不只是效率升級，而是一整套軟體生產方式的重寫。

最近有一個我很喜歡的切分方式，是把今天 AI 寫程式的浪潮，拆成兩個完全不同的方向來看：vibe coding 與 agentic engineering。

表面上，兩者都在講「讓 AI 幫你做軟體」。但如果看深一點，它們代表的其實是兩種不同層級的變化。

一種是在降低寫程式的門檻；另一種，則是在重寫專業工程的生產方式。

一、Vibe Coding 解決的是「能不能做出來」

所謂 vibe coding，本質上是把 LLM 當成超強的自然語言程式助手。

你不一定要先把所有細節想清楚，只要能描述一個方向，模型就能很快吐出一大段可執行的 code。你站在旁邊像導演一樣，負責挑、改、接、補，最後把東西拼起來。

它最大的價值，不只是速度，而是大幅拉高了地板。

以前很多人卡在：「我知道自己想做什麼，但我不會寫。」現在則變成：「我不需要先會所有語法，也有機會把產品做出來。」

這件事的影響非常大，因為它讓軟體創作從一種高度專業技術，開始轉向一種更接近表達與組裝的能力。

但問題也在這裡。vibe coding 很適合做出能跑的東西，卻不必然保證你做出的是能長久維護、能安全上線、能承受成長的系統。

所以如果你的要求不是「先做出來就好」，而是「品質標準不能退」，那麼你進入的就不是 vibe coding，而是另一個更難也更有意思的領域。

二、Agentic Engineering 解決的是「怎麼又快又不爛尾」

agentic engineering 的前提，不是放棄工程標準，而是保留工程標準。

• 安全性不能掉
• 可維護性不能掉
• 效能不能掉
• 架構品質不能掉

在這種前提下，你仍然希望 agents 把速度推到 10 倍，甚至更高。

這就不再只是「叫 AI 幫我寫幾段 code」，而是一門新的工程學：你怎麼拆工作、你怎麼寫 spec、你怎麼定義邊界、你怎麼驗證輸出、你怎麼讓多個 agents 協同，以及你怎麼在人類審查成本不爆炸的情況下，把大量 implementation 自動展開。

vibe coding 面向的是：讓更多人能夠開始做軟體。
agentic engineering 面向的是：讓高標準的專業團隊，在不失控的前提下，把產能放大到新的量級。

三、Software 3.0：當 LLM 成為一台新的「電腦」

如果再往上抽象一層，會發現這背後其實對應的是一個更大的觀點：Software 3.0。

• Software 1.0：人手寫規則
• Software 2.0：用資料與 loss function 訓練神經網路
• Software 3.0：把 LLM 本身當成一台可編程的電腦

這個說法真正有意思的地方，在於它改變了「什麼叫做程式」。在 Software 3.0 的世界裡，你寫的程式不再只是 Python、TypeScript 或 Bash，而會變成 prompt、context、資料、tools 定義、工作約束、驗證條件與執行流程說明。

LLM 則像是一個 interpreter，根據這些上下文，在資訊空間裡完成運算。

一旦接受這個心智模型，很多原本看起來理所當然的工程做法，都會開始鬆動。以前你可能會為了一個自動化流程寫很長的 shell script、處理一堆 if-else、管理繁瑣的 pipeline；現在，某些情況下你更有效率的做法，可能是寫一段高品質 instruction，把工具、限制、目標都描述清楚，直接交給 agent 執行。

這不是「少寫 code」而已，而是把程式設計從語法組裝，轉向語意編排。

四、Menugen 給人的真正啟發：不要只想加速某一步

假設你想做一個 Menugen 類型的產品：拍一張菜單，自動幫每道菜補上圖片，產生更好看的視覺版菜單。

用傳統產品工程的方式，你大概會這樣做：

1. 先 OCR
2. 再 parsing 菜名
3. 再 call image generation
4. 再重排 UI
5. 再包成 app
6. 再部署上線

每一步都很合理，整體也很像一個正統產品架構。

但 Software 3.0 會逼你問一個更狠的問題：如果模型本身已經足夠強，那這整個 app 會不會其實是冗餘的？

也許你真正需要的流程只是：拍一張菜單，丟給 Gemini，加一句指令「把各道菜的圖片自然地 overlay 到這張菜單上，保持排版可讀性」，然後直接得到成品。

如果這條路成立，那你原本花大量力氣搭起來的中介層，其實只是舊思維的產物。

這對產品設計最大的提醒是：不要只問「LLM 能不能加速我其中一個步驟」，而要問「如果讓神經網路變成主角，整個產品會不會長得完全不一樣？」很多時候，最有價值的創新不是把流程變快，而是把整段流程刪掉。

五、LLM 最擅長的，不是規則清楚，而是結果可驗證

另一個我覺得非常重要的觀點，是 verifiability。

傳統軟體最適合自動化的事情，是那些你可以寫出明確規則的工作；但 LLM 最適合自動化的事情，往往不是「規則容易描述」，而是「結果容易驗證」。

今天最強的模型之所以在 code、math 這些領域突飛猛進，很大一部分原因是：它們可以被自動打分。程式能跑測試，數學有標準答案，形式推理可以做精確比對。只要可以自動評分，RL 就能大規模發揮，模型能力也能被迅速拉高。

反過來說，在那些很像日常常識、卻很難精準定義正確與否的問題上，模型反而可能犯出非常荒謬的錯誤。這就形成所謂 jagged intelligence：鋸齒型智力。它不是均勻聰明，而是某些地方異常尖、某些地方異常鈍。

• 找出自己 domain 裡可驗證的子問題
• 把系統拆成一連串能評分、能檢查、能回饋的步驟
• 知道哪些部分可以進入 RL 或自動優化迴路
• 也知道哪些部分仍然必須由人類做最後判斷

如果一個領域本身就高度可驗證，那麼它對 AI-native 產品與 agent 系統會特別友善。

六、Agent 像超強但很怪的實習生

我很喜歡另一個比喻：今天的 agents，很像一群超強但很怪的實習生。

他們的優點很明顯：產出非常快、記憶大量 API 細節、可以不抱怨地做重構、能把 specification 快速展開成 implementation，也可以同時平行處理很多工程碎務。

但他們也有很一致的缺點：很容易做出表面合理、其實邏輯爆炸的決策；工程常識常常不穩；遇到邊界條件時容易亂補；在安全性、抽象品質、效能細節上會犯低級錯誤。

所以真正有價值的人類角色，不是消失，而是升級。今天一個好的 agentic engineer，真正要做的是定義 spec、拆解問題、設定約束、建立驗證方式、挑出危險區域、做架構與抽象設計、維持 taste 與品質門檻，以及做最後的 sanity check。

七、Agent-first 世界，會逼整個 infra stack 重寫

如果 agent 會越來越常成為真正的操作者，那麼今天大量 infra、cloud、framework、平台文件，其實都還停留在人類使用者優先的年代。

很多 docs 寫法仍然是：打開某個頁面、點某個按鈕、進 dashboard、設定 DNS、找 UI 上某個選單、按下 deploy。這種文件對人類還算友善，但對 agent 其實很不友善。

如果未來主流工作流真的變成「我寫一句 prompt，剩下讓 agent 完成」，那平台就必須改成 agent-first：文件要更結構化、API 要完整而清楚、權限要可編排、狀態要可查詢、錯誤要可回傳、部署要可重播。

理想狀況下，你根本不想自己閱讀十篇教學文章。你只想知道：我要 copy/paste 哪一段 instruction 給 agent，事情就能完成？

這看起來像文件設計問題，實際上是整個數位基礎設施的介面革命。

八、Ghosts, not Animals：別用「人性」去期待模型

還有一個很有啟發性的比喻，是把 LLM 理解成 ghost，而不是 animal。

動物的智力是演化出來的。它有本能、有情緒、有自我保存、有好奇心，也有某些很深的人類直覺會自動投射的特性。但 LLM 不是這種東西。

它更像是由資料與 reward function 召喚出來的鬼魂。它能回答、能模仿、能推理、能完成任務，但沒有天然的內在動機，也沒有我們直覺以為它應該擁有的世界理解。

• 不要期待它被罵過就會自然學乖
• 不要期待它會自己在乎風險
• 不要期待它會自發建立常識
• 不要期待它像人一樣有穩定意圖

你真正該問的是：這個 pattern 是否出現在訓練資料裡？這個能力是否在強化回饋迴路中被磨過？這個任務是否超出了它已被驗證的能力分布？這種理解方式，對設計 agent、界定信任邊界、分析錯誤來源都非常有幫助。

九、你可以外包思考，但不能外包理解

You can outsource thinking, but you can’t outsource understanding.

今天很多形式的智力勞動，確實正在變便宜。你可以外包初稿、方案比較、程式樣板、資料整理、研究摘要、實作展開、測試生成；但你不能外包的，是理解本身。

最後仍然是你要決定：什麼值得做、什麼不值得做、哪個方向是對的、哪些風險不能接受、哪些輸出雖然看起來漂亮，但其實是錯的。

所以對個人與組織來說，LLM 最好的角色不是理解替代品，而是理解加速器。你可以用它反覆重組同一批資料、從不同角度摘要、做問答、拉出對比、模擬反方觀點，藉此更快建立自己的 mental model；但真正的吸收、整合與判斷，還是只能由你完成。

十、給創業者與 builder 的幾個實際提醒

1. 優先瞄準高度可驗證的 domain
   因為只要能驗證，就能建立評分、回饋與優化迴路，這會讓模型能力在你的場景裡快速變尖。
2. 設計產品時，不要只想哪一步可以加 AI
   而要問：如果讓神經網路當主角，哪些中介層可以整段刪掉？
3. 把自己升級成 agentic director
   真正的差異化，不會只是你會不會寫 code，而是你能不能設計 workflow、模板、審查機制與驗證系統，讓 agents 穩定放大你的產能。
4. 開始把一切往 agent-first 改寫
   不只是產品，連文件、infra、權限、監控、部署流程，都該重新設計成 agent 也能順暢操作的形態。

結語

如果說 vibe coding 讓更多人開始能做軟體，那 agentic engineering 則是在追問一個更深層的問題：當智慧本身變成一種廉價、可呼叫、可編排的資源時，軟體工程、產品設計、基礎設施，甚至整個數位世界的操作方式，應該如何被重新發明？

未來真正稀缺的能力，可能不再只是「會不會寫 code」，而是你能不能把 LLM、tools、驗證機制、工作流與架構設計，編排成一套高速前進但又不失控的系統。

這才是從 vibe coding 走向 agentic engineering 之後，真正值得投入的地方。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。