Claude Code 的關鍵不是提示詞，而是任務設計與驗證

99% 的 Claude Code 效益來自任務設計與驗證，不是提示詞技巧。

99% 的 Claude Code 效益來自任務設計與驗證，不是提示詞技巧。Boris Cherny 講得很直白：當模型已經能做事，真正拉開差距的是你怎麼定義工作、怎麼給工具、怎麼檢查結果，而不是把指令寫得更花俏。

第一個論點

最有說服力的例子，是他提到把 Claude 放進 Mac 虛擬機裡做程式任務，並且用螢幕截圖逐格比對，直到結果對上為止。這裡的關鍵不是一句神奇 prompt，而是一個能持續迭代的工作流。當模型被賦予真實工具與回饋機制，它的表現會比單純對話高出一個層級。

另一個案例更能說明問題：把 Claude 接上 OpenCV 之後，它能從一組上千種影像演算法裡找出可用方法，甚至做出工程師原本沒預期的結果。這代表模型的能力邊界，已經不是靠「寫得更精準」來解鎖，而是靠「給它正確的任務與上下文」來釋放。過去那種靠字句微調換取進步的空間，正在迅速縮小。

這也解釋了為什麼「prompt engineer」這個職能本身很快就會退潮。當模型變強後，真正稀缺的不是會堆疊關鍵詞的人，而是懂得拆解問題、定義輸出、配置工具的人。說白了，能把工作切成可驗證步驟的人，才是 Claude Code 時代的高槓桿角色。

第二個論點

比起提示詞，驗證才是更大的控制桿。Cherny 強調的一個重點，是很多人最大的錯誤在於沒有替 Claude 設計檢查機制。這在代理式系統裡尤其重要，因為模型不再只是回答問題，而是會真的去執行任務。當它能動手時，問題就不再是「我有沒有寫得夠漂亮」，而是「它有沒有辦法自己知道做對了沒」。

他談到 Claude Desktop 重寫的例子也很具體：不是逐步盯著它每一行怎麼改，而是要求它執行、截圖、比對畫面、再繼續修正。這和傳統軟體工程的思路完全一致，因為工程師本來就依賴測試、日誌、視覺回饋來降低錯誤率。根據 GitHub 的開發實務調查，測試覆蓋與持續驗證一直是交付品質的核心，不是附屬品。

這種方法的影響很直接。你給模型越多可觀測訊號，它越能自我修正；你只給它漂亮句子，它就只能猜。對團隊來說，這意味著投資重心要從「提示模板庫」移到「可重跑的評估流程」。誰能把輸出變成可測量、可回放、可比較，誰就能把 Claude Code 的價值真正吃乾抹淨。

反方可能怎麼說

支持提示詞工程的人也不是沒道理。對新手來說，提示詞確實是最容易上手的槓桿，因為它立刻可見、立刻有回饋。尤其在法務、醫療、財務這種高風險場景，少一句限制、多一個條件，都可能讓輸出偏掉；因此，精準表述依然有價值。

而且，提示詞工程之所以長期受歡迎，還有一個現實原因：它很容易被複製。人們可以直接套模板、貼範例、快速看到改善。相比之下，任務設計與驗證流程需要工程能力、資料管線與評估思維，門檻高很多。對尚未建立 agent workflow 的團隊來說，先從提示詞下手，確實是最便宜的起點。

但這個反方論點只成立在邊緣地帶。對 Claude Code 這種可執行、可回饋、可反覆修正的系統來說，真正限制成果的通常不是措辭，而是流程。若模型不能驗證自己，再好的 prompt 也只是在放大不確定性；若模型能驗證自己，平鋪直敘的指令往往就夠用了。換句話說，提示詞仍有用，但它只是入口，不是核心競爭力。

你能做什麼

如果你是工程師，先別急著再整理一份更長的 prompt 模板，改做三件事：把任務拆成可執行步驟、接上能回饋結果的工具、建立測試或評估標準。若你是 PM 或創辦人，請把需求寫成可驗收的輸出，而不是一段漂亮描述。能被驗證的任務，才值得交給 Claude Code；不能驗證的任務，再華麗的提示詞也只是在賭運氣。