【2026 最新】Claude Code Prompt Suggestions 該關嗎？接受、送出與背景額度的六步教學

你剛請 Claude Code 解釋一段程式，它回完話，輸入框就浮出灰字：「要不要順便修正？」Claude Code Prompt Suggestions 看起來像貼心的下一步，也可能讓你忘記原本只想理解問題。這時最值得弄清楚的，是灰字何時變成你的指令，以及你沒送出時，背景是否已經有模型工作。

這篇專為完全沒有技術背景、已開始使用 Claude Code 的讀者寫。你會學會開關設定、分辨接受與送出，並用一份配對工作表決定是否保留功能。依截至 2026 年 10 月 8 日的官方文件整理；下面的操作練習與量測流程是供你執行的設計，AlphaLab 本次未跑出節省率。

先說結論：Claude Code Prompt Suggestions 是草稿，不是任務

看見建議 ≠ 接受文字 ≠ 送出任務；生成建議的背景請求，則是另一筆工作。把它想成助理放在桌上的便條：拿起來、改成自己的要求、交出去，是不同的步驟。助理寫便條也用了時間，不會因為你沒採用就變成零工作。

• 想保留自己的思路：先關掉一輪，再比較任務是否更順。
• 常做有明確下一步的工作：可以保留，但接受後先核對完整文字。
• 想省額度：記錄總工作與完成品質；訂閱使用比例、Token 和 API 美元分開看。

2026 年 10 月的 Hacker News 討論重新談起這個功能對思考與輸入習慣的影響。留言提供的是使用者經驗與推測；本文不把它們當成 Anthropic 設計目的的證明，也不從討論熱度推算節省比例。

① 分清三種「補完」：你看到的是哪一種？

開場範例像空白筆記本上的示範句；回覆後的下一步建議像讀過對話後寫出的便條；檔名補全則像地址簿幫你找到一個檔案。三者看起來都可能幫你少打字，觸發原因卻不同。

官方互動模式文件說明，開場灰字從專案 Git 歷史挑選；回覆後的建議參考對話歷史。Git 是記錄檔案變更的版本管理工具。輸入 @ 找檔案，則是另一種選取操作，不應拿檔名候選出現次數當成下一步建議次數。

先做一個辨認練習：在你的筆記寫下「開場／回覆後／@ 檔案」三個欄位。每次看到候選，先歸類再操作。這一步能避免把所有灰字都算成同一種模型功能，也能讓後面的記錄有一致口徑。

② Claude Code Prompt Suggestions：先接受，再核對，再送出

操作重點是停在中間。依官方目前的終端互動方式，Tab 或右箭頭會把建議放進輸入框，之後按 Enter 才提交；直接開始輸入自己的文字可以讓建議消失。這段只談下一步建議，不把搜尋歷史、命令選單或檔案選單的 Enter 行為混進來。

假設你原本的任務是：「只解釋 README 裡的三個安裝步驟，不修改檔案。」回覆後可能出現另一個下一步。以下只是假設情境，不是本次取得的建議文字：若候選改成「幫我改寫 README」，你可以先接受，再把它改回「列出仍不理解的名詞，不修改檔案」，最後才送出。

1. 看見：先讀整句，辨認它是否延續自己的目標。
2. 接受：按一次 Tab，停下來看輸入框；先別連按 Enter。
3. 核對：確認動詞、對象與邊界，例如「解釋 README、不修改檔案」。
4. 送出：只提交你願意承擔的完整要求，觀察對話是否出現這則訊息。

如果你的版本有自訂按鍵，先以一個只要求回覆短句的任務確認操作，再開始正式記錄。官方更新紀錄在 v2.1.136 列出修正：空輸入按 Enter 曾可能直接送出建議，修正後要求先接受。因此不能把所有舊版的輸入行為當成一致，也不能僅憑文章描述就替自己的按鍵驗收。

③ 關閉、重新開啟：只改一個功能

覺得灰字干擾思考，先用介面開關最容易回復。在 Claude Code 輸入 /config，找到 Prompt suggestions 並關閉。做完一輪任務後，可以回同一位置重新開啟。以 官方設定參考中的 promptSuggestionEnabled 為準，拼字是單數 Suggestion。

偏好保存設定的人，可以在既有 ~/.claude/settings.json 加入 "promptSuggestionEnabled": false；若檔案是空白，完整 JSON 範例為 { "promptSuggestionEnabled": false }。JSON 是用鍵與值保存設定的文字格式。已有其他設定時只合併這一項，不要整份覆蓋。開啟時把值改成 true。

若想只在一個終端啟動時關閉，可先結束這次 Claude Code，在終端執行 CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false claude。這是 macOS／Linux 常見 shell 的單次啟動寫法；Windows PowerShell 可在當前終端先執行 $env:CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION="false"，再執行 claude。

官方環境變數文件明確指出，這個變數優先於設定鍵。Shell 是解讀終端命令的程式；環境變數像它交給應用程式的啟動便條。如果你之前已 export 為 false，單把 /config 改為開啟可能仍被覆蓋。macOS／Linux 可用 printenv CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION 檢查這一個值，並以 unset CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION 清掉當前 shell 的值；PowerShell 用 Remove-Item Env:CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION -ErrorAction SilentlyContinue。接著重新啟動再查設定。

若值來自 shell 啟動檔，重開終端還可能再載入；若由公司管理，先辨認政策來源。設定優先序文件可幫你分清使用者、專案與管理層級。練習只調建議功能，不順便改權限、遙測或模型，才能看出差別來自哪一項。

④ 沒看到建議，不等於開關壞了

要驗「開」的一組，不能只記設定畫面。現行文件列出會跳過建議的情況，包括Prompt Cache 冷掉、Plan Mode、上一則回覆出錯，以及接近或到達用量上限。Prompt Cache 是重用已處理內容的快取，像沿用上一頁筆記，少一次重讀。功能旗標尚未取得、某些供應商路由，也可能讓 /config 的選項不顯示。

這些條件意味著：「設定開啟」和「這回合真的產生建議」要分兩欄。如果打算量測開關差異，請用短而正常完成的互動工作、記錄是否看到建議；不要為了強迫它出現而把其他系統功能全部打開。讀者可依 官方跳過條件核對自己的情境。

v2.1.283 的更新另記錄：連續 20 次未使用建議後，終端會降低顯示頻率，使用一次會恢復。這是該版發布的行為變更，不是每回合固定有一筆建議請求的保證。保存版本和畫面上的提示，比用「沒出現＝省了一次」猜帳可靠。

⑤ 背景用量怎麼算？先分開兩本帳

背景生成不是免費的文字補全。官方背景 Token 說明把下一步建議列為回覆後送到目前模型的短請求。它重用對話快取，以快取讀取和少量輸出為主；功能關閉能停止這類建議請求。Token 是模型處理文字的單位，不等於中文一字或英文一詞。

這解釋了為什麼「我沒接受」與「生成沒有工作量」不能畫上等號。但整個 session 還有其他工作，少掉建議後，如果你為了想下一步多問幾輪，總用量又可能不同。你的目標應該是完成同一件事所付出的代價，而不是只盯著灰字消失。

• 訂閱帳：在 /usage 看方案使用比例與重置時間，記錄任務前後變化；別把本地顯示的美元直接當成信用卡新增費用。
• API 帳：保留一般輸入、輸出、快取讀取與寫入的分項；本地成本是估算，帳務核對用 Claude Console 的 Usage。
• 額外付費：如果已開啟 usage credits，另外記下這次是否動用它，避免把方案內使用和付費超額混成一條曲線。

現行命令參考將 /cost、/stats 列為 /usage 的別名；初學者統一使用 /usage 即可。成本追蹤文件也區分訂閱用量與 session 成本估算。這篇不提供模型單價表，避免把「開關功能」和「換模型計費」混成同一個問題。

⑥ 用配對工作表決定：你要保留，還是關閉？

最容易做錯的比較，是早上開、晚上關，看到比例不同就下結論。兩輪可能有不同任務、長對話、別的裝置使用或額度重置。解法是先固定任務，再記可觀察結果。這份工作表是量測設計，不是已完成的 benchmark。

挑一份你有權使用的小型 README，任務固定為：「讀完 README，列出三個安裝步驟；逐項指出對應段落；不修改檔案。」通過條件是三步都對回原文、順序合理、檔案未改。原始內容、工具與驗收先寫好；開關輪次都從相近的上下文開始，避免前一輪答案成為後一輪提示。

• 設定欄：日期、claude --version、/model 的模型、帳號計費類型、功能開關、環境變數值、任務文字與資料版本。
• 用量欄：開始／結束時間、/usage 任務前後畫面、重置時間；API 使用者另填 token 分項與帳務紀錄。
• 行為欄：看到幾次下一步建議、接受幾次、接受後改寫幾次、實際送出幾次、偏離原任務幾次。開場範例與檔名候選分開記。
• 成果欄：通過與否、總完成時間、手動修正次數、額外問答輪次；失敗也保留，別只挑最好的一輪。

先做「開→關」一對，再做「關→開」一對，兩對都維持相同成功條件。這個四輪起點只是方便觀察順序影響的練習安排，沒有統計顯著性的保證。每輪結束用同樣的觀察等待時間，再取用量畫面；不要每秒查 /usage，因為官方也列出部分狀態命令本身可能產生背景請求。

訂閱比例若只有粗略顯示，兩輪都不變，請填「這個顯示粒度看不出差異」，不是 0 Token。若期間額度重置、另一台裝置在使用或任務中途出錯，標記該對不可直接比較。API 的帳務延遲也要留在紀錄；session 總量差，不能直接命名為某一筆背景建議的精確費用。

最後用兩條判斷線：保留，如果建議讓你少花時間想下一步，而且完整任務的用量、品質與修改量可接受；關閉，如果建議常讓你偏離任務，或核對它比自己寫更費力。想做更完整的品質對照，可接著讀 Claude Code A/B Test 教學；想查已留下的 session 紀錄，則看 Tare Token 去向教學。

常見問題：八個直接答案

1. 按 Tab 就會送出建議嗎？

依現行文件的兩步流程，不會直接送出。Tab 或右箭頭先放入輸入框，Enter 才提交；舊版與自訂鍵先用短句任務驗證。

2. 我沒接受，背景生成還會計入用量嗎？

會，只要該次建議請求有產生。是否接受是下一步的行為，生成請求本身已是模型工作。

3. 關掉一定省 10% 嗎？

不一定。本文不採固定比例；建議頻率、上下文、模型、快取，以及你是否因此多問幾輪，都會改變完整任務的差。

4. /config 打開了，為什麼仍看不到？

先查環境變數與跳過條件。記「設定開」和「實際出現」兩項，不要把偶爾沒有候選讀成設定失效。

5. 關閉會把 @ 檔名選單一起關掉嗎？

這個設定針對 Prompt Suggestions。@ 檔案選取是另一項操作；分開記錄與驗證，避免把兩者統計混在一起。

6. /usage 的美元是我的訂閱加收嗎？

不是方案內使用的帳單結論。先確認這輪用訂閱、usage credits 還是 API；API 的最終帳務再用 Console 核對。

7. 練習兩輪一樣的結果，可以說完全沒差嗎？

還不夠。先看是否真的有建議、資料顯示有多細，以及結果是否受到重置或其他工作干擾；可以增加配對，但別預設一定要找到勝負。

8. 每次建議都看起來合理，還需要改嗎？

需要核對它是否符合你的當前目標。合理的下一步，也可能超過你今天想做的範圍；把目標、對象與限制補進送出的文字。

給新手的三個重點

• 先學會停在接受與送出之間；你的 Enter 應提交自己的完整意圖。
• 只改一個開關；看不到建議時，查條件與優先序，不靠連續切換猜原因。
• 用同一任務的總用量、時間與合格成果決定；看不出差異，就保留「未分辨」這個答案。