這部由 Anthropic 研究員 Eric 主講的影片，探討了如何在正式環境（Production）中負責任地進行「氛圍寫麥」（Vibe Coding）。影片結尾明確總結了四大重點：
一、成為 Claude 的產品經理 — 進行 Vibe coding 時，你不該只是一個給出簡短指令的工程師，而是要把 AI 當作第一天上班的初階工程師，而你是他的產品經理。
二、專注於程式碼的「葉節點」 — 將 Vibe coding 應用在系統最外圍的功能，讓技術債就算存在，也不會往核心擴散。
三、建立可驗證性與壓力測試 — 設計易於驗證輸入輸出的系統，用測試取代逐行審查。
四、擁抱指數型成長 — AI 能處理的任務長度每七個月翻倍，堅持親手寫每一行的人，終將成為瓶頸。
以下是完整的深度解析。
去年，Anthropic 的研究員 Eric 在一場單車意外中摔斷了手，整整兩個月無法打字。對大多數工程師來說，手骨折就等於職涯暫停。但對 Eric 來說，那八週反而是一次被迫的進化。他讓 Claude 寫下每一行程式碼。
Eric 發現的不只是一個應對受傷的變通辦法，而是一場正在席捲軟體產業的結構性轉變。我們正在告別「手動實作」的時代，進入「憑感覺寫程式」（Vibe Coding）的時代。這個名詞聽起來像在偷懶，但它正在快速變成一種經濟現實、一種職涯必要技能。要維持競爭力，開發者必須學會如何脫離對語法的執念，去管理整個生產環境的「感覺方向」——同時又不能成為拖慢整個專案的瓶頸。
「感覺」是什麼？不只是用 AI 工具
大多數開發者以為自己已經在這樣做了，因為他們用 Cursor 或 Copilot。但其實沒有。「大量使用 AI 輔助」和真正的 Vibe Coding 之間，有一道根本上的差異。
Andrej Karpathy 對這個轉變有個很精準的定義：Vibe coding 是當你「完全交出去，擁抱指數成長，忘掉程式碼的存在」的時候。如果你只是讓 AI 幫你補完一個函式，你還是在一行一行的反饋迴圈裡——你是駕駛，AI 只是輔助方向盤。在 Vibe Coding 裡，你是領航員。你不再在乎括號和分號的具體排列，你只在乎意圖。
這正是最近讓非工程師也能從零打造整個應用程式的關鍵突破。但這裡有個巨大的前提：在生產環境裡搞 Vibe Coding，目前是一項進階技能。對沒有技術底子的人來說，這條路很危險。沒有技術基礎的「憑感覺」，最後就是 API 金鑰外洩、資料庫損毀、資安漏洞。所以，專業工程師的目標不是變得不技術，而是用技術底子成為「AI 的產品經理」。
七個月翻一倍：你根本來不及一行行 Review
我們現在卡在一個人力瓶頸裡。數據顯示，AI 能處理的任務長度，每七個月翻一倍。現在，一個模型大概能處理一小時份量的工作。明年，會是一天；後年，會是一週。
如果 AI 用十分鐘生出一週的工作量，你卻堅持一行行手動 Code Review，你等於親手抹殺了人類歷史上最大的生產力跳躍。要做到規模化，我們必須像信任編譯器一樣信任這套系統。我們不讀編譯器輸出的組合語言，我們驗證結果。
「機器的慈悲不是科幻小說，那是一份產品路線圖……當你在一條指數曲線上，事情會變得很瘋狂，快得超乎你的預期。」——Dario Amodei 和 Mike Krieger
想想 1990 年代。一個為幾 KB 記憶體斤斤計較的開發者，根本無法想像現在 TB 等級的世界。我們現在要準備的不只是「兩倍聰明的模型」，而是能力提升百萬倍的未來。在那個世界裡，堅持親眼看每一行程式碼的人，才是會被淘汰的那個。
心態的轉移：從執行者變成 CEO
管理一件你不完全理解的事，其實是人類幾千年來一直在做的事。每個專業領域的領導者都在這樣幹：
- CEO 和會計師：CEO 不是會計師，但他們會抽查關鍵數字，驗證財務模型的輸出，確認公司有在賺錢。
- CTO 和領域專家：CTO 常常在管比自己更懂某個特定領域的工程師。他們不會重寫專家的程式，他們設定驗收測試。
- PM 和工程師：產品經理確認功能是否正常運作的方式，是壓力測試使用者體驗，而不是審查 PR。
作為工程師，你的價值不再只是硬啃語法的能力。你的價值在於能否引導這個「員工」（也就是 AI），並驗證它交出來的結果。你正在從個人執行者，轉型為透過抽象層來驗證一切的高階架構師。
重點一：成為 Claude 的產品經理
進行 Vibe Coding 時，你不該只是一個給出簡短指令的工程師，而是要把 AI 當作第一天上班的初階工程師，而你是他的產品經理。你應該花時間為 Claude 導覽程式碼庫、提供詳細的需求規格與限制。
「不要問 Claude 能為你做什麼，要問你能為 Claude 做什麼。」
提供越充分的上下文與規劃，AI 成功完成任務的機率就越高。Eric 的工作流程有一個專屬的 15 到 20 分鐘前置規劃階段：
- 探索：用 AI 巡視整個程式碼庫。問它「身份驗證是在哪裡處理的？」或「這個 API 應該遵循什麼模式？」
- 計畫文件：這是一個具體的產出——透過來回對話建立的文件，記錄需求、列出要修改的檔案，並且確立限制條件。
- 執行：等「計畫文件」扎實了，才讓 AI 去跑。
重點二：專注於程式碼的「葉節點」
目前 Vibe Coding 最大的隱憂，是難以在不閱讀程式碼的情況下驗證技術債。因此你需要一張程式碼地圖，分清楚「主幹」和「末梢節點」。
- 主幹與分支：這是你的核心架構——其他系統所依賴的基礎邏輯。這部分必須保持彈性、乾淨、可擴展。人必須深度理解並親自把關，因為技術債是目前唯一我們還沒辦法用「憑感覺」來驗證的東西。
- 末梢節點：這些是終端功能——那些「加分小功能」，沒有其他東西依賴它們。
如果你把 Vibe Coding 集中在末梢節點，技術債就被控制住了。一個終端功能的底層再亂，也不會拖垮核心系統，不會阻礙未來的開發。你其實是在把 AI 的「亂搞範圍」限制在最能發揮效益、危害最小的地方。
重點三：建立可驗證性與壓力測試
真的可以不讀程式碼就合併大量變更嗎？Anthropic 最近把一個 22,000 行的生產強化學習程式碼改動合併進去了，幾乎全由 AI 撰寫。他們不是在賭運氣，而是把驗收的抽象層搬到更高的地方。
就像 CTO 或 CEO 不需要看懂所有程式碼或財務報表，也能透過驗收測試或抽查關鍵數據來確保成果——你可以透過測試驅動開發（TDD）或設計端到端測試（End-to-End Test），來確認 AI 寫出的程式碼是否穩定且正確。
他們用的是三段式策略：
- 末梢節點集中：22,000 行裡的大部分，都落在不可延伸的程式碼區塊。
- 精準 Review：人只重點審查需要長期架構彈性的「主幹」部分。
- 壓力測試抽象：團隊把系統設計成「不用讀程式碼也能理解和驗收」，建立嚴格的壓力測試，跑很長的時間，專門針對各種錯誤情境檢查正常路徑。
如果系統通過了一套嚴格的穩定性測試，對給定的輸入產出了完美的結果，那麼不管有沒有人看過那 22,000 行的 diff，實作就是成功的。
重點四：擁抱指數型成長
AI 的能力正在呈指數級別增長，能處理的任務長度每七個月就翻倍。未來的 AI 將能一次產出幾天甚至一週的工作量，如果工程師堅持要逐行閱讀或親自撰寫每一行程式碼，不僅無法跟上 AI 的進步，反而會成為開發流程中的瓶頸。
我們必須把 AI 視為編譯器——信任其底層運作，並在更高的抽象層級進行開發。
Vibe Coding 最終的大獎，是軟體邊際成本的崩潰。當一個功能從兩週縮短到一天，你「出手的次數」就倍增了。但還有一個更深層的突破：學習週期的崩潰。傳統上，一個架構師可能要等兩年才知道自己的結構決策對不對。Vibe Coding 把這個週期壓縮到六個月。透過一個隨時在線的 AI 配對夥伴來解釋新函式庫、提供替代方案，工程師在同樣的職涯跨度裡，能吸收的東西是以前的四倍。
兩年後，這個產業會分成兩個陣營：因為不肯放開語法而成為瓶頸的開發者，以及善用指數成長、做出規模前所未有的東西的開發者。
忘掉程式碼的存在，但永遠不要忘掉產品的存在。做你 AI 的 PM，守好你的核心架構，然後——負責任地——擁抱那個感覺。
--
不知道配什麼圖，隨意來一張吧
