Prompt Engineering 深度指南：Anthropic 團隊拆解從入門到專家的提示工程心法

本文整理自 Anthropic YouTube 頻道 2024 年 9 月發布的圓桌討論。

別再小看模型了，那是你最大的錯誤

先說一個我覺得最重要的結論：如果你現在還在用各種花招去「騙」語言模型，你可能在浪費時間。Anthropic 的提示工程團隊在這場圓桌討論裡反覆強調的核心訊息就是一句話：尊重模型，把它當成一個聰明的合作對象，而不是一個需要被哄騙的笨系統。

這場對話有四位 Anthropic 成員參與。Alex Albert 負責 Anthropic 的開發者關係（Developer Relations），他之前本身就在提示工程團隊工作。David Hershey 主要跟企業客戶合作，幫助他們解決導入語言模型的各種技術問題。Amanda Askell 帶領 Anthropic 的一個微調（fine-tuning）團隊，她的日常工作是讓 Claude 變得更誠實、更友善。Zack Witten 則是 Anthropic 的提示工程師，負責製作提示生成器和各種教育素材，目標是提升整個社會的「環境提示水準」。

四個人的背景橫跨研究、客戶端、產品，代表了不同視角。但他們在一件事上的共識出奇地一致：很多人對 prompt engineering 的理解還停留在「找到一個神奇咒語」的階段，而真正有效的做法，其實就是清楚地溝通。David 在討論中給客戶的建議很直接，他說很多人寫 prompt 的時候像是在照顧一個不太聰明的小東西，覺得需要把什麼都簡化到 Claude 的程度。但如果你直接把 Claude 當聰明人對待，它的表現通常不錯。

我認為這個觀點對於很多開發者來說是一個需要翻轉的認知。我們從早期跟語言模型打交道的經驗裡，養成了各種「繞路」的習慣。比如用角色扮演來「引導」模型、刻意簡化任務描述、避免給太多資訊怕模型「搞混」。這些策略在舊模型上或許有效，但隨著模型能力的大幅提升，它們反而變成了限制。你給模型的資訊越完整、越誠實，它做得越好。

Prompt Engineering 到底是什麼？為什麼叫「工程」？

Prompt engineering 聽起來很潮，但到底在做什麼？Zack 的定義很實在：就是試著讓模型發揮最大能力，跟模型合作完成你自己做不到的事情。核心是清楚的溝通，再加上理解模型的「心理狀態」。聽起來好像在講跟人溝通，但差別在哪？差別在你跟模型之間有一個「重啟按鈕」。

這個重啟按鈕就是「工程」二字的由來。跟人對話不一樣，你不能每次都把對方記憶清除重新來過。但模型可以。你可以在完全乾淨的起點上嘗試不同的方法，每次實驗互不干擾。這種可控的實驗環境，就是 prompt 從單純的「對話」變成「工程」的關鍵。你可以做版本控制、追蹤實驗紀錄、A/B 測試不同寫法，就像寫程式一樣。

David 進一步把 prompt 比喻成一種「模型的程式語言」。他說雖然這個比喻有點過度複雜化，因為最重要的其實就是把任務寫清楚，但如果你稍微從程式設計的角度想一想，你得考慮資料從哪來、你能取得什麼資料、延遲跟資料量之間怎麼取捨。這些系統層面的思考，確實讓 prompt engineering 成為一個獨立的領域，不完全等於軟體工程師或產品經理的工作。

我覺得有意思的是這個狀態：prompt 是寫出來的文字，它看起來像一篇文章，但你對待它的方式更像程式碼。David 說了一句很到位的觀察，大意是說現在我們確實在把寫好的文章當程式碼來管理，而且這是正確的做法。版本控制、實驗追蹤、精確度要求，全部都適用。如果你還在隨手寫完 prompt 就直接用，沒有任何版本紀錄和系統性的測試，那你大概還沒進入 prompt engineering 的核心。

好的提示工程師需要什麼特質？

Amanda 在被問到招募研究型提示工程師時看重什麼的時候，給了一個有趣的回答。她說清楚溝通能力當然重要，但好的寫作能力跟好的提示工程能力之間的關聯性，其實沒有一般人想的那麼高。一開始她也覺得 prompt engineering 就是一種寫作，但後來發現不是。因為實際在做的事情不是寫一篇東西然後收工。她一個 15 分鐘的工作段落裡，可能會送出幾百個 prompt 給模型，不斷地來回、來回、來回。

所以第一個關鍵特質是願意迭代的態度。你得看模型的回應、判斷哪裡被誤解了、然後修正。這個循環要做得又快又有耐心。第二個特質是預判能力，也就是提前想到你的 prompt 可能在什麼狀況下出錯。Amanda 舉了一個例子：假設你的 prompt 是「從資料裡抽出所有名字以 G 開頭的列」，那你就得想到，如果資料裡根本沒有 G 開頭的名字呢？如果傳進來的根本不是資料集呢？如果傳進來的是空字串呢？這些邊界案例（edge cases）都需要提前測試。

David 補充了另一個經常被忽視的面向：理解你的真實使用者會怎麼輸入。他跟企業客戶合作時最常看到的問題是，工程師在寫測試案例的時候，用的都是完美格式化的輸入。但真實使用者根本不按 Shift 鍵，每隔一個字就打錯，完全沒有標點符號。如果你的 prompt 只在理想狀況下測過，遇到真實流量就會崩潰。

還有一個我覺得特別深刻的觀察來自 David。他說，把自己腦子裡知道的事情完整寫下來給模型，是一件極其困難的事。因為你太熟悉自己的任務了，你有大量的隱含假設，而你寫 prompt 的時候不自覺地把這些假設帶了進去。結果就是你寫出來的 prompt 對你自己來說完全合理，但給其他人看根本不知所云。Amanda 也有同感，她說她看過很多人的 prompt，自己根本做不出那個任務，而她是人類。如果一個人類看了你的 prompt 都做不到，你怎麼期待一個在某些方面不如人類的模型做到？

信任模型與迭代的藝術

關於該不該信任模型的回應，Amanda 的態度很明確：她預設不信任。但她不是因此不用模型，而是透過大量測試來建立信任。她的方法論跟傳統機器學習裡「看大量資料」的做法不太一樣。在傳統 ML 裡，因為每個資料點的訊號相對低，所以你需要看很多很多資料才能去除雜訊。但在 prompt engineering 裡，每一次查詢的訊號其實很高。所以如果你有一組精心構造的兩三百個測試 prompt，它們能提供的訊號可能比幾千個隨便寫的測試更多。

這個觀點對實際操作的指導意義很大。與其追求大量但品質參差的測試案例，不如花時間設計少量但能精確覆蓋各種邊界狀況的測試。Amanda 說她如果看了一百個輸出，發現模型表現很一致，而且她知道這些測試涵蓋了各種奇怪情境和邊界案例，那她對這個 prompt 的信心會比看了幾千個鬆散測試更高。

David 從另一個角度補充了這個觀點。他說傳統 ML 的訊號通常是數字，你看的是「預測對了沒」。但語言模型的輸出是大量的文字，這裡面蘊含的資訊遠不止「對或錯」這麼簡單。模型是怎麼推理到答案的？它經歷了什麼步驟？它在哪裡猶豫了？這些都是你能從輸出裡讀到的訊號。不只看結果，還要看過程。這個方法我自己在日常使用 Claude 時也感受很深，很多時候模型最終答案是對的，但推理路徑揭示出一些有趣的問題，反過來幫助你寫出更好的 prompt。

Amanda 更進一步提到，好的 prompting 有時候真的能決定一個實驗的成敗。如果模型在某個任務上的表現差距是 top 5% 和 top 0.1%，那個差距可能就是實驗有沒有結果的分界線。她覺得如果你願意花時間把程式碼寫漂亮，卻不願意在 prompt 上花同等心力，這在邏輯上說不通。因為 prompt 的品質可能直接決定你整個計畫的生死。

完美 Prompt 的迷思：什麼時候該放棄？

這是一個很實際的問題。每個做過 prompt engineering 的人都有這種經驗：你覺得只要再調一下、再改一點，就能達到完美效果。David 用「地平線上的完美 prompt」來形容這種狀態，說他看到很多人就卡在那裡不斷磨、不斷磨。磨 prompt 本身不是壞事，因為你確實會在過程中學到東西。但問題是要知道什麼時候該停下來。

Amanda 的判斷標準很直覺：她會看模型是不是至少「理解」了任務。如果模型的回應顯示它連任務的基本方向都抓不到，那再怎麼改 prompt 大概也沒用。David 的方法是觀察模型的思考過程，看它是不是「在對的郵遞區號裡」。如果每次微調 prompt 都讓模型的思路往完全不同的錯誤方向偏移，那這個任務在當前模型能力下可能就是做不到。

David 分享了一個很生動的例子。他做了一個實驗，把 Claude 接上 Game Boy 模擬器，想讓它玩初代寶可夢紅版。他花了一整個週末寫各種複雜的 prompt 架構。最終的做法是在遊戲畫面上疊一個網格，然後用文字詳細描述網格的每一個區塊，再把它重建成 ASCII 地圖，告訴模型主角永遠在網格的 4,5 位置之類的資訊。慢慢地他能讓模型大致判斷牆壁在哪、角色在哪，雖然偶爾會偏移一點。但到了要辨認 NPC 的時候就徹底卡住了。他把 NPC 放大到 3000 倍，裁切到只剩 NPC，模型還是說不出那是什麼。他形容模型會說「那是一個人，可能戴了帽子」，但實際上根本沒戴帽子。

他從這個經驗得到的教訓是：當你花了一個週末，從完全沒訊號進步到有一點訊號，但離「堪用」還差得很遠的時候，與其再磨四個月，不如等下一代模型。因為四個月後出來的東西，大概也就是下一個模型。這個判斷我覺得非常務實。在 AI 領域，模型能力的進步速度夠快，有時候「等」確實是比「磨」更好的策略。

Amanda 聽了 David 的寶可夢故事之後的反應也很有意思。她說現在遇到模型完全做不到的任務已經越來越罕見了，所以每次發現一個，她都會覺得特別生氣。她的原話大意是：我竟然找到一個你做不到的任務，你怎麼敢？這種半開玩笑的語氣背後，其實反映的是模型能力確實在快速提升，真正的能力天花板在縮小。

Honest Prompting：誠實比角色扮演更有效

角色扮演（role prompting）大概是最廣為人知的 prompt 技巧了。「你是一個資深數據分析師」「假裝你是某某專家」，這類寫法到處都是。但 Amanda 的做法完全相反。她會直接告訴模型自己是誰，包括她的名字，說明自己是 Anthropic 的 AI 研究員，正在做什麼實驗。她認為既然模型已經足夠理解這個世界，對它撒謊根本沒有必要。

她舉了一個很有說服力的例子。假設你要建立一組語言模型的評估資料集（eval dataset），很多人的直覺是寫「我是一個老師，要出考題給學生」。但模型其實知道什麼是語言模型評估，你問它各種 eval 的格式，它都能講得出來，甚至能生成範例。那你為什麼要假裝自己在做一個「只是沾了邊」的不同任務，然後期待它在你真正想做的任務上表現更好？Amanda 用了一個很直接的類比：你不會走到一個員工面前說「你是一個老師，正在幫學生出考題」，你會直接說「幫我建 eval 資料集」。

Zack 有一個小小的反駁，他說用比喻的方式有時候確實有效，不是撒謊，而是提供一個思考框架。他的例子是讓 Claude 判斷圖表的品質，結果用「如果這張圖是高中生作業你會打幾分」這個框架，效果最好。這不是在假裝模型是高中老師，而是用高中作業的評分標準來校準模型的判斷尺度。

David 的回應很到位。他說這種比喻式的 prompt 確實有它的價值，但問題在於大多數人是把角色扮演當捷徑在用。他們找一個「看起來類似」的任務來取代真正的任務，然後模型就不做他們真正想要的事。他說他在企業客戶身上看到太多這種狀況了。比如你在做一個嵌入在產品裡的客服助理，不要只寫「你是一個樂於助人的助理」。你應該告訴模型：你是一個語言模型，你被嵌在這個產品裡面，你是這個產品的支援聊天視窗。完整且精確地描述實際情境，效果永遠比用一個近似的比喻來得好。

Amanda 說她從來沒用過角色扮演這個技巧，即使在舊模型上也沒有。David 推測這可能是從預訓練模型時代遺留下來的直覺。在那個時候，你確實需要把模型「引導」到某個特定的潛在空間（latent space）裡才能得到好結果。但經過 RLHF 之後的模型，這套邏輯已經不太適用了。很多客戶還是帶著「它在網路上看過多少這種東西」的直覺在寫 prompt，而這個直覺被過度套用到了完全不同架構的模型上。

臨時工思維：寫 Prompt 最好的心智模型

Amanda 分享了一個她反覆使用的心智模型，我覺得是整場討論裡最實用的建議之一。她說，想像你從臨時工派遣公司叫了一個人來。這個人很有能力，對你的產業有不少了解，但他對你的公司一無所知。他走進來的第一句話是：「嗨，我被告知你們有個任務要做，跟我說說。」然後你對他說的那些話，基本上就是一個好的 prompt。

這個比喻的精妙之處在於它同時設定了模型的能力水準（聰明但沒有特定脈絡）和你的溝通責任（需要完整交代背景和任務細節）。你不會對這個臨時工說「你是一個高中老師」，你會說「我們要做的事是判斷圖表的品質，我們所說的好圖表不需要完美，不需要去驗證所有數字是否正確，只要軸標籤有標就行。所以你可以用大概高中程度的好圖表標準來判斷。」你可能會用到類似的比喻，但你是在跟一個理解情境的人說話，而不是在假裝他是什麼。

David 從這裡引出了另一個極其實用的技巧。他說他從 Alex 那裡學到的方法，已經帶給無數客戶了。流程是這樣的：客戶說「我的 prompt 不行，你能幫我改嗎？」David 會說「你先跟我描述一下你想讓模型做什麼。」客戶用口語解釋完之後，David 說：「你剛才跟我說的那些話，錄音下來、轉文字、貼到 prompt 裡。那會比你現在寫的 prompt 好。」這聽起來像是偷懶的捷徑，但它之所以有效，正是因為人在口語解釋的時候會自然地包含完整脈絡、直覺判斷標準、和各種潛在注意事項，而這些在精心「雕琢」出來的簡短 prompt 裡反而常常被省略掉。

Amanda 還提到一個很多人忽略的細節：給模型一個「逃生出口」。如果你的 prompt 會遇到各種邊界案例，你應該告訴模型遇到不確定的狀況時該怎麼做。比如加一句「如果碰到很奇怪的情況，你不確定怎麼處理，就輸出一個 unsure 標籤」。這樣你事後可以檢查所有被標記為 unsure 的案例，確認模型沒有在不確定的情況下亂猜。如果你不給這個出口，模型會努力按照你的指示走，就像那個臨時工一樣，即使遇到一張山羊的照片也會認真告訴你「這是一個還不錯的圖表」。

Chain of Thought 推理到底是不是真的在「思考」？

這是一個哲學味很濃的話題，但對實際操作有直接影響。Chain of thought（思維鏈）這個技巧要求模型在給出答案之前先解釋推理過程。它確實有效，幾乎所有人都同意這一點。但它是不是真的在「推理」？

David 的立場很務實。他說過度糾結「這到底是不是推理」反而會失去焦點。不管你怎麼稱呼它，重要的是結果確實變好了。他也發現，如果你不只是叫模型「一步一步想」，而是實際幫它設計推理的結構、跟它一起迭代出一個好的推理流程，效果會更好。至於那到底是不是「真正的推理」，他覺得這問題更適合給哲學家去煩惱。

Zack 提出了一個有趣的驗證方法。如果你拿掉模型寫出的正確推理步驟，換上看起來合理但導向錯誤結論的推理步驟，看模型是不是真的會得出錯誤結論。如果會，那這些推理步驟就不只是佔空間的填充物。他提到 Anthropic 的 Sleeper Agents 論文裡做過類似的實驗。另一個更直接的驗證是：他試過讓模型在回答之前先隨機生成一堆「嗯」「呃」之類的填充詞，佔用一百個 token 的空間，結果對準確度毫無幫助。如果 chain of thought 只是單純提供「更多計算空間讓注意力機制多跑幾次」，那隨便什麼文字都應該有用。但事實不是這樣，這說明推理內容本身確實在起作用。

Alex 也提到一個有趣的觀察：他看過模型在推理步驟裡寫了一個錯誤的中間步驟，但最終答案還是對的。這暗示模型的「推理」跟人類的線性推理不完全一樣，某種程度上最終的正確答案是基於整體上下文的注意力模式，而不是嚴格地「因為步驟 A 所以步驟 B 所以步驟 C」。David 的回應也很妙，他說他也遇過很多人的推理過程是前後矛盾的。所以如果人類都會這樣，用「推理步驟不一致」來否定模型的推理能力好像也說不通。

我的看法是，不管這個過程的本體論地位如何，作為一個開發者，你該知道的就是：讓模型先寫出思考過程再給答案，確實能提升品質。而且如果你花時間設計模型的推理結構，而不是只寫一句「think step by step」了事，提升幅度會更大。這就夠了。

文法和格式到底重不重要？

這個問題的答案可能出乎很多人意料。Zack 說他寫 prompt 時會注意文法和格式，但主要原因不是因為模型需要，而是因為這反映了一種「注意細節」的態度。如果你一直在反覆閱讀和修改你的 prompt，你自然會順手把錯字修掉。他甚至說自己對 prompt 的排版有固執的偏好，就像程式設計師對 tab vs. space 有固執的偏好一樣。

Amanda 則在另一個極端。她的 prompt 經常充滿錯字，而且她一點都不在意。她的理由是模型知道她的意思。她把精力花在概念的精確度和用詞的選擇上，而不是文法的正確性。她認為在迭代過程中，錯字完全不影響效果。不過她也承認，如果是最終要交付的 prompt，稍微檢查一下文法是合理的，因為這是一個很簡單的品質檢查步驟。

David 從技術面提供了一個有趣的解釋，說明為什麼文法這件事在不同模型上的影響不同。在預訓練模型上，一個錯字出現之後，下一個錯字的條件機率會大幅增加。這是因為訓練資料裡錯字確實傾向於成群出現。所以如果你餵一個充滿錯字的 prompt 給預訓練模型，出來的結果幾乎一定也是錯字連篇。但 RLHF 模型不一樣，它已經被訓練成「就算輸入有錯字也要輸出正確格式」的行為模式。所以 Amanda 的錯字連篇的 prompt 在 RLHF 模型上完全沒問題，但如果拿去餵預訓練模型就會出事。

這裡的關鍵啟示是：很多人還在套用對預訓練模型的直覺來理解經過完整後訓練的產品級模型，但這兩者的行為模式已經有很大差異。Zack 甚至提到一個巧妙的反向應用：如果你想生成含有錯字的測試輸入，用預訓練模型來生成反而更有效，因為 RLHF 模型太「禮貌」了，它被嚴格訓練成不打錯字。

企業 Prompt、研究 Prompt、聊天 Prompt 的本質差異

這三種 prompt 看起來都是在跟模型溝通，但設計思路完全不同。Zack 觀察到最大的差異在於範例的使用方式。企業 prompt 裡他會放大量的範例，多到他覺得自己快要倒下為止。因為企業場景追求的是可靠性和一致性，一個 prompt 可能要被使用一百萬次甚至一億次，你需要確保模型在各種輸入下都能產出格式一致、品質穩定的結果。在這種情況下，回覆都差不多其實是好事。

研究場景則完全相反。Amanda 的做法是刻意讓範例跟實際資料不相似。比如如果她的任務是從事實性文件中提取資訊，她可能會用兒童故事當範例。目的是讓模型理解「任務」本身，而不是讓模型模仿範例的風格或內容。如果給的範例太像實際資料，模型就會傾向於給出非常固定化的回應，這在需要多樣性和靈活性的研究場景是個問題。她把這種做法稱為使用「說明性範例」（illustrative examples）而非「具體範例」（concrete examples）。

Amanda 還提到她很久以前就不再使用 few-shot 範例裡「把話放進模型嘴裡」的做法了。也就是說她不會寫一段對話範例，裡面有模型假裝回答過某個問題。她認為這個技巧的直覺來源也是預訓練模型時代，在 RLHF 模型上並不成立。

David 補充了第三種：日常聊天場景。差別在於聊天的時候你可以持續跟模型互動，告訴它哪裡做錯了、重新嘗試。所以 prompt 的完整度要求比較低。但他也提醒，如果你是在 Claude.ai 上花時間磨出一個好 prompt，那個 prompt 拿去企業場景用通常也是好的。兩者只是在「最後一哩」有些分歧。

我覺得這個區分對很多開發者來說非常重要。太多人把在 ChatGPT 或 Claude 聊天介面上的經驗直接搬到產品的 prompt 設計裡，但這兩者的設計邏輯是根本不同的。聊天場景有人在回饋圈裡，產品場景沒有。這個差異決定了你需要在 prompt 裡投入多少心力去覆蓋邊界案例。

提升 Prompt 能力的最佳方式

四位專家各自給出了一個核心建議。Zack 說：讀 prompt，讀模型輸出。每次他看到 Anthropic 內部有人寫了一個好 prompt，他都會仔細閱讀、拆解結構、理解為什麼有效，甚至自己跑一遍看看。這跟學寫程式要讀好的程式碼是同一個邏輯。

Amanda 的建議是把你的 prompt 給別人看，特別是完全不了解你任務背景的人。如果他們看了 prompt 也能理解任務，那這個 prompt 大概就夠清楚了。她還說了一句很實在的話：最終就是一直做、一直做、一直做。那些在 prompting 上做得好的人，通常就是因為他們真心覺得這件事有趣。如果你享受這個過程，進步就是自然的事。她開玩笑說，試試看用 AI 模型取代你所有的朋友、自動化你自己的工作、閒暇時間拿來紅隊測試 AI 模型，如果你覺得這些聽起來很好玩，你大概已經在成為好的提示工程師的路上了。

David 的建議最有挑戰性：找你認為模型做不到的事情，然後試著讓它做到。他說他學到最多的時刻，都是在探索模型能力邊界的時候。如果你只是讓模型寫寫信、回覆郵件這類簡單任務，你根本看不出自己的 prompting 功力好不好，因為結果都差不多。但如果你嘗試讓模型做一些困難的事，比如拆解一個複雜任務讓模型當 agent 來執行，那你就必須深入了解模型的能力邊界在哪，而這個理解本身就是提升最大的地方。即使最終失敗了，你也會學到大量關於模型如何運作的知識。

Alex 分享的是他自己的經驗。他從 jailbreaking 和紅隊測試入門 prompt engineering。因為寫 jailbreak prompt 本質上就是在尋找模型的邊界，理解它對不同措辭和框架的反應。Amanda 對 jailbreak 的分析很精闢，她說它是一種結合了系統理解和社會工程的混合技能。有些 jailbreak 利用的是模型預測文字的方式，有些利用的是推理機制的特性，有些利用的是訓練資料在不同語言上的覆蓋度差異。這不是純粹的「騙」，而是對整個系統的深度理解。

Prompt Engineering 的演化：從 Hack 到 Honest

Zack 提出了一個關於提示工程演化的核心觀察：每次有人發現一個特別有效的 prompting hack，下一步就是想辦法把它訓練到模型裡面。所以最好的 hack 永遠是短命的。他舉了 chain of thought 在數學問題上的例子。以前你必須明確告訴模型「think step by step」才能在數學題上得到好結果，這個提升非常顯著。但 Anthropic 後來直接讓模型在看到數學問題時自動想要逐步推理。所以現在你不需要特別寫這句話了，至少對數學問題來說。Hack 被訓練掉了，但模型也因此變得更好了。

不過 Zack 也指出，模型同時也在解鎖新的能力，而這些新能力因為太新了，還沒有來得及被「訓練進去」。所以 prompt engineering 的前線永遠在移動：舊的技巧被吸收進模型，新的能力需要新的技巧來釋放。

David 的個人轉變很能代表整個趨勢。他說以前他會刻意對模型隱藏複雜度，因為擔心模型搞不定太多資訊。他會嘗試找任務的簡化版本。但現在他越來越傾向於直接把所有資訊和脈絡都給模型，相信它能融合這些資訊完成任務。Amanda 更是把這個做到了極致。她說如果要讓模型學一個新的 prompting 技巧，很多人會開始寫詳細的描述來解釋那個技巧。她的做法是直接把論文丟給模型。就這樣，直接給論文，然後說「讀這篇論文，幫我產生 17 個這個技巧的範例」。模型就做了。因為模型能讀論文，所以你何必自己寫一個簡化版？

David 把這個態度總結得非常好。他常常跟客戶說：尊重模型能做的事情。不要覺得你在照顧一個可愛的小笨蛋，需要把什麼都幼幼班化。直接把它當聰明人對待，給它原始資料、完整論文、詳細脈絡。這個態度轉變，可能是近兩年 prompt engineering 最根本的演進。

未來：模型來引導你，而不是你引導模型

關於 prompt engineering 的未來，四個人的視野出奇地一致。他們都看到了一個方向上的翻轉：不是你越來越厲害地「指揮」模型，而是模型越來越擅長從你腦子裡「提取」你真正想要的東西。

David 從資訊理論的角度看這件事。他說不管模型變得多聰明，你總是需要提供足夠的資訊來「指定」你到底想要什麼。這個需求不會消失。但模型可以更主動地幫你釐清你自己到底想要什麼。他自己已經開始讓 Claude 來「訪問」他了。具體做法是告訴 Claude：你來面試我，問我問題，把我腦子裡的資訊拉出來，然後把這些資訊變成一個 prompt。因為他覺得 prompt engineering 裡最難的部分不是寫 prompt，而是從自己腦子裡挖出正確的資訊、不遺漏任何重要細節。讓模型來做這個挖掘的動作，比自己閉門造車有效得多。

Amanda 把這個願景用了一個很精彩的類比來說明。她說現在跟模型的關係像是你跟臨時工的關係：你比較懂任務，你負責下指令。但未來可能更像是你跟一個設計師的關係：設計師比你更懂設計，你說「幫我做一張海報，要大膽」，設計師聽了之後會反問你一堆問題，因為「大膽」對他來說有七千種可能的意思。他需要從你腦子裡挖出你真正想要什麼。這是一個根本性的關係翻轉。

Amanda 說她自己已經在經歷這種翻轉了。她會讓 Claude 幫她定義新概念。有時候她想要的東西很微妙、很難用現有詞彙精確描述，所以她會跟 Claude 一起「發明」一個概念，然後定義它、用它來溝通。這已經不是「人類指揮模型」的模式了，而是「人類跟模型共同建構理解」的模式。

Zack 做了一個延伸：如果未來的方向是模型來理解你，那 prompting 的核心技能就不再是「教導」，而是「自省」。你需要清楚知道自己到底想要什麼，然後讓模型能夠「讀懂」你。這就像他說的，從「教學」變成「讓自己變得可讀」。

哲學寫作如何成為最好的 Prompt 訓練

整場討論最意外的亮點，是 Amanda 在最後揭示了為什麼她的 prompt 能力這麼強。她說她的秘密武器是哲學寫作訓練。在她學習哲學寫作的過程中，有一個核心要求：你寫的東西必須讓一個「受過教育的外行人」看懂。就是說一個人隨便拿起你的論文，沒有任何背景知識，也能讀懂每一段話。不能有術語障礙、不能有隱含假設、不能有只有圈內人才懂的暗語。你不能對讀者擺架子，不能犧牲準確度，但你必須把極其複雜的概念用極其清楚的方式表達。

Amanda 說她花了很多年練習這種寫法，然後發現它跟 prompting 幾乎是同一件事。你面對的是一個「受過教育的外行人」（模型知道很多，但對你的特定任務一無所知），你需要把你腦子裡複雜的想法，清楚到不能再清楚地傳達給它。不能居高臨下，不能不準確，但必須極度清晰。

她還提到了一個教學經驗。她以前帶學生的時候，學生寫的論文她看不太懂，就會問學生：「你能不能口頭跟我解釋一下你的論點？」學生通常能給出非常清楚連貫的口頭解釋。然後 Amanda 就說：「把你剛才說的寫下來就好了。」如果他們真的這樣做，往往就是一篇好論文。這跟 David 前面說的「把你口頭描述的任務錄音轉文字就是一個好 prompt」完全一樣。

David 聽完之後說了一句，大意是這可能是他聽過最好的「如何寫好 prompt」的總結。Amanda 最後的收尾是：核心就是把你腦子裡的東西外化，分析到你完全理解為止，然後讓任何一個隨機碰到的合理的人都能接收到你的想法。然後，在這個過程中，不要看低對方。

我認為這個洞察的價值遠超 prompt engineering 本身。它本質上講的是溝通的終極技能：能夠把複雜的事情講清楚，同時尊重聽眾的智識水準。不管未來 AI 模型變成什麼樣子，這個能力都是有價值的。

我的觀察：Prompt Engineering 正在經歷一場靜默的典範轉移

聽完整場討論，我最大的感受是 prompt engineering 正在從「找技巧」的時代轉向「練溝通」的時代。早期那些 hack，像是「我會給你 500 美金小費」「你是世界上最好的專家」之類的寫法，它們可能在某個特定模型的特定版本上有效，但隨著模型的進步，這些東西的邊際效益在快速遞減。反而是最基本的東西，也就是清楚地說出你想要什麼、給完整的脈絡、尊重模型的理解能力，這些才是真正持久的技能。

如果你是一個正在使用 AI 的開發者或知識工作者，我會建議你從 Amanda 的「臨時工思維」開始練習。下次寫 prompt 的時候，想像你要把任務交代給一個剛來的聰明人。你會跟他說什麼？你不會說什麼？你會怎麼確認他理解了？然後把那些話寫下來，那就是你的 prompt。如果模型的回應不對，不要急著找什麼「hack」來修，先問自己：我漏了什麼脈絡沒說？有什麼隱含假設我忘了寫出來？這個方法論看起來一點都不酷，但它就是 Anthropic 內部最強的提示工程師們每天在做的事。