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 值遮掉。