別問 Claude 能為你做什麼——Anthropic 工程師的 Vibe Coding 進 Production 心法

Anthropic 把一個 22,000 行的修改合進了他們生產環境的強化學習 codebase，而且絕大多數是 Claude 寫的。

如果你第一個反應是「哇，AI 終於可以替代工程師了」——你抓錯重點了。

這個案例的真正主角不是 Claude，是那群在 PR 合進 main 之前花了好幾天當「Claude 的 Product Manager」的人類工程師。Anthropic 工程師 Erik Schluntz 在 Code with Claude 大會上把這件事的內情講得很白：vibe coding 進 production 不是放手不管，而是一套把工程責任搬到 AI 之前的紀律。

這篇文章我想把演講精華 + 業界數據 + 真實風險案例編織起來，讓你知道：什麼時候 vibe code、什麼時候絕對不要、以及那 15 分鐘的事前準備到底在準備什麼。

vibe-coding-22000-行PR的真相

從「跟 Claude 聊天」變成「替 Claude 做 PM」

先把名詞講清楚。Vibe coding 不是「用 AI 寫程式」的同義詞。它是 OpenAI 創始成員、前 Tesla AI 總監 Andrej Karpathy 在 2025 年 2 月提出的概念——「完全沉浸在 vibe 裡，擁抱指數成長，忘記程式碼存在」。這條推文當時衝破 450 萬次瀏覽，Collins 詞典直接把它選為 2025 年度詞，連維基百科都單獨開了條目。

關鍵差別是：你打開 Cursor 或 Claude Code、看著 AI 寫一段就 review 一段、覺得不對就改——那叫 AI-assisted coding，不叫 vibe coding。Vibe coding 的精髓是你不再逐行讀程式碼，你只看「跑起來對不對」「結果合不合預期」。

Schluntz 講出整場演講最容易被忽略的金句：

「Ask not what Claude can do for you, but what you can do for Claude.」

仿甘迺迪那句名言，他想表達的是：在 vibe coding 時，你的角色是 PM，不是客戶。你不是在「使喚」Claude，你是在「設定條件讓 Claude 能成功」。

這個重新定位很重要。多數人和 AI 的互動模式是：

「幫我做這個 feature」→ AI 給一個半對的東西 → 「不對，再試一次」→ 再給一個半對 → 來回十次 → 放棄

Schluntz 說，想像一下今天有個新人來上班，第一天你只丟一句「實作這個功能」就走人，任何人類都不可能成功。新人需要 codebase 導覽、需要知道實際 requirement、需要理解約束條件。Claude 也一樣。差別只在於——這個新人不會主動問你，所以收集 context 並餵給它，是你的責任。

那關鍵的 15-20 分鐘準備時間

Schluntz 自爆他的工作流：在讓 Claude 開始寫之前，他會花 15 到 20 分鐘收集 context 進一個 prompt，然後才讓它跑。

但這 15 分鐘不是他坐著手寫 prompt。他是用另一個對話視窗跟 Claude 對話：

讓 Claude 探索 codebase、找出相關檔案
一起討論實作 plan、需要改哪些檔案、要遵循哪些既有 pattern
把整個對話的精華濃縮成一個 artifact（plan 文件 / spec 文件）
開新 context，把 artifact 餵進去，說「執行這個 plan」

這個雙窗口流程的妙處在於——研究 + 規劃 跟執行是兩個不同的認知模式，混在同一個 context 會讓兩者都變糟。Anthropic 自己的 Building Effective Agents 研究也指出，最有效的 agent 不是 prompt 寫得最聰明的那個，而是運作環境設計得最好的那個。

vibe-coding-人類PM與AI執行者

Dotzlaw Consulting 的整理把這個觀察講得很到位：「The biggest challenge in autonomous agents is designing the environment around the agent」。Vibe coding 的功夫不在 prompt，在你給 Claude 的世界。

實作 checklist：

新開一個對話做研究——不要在執行視窗裡邊開邊寫
讓 Claude 先 grep / glob / read，再讓它寫東西
規劃階段就決定 要動哪些檔案、不要動哪些
列出 既有 pattern 的範例檔案（「請參考 src/foo/bar.ts 的寫法」）
把規劃輸出成一份 plan.md，新 context 開始執行
給 Claude 一個 可執行的驗證手段（test command、stress test、output diff）

22,000 行 PR 的四個原則拆解

回到開頭那個 22,000 行案例。這是 Anthropic 內部 production 強化學習 codebase 的修改，根據 199A Consulting 的整理，原本人類工程師預估要花兩週逐行寫 + review，最後壓縮到一天內完成。

但這一天不是按一個按鈕的一天。Schluntz 列了四個原則，每個都對應一種風險控管：

原則一：集中在 Leaf Nodes（葉節點），不要動核心架構

這個策略的精神是：把可能的技術債圈在不會擴散的地方。

Codebase 結構像一棵樹。Root / 中間節點是核心架構、共用工具、抽象層——任何改動都會被千百個地方依賴，未來還要持續演進。Leaf nodes 是那些業務邏輯的末端、特定 task 的實作、不太會被別處引用的程式。

Anthropic 那個 22,000 行的 PR 大部分集中在 leaf nodes，因為這些區段「就算累積一些技術債也沒關係」——它們未來不會頻繁變動，就算之後要重寫也不會牽連別處。重要、要 extensible、會被反覆修改的部分，他們堅持做 heavy human review。

vibe-coding-葉節點與核心架構

這呼應了 SoftwareSeni 引用 DORA 2025 報告的結論：「AI is an amplifier of your development practices. Good processes get better, bad processes get worse.」AI 是放大器——好流程會被放大，壞流程也會。如果你 vibe code 的是核心抽象層，債會以指數速度爆炸；如果是葉節點，債就被框在角落。

原則二：設計人類可驗證的 Inputs / Outputs

PR 那麼大，怎麼確認對不對？答案是——不要用「讀懂程式碼」來確認。

Anthropic 團隊把整個系統設計成 inputs 和 outputs 都是人類可以一眼看懂的。這意味著：

系統邊界清楚（不是隨便插一塊邏輯到中間層）
輸入輸出有明確的 schema 和語意
可以靠黑箱測試來驗證行為，不用打開盒子看內部

這跟傳統 code review 的思維完全反過來。傳統 review 假設「我必須理解你寫的每一行才能批准」；Schluntz 的方法是「我設計一個邊界，讓我不需要讀內部就能判斷對錯」。

原則三：精心設計 Stress Tests 來保證穩定性

RL codebase 最怕的不是「跑一次對」，是「跑一萬次有沒有崩」。所以團隊先設計好壓力測試，再讓 Claude 寫實作——長時間、大量 input 的反覆驗證，遠比讀 22,000 行有效。

這個原則跟學術界對 vibe coding 的觀察方向一致——一篇 2025 年 12 月發表的 arxiv 論文在分析 flow-debt tradeoff 時指出，沒有驗證機制把關的 vibe coding 會在中期累積結構性技術債。換句話說，stress test 不只是品質保證手段，是讓 vibe code 進 production 在長期可持續的關鍵。

原則四：對重要部分做 Heavy Human Review

最後一個原則最直白：該讀的還是要讀。系統中那些「會被反覆修改、需要 extensible」的核心區塊，團隊還是逐行 review。

換句話說——這四個原則合起來形成一個選擇性審查策略（以下對照表是我整理 Schluntz 演講四原則的歸納，非原始投影片）：

區段類型	處理方式
Leaf nodes（不會頻繁變動）	Vibe code，靠驗證測試把關
Core architecture（要 extensible）	Heavy human review，逐行讀
系統邊界（I/O）	預先設計成人類可驗證
全域行為	Stress tests 跑長時間

這不是「全 vibe」也不是「全人寫」，而是根據風險動態分配審查資源。

Vibe Coding 不是給所有人的：Schluntz 的明確警告

Schluntz 在演講中講了一句很多人不愛聽的話——「我不認為完全非技術背景的人應該嘗試從零打造一個 business」。

理由很簡單：他們沒辦法問對的問題，他們做不了 Claude 的 PM，所以注定失敗。

業界的數據站在他這邊。Stack Overflow 2025 年開發者調查顯示，66% 的開發者最大的挫折是「AI 解答幾乎對但不完全對」，45% 表示 debug AI 程式比自己寫還慢，只有 16% 體驗到「巨大的生產力提升」（這個數字也被 SoftwareSeni 整理引用）。Addy Osmani 把這個現象命名為「**70% Problem **」——AI 程式看起來七成對，但要把剩下三成弄到 production-ready，常常比你自己寫還累。

而對非技術用戶來說，這 70% 是致命的。因為他們連「哪 30% 沒對」都看不出來：

2025 年 3 月的 Lovable 平台 CVE-2025-48757：根據安全研究員 Matt Palmer 的抽樣，他掃過的 1645 個 Lovable 應用裡，有 170 個（約 10.3%）存在 RLS（Row-Level Security）漏洞，未驗證攻擊者可直接讀寫資料庫。受影響欄位包括姓名、地址、債務金額、API key、付款資訊。
CVE-2025-54135（Cursor）：透過已連接的 MCP server 在開發者機器上執行任意指令。
CVE-2025-55284（Claude Code）：透過 prompt injection 經 DNS request 外洩資料。

這些漏洞不是 AI 寫程式特有的，但vibe coding 把它們大規模化——當一個開發者忽略某個安全 default，他寫一個有漏洞的 app；當一個 vibe coding 平台忽略 default，整個生態系的每個 app 都繼承這個漏洞。

所以 Schluntz 的「不適合所有人」不是菁英主義，是現實的能力門檻：

你能不能看出 Claude 提的 plan 在哪裡會破？
你能不能設計出有意義的 stress test？
你能不能判斷 leaf node 跟 core architecture 的界線？
你能不能讀懂 stack trace 並且 challenge AI 的解法？

如果上面四題你有任何一題答不出來——你還沒有準備好把 vibe code 推進 production。

別忽略指數：今天可以選擇，明年沒得選

演講的結尾，Schluntz 拋出最具殺傷力的一句：「Remember the exponential.」

METR（Model Evaluation & Threat Research）的 2025 年研究給了這句話一個量化基礎：AI agent 能獨立完成的任務長度，過去 6 年每 7 個月翻倍一次。而且 METR 在 2025 年 7 月的後續分析顯示，2024 年起這個 doubling time 還在加速到大約 每 4 個月。

vibe-coding-指數曲線警告

具象化一下這個趨勢（資料來源：AI Digest 對 METR 數據的視覺化整理）：

時間點	AI agent 能獨立完成的任務長度（50% 成功率）
2022（ChatGPT 發表）	30 秒
2025 中	約 1 小時
2026（現在）	超過 14 小時（前沿模型）
2027（線性外推）	1 個工作日（8 小時）
2028（線性外推）	1 個工作週（40 小時）
2029（線性外推）	1 個工作月（167 小時）

要先打個預防針：METR 自己也提醒，這條曲線是少數 benchmark 上的測量結果，外推到「真實工程任務」時誤差會很大，把它當成方向感而非保證值。但即便打對折——AI 一次能產出幾天的工作量，這個門檻已經夠近了。

Schluntz 的警告是這樣的：今天你還有奢侈說「我堅持每行程式都自己讀」，因為 Claude 一次能寫的還在你 review 得完的範圍。但一兩年後，當它一次產出的 diff 行數遠超你每天能讀的速度，review 工時 / 產出工時的比值會超過 1——你會變成整個團隊的瓶頸。

這不是叫你放棄 review，是叫你重新設計 review 的方式。從「逐行讀」改成「設計可驗證邊界 + stress test + 選擇性 deep review」——也就是 Anthropic 那 22,000 行 PR 的四原則。

我的實作 Checklist：把演講變成肌肉記憶

把整場演講壓縮成一張可以貼在桌上的 checklist：

動工前（5–20 分鐘）

開新對話讓 Claude 探索 codebase，不要急著寫 code
列出 要動的檔案 / 不要動的檔案
找出 2–3 個既有 pattern 範例檔案 給 Claude 模仿
寫一份 plan.md，包含 requirement、constraint、step
確認這個任務在 leaf node 還是 core architecture

執行時

新開 context，把 plan.md 餵進去
讓 Claude 跑，不要每三行就插嘴
同步準備 驗證手段（unit test、stress test、output diff）

驗收時

不靠讀程式碼就能判斷對錯——靠 I/O、靠測試、靠 stress
對 core architecture 的部分逐行 review
對 leaf node 的部分驗證行為，允許一些技術債

長期心法

別問 Claude 能為你做什麼，問你能為 Claude 做什麼
把自己當 PM，不是當客戶
記得指數曲線——你今天在練的不是 prompt，是未來幾年的工作模式

結語：vibe 的反義詞不是「嚴謹」，是「無責任」

整篇文章其實只在講一件事：vibe coding 跟工程紀律不是對立的。

被罵的 vibe coding 是那種把生意建立在「連 30% 沒對的部分都看不出來」的脆弱之上的版本。它會變成 Amplifi Labs 描述的那種累積式技術債 ——隱性架構、淺層理解、過度耦合、解釋性 debug。也會變成那 170 個 Lovable 應用——速度成功了，但用戶資料在外面飄。

而 Anthropic 22,000 行 PR 的版本是另一種——人類做 PM、leaf nodes 收斂風險、輸出設計成可驗證、stress test 把關穩定性、核心區段 heavy review。它沒有比較不 vibe，但它對得起 production 兩個字。

所以下次有人問你「vibe coding 進 prod 安不安全」，你可以反問他：

「你打算當 Claude 的 PM，還是當 Claude 的客戶？」

兩個答案決定兩種命運。

搜尋此網誌

BASHCAT