2025 年 2 月，Karpathy 提出 Vibe Coding 這個詞，描述一種完全順著感覺走、用自然語言跟 AI 描述需求、完全不看程式碼的開發方式。這個詞爆紅後被濫用，到 2026 年初 Karpathy 又補了 Agentic Engineering 這個詞，用來描述有紀律的那一端。

Google 課程的第一個核心主張：這兩個東西不是二選一的開關，而是一條光譜。光譜上有三個位置：Vibe Coding → Structured AI Assisted Coding → Agentic Engineering。判斷標準不是你用不用 AI，而是 AI 的輸出有多少結構、驗證以及人類判斷。

Google 給了一張對照表：Intent 的規格化程度（隨口自然語言 vs 正式 Spec/架構文件）、驗證方式（看起來會動 vs 自動化測試 + CI/CD Gates + LM Judges）、錯誤處理（錯誤訊息貼回去叫 AI 修 vs Agent 在定義好的邊界內自我診斷）。

你該站在光譜的哪個位置沒有對錯，單純看使用場景與出錯風險。做 Prototype 純 Vibe Coding 完全合理，但處理金流的 Production API 就必須用 Agentic Engineering。

想往 Agentic Engineering 那端移動，答案不是把 Prompt 寫得更漂亮，而是學會 Context Engineering。Context Engineering 可以想成是幫新員工做入職簡報——一個新人來報到，你不會只丟一句「幫我把這個功能做出來」，你會告訴他任務是什麼、專案背景是什麼、公司有哪些規範。

Context 一共分成六種：Instructions（定義 Agent 的角色和邊界）、Knowledge（給 Agent 的領域知識）、Memory（短期和長期的狀態）、Example（行為示範）、Tools（他能呼叫的工具定義）、Guardrails（硬性約束）。

這六種 Context 又可以分成兩大類：Static Context（每次都一定會載入的東西，如系統指令、Rule Files、AGENTS.md / CLAUDE.md）——好處是可靠，壞處是貴，因為不管什麼問題都必須載入消耗 Token。Dynamic Context（按需求載入的 Context，如 Skills、RAG、工具執行結果）——好處是便宜、可擴展、需要才付錢，風險是 Agent 該去抓的時候沒去抓。

哪些 Context 放 Static、哪些放 Dynamic，這條邊界本身就是一個關鍵的架構決策，要像 Code 一樣被 Review、被版控。管理 Dynamic Context 最強的 Pattern 就是 Agent Skills，與其把所有專業知識塞進 System Prompt，不如讓 Agent 平常保持通用型，需要的時候再讀取 Skill 變成特定任務的專家，這個機制叫 Progressive Disclosure。

SDLC（軟體開發生命週期）因為 AI 的出現被不斷壓縮，但壓得很不均勻。Implementation（實際寫程式碼）從幾週變成幾小時，但需求訪談、架構決策、驗證品質大多數還是人的速度。不是舊流程被加速了，而是誕生了一個 新流程，迭代週期從週變成分鐘，Spec 的品質變成新的瓶頸。

Google 給了一個心智模型叫 Factory Model（工廠模型）：把整個開發流程想成一座工廠，而你是工廠經理。工廠經理不會親手組裝每一個零件，它負責設計產線、把關品質，產品是產線自己跑出來的。

放到軟體開發上，開發者的主要產出不再是程式碼，而是 產出程式碼的系統。這個系統包含：Spec 跟 Context、負責實作的 Agents、驗證正確性的測試跟品質關卡、把失敗導回去修正的 Feedback Loops、還有約束行為的 Guardrails。你給 Agent 的是 Success Criteria，不是 Step by Step 指令，然後讓它自己迭代。

很多人把 Model 當成系統本身——新 Model 出來就覺得 Agent 變聰明瞭，用舊 Model 就覺得 Agent 變笨了。這個觀念是錯的，而且它會讓你把時間投資在錯的地方。正確的公式很簡單：Agent = Model + Harness。一顆裸 Model 不是 Agent，它要有 Harness 給它狀態、給它執行工具的能力、給它 Feedback Loop、給它可執行的約束，它才變成一個 Agent。

你平常使用 Claude Code、Cursor、Codex 感受到的行為差異，很大一部分是 Harness 決定的，不只是底下那顆 Model。如果 Context Engineering 是新員工的入職簡報，Harness Engineering 就是整間公司的運作方式——IT 基礎設施、工作流程規範、門禁、績效評估系統，全部算在內。

Harness 有六大元件： 1. Rule Files：定義 Agent 是誰、在乎什麼、什麼事情絕對不能做 2. Tools：它能呼叫的 Function、MCP Servers，以及告訴它什麼時候該用哪個的說明 3. Sandbox：它的程式碼在哪裡跑、能碰到什麼碰不到什麼 4. Orchestration：Subagent 的調度、Model 之間的路由、專家之間的交接規則 5. Hooks：在生命週期的固定點跑的確定性程式碼（如 Commit 前自動擋掉硬編碼的密碼） 6. Observability：Logs、Traces、Evals、成本監控

Google 給了兩個案例證明 Harness 的重要性：SWE-bench 2.0 有一個團隊完全不換 Model，只改 Harness 就把成績從 30 名以外拉進前 5 名。LangChain 的實驗同一顆 Model，只調整 System Prompt、Tools 跟 Middleware，加了 13.7 分。同一顆腦，換一套工作環境，表現天差地遠。

日常習慣：Agent 出包的時候，不要修完 Bug 就走。多花五分鐘回頭問自己一句——我的 Rules、Workflows、Skills 哪裡可以改，讓這種錯誤不再發生？把答案寫回你的 Harness。這樣每跑一輪，你的系統就更可靠一點，錯誤也可以從成本變成資產。

Google 用兩個財務概念來回答「建置 Harness 的時間成本真的值得嗎」這個問題：CapEx（前期投資） 和 OpEx（營運成本）。

Vibe Coding 看起來超便宜——一個月的訂閱費、幾句 Prompt 就能開工，前期投資趨近於零。但它藏著三個會複利成長的營運成本： 1. Token 燃燒率：沒有整理過的 Context 整包倒進去，反覆叫 Model 秀它自己沒被驗證過的錯，這個低成功率的迴圈每一輪都在燒 API 費用 2. 維護稅：沒有結構一致性的 AI Code，半年後出 Bug，工程師要花好幾天逆向工程那坨義大利麵 3. 資安補救：Code 生得快，漏洞也會多，Production 環境修一個資安漏洞的成本是設計階段抓到的好幾倍

Agentic Engineering 把這套帳整個反過來：前期要投工程時間設計 API Schema、建測試套件、整理 Context——CapEx 高。但每一個功能的邊際成本大幅下降，因為 AI 是在一座治理好的工廠裡跑，產出的天生產構就是對的、預先測過的、符合公司標準的。

Context Engineering 不只是技術，它是財務槓桿。LM 是按你送進去的每一個 Token 收費的。把 10 萬 Token 的 Report 整包塞進每一個 Prompt，從 Token 效率來說是不友善的。而一份精準的文件、提示詞或任何 Context，會直接拉高 First-pass 成功率——第一次就做對，等於省掉整條 Trial and Error 的錢。你不能決定一個 Model 的費用，但你可以用比較少的 Token 數完成一樣的任務，只要你管理好 Context。

個人開發者的四個行動： 1. 開始建立並維護你自己的 AGENTS.md 或 CLAUDE.md，10 行就可以開始——技術棧、慣例、硬規則、Workflow，然後 Agent 每做一次你不想再看到的事，就加一條規則 2. 測試跟 Evals 在寫 Code 之前寫，它們是你跟 AI 之間的合約，一份好的測試套件比任何自然語言的 Prompt 都更能精確地傳達你的意圖 3. 要上線的 Code 每一行都要 Review，對看起來很聰明的東西保持懷疑，檢查 Import 的套件是不是真的存在 4. 基本功不能忘記——Debug 的方法、系統設計的原則都要留著，因為 AI 是放大你的這些專業，不是拿來替代它

團隊主管的三個行動： 1. 把 AI 開發當成 工程投資，不是生產力功能。導入 Coding Agent 卻不配套 Evals、Observability 跟架構標準，只會產出有速度沒品質的 Code 2. 把 Harness 當成團隊的共用資產——System Prompt、Skill、Evals、套件都要像 Code 一樣被版控、被 Review、有人負責維護。這些東西建一次，之後每個專案都在複利 3. 人跟 Agent 的混合團隊會是常態——人類定出方向，Agent 負責實作。招募和培養人才的重心也會從實作能力移到判斷力。會寫最多 Code 的工程師不再是最有價值的工程師，能把 Agent 指揮得好的纔是