Y COMBINATOR · STARTUP SCHOOL 2026

Claude Code 的產品,不是把 prompt 寫得更長

Boris Cherny 描述的轉折不只是模型更強:當 agent 可以長時間處理任務,產品要做的是把真實問題交給它,並持續刪除那些已經不必要的控制層。

原始發表日期:2026 年 7 月 27 日 · 35 分 51 秒

PART 1 · 產品能力會過期

當模型更可靠,舊的保護層不一定還該留下

訪談一開始談到新模型的長時間運行能力與提示注入風險。這些是受訪者對模型能力的描述,不是本頁對安全性的獨立驗證;但它帶出一個產品問題:過去為了補償模型限制而堆上的指令、框架與手動步驟,是否仍然必要?

Claude Code 團隊的經驗是,系統提示一度很長,後來刪除了大部分內容。這不是「prompt 不重要」,而是產品要持續測試哪些規則真的改善輸出,哪些只是上一代模型留下的拐杖。

先列假設
這個限制是在保護什麼失敗模式?
再做對照
新模型下移除它,品質或安全是否真的變差?
留下原因
只保留仍能被觀察到價值的控制。

PART 2 · agent 的難題是任務,不是演示

把模型放進真實的長任務,才會看見產品缺口

Boris Cherny 將長時間運行視為新模型的重要能力:不只是回答一題,而是可以持續處理更大的工作。這類能力的價值不在 demo 跑了多久,而在任務是否有明確目標、可用工具、可回復的狀態,以及能被人檢查的交付物。

因此,「讓 agent 多跑幾天」不是一條產品策略。任務若沒有邊界,長時間只是放大偏離;若沒有驗證點,完成只是系統自己宣布完成。產品設計必須同時定義 autonomy 的範圍和人類何時介入。

任務規格
清楚定義成果、限制與可使用的工具。
中途檢查
在高代價或不可逆步驟前留下審核點。
可驗證交付
用測試、差異或可閱讀成果驗證,而不是只信文字回報。

PART 3 · 刪除比堆疊更難

系統 prompt 是產品決策的壓縮檔

影片談到「按下刪除」:當產品看到模型可以自己做到某件事,就該重新檢查原本寫死的提示、流程與護欄。這不是鼓勵任意移除限制;相反地,每次刪除都要回答:原本的失敗模式是否已消失,還是只是不容易被看見?

這個做法也適用於一般軟體團隊。流程增加通常有很好的當下理由,但很少有人負責在能力、使用情境或風險改變後把它收回。把「定期刪除」變成實驗,才能讓產品不只累積複雜度。

保留證據
知道每條規則當初解的是什麼問題。
小範圍移除
用受控場景比較品質、成本與風險。
寫下新邊界
刪除後仍需讓使用者知道系統能做什麼、不能做什麼。

PART 4 · 人類仍然要學什麼

當執行能力加速,判斷題不會自動消失

訪談最後轉向學生與創作者:模型能處理更多工作,並不表示人類只要等待答案。使用者仍要選擇值得解的問題、提供足夠好的上下文、辨識輸出是否真的符合目的,並為採取行動負責。

這也是評估 AI 產品最容易被忽略的地方。效率提升可以讓一個團隊探索更多路徑,但它不能替團隊決定哪條路值得走。越能自動執行的系統,越需要在目標、權限與驗證上說得清楚。

選題
把稀缺的注意力放在真正重要、可驗證的問題。
品味
分辨看似合理的輸出與真正有用的成果。
責任
在系統影響他人或不可逆時,保留人類決策與紀錄。

「模型變強時,產品的工作不只是加上更多指令。它也要知道什麼時候能把舊指令拿掉。

此句為依影片中系統提示、模型能力與產品設計討論整理的閱讀引導,並非 Boris Cherny 的逐字引言。

面對能長時間運行的 agent,
你會先檢查哪一件事?

選一個焦點,看看它如何把能力主張轉成產品判斷。

你的產品檢查焦點

回到原始對談,聽完整脈絡

本頁整理的是一條閱讀路徑;原始 Y Combinator 影片保留 Boris Cherny 對 Claude Code、提示、agent 與學習的完整說法。

閱讀完整文章 →