记录一次换赛道（2026-07-06）

承认一条路走不通，比修好它更难

新币模拟跟单这条路，我走了很久。

这天不再往里面加策略了，而是把一件早就该写下来的事写下来：经 http://0.0.0.0:8501/ 验证，模拟跟单新币完全不赚钱。 然后转了方向——用策略交易主流币，BTC、ETH、SOL 这些。

先把结论摆出来

数据本身没有再辩的余地：

• 总交易 2301 笔，全部是新币 / meme 币
• 总亏损 −$1,876
• 平均每笔 −3.7%
• 涉及 518 个不同代币，全是 Sol / Bsc / Base 链上的垃圾币

亏钱不稀奇，稀奇的是 518 个代币、2301 笔之后，还是同一个方向的负收益。这说明问题不在某一次判断，而在策略依赖的那个市场本身。

盘一下手上的牌

转赛道之前，先看清楚自己有什么。第一轮盘点是这样的：

第二轮把 MySQL 那格纠正过来了：本地 MySQL 其实在跑，库 cypto_cache，37 张表；mysql-connector、requests 也已装。

真正缺的是三样：交易所接口（ccxt）、技术指标库、以及主流币 K 线的存储表。

不上 CEX，去链上

盘点里最硬的一条是：GMGN 只做 DEX，不支持 BTC。 所以第一反应是"那得上 CEX，去 Binance / OKX 开个 API Key"。

但随即确认了一件事：不上 CEX，用链上的合约。

链上的永续合约一样能做多空，而且手里的 GMGN Key 和 Helius 本来就在。方向定下来之后，需要补的就只剩工具：装 ccxt、装 ta、写一个 BTC/ETH/SOL 的历史 K 线拉取脚本。

顺便定了几条硬约束：脚本不能跑死、数据量太大要想办法优化、历史数据要落库、**展示界面用 http://0.0.0.0:8501/**。

先把 K 线搬进库里

先装库，再写模块 maincoin_kline.py，然后拉数据。

第一次跑就撞墙：Binance API 被墙了。

查下来是 Clash 在跑，但代理环境变量没设。给模块补上 127.0.0.1:7890 代理之后通了，BTC/ETH/SOL 日线 60 条入库，再拉 4h 数据也顺利。

拉到后面，库里是这样的：

点一次「一键拉取全部」之后，8595 条 K 线，三个币各 4 个周期全覆盖。

模块里定了几条防呆规则：增量更新（只拉库里缺的）、防卡死（15 秒超时 + 3 次重试 + 200 次最大迭代）、批量写入（每 500 条一批 INSERT）、**INSERT IGNORE**（重复数据自动跳过）。同时加了 15 号页「主流币 K 线行情」，K 线用 Plotly 暗色主题，叠 MA7/25/99、RSI、MACD、布林带。

先跑两条最简单的路

数据齐了，写三套策略：双均线趋势（MA7/MA25 交叉 + RSI 过滤 + MA99 确认）、布林带回归（触上下轨 + RSI 确认）、多周期共振（日线 + 4h + 1h 三周期共振）。先拿前两套去回测：

初步结论：ETH + 双均线最好（夏普 1.95，正收益），BTC 偏弱，SOL 波动太大，布林带在当前市场不如趋势策略。

从 3 个币到 10 个币

三个币的样本太薄，于是把范围扩大：排除稳定币，取成交量前十。

最终确认的 Top 10 是：BTC、ETH、SOL、XLM、BNB、XRP、ZEC、TRX、DOGE、TLM。把预计算脚本改成自动取成交量前 10 并建表，页面从 DB 动态读币种列表，重跑一遍——约 110 秒，10 个币 × 2 套策略 = 20 个回测结果，18713 条 K 线。

按夏普排，亮点是这样：

• 🏆 ZEC + 双均线：+28.3%，夏普 8.79
• TLM + 布林带：+11.4%，夏普 2.93
• DOGE + 布林带：+4.6%，夏普 2.34
• ETH + 双均线：+1.4%，夏普 1.95

ZEC 这个 8.79 的夏普很好看，但也最需要警惕——样本里的极端值，往往不是策略的常态。 记下来，但不当结论用。

页面只读库，不计算

中途改了一次架构，值得单独记。

原本三个 Tab 都是按钮触发计算，后来要求打开页面就自动跑，再后来要求预计算存库、页面秒加载。于是有了 mc_precompute.py：

1
2
3
4
5
6
7
8
9
10

python mc_precompute.py     ← 每次跑一次，25 秒搞定
         ↓
    MySQL 存储
    ├── mc_bt_results       ← 回测结果（净值曲线 JSON + 交易明细 JSON）
    ├── mc_signals_latest   ← 最新信号 + 技术指标
    ├── mc_sim_account      ← 模拟账户
    ├── mc_sim_positions    ← 持仓
    └── mc_sim_trades       ← 交易记录
         ↓
    http://0.0.0.0:8501/   ← 页面纯读 DB，秒加载

页面改成零计算、纯 SELECT。踩的坑也都记着：signal 是 MySQL 保留字，要加反引号；MySQL 5.6 不支持 JSON 类型，改成 TEXT。

把计算从"打开时"挪到"预计算时"，是这类看板唯一能既快又稳的做法。

只用了两个数据源

最后一件事，是重新看了一遍"我们到底有多少牌"。

答案是：手上 10 多个数据源，策略只用到了 2 个——K 线（OHLCV）和技术指标（RSI/MACD/MA/BB）。Order Book、逐笔成交、资金费率、CoinGecko 市场数据、GMGN 链上数据，全都没用上。

这一看就知道，双均线 + 布林带只是最薄的起点。真正能在链上合约上做的，有 14 个方向：

• 资金费率类：费率反转、费率趋势共振、费率套利
• 持仓量类：OI 背离、多空比反转、清算磁吸
• 量价类：盘口不平衡、鲸鱼追踪、放量突破
• 技术指标类：ADX 多周期、SuperTrend、RSI 背离+量
• 宏观类：BTC 主导率、恐贪逆向

而且链上合约有它独有的数据优势：资金费率、未平仓量、多空比、链上订单簿——这些是 CEX 策略拿不到的一手信息。

于是最后一句定下来：全部做进去。

第二天做的，就是这件事。

最后

三层。

表面是一次换赛道：新币跟单停了，主流币策略开始了。2301 笔、−$1,876 是这条旧路的墓志铭。

中间是一次资源盘点：GMGN 不支持 BTC，所以要么上 CEX、要么做链上合约；本地 MySQL 其实一直在跑；缺的是 ccxt、TA 库和 K 线表。方向的选择，最后是被"手上有什么牌"决定的，不是被"我想做什么"决定的。

最里面一层，是承认失败这件事的难度。

修一个 bug 是舒服的——你总能感觉到自己在接近答案。但承认整条路不赚钱，是把自己的努力判了死刑。2301 笔里每一次调参、每一个版本号，都是投入，人是有沉没成本的。

但它必须被承认。在一个不赚钱的市场里继续优化策略，不是勤奋，是在错误的地基上盖楼。 那天之后我把这句话又写了一遍：先看清自己站在什么样的地上，再决定要不要往上盖。