记录一次隐藏信号的改造（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 个字段长什么样

接之前先做了一次实战统计。取最近 1 小时里的 300 笔成交，看这些字段的实际分布：

几个数字值得停一下。pump 占了 32%，也就是说差不多每三笔里就有一笔来自 pump 类 launchpad，这个体量比预想的大。top_followed 15% 是有价值的——被大量跟单的地址本身就是一层信号。而 wash_trader 只有 6%，snipe_bot 只有 2%——比例低不代表可以忽略，恰恰相反，它们是被明确标注出来的坏样本，一旦命中就应该一票否决。

ioc=0（加仓）占 41%，这个字段直接告诉你是新进还是追加。

落库：加 3 列，改 5 个文件

要让这些字段能进评分，先得让它们能存下来。db.py 里的 sim_smart_money_signals 表加了三列：

1
2
3

tags             VARCHAR(200)
twitter_username VARCHAR(100)
balance          DECIMAL(30,9)

然后改动铺在 5 处文件上：db.py（建列与读写）、data_sync.py（同步时带上新字段）、9_sim_trading.py（实盘评分消费）、10_review.py（复盘统计）、analysis.py（新增第 13/14 节 UI 报告）。

一条数据从接口到评分要穿过这五个文件，任何一个环节没接上，字段就是死的。这也是为什么改造这种事必须先列文件清单——漏一个文件，症状往往不是报错，而是"这个字段好像没生效"，然后你要花很久才发现是同步层没带过来。

combo 里的四段新规则

字段接通之后，真正决定行为的是 combo 里新增的四段：

1
2
3
4

WASH_TRADER_PENALTY      -10   （一票否决）
GOOD_TAGS_BONUS           +1
IOC_BONUS                 +1
PUMP_LAUNCHPAD_PENALTY    -2

WASH_TRADER_PENALTY 给的是 -10，这个量级不用算也知道是一票否决：任何一条带着 wash_trader 标签的信号，无论其他分多高都会被压下去。剩下三条是轻量微调，+1 奖励好标签和加仓动作，-2 给 pump 类 launchpad 扣一点分。

这种"一条重罚 + 几条轻加"的结构是我偏好的：否决项要足够重，重到不需要讨论；加分项要足够轻，轻到不会把主信号带偏。

v1.16 上线，和它带的三个坑

版本落地：tuning_log 记到 id=47，sim_strategy_versions 里 v1.16 置 is_active=1。两个进程都在跑，sim_loop PID 53428、streamlit PID 54172，健康检查 5/5 全绿。

上一版的健康巡检 cron adc3c10393d5 也顺势升级成了 v1.16_health_patrol，prompt 里加了 4 个指标的验证。openviking 里落了 4 条资源，跟前两版并列。

上线过程中踩到三个坑，都记了下来：

1. **sim_strategy_versions 的列名是 params_json，不是 params**。params 是 v1.15 时代的叫法，已经弃用，upsert_strategy_version 收的是 dict。
2. pymysql 的 DictCursor 是 cursorclass 参数，不是 cursor kwarg。名字看着像，传错了不报错，只是拿不到想要的东西。
3. **init_db() 里写的 ALTER 是"理论上对"**——因为 sim_loop 启动时根本不调用 init_db()。所以 v1.16 的 ALTER 必须手动跑 scripts/_v16_alter_table.py。

第三条是个长期遗留问题，当时留在记录里，写了一句"留给 v1.17 评估要不要在 sim_loop 启动时自动 init_db()"。它不影响这一天，但它是那类"不改就会在下一个版本再疼一次"的问题。

v1.16.4：当天最后一次参数调整

改造上线之后，参数还在继续收。当天 23:46，v1.16.4 部署：

1
2
3
4

STOP_LOSS      0.08
TRAILING_STOP  0.30
MIN_HOLD       15 分钟
COOLDOWN       30 分钟

回看这一小节几个子版本，能看出调参的方向：

v1.16.1 那条特别值得看：修完漏调之后，30s 一次同步，2 分钟内 347 条数据入库，35 笔交易平均单笔 -0.04U，几乎是平的。这是这一串版本里最接近盈亏平衡的一版。

不过全系看下来，结论并不乐观：GMGN 隐藏信号接进来之后，波动被压下去了，盈利性却没有跟着起来。这一点让我对"多加字段就能多赚"这个假设第一次产生了明确的怀疑——它被记了下来，没有当场下结论，因为样本都不够。

最后

这一天的收获，也分三层。

最表面的一层，是那 4 个字段进了库、进了 combo。从接口能力到实盘行为，中间那条链路是真的接通了。

中间一层是那条判断：字段的价值不在于它有多新，而在于它描述的是币还是人。tags / launchpad / is_open_or_close 都不改变币的形态，只改变我们对"谁在动它"的认知。从看币转向看人，是这次改造真正的方向。

最里面一层，是那份克制。 v1.16.1 平均单笔 -0.04U，看着像要翻身了，但样本只有 35 笔；v1.16 全系拿掉了波动却没拿回收益。这两件事放在一起，最自然的反应是"再加字段试试"，而我选择的是先把"没赚到"这个结论记清楚，再决定下一步。

技术活做久了会形成一种惯性：只要有新接口、新字段，就觉得接上去一定更好。可 2026 年 6 月 9 日这天教给我的是相反的——信号加得越多，越要盯住那个没被改善的数字。