AI不是万能的：做 Hyperliquid 聪明钱追踪，我走过的弯路

哈喽大家好，这是一期闲聊视频。

前面几期视频里，大家应该能看到，我一直在做 Hyperliquid 聪明钱追踪相关的分析，主要是分析那些地址的仓位、交易行为和胜率。

最近我想把这个项目做得更好，于是开始追细节。结果越追问题越多，方向也不断在变。所以这期视频就以这个项目为例，聊聊我在使用 AI 开发过程中的一些感想。

这个项目最开始采集的是 Hyperdash 的数据。因为当时 Hyperdash 数据分析做得还可以，当时我还不知道可以用官方的很多元数据来聚合出其他的数据。但后来我发现 Hyperdash 原来的数据接口不能用了。

经过一番摸索，我发现 Hyperdash 前端展示的数据，其实是通过原始订单聚合出来的。也就是说，它会把很多小订单按照一定规则合成一笔大订单展示出来。于是我找到了它的聚合规则，开始采集原始小订单，再自己合成大订单聚合数据。

一开始我还觉得这个方案效果挺好。直到后面我发现，原始小订单的数据量特别大。五六万个地址的时候，小订单表可能接近 2 亿条数据。虽然加了索引，但性能还是不太好。最主要的是这张表占用二三十 G。

而我买的服务器很便宜，99 块钱一年，总存储也就 50G。现在采集规模只是试个水，存储就快满了。

于是我开始给服务器加存储。最开始我挂了一块盘发现用不了，其实应该直接给服务器扩容。相当于多花了几十块钱。之后，我还是觉得不行，因为只要继续采集，存储早晚还会不够。

于是我决定直接把小订单合并成大订单。这样理论上可以直接把存储减少 99%。

并且吸取了之前只用一张表太大了的教训，我决定按地址后两位做了分区表。地址后两位是十六进制，16 乘 16，一共 256 张分区表。

就这样边合并小订单边向分区表迁移数据。

在迁移过程中，迁移速度很慢，一天时间可能只跑了四分之一，我就又改变主意，决定不如把数据全部删掉，重新采集。

采集了一段时间后我发现有些地址我聚合出来的数据和 Hyperdash 的对不上。

继续排查之后，我发现 Hyperliquid 官方的小订单接口返回是有限制的。每次最多返回 2000 条，这个我之前知道；但麻烦的是，如果更早的数据超过大概一万条，可能就获取不到被截断了。

我刚开始研究的时候，文档里并没有明确提到这个限制，应该是后来才补上的说明。然后也说明了完整数据的下载方式，有一些机构有维护完整的历史数据在云存储上。

这就意味着，如果只用接口返回订单还原历史交易，交易数据肯定是不完整的。所以从接口获取小订单这条路基本行不通。但我又懒得去下载全部数据，太麻烦了又要存一大堆数据。我一个人根本耗不起。这些都不重要，应该先找到最轻量的方式跑起来。

所以我就只能回到 Hyperdash，采集它已经聚合好的交易数据。

然后我又把数据全部删掉，改变请求方式和数据存储，采集 Hyperdash。

不过 Hyperdash 也有一些反爬措施，比如 Cloudflare 之类的限制。用 POST 直接请求会失败，需要用一些 TLS 请求库，但一个 IP 请求十几次、二十几次之后，就会提示请求次数过多。而且它的限流规则不像 Hyperliquid 官方接口那么清晰。

所以说一个 IP 肯定不够。要继续采集，就可能需要买代理。但买代理又要花钱，而且如果长期跑，成本也不低。我不想在这个项目上投入太多。

这时候我突然想起，我以前做过一个代理池项目。那个项目大概是大学时候写的，已经三年没动过了。于是我又把它翻出来，让 AI 帮我改造，加各种我临时想到的需求和功能点。

中间当然也会有很多错误，但就是不断改，改到能用。

然后我拿这些代理 IP 去请求 Hyperdash 的历史交易数据，后面发现经常一批请求全部失败，全部被限流。

我一开始很好奇，因为前面明明也有成功的请求。后来排查发现，有些地址的历史交易特别多，可能有十几万条。甚至有个地址交易次数达到了 200 多万次。每页只有 200 条的话，十几万条就要请求八九百次，这肯定会触发限流。

于是我又设置各种规则，比如历史交易太多的地址就跳过，或者限制请求次数。不停地轮换代理去请求。

但后面我又发现一个问题：当我把历史交易数据入库，并且给交易 ID 加唯一索引的时候，数据库提示有大量重复交易数据。

继续排查才发现，Hyperdash 返回历史交易的接口，在超过 50 页之后，返回的数据全是重复的。

也就是说，从它那里获取完整历史交易数据也不靠谱。

我不知道这是因为他们觉得没人会看 50 页以后，也就是一万条以上的数据，所以没处理好；还是说他们故意不开放更深的历史数据。但结果就是：订单这条路走不通，历史交易这条路也走不通。

那这个时候怎么办？

我观察了下他的页面，然后思考了下我的需求，我其实可以直接从他的网站采集每个地址的胜率。突然觉得自己绕了好大的弯路。我真正用到的核心数据，主要是地址的胜率。因为我判断一个地址是不是聪明钱，最核心的依据之一就是它的胜率。

只要有胜率，其他数据，比如当前仓位、盈亏、持仓信息，其实可以从 Hyperliquid 官网接口获取。

所以最后我又回到一个更简单的方案：只采集胜率相关的数据，其他信息从官方接口补。

整个过程非常坎坷。中间有各种问题排查，也有很多方向上的反复。

这也让我意识到，AI 真的不是万能的。

最重要的就是你提供思路和发现问题，AI 可以帮你实现和定位问题、解决问题。

尤其是在做这种项目的时候，AI 很容易带你走弯路。

比如你从一个方案切到另一个方案的时候，到底是做数据迁移，还是全部删掉重跑？到底是优化表结构，还是换数据源？这些判断，AI 不一定能直接帮你做对，还是需要你来决定选出一个最优方案。

AI 可以帮你写代码、改代码、排查问题，但真正决定方向的人还是你。

你要自己发现问题，自己判断方案，自己知道什么时候该继续优化，什么时候该推翻重来。

如果你一开始就让 AI 从一个错误方向开始做，它可能会在这个方向里不断打补丁，越改越复杂，最后陷入一个循环，自己也绕不出来。

所以这次做 Hyperliquid 聪明钱追踪，我最大的感受就是：AI 是一个很强的工具，但它不是项目负责人。它可以帮你找到网页的接口，可以帮你优化代理池的功能，完成你需要的功能。但是有时候开发一个产品并不是一开始一切都是清晰的，而是需要不断试错，遇到问题再解决问题，在做的过程中调整方向。

上面这些优化代码、定位问题虽然大部分都是 AI 完成的，但是需要我不断地去提出问题，而不是说可以直接一句话或者是写个小作文给 AI，AI 就自己寻找需求、开发测试、优化并一直迭代。这可以当作 AI 下一步的进化方向吧。

真正难的不是让 AI 写代码，而是你要知道自己到底要解决什么问题，以及什么方案值得继续做，什么方案应该及时放弃。

上面就是我这期视频想给大家分享的内容。下个视频就带大家看看整个流程的代码和流程大致是怎么样的。

大家感兴趣可以点个关注。