Claude Opus 5.5 協作指南：從逐步指揮，走向完整任務交付

每次新模型推出，大家最常問的問題通常是：

這次 Prompt 要怎麼寫，才能發揮模型的最大能力？

但看完 Anthropic 發布的 Getting the most out of Opus 5.5 in Claude and Claude Code 後，我認為真正值得注意的改變，可能不是又多了一套提示技巧。

而是：

我們應該開始把 Claude 當成可以承接完整任務的協作者，而不只是等待下一道指令的問答工具。

Opus 5.5 更擅長在大型程式碼庫中持續完成多步驟工作，也能進行時間更長的自主操作。

✨ 根據 Anthropic 的測試，它在預設 medium effort 下處理代理式程式設計任務，表現已可達到或超過 Opus 5 的 high effort，同時使用更少步驟與 Token。

💡 這代表我們與它協作的方式，也應該跟著改變。

一句話總結

過去，我們習慣告訴 AI「下一步要做什麼」。

使用 Opus 5.5 時，更重要的是一次交代清楚：

• 最後要完成什麼
• 什麼狀態才算完成
• 哪些限制不能違反
• 哪些情況可以自行判斷
• 哪些情況必須停下來詢問

💡 不是把控制權全部交出去，而是把任務邊界設計得更清楚。

一、不要只交代下一步，直接交付完整任務

過去使用 AI 寫程式時，我們可能習慣這樣做：

先幫我找出所有使用舊版 PaymentClient 的地方。

等它回答後，再繼續：

接著幫我修改第一個 Endpoint。

然後再要求：

請幫我補測試。

這種做法的問題不是不能完成，而是每個階段的目標都被切斷了。

模型只知道眼前要做什麼，卻不知道整項工作的終點。因此，它可能完成了單一檔案，卻沒有清除舊依賴；可能修改了程式碼，卻不知道測試通過才算結束。

對 Opus 5.5，更合適的交付方式會是：

請將所有付款 Endpoint 從舊版 PaymentClient 遷移到新版客戶端。

完成條件：
- 所有 Endpoint 都已使用新版客戶端
- 舊版 PaymentClient 已沒有任何參照
- 不再需要的舊程式碼已移除
- 相關測試已更新並全部通過
- 最後整理修改摘要、測試結果與仍需人工確認的事項

除非遇到無法判斷的測試失敗、可能破壞相容性的行為，
或需要刪除資料，否則請持續進行，不必逐步等待我確認。

💡 這裡真正有用的不是字數，而是「完成條件」。

當模型知道終點，它才有辦法自行判斷：

• 還有哪些檔案沒有處理
• 是否需要補測試
• 舊依賴能不能刪除
• 目前是真的完成，還是只完成其中一部分

二、刪掉「請仔細思考」，把篇幅留給成功標準

很多人的提示範本裡可能都有這些句子：

請仔細思考。
請一步一步推理。
回答前請深入分析。

💡 Opus 5.5 會在每次回覆前思考，並自行決定需要投入多少思考。

✨ Anthropic 在內部聊天產品的測試中發現，移除要求模型「仔細思考」的指示，可以讓回覆更快開始，同時沒有觀察到明顯的品質下降。

因此，對 Opus 5.5 而言，與其重複要求它思考，不如把 Prompt 空間留給真正影響結果的資訊：

• 這項工作的目的
• 可使用的資料來源
• 必須遵守的限制
• 不可改變的既有行為
• 可以接受的取捨
• 如何驗證結果

同樣地，也不必要求模型完整揭露內部推理過程。若想了解判斷依據，可以直接要求：

請用簡短、可檢查的方式說明你的選擇，
並列出支持這項結論的程式碼、測試結果或資料來源。

我們需要的不是模型所有的思考內容，而是足以驗證結論的證據。

三、自主工作不代表可以沒有邊界

當模型能夠連續工作更久，新的問題也會出現：

哪些事情可以讓它自行決定，哪些事情必須回來詢問？

如果沒有說清楚，模型可能在每一個小問題上停下來，讓所謂的自主工作變成頻繁問答；也可能走到另一個極端，在不該自行決定的地方繼續執行。

因此，長時間任務最好同時定義「繼續條件」與「停止條件」。

以下是依照 Anthropic 原文原則整理的自訂範例，可依專案風險與工作方式調整：

遇到一般實作選擇、可逆修改或測試失敗時，
請先自行調查原因並嘗試修正。

遇到以下情況時必須停下來詢問：
- 需要刪除正式資料
- 需要執行 force push
- 需要修改目前儲存庫以外的檔案
- 需求存在會明顯改變產品行為的歧義
- 缺少只有使用者才能提供的權限或資訊

這種規則比「有問題就問我」更實用。

因為它明確區分了：

• 模型應該自己解決的問題
• 需要由人做決策的問題
• 可能造成不可逆影響的操作

四、長時間任務需要外部化的工作清單

在 Claude Code 的長時間工作中，對話可能填滿上下文，較早的內容會被摘要。Anthropic 建議將工作清單保存在檔案中，讓進度記錄不只留在對話裡。

因此，重要任務不要只依賴對話紀錄。

以下是本文延伸的清單格式；原文的簡單範例是要求模型在 TASKS.md 維護待辦、完成時打勾，並補上新發現：

請將工作拆解記錄在 TASKS.md。

每完成一項就更新狀態，並記錄：
- 修改了什麼
- 如何驗證
- 是否仍有風險
- 哪些項目需要人工決定

除非所有必要項目均已完成或明確標示阻礙，
否則不要將任務回報為完成。

這份清單的價值不只是幫助模型記憶。

它同時也是使用者的觀察介面：不需要從冗長對話中猜測進度，就能快速確認哪些項目完成、哪些尚未處理，以及模型是否偏離原始目標。

五、不要用「看起來不要太像 AI」這類抽象要求

✨ Anthropic 指出，沒有設計方向時，Opus 5.5 會回到少數常見的預設風格；只說「不要做出常見的 AI 生成風格」，往往只是讓模型改用另一種常見風格。

如果只說：

請設計得有質感一點。
不要有罐頭 AI 味。

模型並不知道你實際不喜歡的是什麼，往往只會從一種預設風格換成另一種預設風格。

更有效的方式，是直接指出具體限制：

請製作個人作品網站。

不要使用：
- 米白色或奶油色背景
- 標題中的斜體裝飾文字
- 01、02、03 形式的段落編號
- 等寬字標籤
- 膠囊形按鈕

先檢視模型實際採用的設計，再依不喜歡的風格擴充排除清單。

另外，本文建議在完成後檢查手機與桌面版，確認文字沒有溢出或重疊。

這個原則不只適用於設計。

撰寫文章、產生文件、製作簡報或進行程式碼審查時，都應該把「不要太普通」、「請更專業」這類抽象評價，轉換成可以觀察與驗證的條件。

六、模型說完成，不等於工作已經完成

Opus 5.5 會更清楚地回報它做了什麼、發現了什麼，以及還需要使用者提供什麼。

但完成摘要仍然只是模型的報告，不是完成證明。

Anthropic 建議長任務結束後，先讀取模型正在等待你處理的事項，例如待決定的問題或待批准的變更，再閱讀其他摘要。也可以在專案指引中指定固定的回報格式。

面對程式碼任務，至少應確認：

• 修改範圍是否符合需求
• 測試是否真的執行，而不是只說「應該會通過」
• 是否留下未處理的錯誤或警告
• 是否意外修改任務以外的檔案
• 是否有未經驗證的假設
• 是否存在需要人工決定的事項

以上驗收項目是本文的延伸整理；原文另建議研究與分析任務明確標示無法找到或無法查證的內容，並說明查找範圍。例如可補上：

請標示任何無法確認的內容，並說明你查閱過哪些來源。

程式碼審查也不應只要求「幫我看看有沒有問題」，可以改成：

請只列出足以阻擋合併的實際問題。

每個問題都必須包含：
- 檔案與行號
- 觸發問題的具體情境
- 預期行為與實際行為
- 可以重現或驗證問題的方法

若沒有符合條件的問題，請直接說明沒有發現，
不要為了湊數列出純風格偏好。

模型的分析能力越強，我們越應該要求它提供可驗證的結果，而不是只接受看起來合理的解釋。

七、互動時再開啟速度模式

Anthropic 建議在 Claude Code 中，若是需要逐則閱讀回覆、頻繁來回的工作，可使用 /fast。這項功能在原文發布時為研究預覽；Fast mode 仍使用 Opus，以優先速度的設定提供相同能力，但需要額外用量，且每 Token 費用較高。

相對地，長時間自主執行的任務不一定能從每次回覆加速中獲益；若人不必等待每一則回覆，優先考慮整體延遲是否重要，以及額外成本是否值得。這是依照互動方式做出的使用建議。

因此可以簡單區分：

• 即時除錯、共同討論、反覆調整：速度帶來的價值較高
• 長時間遷移、全面稽核、自主任務：若不需逐則等待回覆，通常不必只為了單次回覆速度開啟 /fast
• 一般任務：先使用預設設定，再依實際品質、延遲與成本調整

另須區分 /fast 與 effort：前者改變回覆速度與費用，後者控制思考深度。Anthropic 建議 Opus 5.5 從預設的 medium effort 開始，使用自己的任務評估各級設定；xhigh 與 max 應保留給已實測出品質提升的工作。

一份可以重複使用的任務範本

綜合以上原則，我會把交付給 Opus 5.5 的任務整理成以下結構：

任務目標：
說明最後要完成的工作成果。

背景：
提供模型無法從現有檔案或對話中得知的資訊。

完成條件：
- 條件一
- 條件二
- 條件三

限制：
- 不可改變的行為
- 不可修改的範圍
- 必須遵守的規範

工作方式：
請先調查相關內容，再自行規劃並完成工作。
過程中持續更新工作清單，不必逐步等待確認。
在 Claude Code 任務執行期間，若想到補充事項，可直接追加指示，不必重啟整項任務。

必須停下來詢問的情況：
- 需要執行不可逆操作
- 需求存在重大歧義
- 缺少必要權限或資訊

驗證方式：
- 執行哪些測試或檢查
- 提供哪些可供人工確認的證據
- 標出無法確認的內容與查核過的來源

最後回報：
- 優先列出需要我決定或批准的事項
- 完成了什麼
- 如何驗證
- 尚未完成或存在風險的事項
- 仍需要使用者決定的問題

這份範本真正重要的地方，不是欄位名稱。

而是它把工作的目標、邊界、完成條件與驗證方式放在同一個上下文中，讓模型不需要一路猜測我們到底想要什麼。

結論

Opus 5.5 帶來的最大改變，可能不是我們終於找到了一句更厲害的 Prompt。

而是模型逐漸能夠承接更完整的工作，因此使用者的責任也從「告訴它下一步做什麼」，轉變成「把整項工作設計清楚」。

我們需要練習的不再只是提示技巧，而是：

• 定義清楚的完成狀態
• 提供真正必要的上下文
• 設定自主行動的邊界
• 把進度放進可檢查的工作清單
• 用測試與證據驗證結果
• 在需要人類判斷的地方保留決策權

模型能力越強，越不需要用大量指令控制每一步。

但這不代表我們可以少想一點。

恰恰相反，我們需要把更多注意力放在真正重要的事情上：

我們到底希望完成什麼，以及什麼證據能證明它真的完成了。

參考

💭 Claude Platform 官方指南（含 effort 校準）