可靠的接口日志，应当留下线索而非秘密

一次请求失败需要定位线索，而不是完整对话

刚接入人工智能接口时，把请求和响应全部写进日志，看起来最方便。问题是，这份排障记录也可能包含密钥、客户姓名、内部文件和用户提问。日志往往还会进入监控平台、备份和告警消息，让一次无意记录变成多处泄露。

更安全的起点是只记录解释系统行为所需的信息。例如请求时间、内部追踪编号、模型名称、状态码、耗时和重试次数。这些线索通常足以判断请求是否发出、哪里失败，以及是否值得重试，却不需要保存对话原文。

日志允许记录的字段应该提前明确列出

不要先保存所有内容，再尝试删除秘密。更稳妥的做法是建立允许记录的字段清单，未列入清单的内容默认不进入日志。密钥、认证头、会话凭据，以及请求地址中可能携带的凭据，都应排除在外。

请求正文同样不能默认视为安全。用户可能粘贴密码，也可能上传合同和病历。提示词、工具参数、检索片段、附件文字和模型回答，都应默认不记录。确实需要关联用户时，可使用内部随机编号，而不是邮箱或手机号。

脱敏措施需要覆盖错误响应和工具输出

只替换几个常见敏感词并不可靠。秘密可能出现在嵌套字段、异常信息和工具返回结果里，框架或监控组件也可能自动采集正文。因此，检查范围应覆盖应用、代理和监控链路，而不只是自己编写的日志语句。

错误日志优先保留错误类别、状态码和经过检查的简短说明，不要直接保存完整错误对象。使用虚构密钥和虚构个人信息做测试，确认它们不会出现在日志、告警或导出文件中。截断正文只能缩短泄露内容，不能替代脱敏。

用量核对需要计数记录，而不是用户原文

本文由重视质量的接口中转服务 BestRelay 发布。它按请求中指定的名称转发至官方模型，不以其他模型替换，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列。这类链路适合分别记录请求模型、请求关联编号及用量，便于核对，而不是复制正文作为凭证。

BestRelay 按供应商报告的令牌数量按量计费，缓存读取和写入分别计价。因此，日志应区分输入、输出及缓存用量，不把所有计数混成一项。遇到流式响应中断、未收到完整用量时，应标记缺失，不能把缺失写成零，也不要将本地估算当成正式账单。

开发工具兼容并不代表日志可以自动放心

BestRelay 可配合 Claude Code、Codex、Gemini CLI 及任意 OpenAI SDK 使用，但工具兼容不等于日志安全。启用详细诊断前，应检查客户端、中转层和监控平台各自记录什么，尤其留意自动附带的请求头和上下文。

想实践这些记录原则，可以创建一个 BestRelay 账户。会员邀请他人充值后可获得推荐佣金；相关运营数据应与接口排障日志分开管理，不应为了核算佣金而收集被邀请者的对话。

日志的访问权限和保留期限同样需要收紧

即使不含正文，日志仍可能透露用户活动时间和业务规模。应限制可查看和导出日志的人员，为存储和传输提供保护，并设置明确的删除期限，同时检查备份是否遵循相应规则。

遇到难以复现的问题，优先使用虚构数据重现。确需临时增加诊断字段时，应限定范围、取得授权并设定自动结束时间。好的日志不是把一切都留下，而是用尽可能少的数据，让下一位排障者看懂发生了什么。