轉譯：Claude Opus 4.5 的提示詞（Prompting）實戰指南 為了幫助大家更好地駕馭新模型，我們的研究與應用團隊經過大量內部測試和“折騰”，總結了一份針對Claude Opus 4.5 的提示詞（Prompting）實戰指南。 以下是我們目前摸索出的“獨家秘籍”，教你如何榨乾它的潛能，獲得最佳效果： 1. 用好effort 參數，想多聰明你說了算 新的effort（努力值）參數簡直是神器。它能讓你大體控制Claude 在輸出內容時消耗多少算力。這就好比你有了一個調節旋鈕：你可以通過它，在“智能程度”與“成本/響應速度”之間做一個權衡（向左轉省錢快出結果，向右轉費點時間但智商爆表）。 這個參數對所有類型的Token （AI 處理文字的最小單位，相當於單字或漢字） 都有效，包括模型的思考過程、正式回應以及工具呼叫。 2. 別太兇，溫柔點：調整工具觸發率 你可能會發現工具觸發的頻率改變了。這是因為Opus 4.5 對系統提示詞（System Prompts）的反應較為靈敏。 以前為了防止它「偷懶」不呼叫工具（Undertriggering，即觸發不足），你的舊提示詞可能使用過非常激進或嚴厲的語言。但在新版本裡，反而會導致它變得太敏感，動不動就亂用工具（Overtriggering，即觸發過度）。 所以，是時候把語氣放緩了。將原來那種「CRITICAL: You MUST use this tool」（嚴重警告：你必須使用此工具）的命令，改成平和的「Use this tool when...」（當出現…情況時，使用此工具）就可以了。 3. 防止「加戲」：避免過度設計 Opus 4.5 有時會有點“想太多”，導致過度設計（Overengineer，即把簡單問題複雜化），比如憑空增加不必要的文件或者搞一堆複雜的抽象層。 要解決這個問題，你得在提示詞裡把話說明白，比如加上：「Only make changes that are directly requested. Keep solutions simple and focused.」（只修改我明確要求的部分。保持解決方案簡潔、聚焦。） 4. 拒絕「雲寫程式」：強制它先讀後寫 在探索程式碼庫時，Opus 4.5 有時會表現得比較保守。 如果你發現它沒看代碼就直接瞎提修改建議，請直接給它下死命令：“ALWAYS read and understand relevant files before proposing edits. Do not speculate about code you have not inspected.”（在提出修改建議之前，必須總是先閱讀並理解相關文件。絕對不要猜測相關文件。 5. 眼神更好了：視覺能力升級 Opus 4.5 的視覺能力有了顯著提升，處理影像和擷取資料的能力更強了，尤其是在同時處理多張圖片的時候。 對於那些資訊量巨大、密密麻麻的圖片（Dense Images），教你個絕招：給它配備一個裁剪工具，讓它能像用放大鏡一樣「放大」並聚焦於局部細節。在我們的測試評估中，這一招能穩定提升它的表現。 如果你想快速套用上述所有技巧，將你的應用程式無縫遷移到Opus 4.5，可以直接使用我們製作的這個Claude Code 遷移外掛： https://t.co/VcKqNIWp2A 就連我們自己，每天也都還在挖掘這個新模型的潛力！如果你有什麼獨門秘籍，歡迎在下方分享。
正在載入線程內容
正在從 X 取得原始推文，整理成清爽的閱讀畫面。
通常只需幾秒鐘，請稍候。