Forever BLog

一个版本跑得好，可能只是因为它被允许晚一点开始 前几天看榜单的时候，总觉得有些版本"数据特别漂亮"。但心里清楚：回测里每多一条规则，都可能是在给某一个版本开后门。 所以这天不干别的，把回测器里那些不公平的地方一件件拆掉，让所有版本回到同一条起跑线上。 拆掉三处"起跑线偏差"backtest_v12.py 里有几处逻辑在执行"区分对待"，全部改掉： 去掉 v1.19 的 deploy_ts BUY 过滤（backtest_v12.py line 733-735）。原来每个 version 的候选被 deploy_ts 截断过一次，现在改成对 prefetch 的全量 hot token 独立评分，不再按时间窗口截。 去掉 v1.18 的 BacktestAccount 组合约束：cash=inf, positions=[], recent_sells=[]。也就是资金无限、不设已有仓位、不记已卖记录——只保留 eng.check_buy_risk 这一道单笔硬约束（holder / liquidity / ...

数据"消失"的时候，先看它是被删了，还是根本没写进去 TVL 看板某天开始是空的。不是加载慢，是图表直接报错，一张干干净净的空白。 这天把这块看板修回来。 一块空的图页面 pages/1_tvl_rank.py 里的 Plotly 柱状图，x 轴取的是 protocol 字段： 1px.bar(x='protocol') 它读到的是一个空列，于是图表报错、数据全丢。 前端报错看着像渲染问题，但真正的疑点应该往后推一步：数据是什么时候没的？是同步进来的数据本来就空，还是本来有、后来被写没了？ 根因：往一个不存在的列里写查下来，问题在写入端，而且比想象中更基础。 tvl_rank 表原本就没有 protocol 列。而 save_tvl_rank 在做 INSERT 的时候，把协议名写进了这个不存在的列——结果数据全丢。 同时，页面又反过来用 px.bar(x='protocol') 去引用这个空列，于是一起报错。 这条链子很典型：写入端写了个不存在的目标，读取端读了个空的结果，两头各自沉默，直到图表上什么都看不见，才被人发现。中 ...

两个数据源如果答案一样，那第二个就没有存在意义 GMGN 用了一整周，能挖的字段基本都挖过了。但有一类信息它天然给不了：市场热度、社媒包装、广告投放、多池流动性快照。 这天做的事，是把 DexScreener 接成第二个数据源——不是替换 GMGN，而是补它的盲区。 先想清楚：为什么要第二个源结论很早就定了，而且这次是先想清楚分工再动手： DexScreener = 市场热度 / 社媒包装 / 广告投放 / 多池流动性快照GMGN = 链上聪明钱 / KOL 成交流 / 安全字段 / dev 信誉 / trenches 新币热榜 这两份能力清单几乎没有交集。GMGN 擅长看链上的人在干什么，DexScreener 擅长看市场在关注什么、项目方在花钱做什么。互补，不重复——这是接入的前提。如果第二个源只是把第一个源的数据再抄一遍，那接它纯粹是浪费。 8 个端点，全部不要 keyDexScreener 的公开接口实测下来很友好：全部返回 200，无需 API Key。 接口 用途 限速 ...

踩坑能教会你一个点，系统读一遍才能连成一条线 过去用 GMGN，方式是打通一个用一个，踩到坑就记一条。这样攒下来的东西很实用，但它是碎片——你能说清"这个字段是字符串"，却说不清"整套认证到底怎么设计"。 所以这天没有改任何策略代码，只做一件事：把 GMGN 的接口文档从头到尾系统读一遍。 三份笔记，一个仓库学习分了三路，最后合成一份。 第一路 t_066ec7da：完整读了 GMGN/gmgn-skills 仓库里所有核心 SKILL.md，覆盖 6 个模块、Readme 和 Wiki。产出是约 19000 字的 GMGN_OpenAPI_学习笔记.md，放在 C:/Users/Administrator/.hermes/kanban/workspaces/t_066ec7da/ 下。 第二路 t_d13a7d02：读 docs.gmgn.ai 官方文档，并用 OpenApiClient.ts 源码对着验证，产出 GMGN_官方文档学习报告.md。 第三路 t_c4e8bab0：把前两份整合成 GMGN_综合学习笔记_T1+T2+T3.md（ ...

一个数字离谱到没人信的时候，问题多半不在那个数字上 新做的 12 号页跑完之后，v1.16.4 的 BUY 数量是 15254。而同一时间，11 号页里真实成交只有两百多笔。 差了将近两个数量级。这天做的事就是把这个数字修回来。 一张对不上的表：11 页 215，12 页 15254起因很朴素：11 号页显示"买的币很少"，12 号页却显示买了 15254 次。策略筛选出要买的币本来应该非常少，两个页面却给出了完全不同的结论。 这里先要分清两个页面在干什么。11 号页读的是 sim_trades，真实跑出来的成交；12 号页是反事实回测，用历史数据按每个版本的规则重放一遍。回测的意义在于"把历史数据和样本重新过一遍，快速筛出最近真正赚钱的策略，顺带看出优化方向"——它能跑出的笔数本来就该和实盘一个量级，绝不该多出几十倍。 15254 这个数字本身就在喊"我不对"。 根因一：combo 的 max() 被避雷策略钻了空子第一层根因在 engine.py 的 score_combo()。 原来的写法是用 max() 取 4 个子 ...

接口里最贵的从来不是新端点，是老端点里没被读过的字段 前几天把 GMGN 的 27 个端点一个个打了出来，清单躺在那里。可清单本身不会下单——不把字段接进评分，它只是一份好看的能力说明书。 这天做的事很具体：从那份清单里挑出四个一直没被读过的字段，让它们真的进 combo。 从 27 个端点里挑出 4 个字段选中要改造的是 /v1/user/smartmoney 和 /v1/user/kol 这两个成交流接口。它们返回的每一条记录里，有四个字段是之前完全没用上的： maker_info.tags —— 这个 maker 被打上的标签 base_token.launchpad —— 代币的 launchpad 来源 is_open_or_close —— 这笔是开仓还是平仓 twitter_username —— maker 关联的社交账号 这四个字段的共同点是：它们描述的不是"这个币长什么样"，而是"动这个币的人是谁、怎么动的"。之前整套评分都在看币，这四段是第一次往人的方向看。 先看清这 4 个字段长什么样接之前先做了一次实战统计。取最近 ...

事情的起因很朴素，就是亏钱 v1.14 这一版，被 4 个 bsc 上的土狗反复套了 43U，而这 43U 占了我 v1.13 整版亏损的 61%。换句话说，一版的亏损里，一大半都是被同一个坑慢慢啃出来的。 复盘的时候问题其实很直白：我的信号太慢了。等热榜（trenches）刷出来的时候，行情往往已经走了 1-2 个小时，这时候再进去，基本就是给先到的人接盘。 所以 v1.15 就换了个思路——与其等一个"事后聚合"的结果榜，不如直接去接平台精选的实时成交流。这一次改造用一句话概括，就是：**让信号从"看结果"变成"看动作"**。 什么叫"内部喊单"说白了，就是平台上有一批被标记出来的"聪明钱"和"KOL"，他们真实下单的成交记录会实时公开。我盯着的不是价格涨没涨，而是这些人正在买什么。 这次接了两个流： GMGN 的 smartmoney：sol 上名单固定 15 个 maker，时延 5-15s GMGN 的 kol：sol 上名单固定 6 个 maker，时 ...

平台真正的能力边界，从来不在文档里 前一天的教训还热着：trenches 有个 type=completed，文档里没写，但返回的是全网热榜，而前十轮调优一直在最冷的数据源里打转。 所以这天不干别的，把 GMGN 到底有什么接口，从头到尾摸一遍。 为什么不能信文档用第三方数据源做量化，最大的成本从来不是写代码，而是搞清楚它到底能给你什么。 文档的问题有三个：漏的（有的端点根本没写）、错的（写了但已经不返回数据了）、含糊的（写了但字段含义和你以为的不一样）。而交易系统对这三件事全都零容忍——字段理解错一个，整套策略就是反的。 所以这一天的原则很简单：文档只当线索，结论必须自己打出来。 摸的办法：从 npm 包里挖官方客户端 [email protected] 是个 npm 包。它在服务器上跑，跟服务端保持一致——所以它里面写的路径，就是真实存在的路径。 装一个干净的探测目录： 1mkdir _npm_probe && cd _npm_probe && npm init -y && npm install gmgn-cli 然后 npx gmg ...

系统在跑，日志在滚，但一笔交易都没发生 这是做交易系统时最让人心慌的一种故障：**它不是崩了，它是"活着但不动"**。 v1.8 部署上去两个小时，0 BUY、0 SELL。进程在，决策在写，就是不下单。 四层诊断：把"不动"拆开面对这种情况，最容易犯的错是直接去怀疑策略——是不是阈值太高了？是不是信号太差了？然后开始降阈值。 但那天没有先动手改参数，而是先做了一次分层排查。因为"0 BUY"这件事，可能在四个完全不同的地方断掉： 层 卡住的表现 1. 策略层 headless 跑出来的 want 比例过低 2. 风控层 策略想买，但被 _risk_check_buy 拒了 3. 仓位层 想买，有额度，但拿不到仓位 4. 持久化层 链路断了，数据根本没进来 排查结果： 第 1 层——健康。 headless 跑 sol + bsc + base 共 120 个 token，**111 个 want=True，通过率 92.5%**。策略评分没有任何问题。 第 2 层——有问题，但只说明一件事。 那 ...

上午还在修一个报错，下午决定从零搭一整套系统 那天的开始很普通——修 page 8 的一个 format_func 报错。修完顺手看了一眼，页面上是 GMGN 的 trenches 新币数据，一行行刷出来。 然后就有了那个念头：数据都在这儿了，为什么不干脆拿它做一套模拟交易？ 拿真金白银试错太贵，但拿一套虚拟账户去跑，成本是零——而且能跑出真实的数据。 于是就有了后面这一整天。 9 号页：4 套策略 + 一套硬风控新建的页面是 pages/9_sim_trading.py，里面装了四套策略： 跟 KOL 跟聪明钱 避雷 综合 起始资金 1000U，纯虚拟。 策略可以有多个，但风控只有一套，而且是硬编码的： 规则 值 单笔金额 30U 同时持仓上限 5 止损 30% 止盈 100% rug 比率 > 0.6 强平 sniper 数量 > 5 强平 最长持仓 72 小时 价格超时 24 小时未更新强平 把风控写成常量而不是配置，是刻意的选择。策略是要被反复比较的对象，风控不是。 如果风控也能随手改，那两版策略的收益差异就说不清是 ...