适用场景
这篇适合接入 AI 模型接口后经常需要排查“为什么这次回答不对”的团队。没有样本，开发者只能猜；样本保留过多，又可能把客户姓名、手机号、合同条款、内部价格、工单截图写进日志。前几天如果刚排查过提示词变量注入，可以结合 AI API 提示词变量被用户输入带偏怎么办 一起看。
永沃云枢在 https://ai.jn83.com 记录 AI API 接入、AI 模型接口、Codex 接入和模型调用管理经验。新手搜索“GPT 中转”时，真正需要的不只是地址和 Key，还包括请求日志的边界。
先给字段分级
把请求字段分为四类：可公开字段、业务上下文字段、敏感个人字段、凭证和密钥字段。可公开字段可以完整记录，比如模型名、功能入口、request_id、耗时、状态码。业务上下文字段建议截断或摘要。个人字段要脱敏，凭证字段默认不落盘。
字段分级不要只写在文档里，最好进入代码和检查脚本。比如日志序列化前先调用统一的 redact()，单元测试里固定检查手机号、邮箱、API Key、身份证号、Token 字样不会直接出现。敏感字段处理的底线可以参考 AI API 接入前怎么处理敏感字段。
操作步骤
第一步，给每次调用生成 request_id，并把前端事件、后端日志、上游响应和用户反馈串起来。第二步，只保留能复现问题的最小输入，不把完整原文长期放进普通日志。第三步，把脱敏前样本和脱敏后样本分仓存放，普通开发者只看脱敏版本。
第四步，准备复现样本。复现样本应该能说明模型名、系统提示词版本、用户输入摘要、关键参数、返回状态和错误表现。第五步，设置留存周期：普通调试日志短期保留，合规审计日志按业务要求保留，含敏感字段的原始样本必须有删除流程和访问记录。
如果用 Codex 帮忙写排错脚本，不要把真实客户输入直接贴进任务。可以给 Codex 一份脱敏样本和字段说明，让它补日志格式、校验规则和复现命令。涉及批量处理时，还要结合 AI API 批量处理失败后怎么断点续跑 里的任务编号思路。
常见问题和避坑
第一个坑是把“日志里没有明文 Key”当成脱敏完成。很多业务字段组合后仍能识别个人或客户，尤其是工单号、城市、金额、时间、截图文字一起出现时。第二个坑是只脱敏请求，不脱敏模型输出。模型可能把输入里的敏感内容原样复述回来。
第三个坑是排错时临时打开 debug，问题解决后忘记关。第四个坑是把日志发到聊天工具、工单系统或外部知识库里二次扩散。AI 自动化办公场景下，尤其要把用户上传文件、OCR 结果、摘要结果和人工备注分开管理。
检查清单
- 是否给请求、响应、错误和用户反馈使用同一个 request_id。
- 是否明确哪些字段允许完整记录，哪些只能脱敏或摘要。
- 是否检查模型输出里不会回写敏感内容。
- 是否保留可复现样本，而不是保留全部原文。
- 是否设置日志访问权限、删除周期和临时 debug 关闭动作。
好的 AI API 日志不是越多越好，而是足够复现、足够克制、足够可追责。后续在 https://ai.jn83.com 做开发者 AI 调用或模型调用管理时，把这套规则前置，比上线后补救更稳。
复盘补充：给排错样本做最小化
很多团队一开始会保存完整请求，觉得这样最保险。更稳的做法是给每类问题准备最小样本：格式错误只保留触发格式错误的字段，权限错误只保留角色和权限标记，质量问题只保留能复现偏差的短文本。样本越小，越容易分享给开发者，也越不容易把业务隐私带到无关系统里。
如果必须临时查看原文，应给操作加上到期时间和访问记录。比如当天排查结束后删除临时文件，只把脱敏样本和结论写进知识库。这样下次遇到同类 AI API 接入问题，仍能复用排查路径，却不必长期保存客户原始内容。