# 策展 · X (Twitter) 🔥🔥🔥🔥

> 作者：傅盛 (@FuSheng_0306) · 平台：X (Twitter) · 日期：2026-05-05

> 原始來源：https://x.com/FuSheng_0306/status/2051283714269970631

## 中文摘要

Anthropic研究員Erik Schluntz強調，真正「Vibe Coding」是忘記程式碼存在，而非逐行審查AI產出。

Anthropic研究員Erik Schluntz在演講《Vibe Coding in Production》中，批判多數工程師誤以為使用Cursor或Copilot寫程式碼就是「Vibe Coding」，實際上大多停留在過渡期開端。他指出AI能力每7個月翻倍，呼籲工程師轉向更高抽象層驗證，並重新定義責任邊界，以因應即將到來的範式轉移。

**Vibe Coding真義**  
Karpathy精準定義「Vibe Coding」為「完全沉浸在vibe中，徹底忘記程式碼的存在」。Schluntz更直指：只要還在逐行審查AI寫的程式碼，就不是Vibe Coding，只不過換了個更貴的IDE。真正Vibe Coding是清楚告訴AI需求，它產出結果，你只驗證結果是否正確，像搭計程車只關心是否到達目的地，而非司機如何握方向盤。多數工程師尚未進入真正範式轉移。

**AI能力成長速度**  
Schluntz提供數據：AI獨立完成任務時長每7個月翻倍。目前穩定執行1小時程式任務，7個月後半天，再7個月一整天，之後一周。當AI一次產出相當於一周工作量的程式碼，逐行審查將使人類成為鏈條中最慢環節。這類似編譯器發展史：早期程式員寫C語言後須檢查生成的組合語言，後來編譯器可靠後，坚持檢查者被淘汰；AI寫程式碼即今日編譯器，但抽象層更高、變化更快。

**驗證抽象層策略**  
演講精華在於「找到你能驗證的抽象層」。CEO看財務指標、CTO看驗收測試、產品經理直接體驗產品，無人查看程式碼。用AI寫程式碼的核心問題不是AI寫得對不對，而是你在哪層能判斷對錯：  
- 能透過跑測試驗證，就不用看程式碼。  
- 能透過體驗產品驗證，就不用跑測試。  
- 能透過使用者資料驗證，就不用親自體驗。  
找到該層，就在那層工作，向上走而非向下鑽。這不是放棄責任，而是重新定義責任邊界。

**程式庫分層實操**  
對創業者最實用策略：將程式庫分為主干架構（核心邏輯、底層介面、大量模組依賴部分）和葉子節點（末端功能、附加元件、無依賴部分）。策略為：  
- 葉子節點讓AI隨意寫，技術債無妨。  
- 主干架構須人工守住。  
在「放手」與「控制」間找到最優解，避免全交AI（找死）或完全不信任（浪費）。Anthropic團隊實例：合併22,000行Claude寫的程式碼，原兩工程師需兩周逐行審查，壓縮至一天。四招包括：需求規劃、限定葉子節點、核心邏輯人工審、建立可驗證檢查點。這是有邊界的授權，而非盲目信任。

**責任轉移與Prompt技巧**  
Schluntz強調：「不要讓AI為程式碼負責，讓工程師為產品負責。」舊模式工程師對程式碼品質負責，新模式工程師對產品結果負責、AI對程式碼實現負責。核心能力從「會寫程式碼」轉為「會清楚說出需求」。具體動作：任務前花15至20分鐘與AI對齊，先讓AI探索專案結構、找相關文件、表述任務理解、共同定計劃，再整合上下文成完整prompt執行，成功率指數級提升。好prompt不是寫得長，而是上下文給足。

**對小團隊衝擊**  
此趨勢對小團隊與創業者衝擊最大。過去軟體開發，技術團隊是最大門檻，好想法缺工程師無法實現；現在門檻快速降低。未來競爭力非「會不會寫程式碼」，而是「能不能清晰定義什麼叫完了」。能說清需求者為未來產品經理，加AI交付者為全棧。每次範式切換，心理模型未更新者將出局，變化不會等任何人。

**立即行動建議**  
Schluntz提出三件事立即可做：  
- 在低風險模組放手，從一葉子節點開始，讓AI執行、你驗收結果。  
- 任務前與AI對齊，先讀懂背景、定計劃再开工。  
- 釐清驗證層，建立快速判斷「做對沒做對」的標準，這比學AI工具更迫切。  
AI能力每7個月翻倍，調整時間有限。推薦觀看原演講影片，此思路適用產品、技術、管理領域。

## 標籤

產業趨勢, IDE, Agent, Anthropic, Cursor, Copilot