Claude 提示詞越長越好？Addy Osmani 建議把重點放回目標與驗收
Claude 提示詞越寫越長，結果卻未必更好。整理 Addy Osmani 對 Opus 5.5 的建議，從完整任務、驗收證據、舊指令刪減，到子代理與雲端工作的使用時機。
你是不是每次交代 Claude 做事，都先貼一大段「仔細思考、逐步分析、請勿出錯」？Claude 提示詞累積得愈來愈長，但工作做完後，還是得追問它到底檢查了什麼。
Claude Code 團隊的 Addy Osmani 在 2026 年 10 月 29 日發表〈You're probably overprompting Claude〉，提醒使用者，新模型需要的引導，可能比我們習慣給的少。
Claude Code 能讀取專案檔案、修改程式並執行檢查。Addy 以 Opus 5.5 為例，建議一次說清楚要做什麼，以及怎麼驗證做到了。因為模型能自行安排更多步驟，使用者就可以把時間留給需求與驗收，減少反覆替它指定下一個動作。
但減少提示，仍然需要提供必要背景。像是要用哪份檔案、交給誰看，以及哪些資料不能改，都是模型無法替你決定的事。
對經常讓 AI 修網站、整理資料或製作文件的人，我會先從一項熟悉的任務試起：保留背景與限制，拿掉重複叮嚀，再補上能實際執行的檢查。
要做到這點，得先分清楚哪些文字在傳達需求，哪些只是沿用舊模型時代的操作習慣。
為什麼 Claude 提示詞越寫越長，結果卻不一定更好？
過度提示，是把模型已經能自行處理的細節，重複寫成強制步驟。例如每個任務都要求逐步思考、反覆自問，卻沒有交代最後要交出什麼。
依照 Opus 5.5 官方使用指南，這個模型本來就會在回覆前思考，因此不需要再加上「think carefully」這類提醒。若想調整 Claude Code 的推理強度，可以在 Claude Code 的對話輸入 /effort 設定，本文的斜線指令都適用於這個工具。
Addy 在原文建議先從 /effort medium 開始，再依任務調整。這是起點建議，並不代表每一種工作都該固定用相同強度。
提示詞有用與否，要看它補充了什麼資訊。「這份報告交給第一次接觸產品的業務」會改變寫法，「一定要非常專業」卻沒有告訴模型，讀者需要理解哪些事情。
同樣地，「保留既有價格與客戶資料，只修改排版」也值得留下。因為它界定了工作範圍，刪掉反而可能讓模型做出你不想要的變更。
因此，縮短提示之前，要先補齊更重要的事：讓模型知道交付什麼才算完成。
把目標、完成標準與停止條件放在同一則指令
一則能直接開工的指令，應該讓模型知道要交出什麼、如何檢查，以及遇到什麼事情需要找你。這樣它才能自行安排中間步驟，也比較容易辨認工作何時結束。
下表把常見的模糊指令，改成可以核對的交代方式。這些是依原文原則撰寫的示例，並非官方測試結果。
| 工作情境 | 容易留下的缺口 | 可以改寫成 |
|---|---|---|
| 修改網頁 | 「幫我做好手機版」沒有尺寸與檢查項目 | 修正報名頁在 390px 寬度的排版，欄位與送出按鈕須完整顯示，完成後提供手機截圖 |
| 整理資料 | 「把報表整理乾淨」沒有說明哪些值可變 | 依提供的對照表統一品名，保留金額、日期與原始列數，另列無法對應的項目 |
| 製作文件 | 「做一份專業簡報」沒有讀者與交付形式 | 為第一次接觸產品的業務製作簡報，每項功能附一個使用情境，交付可編輯檔與預覽 |
表格裡的差別，在於完成後都有東西能檢查。如果只說「手機版做好了」，你很難判斷它看過什麼，有了尺寸與截圖，才能對照交付是否符合需求。
可以直接修改的任務範例
以修正報名頁為例，可以把完整需求放在同一則訊息裡：
請修正報名頁的手機排版。以目前專案的頁面與樣式為準，保留文案、價格和表單欄位。完成標準是桌面與 390px 手機畫面都能完整顯示欄位及送出按鈕，頁面沒有橫向溢出。請實際開啟兩種尺寸，附上截圖與檢查結果。若必須改動表單資料結構，先停下來問我。
這則指令沒有指定模型先讀哪個檔案、再改哪一行，因為那些可以交給它判斷。但它明確留下不可改動的內容，以及需要使用者決定的界線。
需求還不清楚，就先讓模型訪談你
如果你只有「想做一個工具」的想法，可以先請模型提問，直到能寫出規格。規格就是把目的、使用者、功能與驗收方式記下來的文件，能讓後續工作有共同依據。
Addy 建議，規格釐清後再開新對話，用那份文件開始製作。這樣正式執行時，模型拿到的是整理過的需求，也能減少探索過程中已放棄的想法造成干擾。
停止條件也可以寫進 CLAUDE.md，這是 Claude Code 讀取的專案指示檔。把固定的工作邊界放在這裡，就不必每次重新貼上整套規則。
不過，條件寫清楚只能幫模型安排工作，做完之後，它仍需要拿出能讓你核對的證據。
讓 AI 拿出測試結果，別只回報「已完成」
模型說自己做完，只能當成驗收的起點。因為它可能完成了修改，卻漏掉你在意的使用情境，所以回報最好附上實際執行的指令、結果或畫面。
對程式工作，可以看測試是否通過，對網頁工作，可以看指定尺寸的操作與截圖。資料整理則要核對筆數、總額與例外清單，避免表面上變整齊，內容卻被改掉。
Claude Code 團隊的審查流程也強調，交給模型能執行的檢查，並要求它展示輸出。團隊會在人工審查前先用 AI 找問題、修正，但仍依變更風險安排人的審查。
因此，使用者可以把最後一句從「確認沒問題再回覆」，改成「列出做過的檢查與結果，沒有執行的項目也請說明」。後者讓驗收缺口看得見，比一個肯定的結論更有用。
延伸閱讀：Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程
/goal 能接續工作，但仍需要可讀的證據
針對耗時工作，/goal 官方文件提供了設定完成條件的方法。每輪結束後，另一個模型會檢查條件是否成立，尚未達成時就讓工作繼續。
但評估模型不會自行呼叫工具，只能根據對話裡已經呈現的資訊判斷。因此，即使設定了目標，也要讓執行模型把測試輸出或檢查結果帶回來。
這套機制也有停止情況。除了條件達成，當模型判定目標不可能完成，或遇到必須由人處理的錯誤時，目標也會結束，並不保證任何任務都能一直跑到成功。
Auto mode 處理的是動作審核
Auto mode 會用分類器檢查模型打算執行的動作，減少逐次詢問權限的中斷。但它處理的是動作能否執行，和工作是否符合驗收標準是兩回事。
依 Anthropic 的官方說明，這個模式針對危險行動做檢查，仍不代表零風險。因此，你可以減少盯著每一步，最後仍要檢視成果是否正確。
當驗證方式固定下來，你才有依據判斷，舊提示詞裡哪些規則可以刪。
舊指令怎麼刪？先用同一個任務比較
刪減提示詞時，先移除重複提醒，再觀察結果是否變差，比一次清空所有規則更容易找出原因。因為背景、權限與交付要求常混在同一份指示裡，全部刪除會連必要資訊一起丟掉。
Addy 提到，Claude Code 曾針對 Opus 5、Fable 5 等模型移除超過八成的系統提示，程式評測未出現可測得的退步。官方代理架構文章也提到這次縮減。
這項經驗有特定模型與評測範圍，所以不能直接推成「每個人的指令都能刪八成」。對個人使用者，更有參考價值的做法，是把刪減當成能比較結果的小實驗。
先選一項熟悉的任務，保留原版指令與成果，再刪掉重複思考提醒、重複格式要求或模型已能自行處理的步驟。接著用相同驗收條件檢查，才能知道哪些規則確實有幫助。
如果結果少了必要欄位，就把欄位要求補回。若刪減後仍能穩定通過驗收，那些重複叮嚀就可以省略。因為修改範圍有限，你也比較能分辨結果變差的原因。
Claude Code 也提供 /doctor prompt-audit 協助檢視指示。指令文件列出這項功能需要 v2.1.283 或更新版本，因此找不到指令時，可以先核對安裝版本。
等一個工作流程能穩定完成，再考慮同時開更多工作，才看得出分工有沒有幫上忙。
什麼時候才需要子代理與雲端工作？
需要平行處理的獨立大任務，才比較值得拆給不同代理。但「怎麼分工」與「在哪裡執行」是兩個決定，可以分開考慮。
子代理適合能獨立交付的工作
子代理是主代理交辦工作的另一個 AI 執行單位，通常有自己的對話脈絡。例如檢查多個相互獨立的服務，就能分頭蒐集證據，再由主代理整理結果。
如果只是修改一句文案，拆成多個代理反而多了交接與等待。Addy 因此提醒，小任務不必刻意要求分工，多開代理，也不代表答案自然會更聰明。
官方架構文章同樣建議先考慮簡單的單一代理，再透過技能按需要載入工作流程。技能可以理解成可重複使用的操作指南，模型需要時才讀取完整內容，減少一開始塞入大量指示。
因此，是否分工應看任務能否獨立完成、交接是否容易，以及結果有沒有改善。若多個代理都得反覆詢問同一批背景資料，分工可能只是把協調工作移回你身上。
雲端適合不依賴本機資源的任務
如果還希望關掉筆電後繼續執行，就需要考慮雲端工作階段。官方雲端指南說明，工作會在獨立虛擬機上執行，也就是另一台隔離的雲端電腦，並取得程式庫的副本。
如果使用從 GitHub 複製程式庫的流程，開始前要先把工作需要的程式變更上傳到遠端程式庫，雲端工作階段才能取得。如果任務依賴只存在你電腦裡的檔案、服務或設備，就不能假設換到雲端後仍能直接執行。
官方影片以本機介面重播真實工作紀錄，示範切換工作階段、查看對話與程式變更，並非本文實測。影片來源：Claude Code in the cloud。
延伸閱讀：Claude Code 桌面版多工教學：側欄、支線對話與並行任務怎麼安排？
Projects 可以協調多個工作，但仍在逐步開放
Projects 是用一段持續的對話，協調多個相關工作階段的功能。你可以提供共用指示，再從總覽查看完成項目、程式變更提案與需要回覆的問題，減少自己逐一追蹤的負擔。
截至 2026 年 11 月 2 日，官方 Projects 文件列出的公開測試方案為 Pro、Max 與 Ultra，並註明逐步推出，Team 與 Enterprise 尚未提供。因此，選單裡沒有這項功能，可能是帳號還沒輪到。
無論工作在哪裡跑、由幾個代理處理，最後都要回到原本的規格，核對結果與證據。
Claude 提示詞常見問題
Claude 提示詞寫短一點，一定比較好嗎？
字數少本身不保證品質，重點是保留能影響結果的資訊。
如果缺少資料來源、讀者或限制，模型仍可能做錯方向，因此應刪的是重複叮嚀，並保留必要背景。
這些建議適用所有 AI 模型嗎？
Addy 這篇主要以 Opus 5.5 與 Claude Code 為例。
完整任務與驗收方式可以拿到其他工具嘗試，但指令、功能與實際效果仍應分別確認，不能假設完全相同。
使用 /goal 後，還需要自己檢查嗎？
需要，因為目標評估依賴模型已呈現的證據。
你仍要核對驗收條件是否設對，以及結果是否符合實際用途，尤其是對外發布或影響既有資料的工作。
可以直接刪掉整份 CLAUDE.md 嗎？
先保留專案背景、不可改動的資料、必要測試與權限界線，再逐段刪減比較容易追查影響。
如果指令縮短後某項要求消失，就把那項具體要求補回，而不用恢復所有舊文字。
下次交辦前，先把「做得好」寫成能檢查的條件
對已經熟悉 AI 工具、卻花很多時間盯每一步的人，這套做法值得先試一個任務。因為你原本就知道成果該長什麼樣，比較容易把模糊期待改成清楚的驗收條件。
如果連需求都還沒定下來，就先請模型訪談、整理規格。等目標釐清後再開始製作，才不會讓它持續朝一個你也說不清楚的方向執行。
下次送出指令前，先檢查是否說清楚交付物、完成證據與停止界線。把這些寫好，再讓模型決定中間步驟，比繼續累積「請仔細思考」更值得嘗試。
如果想繼續練習驗收，可以延伸閱讀：Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程，挑一項適合自己工作的檢查用在下次交辦。
