Claude Code — 從「如何安全使用」到「如何真正用進工作流」上篇
從 Anthropic Technical Staff — Erik Schluntz 到 Claude Code 創始人 Boris Cherny 的兩個 30 分鐘分享中，學習未來又或是現在進行式的 AI 工作流。
Erik Schluntz 談治理問題，不是在談 prompt 技巧
他認為真正的 vibe coding，不只是大量使用 AI 產出 code，而是你開始不再與程式碼本身維持緊密逐步互動。這件事之所以值得正視，不是因為它現在已經完全成熟，而是因為如果模型能處理的任務長度繼續變長，人類不可能永遠逐行 review。
所以真正的問題不是模型會不會寫，而是：
當你沒有完整看過實作時，你要怎麼建立足夠的信心，知道這段東西可以進 production？
Erik Schluntz，Anthropic 專注於 coding agents 的研究員，也是 Anthropic〈Building Effective Agents〉一文的共同作者之一。最近一支很值得反覆咀嚼的短講，主題是「如何負責任地在 production 做 vibe coding」。他一開始先把「vibe coding」這個常被濫用的詞重新定義了一次。
很多人以為，只要大量使用 Cursor、Copilot 或 Claude 幫忙產生程式碼，就算是在 vibe coding。但他認為這還不夠準確。真正的 vibe coding，更接近 Andrej Karpathy 當初那個帶點戲謔、但很有穿透力的定義，也就是你開始「fully give into the vibes」，開始接受指數級能力成長帶來的新工作方式，甚至某種程度上「忘記 code 的存在」。
這裡最重要的，不是 AI 幫你補了多少 code，而是你是不是還維持著和程式碼本身的緊密逐步互動。如果你還在一個很短的 feedback loop 裡，持續盯著每次產出的細節、頻繁來回修補，那其實還比較像是傳統的 AI 輔助開發，而不是他所說的 vibe coding。
但問題來了，既然這種開發方式這麼容易失控，為什麼還值得認真面對？Erik 的答案很直接，因為 AI 可處理的任務長度正在持續成長。現在它也許只能穩定地完成一小時等級的工作，你還能完整 review；但如果再往下走，變成一天、甚至一週等級的產出，人類就不可能永遠維持「逐行跟上」的工作模式。到那個時候，問題就不是要不要接受 AI 大量寫 code，而是你有沒有能力在不完整閱讀實作的前提下，仍然可靠地驗證成果。
他用了 compiler 當類比，這個比喻非常好。早期工程師也不一定信任 compiler，可能會去看它吐出的 assembly，確認底層是不是符合自己的預期。但這種做法不會永遠成立。當系統複雜到一定程度之後，你只能選擇信任更高層次的抽象，前提是你知道怎麼驗證它的輸出。AI coding 也是一樣。未來不一定代表我們完全不在乎 code，而是我們會把驗證重心，從「逐行檢查 implementation」慢慢轉向「驗收行為、產品結果、穩定性與風險邊界」。他在演講裡有一句很值得記住的話：
Forget that the code exists, but not that the product exists.
這也是整支影片最有力量的地方，它把問題從「模型夠不夠強」拉回到「你如何建立驗證機制」。而且他進一步指出，這其實不是一個全新的問題。CTO 本來就常常要管理自己不完全熟悉的技術領域，PM 也不可能看完每一行程式碼，CEO 更不會精通所有會計細節。但管理世界早就學會了怎麼處理這件事。你可以定義驗收標準、做 spot check、看關鍵指標、針對重要輸出建立可驗證的 checkpoints。換句話說，未來工程師的角色可能不再只是 implementation author，而會越來越像 implementation manager。真正有價值的能力，會慢慢從「手動把每一行寫出來」，轉向「能不能定義問題、提供上下文、設計驗收、控制風險」。
當然，這支分享也沒有天真到忽略最難的部分。Erik 直接承認，目前最難被外部驗證的，不是功能正不正確，而是 tech debt。功能能跑，不代表架構健康；表面驗收通過，不代表系統之後還容易擴充。你可以測試一個功能是否符合需求，但很難只靠輸入輸出去判斷：這段 code 的抽象是不是已經變脆弱、依賴是不是已經糾結、未來加新功能時會不會開始崩。這一點我非常認同，也是現在很多 AI coding 討論最容易故意略過的地方。功能 correctness 和長期 maintainability，本來就是兩件不同的事。
也因此，他提出了一個很實際、而且我覺得相當重要的採用策略：先讓 AI 去處理 codebase 的 leaf nodes，而不是核心主幹。所謂 leaf nodes，就是那些比較末端、比較獨立、沒有太多其他模組依賴它的功能區塊。這類部分就算留下了一些 tech debt，風險通常也比較局部，不容易污染整體架構。相反地，對於 trunk 和 branches，也就是系統的核心抽象、底層結構、之後很多功能都會依賴的主幹部分，仍然需要人類工程師深度理解與主導。這種切法很務實，因為它不是空泛地喊 all-in AI，也不是保守到完全不用，而是明確告訴你應該先從哪裡開始、哪裡絕對不能放手。
影片後半段最實用的部分，是他對「如何真的讓 Claude 成功」的描述。他說了一句很有記憶點的話：Ask not what Claude can do for you, but what you can do for Claude. 這句話的意思是，當你在做這種 AI 驅動開發時，你其實是在扮演 Claude 的產品經理。你不能只是把 AI 當成一個懂你心思的自動機器，丟一句「做這個 feature」就期待結果漂亮。你要像帶一個新加入團隊的工程師那樣，提供它需要的全部上下文，包括 codebase tour、需求背景、規格、限制、應該遵循的既有模式、哪些檔案可能會動、哪些地方不能碰、成功的定義是什麼。Erik 提到，他常常會先花 15 到 20 分鐘蒐集這些資訊，甚至先跟 Claude 來回探索 codebase、一起把計畫講清楚，然後才讓它真正去執行。這種做法聽起來比較慢，但結果反而更快，因為成功率高很多，需要修改的地方也少很多。
他也很明白地說，這並不是完全非技術的人就能安全做到的事。原因不在於模型不夠強，而在於使用者必須有能力問對問題、抓到真正的風險、判斷什麼該驗證、什麼不該放手。這一點很重要，因為現在很多市場敘事會故意把「AI 讓所有人都能輕鬆做 production software」講得太簡單，但實際上，如果你連系統風險在哪裡都不知道，你就很難成為 Claude 的有效產品經理。
最有說服力的，是他分享了一個 Anthropic 內部的案例。他們最近合併了一個大約 22,000 行的 production reinforcement learning code change，而這個改動大量依賴 Claude 參與完成。重點不在於「Claude 自己寫了 22,000 行」，而在於他們是怎麼負責任地做這件事。首先，這不是一個 prompt 就直接 merge，而是中間仍然有數天的人類工作，在定義需求、給上下文、設計系統、引導方向。其次，這次變更大部分集中在 codebase 的 leaf nodes，也就是可以容忍一定 tech debt 的區域。第三，對於那些未來仍然需要 extensibility 的關鍵部分，他們仍然進行了重度人工 review。最後，他們還特別設計了 stress tests 與可驗證的 input/output checkpoints，讓團隊不需要完整讀完底層實作，也能建立對穩定性與正確性的信心。
這個案例最值得注意的，不只是省下了多少工程時間，而是它改變了團隊對軟體成本的感知。當一個原本要兩週的變更，現在只要一天就能做完，而且還能保留足夠信心，你的產品設計和工程決策就會跟著變。很多原本覺得太貴、太麻煩、不值得做的功能，突然變成可以考慮的選項。換句話說，AI coding 的價值不只是幫你省時間，而是改變你對「什麼值得做」的邊界判斷。
如果要把這支影片的觀點收斂成一句話，我會說：未來軟體工程最關鍵的能力，可能不再只是寫出正確實作，而是建立一套能讓你在不逐行閱讀所有實作的前提下，仍然可驗證、可控、可擴展的開發系統。這不代表工程師不重要，反而代表工程師的重要性會轉向更高層的判斷。會寫 code 當然還是重要，但更稀缺的能力將會是：定義問題、設計邊界、給出上下文、判斷風險、管理 tech debt、設計驗收流程，以及在速度和安全之間做出成熟取捨。
這也是我看完這支影片後最大的感受。它不是一篇廉價的「AI 要取代工程師」論述，而是在提醒我們，當 AI 真的開始變成高產能的實作者後，工程師最需要升級的，不是打字速度，而是治理能力。真正的挑戰，不是讓模型多寫一點，而是讓整個系統在寫得更快的同時，還不會失控。