AI API 中转会记录我的 prompt 吗?能验什么、验不了什么(2026)
把代码和业务数据发给一个中转站,它到底会不会留下来?这篇把链路拆成三层讲清楚:哪一层你能自己验、哪一层任何中转都给不了保证。含 4 个可自己动手的检查方法,以及"什么数据根本不该走中转"的判断线。
1. 先分清你到底在担心哪一层
"中转会不会看我的代码"这个问题,其实混了三件事。你的请求要经过:客户端 → 中转 → 上游厂商。中转确实能看到明文(它必须解密才能转发,这是这个形态的物理前提,任何中转都一样,声称"我们看不到"的反而要警惕)。但能看到 ≠ 会留下来。而最后一层——上游厂商留不留存——中转根本管不了,它自己也只是厂商的客户。把三层分开,才知道哪些问题该问谁。
2. 中转这一层,你能验的四件事
① 账单粒度:如果它的账单能列出每一次调用的模型和 token 数,说明它至少记了元数据;如果账单里能搜到你的 prompt 片段,那就是明确在存内容。② 条款:搜"日志""留存""训练"三个词,写清楚"不存储请求与响应内容"的,出事时你有依据;只写"我们重视您的隐私"的等于没写。③ 唯一字符串测试:在 prompt 里塞一段随机字符串(比如一串 UUID),过几天用它的搜索/客服问一次,或看它的任何面向用户的界面能不能检索到。④ 看它敢不敢让你自己查:控制台能逐笔看到调用记录、且记录里只有模型和 token 数没有内容,这本身就是一种证据。
3. 第三层为什么谁都给不了承诺
中转把请求转给上游厂商之后,数据怎么处理由厂商的政策决定。厂商对不同客户、不同套餐、不同接入方式的留存策略可能不一样,而中转只是它的一个客户,没有能力代替它承诺。所以看到"我们全链路零留存"这种话要多想一层:它凭什么替上游承诺?真正诚实的说法是"我们这一层不存,上游按厂商政策"。这一点上所有中转的处境是一样的,包括我们。
4. cocodot 这一层是什么情况
我们不存储 prompt 和回复内容:数据库里没有存放请求内容的表,账单流水里只有模型名和 token 数(形如"mcs-5 in=1200 out=340"),你在控制台可以逐笔看到,里面没有任何正文。服务器访问日志记录的是路径和状态码,不记请求体。但同样地,我们不能替上游厂商承诺留存策略 —— 上面第 3 点对我们一样成立。另外提醒一句:你在我们这里用的是我们签发的 key,不是厂商的 key,可以随时在控制台吊销、也可以设消费上限,这比共享厂商 key 的方案可控。
5. 什么数据根本不该走中转
一条实用的判断线:如果这段内容泄露会让你赔钱、违约或者违反合规要求 —— 客户的个人信息、未公开的财务数据、有保密协议约束的代码 —— 那就不要走任何中转,直连官方并签数据处理协议(DPA)。这不是哪家中转好坏的问题,是链路多一跳就多一个信任对象。反过来,如果你跑的是公开资料整理、自己的玩具项目、开源代码相关的活,中转的性价比优势是实打实的。别用一个极端场景否定另一个场景。
6. 顺手把 key 的风险也管住
不管用哪家中转,这三件事都该做:① 给不同项目用不同的 key,出事能定位、能单独吊销;② 设消费上限,key 泄露时损失有天花板;③ 别把 key 写进前端代码或提交进 Git —— 中转的 key 泄露后果和厂商 key 一样,别人能拿去花你的余额。cocodot 控制台支持建多个 key 并单独吊销。
三层链路:哪层能验、哪层验不了
| 环节 | 风险是什么 | 你能怎么验 |
|---|---|---|
| ① 你的客户端 / 插件 | 有些第三方客户端会把请求同时发给自己的服务器 | 抓包看它连了几个域名;用开源客户端 |
| ② 中转站 | 可能落库存 prompt、可能拿去训练或转卖 | 看账单明细粒度、看条款写没写、发一段唯一字符串测(见下文) |
| ③ 上游模型厂商 | 留存策略由厂商定,中转说了不算 | ❌ 验不了 —— 只能看厂商自己的政策 |
| 你的 API Key | 中转必然能看到你在它这里的 key(不是厂商的 key) | 用独立 key、设额度上限、定期轮换 |