摘要

本篇作者 Addy Osmani 是一位軟體工程師，目前是 Anthropic 技術團隊成員，先前長期在 Google 負責開發者體驗。他在 claude.dev 部落格分享了如何充分發揮 Opus 5.5 的能力，尤其是執行複雜、耗時的長任務。整篇重點可以濃縮成這段：

給 Opus 5.5 一個完整的任務，說清楚目標、完成標準，以及遇到什麼狀況要停下來問你。它每次回覆前都會先思考，不需要再寫「請仔細、逐步思考」這類指令。

本篇為原文的節錄翻譯加上個人心得整理。原文請見：Getting the most out of Opus 5.5 in Claude and Claude Code

Opus 5.5 模型介紹

Opus 5.5 是 Anthropic 今年 9 月下旬推出的最新模型，也是他們目前最強的模型。詳細介紹請參考官方資訊：

https://www.anthropic.com/claude-opus-5-5#introduction

使用 Opus 5.5 之前，先試試這三件事

1. 把整個任務交給 Opus 5.5，並且說清楚怎樣才算任務完成，以及遇到哪些情況時，你希望模型停下來詢問你。
2. Opus 5.5 在每次回覆前會先進行思考，所以 Prompt 中不用再寫「請你仔細思考」。
3. 當執行完一個長時間的任務後，仔細閱讀模型需要你確認或提供的資訊。

1. 如何向模型提問

1.1 先定義任務完成標準

在一則訊息中告訴模型要做的任務，定義怎樣才算任務完成，例如測試全部通過。

Migrate the payment endpoints from the old client to the new one.
Done means: every endpoint uses the new client, the old client is deleted, and the test suite passes.
Stop and ask me only if a test fails for a reason you can't explain.

把所有付款相關的 API 端點，從舊版用戶端遷移到新版用戶端。
完成標準：
- 所有端點都改用新版用戶端。
- 舊版用戶端已刪除。
- 整套測試全部通過。
只有當測試失敗，而且你無法解釋失敗原因時，才停下來問我。

寫 Prompt 時，可以根據這個架構去思考

• The whole task：把整個任務交代清楚。
• The finish line：明確定義怎樣才算完成。
• When to stop：說明遇到什麼情況，要暫停並詢問你。

為什麼這對 Opus 5.5 重要

Opus 5.5 比 Opus 5 更能持續處理耗時、包含多個環節的複雜任務。相較於先前的 Opus 模型，它最大的進步在於需要多個步驟才能完成的工作，例如在大型程式碼儲存庫中完成一項修改，並一路修正到測試通過。早期測試者曾讓它連續執行數小時的程式開發任務，過程中幾乎不需要監督。只要完成標準夠清楚，它就知道什麼時候算做完。

1.2 停止告訴它要認真思考

在提示詞或儲存的指令中，刪除「仔細思考」、「一步一步思考」及其他類似的句子。

為什麼這對 Opus 5.5 重要

Opus 5.5 每次回覆前都會先思考，並自行決定要花多少心力。你不需要特別要求它思考。在產品測試中，刪除「仔細思考」這句指令後，模型能更快開始回覆，而且沒有觀察到明顯的品質下降。

1.3 任務進行中，可以直接補充指示

如果任務進行時想到要補充什麼，可以直接輸入追加指令。

為什麼這對 Opus 5.5 重要

任務現在會跑得更久，中斷重來的成本也更高，所以與其停下來重下指令，不如直接在途中補充。

如何進行

在 Claude Code 執行任務時，直接輸入要補充的訊息並送出即可。

1.4 在進行設計任務時，明確地告知不想要哪些設計風格

當請 AI 製作網頁、App 或其他作品時，列出你希望它避免的慣用設計風格。

為什麼這對 Opus 5.5 重要

沒有明確的設計方向時，Opus 5.5 會退回幾種預設風格。像「避免平時常見的設計」這種籠統的指令，通常只會讓它從一種預設風格換成另一種。直接列出要避免的具體設計模式，設計效果會更好。

Build a personal website with placeholder content.
Don't use a cream or off-white background, italic accent words in headings, numbered "01 / 02 / 03" section labels, monospace labels, or pill-shaped buttons.

建立一個個人網站，先用 placeholder 內容填充。
請避免以下設計：
- 奶油色或米白色背景。
- 在標題中用斜體強調個別字詞。
- 用「01 / 02 / 03」這類編號標示區塊。
- 使用等寬字體的標籤。
- 膠囊形按鈕。

2. 如何引導 Claude Code 執行複雜長時間的任務

2.1 定義任務繼續執行與停止規則

告訴模型什麼狀況下需要繼續執行，以及什麼狀況下該停止並詢問確認，把這個規則寫到 CLAUDE.md 檔案裡面。

When a step doesn't need my input, keep going. Put status notes in the same message as your next action.
Stop and ask only when you can't continue without me, or before anything destructive: deleting data, force-pushing, or changing anything outside this repository.

如果某個步驟不需要我的意見，就繼續執行。回報進度時，請在同一則訊息中接著採取下一步行動。
只有在缺少我的協助就無法繼續，或即將進行以下操作時，才停下來詢問我：刪除資料、強制推送（force push），或更動這個程式碼儲存庫以外的任何內容。

2.2 將大型任務拆分給多個子代理

進行大型程式碼庫的稽核、遷移或審查時，請 Opus 5.5 將工作拆分給多個子代理（subagents），並檢查各自的執行結果。

Audit every service in services/ for the retry bug in the linked issue.
Give each service to its own subagent. When a subagent reports back, check its evidence before you accept it.
Finish with one table: service, affected yes or no, and the evidence.

檢查 `services/` 目錄下的每個服務，確認是否存在連結中的 issue 所描述的重試（retry）錯誤。

將每個服務分配給一個專屬的子代理。子代理回報後，先查核它提供的證據，再採納其結論。

最後用一張表格彙整：**服務名稱、是否受影響（是／否），以及判斷依據。**

為什麼這對 Opus 5.5 重要

早期測試者曾讓 Opus 5.5 協調多個子代理，同時處理耗時的稽核與遷移工作，過程中幾乎不需要人工監督。

2.3 將所有任務整理並保存到一份文件檔案

對於需要較長時間的任務，請 Opus 5.5 將任務清單保存在檔案中，並隨著執行進度持續更新。之後直接查看檔案，就能掌握進度，不必往回翻閱對話紀錄。在 TASKS.md 中維護一份待辦清單。每完成一項就打勾，並加入過程中新發現的任務。

為什麼這對 Opus 5.5 重要

現在任務執行時間更長，可能填滿上下文視窗，Claude Code 隨後會將較早的對話壓縮成摘要。保存在檔案中的清單不會因這個過程而消失，也能讓你一眼看出哪些已完成、哪些尚未完成。

3. 檢查執行任務後的結果

3.1 先看有哪些結果需要你決定和提供額外資訊

當長時間執行的任務結束後，先查看 Claude 有哪些事情還在等你處理，例如尚未決定的事項，或需要你核准的變更。接著再閱讀其餘的工作摘要。

若要調整摘要格式，可以在 CLAUDE.md 中寫：「每次執行結束時，以三個標題整理結果：待我處理、已做的變更、發現的事項。」

為什麼這對 Opus 5.5 重要

Opus 5.5 比 Opus 5 更能清楚說明工作情況。它會在進度回報與最終摘要中，用淺白的語言交代做了什麼、發現了什麼，以及需要你處理什麼。

3.2 請模型檢查程式碼

在人工進行 PR Review 之前，先請 Opus 5.5 審查程式碼差異（diff）或 PR。

Review the diff on this branch against main.
List only problems you'd block the merge for. For each one, give the file and line, why it's wrong, and how to show it fails.

審查目前分支相對於 main 的程式碼差異。
只列出嚴重到應阻止合併的問題。針對每個問題，請提供：
- 檔案名稱與行號。
- 為什麼這是問題。
- 如何重現錯誤，證明它確實會出問題。

為什麼這對 Opus 5.5 重要

一位早期測試者表示，Opus 5.5 在最低思考強度下，比採用高思考強度的 Opus 5 找出更多錯誤，而且誤報更少。它也會用淺白的語言解釋修改內容，讓 PR 說明更容易審閱。

3.3 請模型標示無法確認的內容

進行研究與分析時，請它明確說明哪些資料沒有找到，或哪些內容無法查證。在 Prompt 中加上：「標示所有無法確認的內容，並說明你查找過哪些來源。」適用於 Claude 的研究報告及 Claude Code。

為什麼這對 Opus 5.5 重要

「我找不到這項資料」本身也是值得注意的資訊。明確要求它回報，就能讓這些資訊更容易被看見。

4. 執行速度

4.1 當你需要一來一往、逐次等待回覆時，開啟快速模式

如果你的工作方式是「看完一則回覆，再輸入下一個要求」，可以在 Claude Code 中輸入 /fast 開啟快速模式，縮短等待時間。

為什麼這對 Opus 5.5 重要

Opus 5.5 推出時，快速模式也以研究預覽的形式開放。使用的仍是同一個模型，但回覆文字會更快出現。你需要先啟用「額外用量」（Extra usage），而且每個 token 的費用比標準模式更高。

5. 對照我目前的做法：哪些地方可以改？

讀完整篇，算是給了我一些不同的使用 Claude Code 技巧，未來可以嘗試進行實驗優化。

5.1 在 Prompt 中指定這次開發任務要通過的驗收標準

在開發時，我是把驗收標準獨立成一份文件，讓 Claude Code 做完之後再去裡面對照。讀完這篇我才意識到，兩種做法差在順序。我的做法是先做、再對答案，驗收標準變成事後檢查；作者的做法是開工前就給終點，模型每一步都朝著標準走。有空檔時，我想做個小實驗：同一個任務從同一個起點跑兩次。A 組照我原本的方式，B 組在 Prompt 裡指定這次要通過哪幾條 AC，再比較兩件事：第一次回報完成時，我在模擬器上逐條檢查能通過幾條 AC，以及要再補幾次指令才能全部通過。

5.2 定義不要的設計規則

這是我之前沒想過的。我給 AI 的設計指令，通常是描述我想要的感覺加上參考圖片，例如「簡約」「有侘寂感」。但這類形容詞每個人的理解都不同，AI 也不例外。原文就提到，籠統的指令往往只會讓它換成另一種預設風格。相反地，不要什麼也可以是逐條檢查的規則。