verbatim_prompts 打開之後，Claude 還能理解使用者輸入裡提到的檔案路徑嗎？
可以理解，但方式不同。關掉展開功能後，Claude 收到的是純文字裡的 @path/to/file 字樣，它仍然可以把這段文字當成「使用者在談論這個路徑」來理解語意，只是不會自動幫你把檔案內容抓進來塞進 prompt。如果你的應用需要讓 Claude 真的讀取某個檔案的內容，打開 verbatim_prompts 之後就得透過工具呼叫（例如讓 Claude 主動呼叫一個讀檔工具）來完成，而不是依賴訊息格式自動觸發。
這個差異其實是好事：檔案讀取變成一個可以被明確授權、記錄、甚至限制範圍的工具呼叫，而不是藏在文字格式裡的隱性行為。
如果我的應用一部分訊息是開發者寫的、一部分是使用者輸入拼接的，可以只對使用者輸入那段打開 verbatim_prompts 嗎？
不行，verbatim_prompts 是整個 session／每次 query 呼叫層級的設定，不是訊息內逐段生效的開關。如果你的 prompt 組裝邏輯同時混合開發者文字跟使用者輸入，打開這個選項會讓整段訊息都不解析 @path 跟 slash command，包括開發者原本想讓它生效的部分。
比較穩妥的做法是重新設計 prompt 組裝方式：把開發者想要觸發檔案展開或 slash command 的邏輯，改成用明確的工具呼叫或程式邏輯處理，而不是依賴訊息格式本身，這樣全面打開 verbatim_prompts 就不會犧牲任何原本需要的功能。
打開 verbatim_prompts 會影響 Claude 回應的品質或行為嗎？
從設計目的來看，不會直接影響模型本身的理解或回答品質——這個選項動的是 SDK 跟 CLI 之間的 prompt 預處理層，不是模型的推理行為。差異只會出現在那些原本依賴 @path 展開或 slash command 派送才能運作的功能上：如果你的工作流程本來就靠這些機制自動抓檔案或觸發指令，打開之後這些自動化就會失效，需要改用明確的工具呼叫替代。
如果你的應用從來沒依賴過這兩個自動展開機制，打開這個選項對使用體驗應該是無感的，純粹是多一層防護。
只是用 Claude Agent SDK 做內部工具、使用者都是自己團隊成員，還需要打開 verbatim_prompts 嗎？
風險評估的關鍵不是「使用者是誰」，而是「訊息裡的文字內容是不是全部由受信任的一方產生」。即使使用者是自己團隊成員，如果應用的訊息組裝邏輯裡混入了來自外部的文字（例如貼上客戶的 email 內容、抓取的網頁文字、第三方系統回傳的欄位），這些外部文字本身仍然可能無意間包含符合 @path 或 slash command 格式的片段，造成非預期行為——不一定是惡意攻擊,單純格式巧合就可能觸發。
所以判斷標準應該是「這段訊息裡有沒有任何不是開發者自己打的文字」，而不是「使用這個工具的人可不可信」。
用 Claude Agent SDK 建構的應用程式，常見的一種架構是：把使用者輸入、資料庫欄位、或是從外部 API 抓回來的文字，直接組進傳給 Claude CLI 的 prompt 字串裡。問題是，SDK 預設的 prompt 處理行為，會把訊息裡符合特定格式的片段當成「指令」解讀——像是 @path/to/file 這種寫法會被展開成檔案內容，以 / 開頭的字串可能被當成 slash command 分派出去。如果這段文字不是開發者自己打的，而是來自不受信任的來源（使用者貼上的內容、第三方系統回傳的欄位），這就形成一個具體的注入風險：有心人只要在輸入裡塞進 @/etc/passwd 或是偽裝成 slash command 的字串，就有機會觸發非預期的檔案讀取或指令派送。
新增的 ClaudeAgentOptions.verbatim_prompts（預設為 False）選項，打開之後，使用者訊息會被原封不動地送進 CLI，不做 @path 檔案展開，也不做 slash command 派送。換句話說，一段文字裡不管寫了什麼看起來像指令的東西，Claude 收到的就是純文字本身，不會因為格式巧合而觸發任何檔案存取或指令執行的副作用。這個選項同時支援 query() 函式呼叫，以及 ClaudeSDKClient.connect()／ClaudeSDKClient.query() 的互動式連線模式，字串輸入跟 async iterable 輸入兩種形式都涵蓋到。要注意的是，這個功能需要 CLI 2.1.248 以上版本才支援，用舊版 CLI 開啟這個選項會記錄一條警告，但不會中斷執行——這代表如果你的部署環境釘選了較舊的 CLI 版本，這個防護實際上不會生效，必須額外檢查版本號確認。
如果你的應用程式架構裡，傳給 Claude 的 prompt 完全由開發者自己組裝、不含任何外部輸入的原始文字，那麼 verbatim_prompts 帶來的差異不大，因為沒有攻擊者能控制的輸入管道。但只要架構裡有任何一個環節，是把使用者輸入、網頁爬取內容、或第三方 API 回傳資料，不經過處理就直接接到傳給 CLI 的訊息字串裡，這就是一個真實存在的注入面——這種模式在客服機器人、文件摘要工具、或是任何「讀取外部內容再回答」的應用裡很常見。這類應用應該把 verbatim_prompts=True 視為預設該打開的防護，而不是遇到問題之後才補。
需要說清楚的是，verbatim_prompts 解決的是一個specific且具體的攻擊面：透過 @path 展開跟 slash command 格式觸發非預期的檔案讀取或指令派送。它並不處理更廣義的 prompt injection 問題——例如攻擊者在輸入文字裡用自然語言說服模型忽略先前指示、或是誘導模型輸出不該輸出的內容，這類問題仍然需要靠系統提示設計、輸出驗證等其他手段處理。把 verbatim_prompts 當成唯一的防線會是一種誤解，它是防禦縱深裡的一層，而不是整個防禦。
如果你的團隊正在用 Claude Agent SDK 建構會接觸外部輸入的應用——客服系統、內容分析工具、或任何把第三方文字塞進 prompt 的架構——現在就該盤點一次：哪些訊息組裝路徑含有不受信任的原始文字，然後針對這些路徑打開 verbatim_prompts，同時確認部署環境的 CLI 版本在 2.1.248 以上，否則這個開關不會真的生效。這類安全選項的成本很低（一個布林參數），但要等到真的出事才補上，代價通常遠高於現在花十分鐘檢查一次。