匿名接口调付费 AI，别等账单教你做人：四个最容易漏的洞
有一晚我顺手看了眼模型服务商的后台，发现调用量的曲线和网站流量的曲线对不上。流量几乎是平的，调用量却在往上爬。
那天没出事，只是一个很小的异常。但我盯着那条曲线想了很久：如果这是一次真正的刷量，我会在什么时候知道？ 是当晚，还是月底账单出来的时候？
我问了自己最坏情况的问题：一个完全不认识我的人，一天最多能让我花多少钱？我答不上来，这才是真正的问题。
做匿名可用的 AI 功能，转化好，门槛低，但每个请求背后都是真金白银。我每月花在 AI 与基础设施上大约至少 1000 美元（这是成本，不是收入），所以这笔账我不敢不查。服务端分不清真人和脚本，你的账单只会按调用次数涨。下面是我顺着这个问题查出来的四个洞。只写机制和方向，不写任何能照着利用的细节。
为什么会发生：四个洞
洞 1：匿名接口直接连着付费模型
最基础的一个：接口不要求登录，也不验证请求者是不是真人，收到请求就转给按量计费的模型。
这类风险不是被「黑」，而是被「正常使用」。任何人都能调，调多少都是你付钱。
解法是在调用模型之前先过一道人机验证：前端拿一次性令牌，服务端校验通过才往下走，失败就一分钱都不花。顺序也要记牢：人机验证 → 限流 → 模型调用，别反过来。
洞 2：限流出错时选择放行
这个洞最隐蔽，因为平时测试永远看不到。
限流通常要靠某个存储来记次数。逻辑一般写成「查存储，超限就拒绝」。但很少有人认真想过另一个分支：存储本身查询失败呢？ 很多实现在这里选择放行，理由很朴素，怕限流挂了把正常用户也挡在外面。
结果是限流只在存储健康时有效。存储抖动、超时或被打爆的时候，限流整体失灵，而这恰好是流量最异常的时候。
对连着计费的接口，应该 fail closed：出错就拒绝。宁可让一部分正常用户看到一句「稍后再试」，也别在保护层失灵时把闸门打开。我现在给自己定了个习惯：review 任何保护层代码，都要单独问一句，出错的时候，这里是开还是关？
洞 3：没有全站日上限，也没有独立封顶的 key
前两个洞补上后，还有一个结构性问题：没有任何一层在管总量。
人机验证和限流管的都是单个请求者。如果请求者看起来各不相同，或者验证被某种方式绕过了，这些单点防护加起来，并不能保证全站一天的总花费有天花板。
所以需要两样东西：
- 全站级的日上限。 当天付费调用累计到线，就整体暂停。它不必优雅，只要能挡住最坏情况。
- 每个站、每个付费功能一把独立的、有额度封顶的 key。 别多个项目共用。一处出事，不会拖垮别处。
服务商后台的账单告警和硬上限也算这一层。代码里一份，后台里一份，两边都放。
洞 4：预览地址和默认域名成了旁路
托管平台往往会给同一份代码额外分配对外入口，比如预览地址、平台默认域名。你在正式域名上配好的防护，不一定覆盖这些入口。
主站看起来关得严严实实，旁边的入口却敞着。攻击者不需要攻破什么，换个入口就行。
解法很直接：正式流量只走你绑定并配了防护的域名，多余入口要么关掉，要么挂上同等强度的防护。
一份能照做的检查清单
一个晚上能走完一遍：
- 列出所有「匿名可达、且后面连着计费」的接口。 不登录就能调、调了你要付钱，就是重点对象。
- 在调用付费模型之前加人机验证。 顺序固定：人机验证、限流、模型调用。
- 逐个检查保护层的异常分支。 限流、校验、额度查询出错时，默认拒绝。
- 加全站日上限。 到线整体暂停，并在服务商后台再设一层告警和硬上限。
- 每个站、每个付费功能用独立的封顶 key。 自己测试也用它，不借别处的。
- 核对所有对外入口。 正式域名、预览地址、默认域名、旧域名，防护是否一致，不需要的直接关。
- 新功能先小额真测成本，再定价。 小额就够，比凭感觉靠谱。
- 每次改动后回头问一句：最坏情况下，一个陌生人一天能让我花多少？ 答不出来，就是还没做完。
阈值我不写，因为你的流量、成本和承受力都跟我不同，写出来要么没用，要么有害，得自己定。
最后
匿名 AI 功能本质上是一笔你自己付的获客成本，成本有没有天花板，比功能好不好用更先决定它值不值得做。
如果你还在犹豫要不要做这类功能，可以先看独立站变现的几种方法，把能付多少算清楚。想了解怎么把「相信」换成「核对」，让自动化流程替你守红线，看Agent 协作那篇。
想持续看后续，可以订阅 /posts 的 RSS，我分三条线更新：Agent 协作、SEO·出海、商业化。