中转站日志会记录哪些内容

很多人用中转站只看价格和速度，从没想过自己发的提示词、上传的文件、Key 的调用时间会被记成什么样、留多久。等出事要举证，或者发现某段内容不该外发时，才发现根本没看过对方的日志口径。这篇不重复「什么能发什么别发」的原则，而是给你一份日志记录范围的对照清单、自己动手查证的动作顺序，以及不同敏感度场景下该怎么选。

很多人挑中转站只看两件事：价格和速度。提示词发出去之后到底被记成什么样、留多久、谁能看到，几乎从来没人主动问过。等到需要举证某次调用、或者突然发现某段内容本来不该外发，才回头翻服务条款，结果发现对方口径含糊，自己也拿不出任何记录。

这篇不重复「什么内容能发什么别发」的原则，那条线在站内其他文章里已经讲透了。这里只解决一个问题：一次请求经过中转站，到底可能被记下哪几层东西，你怎么自己动手查，以及不同敏感度下该怎么选。顺带说清自查的边界——有些结论只能证有，不能证无。

一次请求经过中转，可能被记下的是哪几层

把中转站想成一条流水线，日志分散在四个环节。多数人只关心内容层，但真正稳定产生记录的其实是前面两层，因为计费和风控离不开它们。先分清四层，再看每一层对自己意味着什么，判断会清楚很多。

接入层

IP、User-Agent、请求时间戳、请求路径，用来做风控和限流，基本每家都有

鉴权层

用了哪把 Key（常见做法是只存尾号）、额度怎么扣、调用频次、是否命中限速

内容层

请求体和响应体是否落库或落盘，是否只记 token 数不记正文，这一层差异最大

运维层

错误栈、重试次数、上游回包状态码，出故障排查时用，一般不涉及你的正文

接入层和鉴权层几乎可以默认一定会记，这不是坏事，没有这些它没法计费也没法防滥用。差异全在内容层：有的站只记调用元数据，正文不落盘；有的站为了「方便你查历史」把完整 prompt 和响应都存下来。两种都合理，但隐私含义完全不同。

从哪些地方判断一个站在记什么

最省事的路径是先读文字，再用控制台交叉验证。文字看三处：服务条款、隐私政策、以及有没有单独的数据处理说明。重点找留存期限、用途限定、是否用于训练、是否与第三方共享这四个点。找不到明确表述的，按更保守的一侧假设。

• 翻服务条款与隐私政策里「日志」「数据留存」「第三方共享」相关段落，重点看留存期限和是否用于训练
• 看控制台给你开了什么：有没有请求历史、能不能看自己的调用明细、有没有导出按钮
• 看账单页和通知邮件：额度扣减记录里带不带时间、Key 尾号、模型名这些字段
• 对照站内的中转站资料页核对它的公开口径，再到 /sites 看同类站的普遍做法，别只信一家

有一条经验值得记住：你能在控制台看到多少，往往说明它后端存了多少。如果它大方给你列出每次调用的完整历史，那内容层大概率是有留存的；如果只给你一个总数，反倒可能只是聚合了计费字段。

不适用的情况也要说清：纯转发、个位数请求量的小站，或者你只是临时试用几天，条款写得再细也未必和实际一致，这种场景直接按最坏情况假设更省心，别花时间抠字眼。

不靠嘴说：自己动手验证记录范围的笨办法

文字可以写得漂亮，行为骗不了人。花十几分钟做一轮小测试，比读十页条款有用。核心思路是：发一段自带唯一标记、又没有真实信息的内容，然后去所有你能看到的地方找这段标记有没有出现。

1. 造一段一次性测试内容自造一串无意义的唯一标记，比如几个随机字母加数字组合，混在一句普通提问里发出去。不要用任何真实信息
2. 跑一轮完整请求正常调用一次，记下发起的大致时间和你用的那把 Key 的特征（比如尾号）
3. 翻所有可观测入口去控制台请求历史、账单明细、邮件通知、导出文件里搜那串标记。出现在哪里，就说明那一层确实在记正文
4. 换变量再跑一次换个网络环境、换把 Key 再发一次，对比记录里能不能看到 IP、时间、Key 特征这些字段，能对上就说明这些在记
5. 把结论落成一行笔记写清哪个字段有、哪个没有、什么时候测的。以后换站或对方改版，可以拿同一套方法再比一遍

必须提醒一句：单次验证只能证明「有」，不能证明「无」。你搜不到那串标记，可能是没记，也可能是记了但没开放给你看，还可能是留存周期没到。所以这个方法用来排除「公开可查的留存」，不要用来给对方背书。

按内容给敏感度分档，比一刀切好使

「能不能发」这个问法太粗，容易走向两个极端：要么什么都不敢发，要么觉得无所谓。更实用的做法是按内容分三档，不同档位对日志的要求不一样，注意力该放的地方也不一样。

判断「算不算高敏」拿不准的时候，往上抬一档处理。抬一档的代价通常只是多花点时间做预处理，抬错的代价可能是不可逆的泄露。这条规则比任何清单都好用。

还有一层容易被忽略：中敏内容的风险不在「被看到」，而在「被留着」。今天无害的会议草稿，半年后可能变成敏感信息，而对方的留存策略不会因为你改变主意而跟着变。所以中敏内容优先做脱敏，而不是赌对方不留。

留存多久、能不能删：要问清的三件事

大部分人对日志的默认想象是「过几天自动清掉」，实际情况往往不是。与其猜，不如直接问，问的时候聚焦三个具体问题，答不上来本身就是一种信息。

• 留存期限：是滚动删除、定期清理，还是「保留至你注销」这类模糊说法；模糊表述一律按长期留存假设
• 删除通道：有没有自助删除入口、提工单能不能删、多久生效、删的是日志内容还是整个账号
• 备份与归档：主库删掉之后，备份和归档里还有没有副本。这条多数小站答不上来

问的时候建议留个记录，把提问时间和对方的回复一起存下来。第一次合作就含糊其辞的，后面出问题大概率还是同一套说辞。评估中转站时可以把这几个问题做成固定检查项，配合站内 /sites 里各家的资料页一起看。

出事时怎么把日志变成有用的东西

真需要追溯某次调用时，最怕的不是对方不留日志，而是你自己这边什么都没留。事后能拼出「哪次调用、什么内容、谁在什么时间发起」的，靠的都是平时顺手存下的三样东西。

• 调用时间与对应额度变化：能定位到具体那次请求，而不是「大概上周」
• Key 尾号：多把 Key 并行时，这是唯一能区分调用来源的线索
• 关键请求的自建标记：发之前顺手记一串标记，事后好检索

截图也有讲究。控制台列表页和详情页都要截，带上完整 URL 和时间戳，别只截一行数据；只截数字的图，事后很难证明它来自哪个页面。留证的规范可以对照站内 dispute-evidence-keep 那篇的步骤。

顺序也要注意：先固定证据，再去找对方沟通。反过来的话，对方可能在你截图之前调整了展示口径，两边说法就对不上了。不适用的情况是：如果涉及的是高敏内容泄露，优先做的事应该是止损和换通道，留证排在后面。

按场景抄作业：三类人该怎么选

同一个问题，不同角色的答案不一样。个人用户、小团队、涉及合规约束的业务，对日志的要求和可承受的成本差得很远，下面按三类分开说，直接对照自己的情况抄。

个人用户最容易犯的错是「反正内容不重要」，结果偶尔夹带真实信息；小团队最容易犯的错是全员共用一把 Key，出事之后谁也说不清是哪次调用；有合规约束的业务最容易犯的错是把日志问题当成选型问题，其实它是个法务问题。