检查流程：

1. 先检查大模型 key 全部准确，排除掉 key 配置错误导致的问题 ✅

2. 查服务器日志，按照后台异常数据的时间，精确到 21 点 20 分 56 秒 ✅

3. 但接入大模型的日志只记录了该次请求的 resp，没记录账户信息、ip 信息 ❌

4. 然后查询系统数据库，查找该记录绑定的用户信息，才想起来该接口是试用体验接口，没有用户 ❌

5. 早前考虑到有人可能会恶意刷接口，所以做了 ip 和设备号的限流，因为是用 ip作为 key 记录的数据，所以尝试从 redis 中获取 ip 信息。

6. 但因为忘记了服务器使用的 nginx 作为转发服务，是无法直接通过request.getRemoteAddr()获取到真实 ip，只会获取到 nginx 本身的 ip，即localhost。所以 ❌

7. 随后放弃查找，向客户认错，主动背锅！（挨打要立正，态度要摆正！） ❌❌❌

8. 内心 os：别骂我，我心眼小，挨骂晚上睡不着，明天还怎么改 bug 😭😭😭

9. 记录了明天要修改的 todolist 后打开了吞噬星空，罗峰，我来啦！看到一半，突然想起，nginx 有他么的 access访问日志啊！！！ 我真是个呆逼

10. 然后就查到了这个坏人的 ip 地址！ヽ(｀⌒´メ)ノ 接受制裁吧！

呆逼犯错：

1. 疏忽了 nginx 转发，导致 ip 获取错误
2. 试用体验接口和正式接口的核心计算方法没有隔离，导致坏人可以通过修改请求参数扰乱数据，虽然不会造成什么大的影响
3. 请求的模型类型简单的使用了数字类型，太简单了，是个人都知道这个 type 是不是还有 2，3，4？
4. 日志记录太粗糙了，相查点东西，满眼茫然！

后续修改方案：

直接加个手机号短信验证，让你无所遁形！请求接口我再来个签名验证！做好日志记录，做好试用数据留存！