Forever BLog

记录一次全量验证（2026-06-18）验证不是"看起来没报错"，是把每一格都点开看过 v1.25 的代码前一天已经写完、入库、冒烟。但"写完"和"验证完"之间，隔着一段必须走的流程：换一个干净进程、把回测跑满、把每个页面的数据源挨个查一遍。 这天做的就是把这段流程走完。全量验证，一个页面都不跳。 先换一个干净的进程验证的第一原则是别在旧的进程上验。 杀掉旧进程（417088、416872），重启 4 个新实例，主进程 PID 402864 加 3 个辅助进程，port 8501 返回 HTTP 200。 为什么非要重启？因为旧进程里可能还残留着改代码之前加载的模块。**要验的是"现在这份代码"，不是"过去某个时刻加载过的代码"**——不重启，验的可能是一份已经不存在的版本。 104 秒，50 个版本backtest_runner.py 跑完，耗时 104s，exit 0，50 个版本回测完成，结果写入 bt_cf_summary 和 bt_cf_trades，最新 run_at 是 ...

记录一次版本的收尾（2026-06-17）一个版本真正花时间的，从来不是写它的那部分 写新功能的时候人是兴奋的，收尾的时候不是。 v1.25 这天要做的，全是最不性感、也最容易漏掉的事：入库、冒烟、补文档、接线。一天下来三个任务，没有一个是"新功能"，但没有一个可以跳过。 第一件事：让版本号在库里落地一个版本如果只在代码里，就不算发布。 tuning_log 表 INSERT id=91 成功，SELECT ... WHERE version='v1.25' 返回 1 行。到这一步，v1.25 才算被系统"认领"。 这一步看起来只是插一行数据，意义却不小：这张调优日志表，是后面所有版本对比的索引。没有这一行，v1.25 的回测结果就是一份没有出处的数字。 冒烟测试：4/5 通过cg_smoke_v125.py 跑了 5 项，结果如下： 检查项 结果 ping [OK] CG Demo 可正常访问 /global [OK] BTC dominance 56.25%，总市值 $2.325T /coins ...

记录一次回测版本的公平化（2026-06-16）一个版本跑得好，可能只是因为它被允许晚一点开始 前几天看榜单的时候，总觉得有些版本"数据特别漂亮"。但心里清楚：回测里每多一条规则，都可能是在给某一个版本开后门。 所以这天不干别的，把回测器里那些不公平的地方一件件拆掉，让所有版本回到同一条起跑线上。 拆掉三处"起跑线偏差"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 ...

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

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

记录一次接口文档的系统学习（2026-06-11）踩坑能教会你一个点，系统读一遍才能连成一条线 过去用 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：把前两份整合成 ...

记录一次回测链路的抢修（2026-06-10）一个数字离谱到没人信的时候，问题多半不在那个数字上 新做的 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( ...

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

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