你的 AI 程式助手，其實有一半的指令都在說廢話？Boris Cherny：我們砍掉了 Claude Code 80% 的 Prompt
你有沒有想過，當你打開 Claude Code 或任何 AI 程式助理，劈哩啪啦地貼上一大段精心設計的指令時，你的 AI 夥伴真正讀進去的到底有多少？我們都有一種直覺：指令寫得越詳細，AI 的表現就越好；把需求描述得越精確，程式碼就寫得越完美。於是，我們像對待一個初來乍到的實習生一樣，為 AI 鉅細靡遺地交代背景、限制、格式，甚至連語氣都要規定好。
但這一切，在 Y Combinator 最新一集邀請的來賓 Boris Cherny 面前，彷彿是一場大型集體迷思。
在一支名為「We Cut 80% of Claude Code's Prompt」的影片中，Cherny 拋出了一個震撼彈：他們團隊將 Claude Code 的系統提示詞（System Prompt）砍掉了整整八成，而效能反而提升了。 這不是什麼實驗室的極端案例，而是真實專案中的一記當頭棒喝。如果連 Claude 這種頂級模型都不需要我們喋喋不休的指令，那我們大部分寫的提示詞，到底是在幫 AI，還是在拖累它？
準備好翻轉你的 AI 使用手冊了嗎？我們把 Cherny 這場極具啟發性的實戰分享，拆解成六個你必須知道的核心要點，帶你重新審視「少即是多」這四個字在 AI 時代的真實意義。
一、為什麼我們總是不自覺地寫出「千字廢片」？
如果你把提示詞工程（Prompt Engineering）當作一門「給 AI 寫作文」的藝術，那你可能已經走上了歪路。Boris Cherny 的團隊在分析 Claude Code 的運作時，發現一個令人哭笑不得的現象：我們人類非常擅長把重點藏在大量無意義的詞彙裡。
為什麼會這樣？這其實是我們與生俱來的溝通習慣——我們習慣用「鋪陳」來代替「溝通」。在與人類同事講話時，我們會先說明背景：「你聽過那個專案嗎？就是上次那個客戶提出要加會員系統的。因為老闆說下個月要上線，所以我們現在很趕……」但在 AI 面前，這種鋪陳完全沒有意義，甚至有害。
Cherny 的理念是：AI 不像人類，它不需要情緒鋪墊，也不需要人際關係的潤滑。 當我們寫下長長的提示詞，其中夾雜著我們對專案的擔憂、對未來擴充的想像，以及各種「以防萬一」的條件時，這些文字在模型眼中是具有同等權重的噪音。
具體來說，團隊發現原本的 Prompt 裡充斥著大量的「公司願景」和「軟體開發原則」。例如，它會寫道：「這是一個重視用戶體驗的產品，我們追求的是一流的工程品質，並且要考慮未來的可擴充性。」Cherny 直言，這些內容 95% 都是廢話，模型無法將「一流的品質」轉化為具體的 API 呼叫，也無法將「考慮未來擴充」變成合理的抽象化設計。
這些模糊的形容詞，只會讓模型在生成程式碼時，陷入無窮無盡的「試探性」行為——因為它不確定「卓越」到底要做到哪個程度，它只能東拼西湊地塞入一堆設計模式，結果就是程式碼變得又臭又長、效能低落，而且難以維護。
「我們給 AI 的指示，往往摻雜了我們人類無限的自我與誤解。AI 不想要你的願景，它想要的是你的規格。」
這正是大部分開發者的痛點：我們太習慣把人當作受眾，以至於忘了我們正在與一個統計模型對話。這個對話的本質不是「情感理解」，而是「指令解碼」。
二、削減 80% 的祕密：從「論文」變成「一行訂單」
那 Boris Cherny 到底是怎麼砍掉那 80% 的內容？他把這個過程形容為「從論文變成一行訂單」。這是一個非常生動的比喻——當你走進一家咖啡店，你不會跟店員解釋咖啡豆的產地、烘焙的溫度和萃取的比例，你只會說：「一杯美式，大杯，去冰。」
在原本的 Claude Code 設定中，團隊的 Prompt 長達數千字，內容涵蓋了軟體開發的「道德哲學」。但 Cherny 發現，真正有價值的資訊只佔了 20%。那 20% 到底是什麼？
是「約束條件」，而不是「行為準則」。
白話文來說，AI 不需要知道它「應該怎麼做」——因為模型本來就會根據訓練資料做出最「合理」的反應。AI 需要知道的是「在什麼情況下不能做什麼」。Cherny 團隊將 Prompt 精簡為最純粹的「限制條件」。
舉例來說，原本的 Prompt 會花費大量篇幅描述「當使用者要求修改資料庫時，請務必確認 SQL 語法沒有注入風險，並且要考慮到交易的一致性與隔離級別，以確保系統在併發的情況下……」；精簡後，他們只保留了一句話：「永遠使用帶參數的 SQL 查詢。」
看懂了嗎？前者讓 AI 陷入決策焦慮，後者給了 AI 一個絕對的命令。 AI 不會因為你的解釋而變得更聰明，但絕對會因為你的命令而變得更專注。這就像一台導航系統，當你輸入的是「帶我去一個風景優美的路上」，它會當機；但當你輸入「走國道三號，避開收費站」，它就能完美執行。
團隊透過這種方式，將原本陪伴 Claude Code 的「長篇小說」縮減至幾行具體的規則。Cherny 甚至開玩笑說，如果提示詞裡頭出現任何「形容詞」，你就應該懷疑自己在浪費錢。 形容詞代表主觀判斷，而主觀判斷是需要模型去猜測的巨大成本。
三、AI 的「工作記憶」比你想像的更珍貴
這大概是整場分享中最核心的技術洞見：砍掉 80% 的 Prompt，其實是在幫 AI 節省算力與記憶體，讓它把資源花在真正重要的任務上。
我們常常忽略，大型語言模型在執行程式碼生成任務時，它們的「注意力窗口」（Context Window）是有限的。無論是 128K 還是 200K tokens，看起來雖然很大，但這些空間既是你的「工作空間」，也是「記憶空間」。當你把 80% 的空間塞滿了宏觀的企業願景與開發守則時，留給「當前檔案」與「相對應的程式碼片段」的位置自然就變小了。
這導致了什麼後果？AI 為了配合你的長篇大論，只能選擇性地「遺忘」某些程式碼細節，結果就產生了幻覺（Hallucination）。 你可能遇過這種狀況：你明明貼了完整的專案結構給 AI，它卻忘了你使用的是 TypeScript，然後生成了一段 JavaScript 程式碼；或者，它忘了你使用的套件版本，而寫了一個過時的 API 指令。這不是因為 AI 笨，而是因為你的系統提示詞佔據了太多資源，擠壓到了模型讀取實際程式碼的空間。
Boris Cherny 在影片中提到，他們發現效能提升的關鍵並非模型本身變強了，而是模型「終於看得起」自己正在處理的檔案了。 當你把那些虛無縹緲的「守則」全部移開，模型終於可以把所有的注意力放在「檔案結構」與「現有程式碼風格」上。這就像是一個焦慮的員工，終於不用再背誦公司的文化手冊，可以專心做自己的專案了一樣。
因此，精簡 Prompt 不只是為了省錢、省時間，更是一種**「資源重分配」的戰略**。我們要確保 AI 的寶貴注意力，時刻聚焦在「你想解決的問題」上，而不是「你的公司有多棒」上面。
四、少即是多：為什麼「限制」比「賦權」更能激發 AI 潛力？
這一觀點可能與直覺相反。在人類管理學中，我們提倡賦權、提倡願景領導。但在 AI 領域，「過度的自由」等同於「災難」。 Cherny 的團隊發現，當他們把 Prompt 中那些「你可以自由地……」或「請發揮創意……」等字眼刪除後，AI 生成的程式碼品質反而穩定了。
為什麼？因為 AI 的本質是一個**「概率預測機器」**。當你叫它「自由發揮」，它就會在巨大的機率空間中不斷探索，試圖找到一個「人類會喜歡」的答案，這導致了結果極度不穩定——有時它會給你一個驚為天人的設計模式，但有時它會給你一個無法運作的結構。
但當你告訴它「僅限使用標準函式庫」或「不得使用第三方套件」時，AI 的搜索空間被急遽壓縮，它反而能在這個框架內找出最佳的解法。限制，是 AI 創造力的催化劑。
影片中提到一個實際案例：他們過去總會在 Prompt 中鼓勵 AI「嘗試寫出最先進、最現代化的 React 元件」。結果，AI 每天都試圖引入不同的狀態管理函式庫，導致專案依賴膨脹，程式碼風格五花八門。後來，團隊直接在 Prompt 裡寫下「禁止額外安裝套件，除非我明確要求」，瞬間，AI 回歸了本質，開始用手寫的 Hooks 與簡單的 State 解決問題，程式碼不僅變短了，執行速度也變快了。
這告訴我們一個殘酷的事實：AI 的「自主性」是我們賦予的，而我們的責任是為它畫好圍籬。 不要害怕給 AI 設定嚴格的限制；相反地，沒有邊界的 AI 只會讓你感受到失控的恐懼。
五、這 80% 的削減，究竟省下了哪些成本？
既然砍掉 80% 的 Prompt 能讓效能提升，那實際上省下的是什麼？我們簡單地算一筆帳。
1. 錢
每一千個 Token（無論是輸入還是輸出）都是需要付費的。如果你的系統提示詞高達 2,000 Token，而每個使用者每個月會觸發 1,000 次 API 呼叫，那光是「重複輸入那些廢話」的成本就是非常可觀的。Cherny 團隊重構後，總體 Token 消耗量下降了 40% 到 50%，這是成本的直接下降。
2. 時間
更少的 Token 意味著更快的響應速度。在即時互動的程式碼生成中，延遲是致命的。精簡掉的 80% Prompt，讓 AI 的平均回應時間縮短了 1.5 到 2 秒。這在人類體感上或許不明顯，但在自動化測試與 CI/CD 流程中，卻能積少成多，顯著加快迭代速度。
3. 除錯成本
長 Prompt 導致的「上下文遺忘」往往會產生看似合理但實則錯誤的程式碼。開發者如果沒有仔細檢查，就會將這些錯誤視為基礎，然後在錯誤的基礎上繼續建構。精簡 Prompt 後，程式碼的錯誤率顯著下降，這才是最大的成本節省——因為 AI 工程師的時間，遠比 GPU 的算力要昂貴得多。
也許會有人問：「系統提示詞通常只需要設定一次，又不是每次使用者互動都會重傳？」但在現代 AI 架構中，為了確保狀態的連貫性，這些 Prompt 往往會被隱式地挾帶在每一次的 API 請求之中，或者耗費大量的記憶體來維持資料流。所以，不管你用不用它，它都在那裡默默消耗你的資源。
六、這是極端案例嗎？我們能從中複製什麼經驗？
Boris Cherny 的經驗當然是基於特定的團隊與專案，但這套邏輯適用於任何使用 AI 輔助開發的人。我們可以從中提煉出三個通用的準則：
第一，刪除所有形容詞。 這是啟動精簡計畫的第一步。檢查你的 Prompt，把「優秀」、「穩健」、「完善」、「高效」這些詞全部刪掉，改成明確的技術指標。不要說「效能要好」，請說「API 響應時間必須少於 200 毫秒」。
第二，為 AI 建立「任務邊界」。 將 AI 從「顧問」的角色轉變為「高級打字員」。告訴它專注在「這個儲存庫」的檔案，不要試圖去理解你整個公司的商業版圖。畫出範圍，禁止它跳出範圍。
第三，將 Prompt 當作一段會執行的程式碼來看待。 對它進行版本控制，對它進行測試。如果你新加了一句話，必須確保這句話能讓輸出結果更好，否則就應該刪掉它。Cherny 的團隊建立了評估測試集，用相同的輸入去測試精簡前後的 Prompt，量化「效能」，而不是憑感覺。持續刪除，直到結果變壞為止——這就是所謂的「提示詞極限測試」。
七、深度對比：精簡前後，到底有多大差異？
為了讓你更直觀地感受這個震撼的轉變，我們將 Boris Cherny 團隊的經驗整理成一個對照表：
| 比較維度 | 精簡前（長篇 Prompt） | 精簡後（核心指令） |
|---|---|---|
| Prompt 長度 | 數千 Token，包含企業願景、開發哲學與模糊形容詞 | 約 20% 篇幅，僅包含具體限制條件與技術規格 |
| AI 回應品質 | 程式碼風格不穩，容易過度設計，時常幻覺 | 程式碼結構簡潔，貼近現有專案風格，符合需求 |
| 上下文記憶 | 模型注意力被分散，忽略關鍵的檔案結構與變數名稱 | 專注於當前任務，準確記住目標語法與限制 |
| 執行效率 | 生成時間較長，Token 消耗巨大，API 成本高 | 回應延遲降低，Token 使用量降低約 40-50% |
| 錯誤率 | 容易產生邏輯不通的虛構 API 或錯誤的套件用法 | 錯誤率顯著下降，減少了人工 Code Review 的負擔 |
| 開發者心態 | 擔心 AI 不理解需求，不停補充背景 | 信任 AI 的基礎能力，只提供核心邊界，放手讓它做 |
這個表格背後的核心差異，不是「量」的縮減，而是「質」的飛躍。當我們簡化了輸入，模型輸出的熵值（混亂程度）也跟著大幅下降。 我們得到的是一個更忠實、更可靠的執行人，而不是一個囉嗦且神經質的初級工程師。
八、未來的 AI 程式設計，將在「少即是多」的哲學下重構
Boris Cherny 的這次分享，帶給我們的衝擊絕對不只是「要怎麼寫 Prompt」這種微觀技巧，而是一場觀念上的解放。我們正處於一個從「把 AI 當外掛」到「把 AI 當基建」的關鍵轉捩點。我們正在服務於 AI，而不是 AI 服務於我們。
過去我們犧牲自己的時間去「遷就」模型，寫出巨細靡遺的規格書；現在，既然模型的水準已經大幅提升，我們更應該讓模型回歸本質：程式設計就是語言的藝術，而語言的極致，在於精準的省略。
未來的電價、算力成本、工程師工時，都會迫使我們更極致地去思考「每一句 Prompt 的投資報酬率」。AI 這個工具，已經從「需要被餵食大量資料才能運作的龐然大物」，進化成「一個只需三言兩語就能心領神會的高手」。
或許，我們最該刪除的，不是那 80% 的文字，而是我們心中「AI 很笨，所以要講清楚」的那個刻板印象。Boris Cherny 透露了未來工程師的核心技能：在混沌中發現秩序的洞察力，以及在必要的時刻，懂得讓 AI 自己摸索的勇氣。
給科技愛好者的最終省思：現在，請打開你的 Code Editor，看看你藏在角落裡的那套「精心設計」的 System Prompt。你敢不敢，按下「全選」與「Delete」，然後用一句話把任務重新定義？你認為，在未來的 AI 世界，我們究竟是因為「做得多」而成功，還是因為「想得少」而進化？這是一個值得我們所有人用行動來回答的問題。