先画出请求链路

在应用侧为每次交互生成关联标识，并记录输入校验、媒体预处理、模型 API 调用、响应解析和界面呈现的起止状态。为每个阶段定义成功条件，再用关联标识串起记录；不要假设平台会提供相同粒度的追踪。如果通过 NexoToken 接入模型 API，请以当前主平台文档确认实际调用方式，并由应用自行保存诊断所需的阶段记录。

分段测量延迟与流式体验

分别记录预处理耗时、等待响应耗时、首个可用输出出现的时间，以及输出完成时间。若所选调用方式支持流式输出，再记录流的开始、片段到达、中断和用户取消；否则不要把非流式请求标成流式故障。举例来说，假设用户认为“图片提问卡住了”，先检查时间花在图片处理、请求等待，还是界面未呈现已收到的内容，而不是直接归因于模型。

分类错误并设置条件检查

按发生阶段和可采取的处置方式分类，例如输入格式无效、媒体读取失败、调用未完成、输出无法解析，或界面呈现失败。为每类定义判定依据，并让开发者运行带有无效媒体、取消操作和正常输入的自有测试，记录实际结果。若请求已返回而界面仍无内容，就检查解析与呈现记录；若调用前已经失败，就先检查输入校验与预处理。

留下可排查、可保护的记录

日志优先保留关联标识、阶段、时间、错误类别和必要的媒体类型等元数据，避免默认保存原始提示词、图片、音频或输出内容。制定访问、保留和删除规则，并用测试输入检查日志是否意外包含敏感内容。NexoToken 的用量历史可供核对账户层面的使用情况，但不要假定它能替代应用侧逐请求追踪；完成排查时，应同时记录证据、尚未确认的环节和下一步验证动作。

参考资料

NexoToken 平台与交流群

平台地址：https://www.nexotoken.net/

QQ 交流群：822274386

由 NexoToken 维护的自营资料站。平台介绍包含运营方利益关系，不构成独立第三方认证。