---
title: 別問 Claude 能為你做什麼——Anthropic 工程師的 Vibe Coding 進 Production 心法
date: 2026-04-28
tags: [AI, vibe-coding, claude-code, anthropic, software-engineering]
description: Anthropic 把 22,000 行 Claude 寫的程式合進 Production RL Codebase。這不是「AI 很強」的故事，而是一套人類工程師當 PM 的紀律。本文拆解 Erik Schluntz 的演講精華，搭配 METR、DORA、Stack Overflow 的反向證據，給你一份能落地的 vibe coding 守則。
---

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

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

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

這個案例的真正主角不是 Claude，是那群在 PR 合進 main 之前花了好幾天當「Claude 的 Product Manager」的人類工程師。Anthropic 工程師 [Erik Schluntz](https://erikschluntz.com/software/2024/07/30/code-with-ai.html) 在 Code with Claude 大會上把這件事的內情講得很白：vibe coding 進 production 不是放手不管，而是一套**把工程責任搬到 AI 之前**的紀律。

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


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

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

關鍵差別是：你打開 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 對話：

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

這個雙窗口流程的妙處在於——**研究 + 規劃** 跟 **執行** 是兩個不同的認知模式，混在同一個 context 會讓兩者都變糟。Anthropic 自己的 [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) 研究也指出，最有效的 agent 不是 prompt 寫得最聰明的那個，而是**運作環境設計得最好**的那個。


[Dotzlaw Consulting 的整理](https://dotzlaw.com/insights/claude-agents/) 把這個觀察講得很到位：「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 的整理](https://199a.agency/en/article/vibe-coding-and-production-a-survival-manual-for-it-decision-makers/) ，原本人類工程師預估要花兩週逐行寫 + review，最後**壓縮到一天內完成**。

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

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

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

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

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


這呼應了 [SoftwareSeni 引用 DORA 2025 報告](https://www.softwareseni.com/the-case-against-vibe-coding-understanding-craftsmanship-and-long-term-costs/) 的結論：「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 論文](https://arxiv.org/pdf/2512.11922) 在分析 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 整理](https://www.softwareseni.com/the-case-against-vibe-coding-understanding-craftsmanship-and-long-term-costs/) 引用）。Addy Osmani 把這個現象命名為「**[70% Problem](https://addyo.substack.com/p/the-70-problem-hard-truths-about) **」——AI 程式看起來七成對，但要把剩下三成弄到 production-ready，常常比你自己寫還累。

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

- **2025 年 3 月的 Lovable 平台 [CVE-2025-48757](https://medium.com/@nikhilrajiiita/vibe-coding-the-security-debt-bomb-ticking-in-your-sdlc-04c0ca7a6f9a)**：根據安全研究員 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 年研究](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/) 給了這句話一個量化基礎：**AI agent 能獨立完成的任務長度，過去 6 年每 7 個月翻倍一次**。而且 [METR 在 2025 年 7 月的後續分析](https://metr.org/blog/2025-07-14-how-does-time-horizon-vary-across-domains/) 顯示，2024 年起這個 doubling time 還在加速到大約 **每 4 個月**。


具象化一下這個趨勢（資料來源：[AI Digest 對 METR 數據的視覺化整理](https://theaidigest.org/time-horizons) ）：

| 時間點 | 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 描述的那種累積式技術債](https://www.amplifilabs.com/post/the-hidden-risks-of-vibe-coding-and-the-technical-debt-it-leaves-behind) ——**隱性架構、淺層理解、過度耦合、解釋性 debug**。也會變成那 170 個 Lovable 應用——**速度成功了，但用戶資料在外面飄**。

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

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

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

兩個答案決定兩種命運。

---

## 延伸閱讀

- [Erik Schluntz — Replacing my Right Hand with AI](https://erikschluntz.com/software/2024/07/30/code-with-ai.html) ：講者本人骨折期間靠 Claude 寫了上千行 production code 的第一手紀錄。
- [Anthropic — Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) ：Anthropic Applied AI 團隊（Erik Schluntz 等人）對 agent 環境設計的官方指南。
- [METR — Measuring AI Ability to Complete Long Tasks](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/) ：「每 7 個月翻倍」這條曲線的原始研究。
- [METR — How Does Time Horizon Vary Across Domains?](https://metr.org/blog/2025-07-14-how-does-time-horizon-vary-across-domains/) ：跨領域延伸分析，顯示 2024 後加速到每 4 個月。
- [AI Digest — A new Moore's Law for AI agents](https://theaidigest.org/time-horizons) ：把 METR 數據視覺化成可互動的時間軸。
- [Wikipedia — Vibe coding](https://en.wikipedia.org/wiki/Vibe_coding) ：詞彙定義與爭議的中立整理。
- [BBC — 'Vibe coding' named word of the year by Collins Dictionary](https://www.bbc.com/news/articles/cpd2y053nleo) ：2025 年度詞背景。
- [199A Consulting — Vibe coding and production: a survival manual](https://199a.agency/en/article/vibe-coding-and-production-a-survival-manual-for-it-decision-makers/) ：22,000 行案例的決策者觀點解讀。
- [SoftwareSeni — The Case Against Vibe Coding](https://www.softwareseni.com/the-case-against-vibe-coding-understanding-craftsmanship-and-long-term-costs/) ：DORA 2025、Stack Overflow 2025、70% Problem 的整合批判。
- [Addy Osmani — The 70% Problem: Hard Truths About AI-Assisted Coding](https://addyo.substack.com/p/the-70-problem-hard-truths-about) ：「AI 程式七成對」現象的原始命名出處。
- [Amplifi Labs — The Hidden Risks of Vibe Coding](https://www.amplifilabs.com/post/the-hidden-risks-of-vibe-coding-and-the-technical-debt-it-leaves-behind) ：隱性架構、淺層理解等技術債型態的分析。
- [Vibe Coding in Practice — arxiv 2512.11922](https://arxiv.org/pdf/2512.11922) ：學術界對 flow-debt tradeoff 的實證觀察。