GLM-5 對了：該殺掉 vibe coding，改做 agent engin…

GLM-5 說得對，AI 開發必須從 vibe coding 轉向 agent engineering。

GLM-5 對 vibe coding 的否定是必要的，因為一旦 AI 要跨步驟規劃、呼叫工具、保留狀態並完成工作，靠靈感式調 prompt 就不夠了。它的系列化版本敘事，從 GLM-5 到 GLM-5.1、GLM-5.2，傳達的其實是同一件事：模型不該只被當成聊天介面，而要被當成可交付、可維運的系統來設計。

第一個論點

vibe coding 只適合原型，不適合交付。當代理人要處理工具調用、錯誤復原、長任務上下文時，直覺式提示詞會立刻暴露脆弱性。OpenAI、Anthropic 這類團隊近年反覆強調 evals、tool use、memory 與 workflow，原因很簡單：只靠 prompt，系統不會穩定重現同一結果。

軟體史也一再證明，先有靈感、後有工程。早期 Web、雲端自動化、行動 App 都曾經靠粗糙試驗起步，但真正能上線的產品，最後都回到架構、測試、觀測性與版本控制。GLM-5 把這個老道理重新說一遍，重點不是姿態，而是把 AI 代理的評估標準從「第一次看起來很強」改成「第 100 次還能做對」。

第二個論點

vibe coding 最大的問題，是它依賴隱性知識。A 工程師找到某句神奇提示詞，B 工程師照抄卻得到不同輸出，因為隱藏狀態、工具順序或上下文已經變了。這不是方法論，而是口耳相傳的巫術。agent engineering 的價值，在於把任務分解、工具政策、記憶邊界與控制流程都顯性化，讓行為可以檢查、比較、測試。

對開源來說，這種轉向更重要。GitHub 上的專案能否被重用，不取決於 prompt 有多神，而取決於行為是否可讀、可量測、可修改。GLM-5 被包裝成一個系列，而不是單次奇蹟發表，反而是好訊號，因為它暗示團隊知道 agentic AI 靠的是迭代與紀律，不是一次性的話術。

反方可能怎麼說

最強的反對意見是速度。vibe coding 讓小團隊能快速試錯，不必先搭完整架構，就能看見產品雛形。對每週都在變的 AI 領域，這種低成本探索很重要。太早導入工程化，會把團隊綁死在過度設計裡，錯過真正的使用者需求。

另一個合理擔憂是，agent engineering 可能淪為形式主義。團隊還沒找到明確問題，就先加記憶、規劃器、評估器與工具層，最後只是在技術上堆疊儀式感，掩蓋產品思考不足。若模型本身還不夠穩，任何華麗架構都只是把失敗包裝得更精緻。

這些批評成立，但只能界定邊界，不能推翻方向。vibe coding 應該留在探索階段，agent engineering 則是交付階段的標配。真正的錯誤，是把前者當成永久工作流。只要系統開始代表使用者做事，團隊就必須接受結構化設計，否則失敗不是例外，而是產品本身的一部分。

你能做什麼

如果你是工程師，別再把代理行為當成 prompt 手藝，改成軟體設計問題來做：定義工具契約、加上 eval、記錄每次動作、把失敗狀態顯性化。如果你是 PM 或創辦人，請把探索與交付切開，先用 vibe coding 找價值，再在流程碰到真實使用者、真實資料、真實金額時，立刻投入 agent engineering。這才是 AI 從 demo 變成產品的分水嶺。