AIREITER如果 Claude 顯示「幾乎完成思考」，而你在想是不是出了問題——其實沒有。這個狀態表示 Claude 正在進行延伸思考（其推理模式）：它會在開始輸出前先規劃答案。持續幾秒，甚至 20–30 秒，都是正常的。不正常的是等了好幾分鐘卻完全沒有回應。這是兩個不同的問題，本指南會將它們區分開來，並提供各自的解決方法。
「幾乎完成思考」實際上是什麼意思
"Almost done thinking" 是 Claude 在執行其 延伸推理 過程時顯示的標籤。模型不會立刻逐字回覆，而是會先花費一部分「思考」token 來擬定計畫，接著才產生可見的答案。這與 Claude Code 中的「high effort 的思考」以及 Claude 應用程式中的推理指示器是相同的機制。
最清楚的理解方式是：這個短語是一個 進度 訊號，而不是 錯誤。正如一個 r/ClaudeCode 討論串 所說，延伸推理的暫停是「Claude 在執行前進行規劃，而不是伺服器問題。」所以當你看到 claude almost done thinking 時，模型正在運作——唯一的問題是它是不是運作了 太久。
一條大致可作為界線的標準：
數秒到約 30 秒的思考時間 → 正常，尤其是在處理困難的推理或程式編寫任務時。
數分鐘完全沒有輸出，而且反覆出現 → 這表示有問題；請直接跳到下面的修復方法。
為什麼會花這麼久（或甚至完全卡住）
緩慢與真正的當機有不同的原因。造成緩慢情況有三個因素：
延展思考深度。 在快速查詢時，Claude 可能會傾向投入超過任務所需的推理努力——它會對一個其實不需要那麼多思考的問題「想」得很用力。
序列式工具呼叫。 在代理式使用（Claude Code）中，大多數的實際耗時並不是模型推理——而是工具呼叫。一份對 Claude Code 延遲的分析量測到每次檔案讀取、搜尋或測試執行大約需要 300–800ms，作為同步往返耗時，並指出預設情況下它們不會平行執行——因此，一個模糊的提示若觸發十幾次探索性呼叫，會在任何真正工作開始之前，就把這些往返累積成十幾秒的延遲。
上下文膨脹。 每一輪都會將整段對話紀錄重新送回模型。隨著一個會話逐漸填滿，回應會變慢且品質下降——同一份分析觀察到，當會話超過上下文視窗的約 60% 時，速度會出現明顯變慢，不過精確的臨界點會有所不同（這就是細節埋得很深時的「中間遺失」效應）。
真正的卡住是另一種故障。Claude Code 的一個已追蹤問題（#32526）描述了新工作階段卡在「thinking」並且從不產生輸出——沒有任何錯誤，連對一個簡單的「hello」也一樣——而先前已開啟的工作階段則仍可正常運作。該回報來自一個負載很重的設定：許多 PreToolUse hooks、多個 MCP servers、80+ 已註冊技能，以及一個自訂的（Bedrock）provider。如果你的情況是連一個 token 都從未返回，請把它視為卡住，而不是速度慢。
如何修正
快速修復（請先嘗試這些）
/clear用於捨棄對話並重新開始乾淨狀態——解決上下文膨脹最快的方法。/compact用於摘要並縮減上下文。請注意，這種方式本身就會有資訊遺失，所以先把任何重要內容存到檔案中。重新啟動工作階段，或回到一個仍有回應的較舊工作階段——這是大多數使用者在當機時採用的變通方法。
控制努力程度
最常被忽略的速度槓桿是 effort。Claude 傾向預設為高／最大推理；將 effort 與任務相匹配，能在例行工作上大幅提升速度，且不會降低品質。實用速查表：
任務 | 耗費 | 原因 |
|---|---|---|
快速查找、摘要、格式化 |
| 不需要深入推理；幾乎即時 |
一般程式撰寫、草擬 |
| 平衡 |
架構設計、困難除錯、數學 |
| 值得等待 |
如果不透明度讓您困擾（Claude 預設會隱藏思考細節），Claude Code 可以顯示思考摘要，讓您至少能看到它正在做什麼。
當它真的卡住，而不只是變慢時
如果你得到 零 輸出，那是卡住了，不是深度：
減少啟動載入 — 暫時停用額外的
PreToolUsehooks、未使用的 MCP servers，以及 skills，然後重新開啟工作階段。檢查您的 provider — 自訂 model IDs 和 gateways（Bedrock 及類似項目）會出現在多起當機報告中。
使用
--verbose執行，以查看它實際在做什麼：一長串的檔案讀取表示 tool-call 問題；沒有 tool calls 的緩慢首次回應則表示延遲或 context 問題。
進階：從 API 控制思考
應用程式只能讓你對思考的控制有限。API 直接把這種控制權交給你——如果你需要可預測的延遲，這就是實際可行的解法。上方速查表中的相同 effort 等級就是 API 參數，而且你也可以完全關閉 extended thinking：
message = client.messages.create(
model="claude-opus-4-6",
max_tokens=4096,
thinking={"type": "adaptive"}, # Claude decides how much to think
output_config={"effort": "low"}, # low | medium | high | max — caps the depth
# or, to skip extended thinking entirely:
# thinking={"type": "disabled"},
messages=[{"role": "user", "content": "..."}],
)在目前的 Claude 模型（Opus 4.6 及以上）中，你不會設定固定的 token 預算——你會設定一個努力等級（low 用於快速工作，最高到 max），或者直接停用延伸思考。這和應用程式隱藏的那個控制項是同一個，只是以你可控制的參數形式暴露出來。（請參閱官方延伸思考文件以取得目前的參考——參數名稱可能會在不同的 SDK 版本之間變動，所以請確認你正在使用的版本。）
任何相容 Anthropic 的 endpoint 都可以發出這些呼叫——官方 API，或像 AIReiter 這樣的相容 mirror，上面的 request 無需變更即可運作。你使用哪一個其實沒那麼重要，重點是：thinking control 位於 API layer，而 apps 不會暴露它。
Claude 真的「變差」了嗎？
這是大多數「為什麼 Claude 幾乎一直在思考到永遠」搜尋背後潛藏的問題，而誠實的答案是：通常這不是永久性的。許多看似退步的現象其實可追溯到預設行為變更——例如伺服器端對思考預算的調整，或在更新中推出的保守預設——而不是模型變笨了。社群對此有很多來回討論，而反覆出現的結論都一樣：當你重新掌控後，體驗就會恢復——設定努力等級、清除過於臃腫的對話階段，並提供結構化提示。如果這週 Claude 感覺變差了，先改這三件事，再來判定它是不是壞掉了。
常見問題
「幾乎想完了」是什麼意思？
這表示 Claude 正處於延伸推理模式，在寫出答案之前先規劃步驟——這是正常的進度狀態，不是錯誤。只有在它一直無法完成時，才代表有問題。
為什麼 Claude 需要這麼久才能思考？
三個常見原因：較高的預設努力等級、agentic 會話中緩慢的連續工具呼叫（每次約 300–800ms），以及過大的上下文視窗。降低努力等級、減少工具呼叫次數，以及清除上下文都會有幫助。
Claude 會不會有時卡在思考中？
是的——這與緩慢不同。新的會話可能會卡在「thinking」並且永遠不返回輸出，這通常與繁重的 hook/MCP/skill 設定或自訂 providers 有關。請重新啟動會話，或回到可正常運作的會話。
Claude 沒有完成回應——我該怎麼做？
將其視為卡住：/clear 或重新啟動，減少啟動載入，並檢查你的供應商。如果它只是變慢而不是停滯，降低努力等級並縮小上下文。
我可以讓 Claude 思考得更快嗎？
可以。對於例行工作，將 effort 設為 low/medium，保持會話時間較短；若要完全控制，請以較低的 effort level 或停用 extended thinking 來呼叫 API。