Claude Code 創建者 Boris Cherny 勸誡開發者刪除 80% 的系統提示

每六個月，刪除你的 Claude.md、你的 skills 和你的 hooks。

這是 Boris Cherny——Claude Code 之父給產品使用者們的建議。

在 YC 於 7 月 28 日新發布的訪談影片《Boris Cherny: We Cut 80% of Claude Code’s Prompt》中，Boris 熱情呼籲所有從事 AI 產品的人，都應勇敢地為自己的新產品按下刪除鍵，大刀闊斧地刪除系統的提示詞、工具和 harness 代碼。

△

你應該把整個系統提示詞全刪掉，然後一行一行加回來，看看每一行到底有什麼影響。

這個觀點背後的概念是消融實驗（ablation study），該概念貫穿了 Boris Cherny 的最新訪談，旨在在控制其他條件不變的前提下，移除、替換或關閉一個模組，以比較性能、穩定性、效率或成本的變化。

在訪談中，Boris 毫不驕傲地聲稱：實際上對於 Opus 5，我們真心建議大家試試把這些東西全部刪除，因為模型已經不需要了。

儘管最近的風波……用戶也可以聲稱，「實際上對於 Claude，真心建議把它刪掉，因為我們已經不需要了。」（x）

除了「大膽刪除」，Boris 在訪談中還透露了更多關於自己對產品設計、模型使用和編程學習的價值性思考——

本文觀點出自訪談影片，閱讀重點如下：1、Boris 的產品迭代策略：少一點預判，多去做測試 2、「產品懸餘」：同一時期內，模型能力總會超出產品邊界 3、「解縛」：讓模型執行更困難的任務，獨立工作更長的時間 4、頂尖 Claude 用戶是如何使用 AI 的？ 5、給編程學習者的 3 個建議

模型是一種活體生物，它有自己的性格

Today, the code in Claude Code Harness is almost entirely limited to security, permissions, and static analysis.

7月24日，Anthropic 發布了關於 Claude 5 上下文工程的最新規則，其中針對 Opus 5、Fable 5 等新模型，Claude Code 的 system prompt 被大幅精簡，刪除了超過 80% 的原有指令。

Refer to the QbitAI article: >>> Claude Code 刪除 80% 提示詞，Opus 5 反手加回去

針對此次變化，Boris 在訪談中分享了自己的產品迭代策略：你不要去猜模型需要什麼指令，因為你根本猜不對。你能做的就是一行行刪除、測試，然後找到模型反覆卡住的地方。

你得把模型當作一個活的生物，一種更有機的東西。每一代模型的行為都不同，性格也略有差異，你得花時間去了解它，然後根據此調整 harness。

△

因此，這對 Boris 而言更偏向「經驗性」，需以科學的方式對待：無預設地嘗試，觀察結果，迭代，重複。

而在這個不斷推倒重來的世界裡，Eval 也未必能穩定使用。儘管它確實比 harness 和 prompt 更耐用，但當前模型進化太快，很多時候一套評測會很快被刷到滿分。因此需要觀察模型到底在哪裡不斷掙扎，然後設計新的 Eval。

一種思維：懸餘、解縛

在訪談中，Boris 分享了一個稱為 “Product Overhang” 的概念，他認為這是一種對他做產品很有幫助的思考方式。

Overhang，意思是懸餘。

大模型以不連續的跳躍式速度躍遷，而產品集成卻以連續的增量式節奏推進。這導致模型所具備的能力總會超出目前產品所能釋放的邊界。

Boris舉了一個例子：2024 年底 Sonnet 3.5 剛推出時，這個模型已經能夠一次性寫出整個文件的代碼了。但當時的編程產品 Copilot、Cursor 早期版還在做補全代碼這樣的瑣事。

擁有完整終端權限的 Claude Code 在一定程度上彌補了這種差距。這也是 Boris 提出的第二個概念「Unhobbling」，解縛，拿掉限制。

△

他分享了 Anthropic 內部的一個案例：有人嘗試將 Opus 5 連接到 OpenCV（全球最大的開源電腦視覺庫），結果發現模型能夠自行繪製人物肖像和動物風景，而在此前他們從未訓練過模型進行繪畫。

這就是「模型激發」（model elicitation），在不改變模型權重的前提下，透過提示詞、上下文、工具或產品形態的設計，讓模型表現出它本已具備、但此前未被調用的能力。

儘管這裡或許還存在著疑問：如何歸因？究竟是模型被激發出了原本就具備的能力，還是模型因為「腳手架」設計而學會了新的技能？

不過這或許並不重要，不管怎樣，Boris 毫不懷疑此間存有巨大的商業機會：

我不是說所有初創公司都能抓住，但我知道有人正在思考這些問題，這裡真的有巨大的機會，能從模型身上激發出那些令人驚嘆、有趣且有商業價值的行為。

為此，Boris 提出了三條他本人的模型「解縛」方法。

第一，給模型比你想像中更難做的任務。描述清楚目標、邊界和退出條件，然後就放手。

第二，多做實驗。允許模型做一些沒有明確商業目的但有趣的嘗試，「給自己自由去玩模型、去做有創意的事」。

第三，讓模型自行驗證成果。如今的重點已不再是「prompt engineering」，問題在於：「當你給 Claude 分配了一個非常困難的任務後，你怎麼讓它在過程中就去驗證自己所做的工作？」

Boris 認為第三點可能是如今大家做得最不盡如人意的一件事。因為如果模型不能自我驗證任務，它就無法長時間獨立運行。

△

他自己的例子或許能給大家啟發：

Boris：「好吧，我要你做的是——把 Electron 應用重寫成 Swift。我要你在 Mac 虛擬機裡運行 Electron 應用，截圖，然後逐像素對比，跟 Swift 版本比，沒做完就不要停。」主持人：這就是你的 prompt？ Boris：這就是我的 prompt。主持人：跑了多久？ Boris：還在跑。主持人：什麼時候開始的？ Boris：已經跑了兩個多星期了，大概 14 天、15 天吧…… Claude 還決定做直播，它做的事情是在內部建了一個 Slack 頻道，然後每隔幾分鐘就發一張進度截圖。