LLM 對話報文診斷器
免費線上 LLM messages 陣列診斷器。貼上 OpenAI 或 Anthropic 的對話 JSON，立即看出是第幾則訊息壞了結構——tool_call_id 配對不到、role 順序非法、system 位置錯——每條都附具體修法。
LLM 對話報文診斷器
免費線上 LLM messages 陣列診斷器。貼上 OpenAI 或 Anthropic 的對話 JSON，立即看出是第幾則訊息壞了結構——tool_call_id 配對不到、role 順序非法、system 位置錯——每條都附具體修法。
關於 LLM 對話報文診斷器
為什麼 API 會拒收你的 messages
messages 陣列是一份帶隱形順序規則的契約：tool 回應必須緊跟宣告它的 assistant 訊息、每個宣告的 tool_call_id 都要在對話前進之前被回應，Anthropic 還要求 user 與 assistant 交替、system 移到頂層參數。當程式動態組裝這個陣列——裁剪歷史、重試呼叫、合併輪次——這些不變式很容易被打破，而 API 的錯誤訊息只引述規則、不告訴你是哪一則違反。本工具用同一套配對邏輯走訪陣列，直接指出確切的位置。
兩套規則、一次貼上
OpenAI Chat Completions 與 Anthropic Messages 在根本處就不同：有哪些角色、system 指令放哪裡、tool 呼叫怎麼與結果配對（頂層 tool_calls 與 tool 訊息 vs. tool_use 與 tool_result 內容區塊）。切換規則版本，同一份輸入立即重新判定——把對話紀錄從一家搬到另一家時特別有用，因為診斷清單就是你的遷移待辦。
隱私
所有解析與診斷都在你的瀏覽器本機完成。貼上的內容不會上傳、不會記錄——對話紀錄經常夾帶憑證、客戶資料與內部 prompt，所以這裡刻意沒有伺服器端、也不對你的輸入做任何分析追蹤。
常見問題
關於這個主題的常見疑問與實用解答。
這個工具能解釋哪些 API 錯誤？
結構類的 400 錯誤：role 為 tool 的訊息必須回應帶 tool_calls 的訊息、帶 tool_calls 的 assistant 後面必須接 tool 訊息、未知或缺少的 role、空陣列、content 形狀不合法；Anthropic 側則有 user 與 assistant 交替斷裂、system 位置錯、tool_use 與 tool_result id 配對不到。語意類問題——模型名稱錯、超過 context 長度、function 參數格式錯——屬於不同的失敗，不在守備範圍。
我的 SDK 已經有型別檢查了，為什麼還需要這個？
型別在編譯期擋形狀錯誤，但造成多數 400 的是跨訊息的順序規則：這個 tool_call_id 是不是兩則之前宣告的、每個宣告是否都在下一個 user 輪次前被回應。這些只存在於 runtime——在你的歷史裁剪與重試邏輯組裝出實際陣列之後。把組裝後的陣列貼進來，跨訊息配對會被直接檢查——不限語言，production 撈出來的 log 也行。
貼真實的對話紀錄安全嗎？
安全——解析與診斷完全在你的瀏覽器內執行，內容不會離開頁面：不上傳、不儲存、不對貼上的文字做分析。而且診斷只讀 role、id 與形狀，想更謹慎的話，貼上前可以先把 content 值遮掉。