从"免单幻觉"到负责任的披露：一次真实的 AI 通道逆向与一个被封的号

让 AI 操控 AI：我扒了一个 AI 编程助手的通道，然后被风控封了号

这事儿的起点，是一个很朴素的念头：用 AI 去操控另一个 AI，行不行？

我当时天天用一个桌面 AI 编程助手，界面里明晃晃写着能免费调好几个大模型。我就想，既然这些模型能被这个软件调起来，那我能不能绕开这个软件，让别的 AI 直接去调它们？等于给 AI 之间搭一座桥，一个 AI 当大脑，另一个当算力，我自己在旁边看。

后来的事情证明，这个念头把我带进了一条特别有意思的路：我扒开了这个助手的底层机制，发现了它背后藏着一个可以直接对话的云端通道，动过把它嫁接到我本地模型里的心思，然后——因为一个越界的操作，被风控当场封了号。

今天把这条路的每一段都如实写出来。技术细节我讲透，但你不用懂协议也能看懂。最后那个漏洞，我已经整理成报告递给了开发者。

一、第一铲子：我想在本地改改数字

一开始，我的想法跟大多数人一样。软件跑在我电脑上，配置也在我电脑上，那"免费额度"总该是个本地文件里的数字吧？改一改，说不定就免单了。

结果第一铲子就挖到了石头上。

我试着向它背后的服务端传一个不在白名单里的模型名。服务端连蒙都不蒙，直接甩回来一个 400，还顺手把我这个账号"当前能用哪些模型"的清单列给我看。那一刻我明白了一件事：模型白名单根本不在本地。 客户端界面上显示你能调谁、标榜支持谁，全是 UI 表演，真正拍板的是服务端那页清单。

我又去改客户端配置里的"积分倍率"字段。界面上数字真变了，看着是"便宜了"。但我每发一句话，服务端返回的扣费明细里，那个数纹丝不动。本地这个倍率，纯摆设。这给我上了一课：凡是跟钱有关的账，服务端只认自己算出来的数，本地给的依据它一眼都不看。

不过，塞翁失马。正因为服务端把扣费明细大方地返了回来，我拿到一个特别有用的东西——响应里有个叫 credit 的字段，就是这次调用真实扣掉的费用。后来我所有"省钱有没有效"的判断，全靠盯着它。没有这个字段，你调一百个参数都只是在自我感动。

我还顺手验证了一件事：同一个问题反复问，每次都是真刀真枪地推理、真金白银地扣费，没有任何"缓存命中"的白嫖空间。服务端记账是"推理一次记一次"，没给重放留后门。

这几条凑一块儿，真相浮出来了：这个产品把所有的权威都收在云端，本地只是个传声筒。 这设计其实挺聪明的——至少你想在本地改账，门都没有。

二、四条野路子，全废了

但好奇心这东西，拦不住。既然"本地改数"死了，最容易想到的几条野路子，我总得试完才甘心。结果全废了，我挨个说，你也能少走弯路。

我在请求里塞了些自以为聪明的字段，什么 free、tier、credits，意思是"求你免个单"。服务端看都没看，直接忽略，该扣照扣。

我把上一次请求的 id、会话 id 原封不动复用，赌它能"重复利用"。没用，每次 id 独立计费，重放就是个寂寞。

我同时甩好几个请求出去，赌它的记账在高并发下出个竞态漏洞。人家记账是原子化的，三个并发全给我独立扣了费，一个子儿没省。

同一个问题问八百遍，赌哪次命中缓存。前面说了，没有缓存，每次都是真推理。

踩完这四坑我彻底死心：凡是"绕结算"的念头，在云端那本权威账本面前全是徒劳。 想省钱只有一条路走得通——把每次请求的真实成本打下来。这个我后面讲，先记住这句：绕是不可能的，降才是正道。

三、发现通道：原来可以直接对话

真正让事情变得好玩的，是我把客户端发出去的完整请求截下来看了一眼。

一个请求，居然有两万两千多个输入 token。可我真正想问的那句话，才几十个 token。钱花哪儿了？七成六花在"工具定义"那一大坨 schema 上，剩下的被系统提示词和记忆注入吃掉了。

也就是说——客户端每次调模型，都扛着一身重得要死的"装备"上路，而云端的通道本身，只要一句人话就能对话。

这个发现直接改变了我整个思路。我绕开客户端，直连云端通道，只发一个裸请求：

{
  "model": "目标模型",
  "messages": [{ "role": "user", "content": "一句话问题" }],
  "stream": true,
  "max_tokens": 1024
}

就这。输入 token 从 22794 掉到 22，降了 99.9%，回复质量一点没差。

顺带一个坑得提醒你：这通道要求必须流式（stream 得是 true），非流式发过去，它直接 400 把你打回来（错误码 11101）。这不是 bug，是它对"裸请求"的硬约束——反过来说，它在协议这一层就把某些调用形态卡死了。

走到这一步，我眼前的东西已经跟最开始完全不一样了：一个免费的、可以直接对话的云端通道，就躺在那里。

四、动念：把它嫁接到我的本地模型里

通道打通了，下一个念头几乎是自然而然冒出来的：我能不能把这个通道，直接嫁接到我本地的 AI 工具里，让它看起来就像我本地的一个模型？

说白了，就是给我自己的 AI 装一个"外挂模型"。我本地发一个请求，它把话传给云端通道，云端模型答完了再传回来——全程就像在调一个本地模型一样自然。

这个念头本身不违法，它就是个"通道适配"的工程活。而且做这件事的过程中，我还攒下了几个实打实能省钱的本事：

关思考有讲究，而且每个模型不一样。 你以为关掉模型思考就是传个 none？大错特错。我实测下来，Kimi 那一支得传 minimal 才是真把思考预算掐死，能从两千多思考 token 降到个位数，省九成；手滑传了 none，它只当你是"软建议"，只降 13%，该烧还烧。GLM 那一支倒是传 none 就彻底关了，省七成。还有些模型，你最好压根别传这个参数——传了反而把思考"唤醒"，烧得更凶。铁律就一条：省思考的参数，必须每个模型亲手测。

白名单里藏着一个免费模型。 它的 credit 是 0，用它跑批量、跑草稿、跑采样，一分钱不花。这是"免费"里唯一合法成立的一条——不是绕过去的，是通道自己就把它设成免费。把它当草稿机、预处理器，正经活交给付费模型，整体成本压得很低。

每次把 credit 打出来。 这是你的扣费小票。任何省钱招数，没它佐证都是玄学；有了它，省多少、哪个参数最管用，全是看得见的数据。给你个量级感受：小任务两三百 token 大概 0.06 credit，带思考的三五百 token 约 0.11，单次基本在几毛钱以内——但工具定义带来的固定开销，会让"每轮对话"明显高于"单次问答"。

到这儿为止，一切都是干净的：机制看懂了，成本降下来了，嫁接也接上了。如果没有下一步，这会是一个很圆满的技术探索故事。但我的好奇心多走了一步——一步越界的棋。

五、越界：本地 token 直连，然后号没了

这事儿得从登录态说起。这类桌面助手登录之后，会在本地存一个 token，相当于你在这套系统里的"门禁卡"，证明"你是谁、能调哪些模型"。问题出在：这张卡是以一种别的程序也能轻易读到的形式，安静地躺在本地。

我脑子里冒出的想法是：既然我有这张卡，通道又在那儿，那我直接拿卡去调通道，是不是连官方认证都省了？

路径走得通。我拿着本地 token，确实能直接向云端发请求、拿回模型响应。那一刻我还挺得意。

然后，啪，403。

不是"这次请求失败"那么轻描淡写。是服务端统一甩回来一个 403，错误码 11140，性质是账号级风控。意思是：整个账号被标记了。封号级别的处置。

我后来复盘才想明白它怎么做到的：服务端有一套异常调用检测。当某张卡的"使用形态"——来源、频率、请求结构——明显偏离了"正常桌面客户端"的基线，它就触发账号级风控。

一句话总结这段经历：漏洞是有的，但人家的检测也有，而且当场就生效了。

所以，我在这里郑重劝一句：别学我这一步。 拿本地 token 直连，性质上是绕过客户端认证、违反服务条款的行为。你以为自己是"技术探索"，服务端眼里你就是异常流量；你以为省的是钱，实际丢的是账号。那个被标记的号，就是代价。

六、这确实是个漏洞，我已经报上去了

但换个角度看，这条路径的存在，本身就是一个值得修的设计缺陷——登录态以一种"谁都能读"的形式躺在本地，谁拿到就能绕壳直连。 这不该只是"谁踩谁封"的猫鼠游戏，而该从根上收口。

所以我没有藏着掖着。我把整条链路、检测结果，连同修复建议，整理成一份报告递给了开发者。修复建议我摊开说，这才是负责任披露该有的样子：

第一，本地那张 token 卡，不该以"谁都能读"的形式长期驻留。 它应该绑设备指纹、走系统级的密钥库，并对 token 做使用上下文校验，让它没法被别的程序直接拿去用。

第二，直连请求该做来源鉴权。 现在的 403/11140 是"抓到了再封"，有效但属于事后。更稳的做法是在协议层就把"合法客户端"和"裸 token 直连"区分开，比如设备 attestation 或者请求签名，从源头把可滥用的口子收小。

第三，我得替它说句公道话。 现有的"本地是壳、云端是账本"设计，本身是安全的——它保证了计费不能本地篡改、白名单不能本地伪造，这点要肯定。要补的只是"登录态在本地怎么保护好"这一环。

第四，官方 API Key 通道应该成为唯一被支持的编程入口。 把"拿本地 token 直连"这种灰色路径，收敛到"申请官方 key、走官方端点"的正道上来。既满足开发者的调用需求，又彻底消灭 token 泄漏的滥用面。

我自己后来也想透了：逆向的价值，在于看清机制、找到那些合法的省钱参数，而不是去偷 token。那次被封号，对我个人是个教训；对这个产品，反而是一次"风控没在睡觉"的证明。

七、回头看：一套能复用的打法

这一圈走下来，我沉淀了一套打法，任何"本地客户端 + 云端计费"的 AI 产品都通用：

先抓包，看客户端到底发出了什么真实请求——别猜，看真实的流量，这是一切的起点。然后做减法，把字段一个一个删掉试，看哪个把 token 撑大了，成本构成就清楚了。再然后测参数的真实语义，同一个参数在不同模型上意思可能完全相反，必须亲手测。还要找那个能观测的锚点，比如响应里的 usage、credit，没它你永远在瞎蒙。最后，永远分清"绕过"和"降本"——绕结算必死，降请求成本、用免费额度、关思考，才是活得久的正道。而一旦看到漏洞，负责任地披露、推动修复，比写成"绕过教程"有价值得多，也安全得多。

写在最后

回到最开始那个念头：用 AI 去操控另一个 AI，行不行？

行。这条路上我扒开了壳、打通了通道、接上了模型，也撞上了边界。现在我可以完整地回答这个问题了：AI 连 AI 是可行的，而且会越来越普遍——但连法有正道和歧路之分。正道是把接口走通、把成本降下来、把边界看清楚；歧路是拿登录态去绕认证，看起来是捷径，其实是悬崖。

我平时看东西就带点安全测试的眼光，你们叫红客也行。我的立场一直很清楚：机制可以研究、可以讲透；省钱可以合法地做、可以分享；但凡涉及绕认证、盗用登录态的路径，看到就报告、就推动修掉——因为它一旦落到坏人手里，埋单的是所有正常用户。

那次封号，对我是个教训；对这个产品，是一次风控确实在岗的证明。链路和修复建议我都递出去了。剩下的，就看开发者了。