量化

平台真正的能力边界，从来不在文档里 前一天的教训还热着：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 小时未更新强平 把风控写成常量而不是配置，是刻意的选择。策略是要被反复比较的对象，风控不是。 如果风控也能随手改，那两版策略的收益差异就说不清是 ...

数据频率一换，累计算法不换，报表就是 100% 假象。 今天这一天基本都耗在 factory_api_server.py 和前端报表上。数据库从旧表 work_load 切到新表 work_load_0521，本来以为只是换个连接串，结果时间字段从时段变成每 10 秒一条快照，利用率算法也跟着塌了，改到第三轮才把口径理顺。 一、新表 work_load_0521：TIME 是单点快照，不是 START/END拿到的新库配置很直接：100.64.0.2:3306，表名 work_load_0521，每 10 秒记录一次人员及工时。字段里 TIME 代表记录时间，worker_num 是人数，workload 是总工时，area 和 main_area 保持原意。 跟旧表 work_load 放一起，差异一眼就能看出来： 维度 旧表 work_load 新表 work_load_0521 时间 START_TIME / END_TIME TIME（快照单点） 工时 WORKTIME（秒） 无此字段，WORKLOAD 为累计值 频率 不定时 10 秒一 ...