量化

记录一次实盘前的复盘（2026-07-31）在真金白银进场之前，最有价值的动作不是再加一个策略，而是把「能不能加」的标准写死 这两条复盘记的是同一种东西：面对一个「看起来成立」的策略，怎么在它变成实盘仓位之前，把它问倒。它们不是技术日志，是判断标准——所以值得单独留下来。 一条「对称」的诱惑第一条来自一个很自然的念头：既然 24 小时反转策略（做空高动量）是有效的，那它的对称腿——做多低动量——是不是也该有效？ 需求写得很直白：验证这条对称多头腿的有效性，判断能不能加进现有策略组合。 「对称」两个字最诱人，也最容易让人偷懒——如果因子 IC 是对称的，做空高动量有效，做多低动量似乎就该成立。但「似乎」不是证据。 方法：不新造轮子验证没有另起炉灶，而是复用已验证的横截面回测框架，参数和已有策略完全保持一致： 12 个主流加密货币 5000 根 1h K 线 24h 持有期 120min 冷却期 5% 止损 / 15% 止盈 1bp 手续费 IS / OOS 切分点：2026-07-31 唯一改动的，只有信号方向——从做空最高动量，改成做多最低动量。 回测要输出三 ...

记录一次实时信号架构（2026-07-14）把「读旧表交易」改成「每轮自己算信号」，是这套系统第一次真正意义上的实时化 前一天把止盈从 5% 调到 3%、又给信号刷新补了坑，第一批仓位陆续有了结果：三笔 +3% 附近止盈、两笔 -2% 止损，胜率 60%。数据能看，但更值得记的是那天对架构动的刀——主流币模拟交易从「读表」走向了「实时计算」。 三条并排的问题改架构之前，问题其实是三条并列的： 止盈 5% 太高 → 已经降到 3% 信号每 2–4 小时才刷新一次 → 平仓之后没有新信号可用（旧信号被「过期 > 4h」跳过） 开仓太随意 → 只要有一条信号就想开仓，缺一道「够不够格」的判断 前两条在前一天已经处理，第三条才是这天架构改造的动机。 从「读表交易」到「实时计算」旧架构是标准的三段式流水线： 1mc_precompute.py（定时）→ mc_signals_latest 表 → maincoin_paper.py（读旧表交易） 它的命门很明显：中间那张 mc_signals_latest 一旦不刷新，整条链就断在「过期跳过」上——前一天那场「平仓后开不出新仓」，就 ...

记录一次止盈参数的调优（2026-07-13）止盈设得太高，本质上是把「不想太早下车」写进了参数里 17 号页的 5 个仓位挂了 12.9 小时，一笔平仓都没有。看了一眼持仓就有人问：持仓这么久还没操作，止盈是不是太多了。这一问，引出来的不只是止盈那一个数字。 12.9 小时，0 笔平仓先把当时的持仓摆出来： 币种 方向 入场价 现价 浮盈 距止盈 距止损 BTC SHORT $64,045 $63,725 +0.5% 还差 4.5% 2.5% ETH LONG $1,807 $1,819 +0.6% 还差 4.3% 2.6% SOL SHORT $77.14 $77.04 +0.1% 还差 4.9% 2.1% ZEC LONG $523.8 $533.9 +1.9% 还差 3.0% 3.8% XRP SHORT $1.10 $1.09 +1.1% 还差 4.4% 3.0% 持仓 12.9 小时，0 笔平仓记录，账户余额 $4,437（另外 $5,563 锁在仓位里）。 5% 止盈对主流币意味着什么数据摊开之后，结论其实很清楚：5% 对主流币太高了。 ...

记录一次模拟盘的排障（2026-07-10）模拟盘最坑的地方，不是它亏了钱，而是它让你以为策略已经能跑了 这天打开 http://0.0.0.0:8501/，主流币模拟交易那条曲线几乎全是红的。接下来的几个小时基本都在同一个循环里转：发现一处数据不对，翻代码，改掉，重启，然后发现下一处不对。 下面按当时踩到的顺序记。 第一次运行就崩maincoin_paper.py 里 scan_signals() 返回的是 dict，但 run_tick() 全程用属性访问：sig.confidence、sig.signal.value。所以第一轮 mc_paper_loop 一起来就崩了。 改成 sig["confidence"]、sig["signal"]，顺手删掉没用的 Signal import。这个 bug 的性质其实很典型——函数签名和调用方之间没有契约，写的时候两边各自都对，合起来就炸。 开仓时间和平仓时间一模一样翻交易记录时发现一件事：每一笔的 opened_at 和 closed_at 是同一秒，大量交易 duration=0s。 根因在 ...

记录一次主流币系统的落地（2026-07-07）把"想做"变成"在做"，中间隔的是一个能自己跑起来的系统 前一天定了方向：做链上合约可用的 14 个高级策略，全部做进去。 这天就是落地——数据采集层、14 个策略引擎、回测引擎、预计算脚本、展示页，以及第一批真实仓位。 14 个策略，分五类策略清单这么落： 类别 策略 A. 资金费率类 1. 费率反转 · 2. 费率趋势共振 · 3. 费率套利 B. 持仓量类 4. OI 背离 · 5. 多空比反转 · 6. 清算磁吸 C. 量价类 7. 盘口不平衡 · 8. 鲸鱼追踪 · 9. 放量突破 D. 技术指标类 10. ADX 多周期 · 11. SuperTrend · 12. RSI 背离+量 E. 宏观情绪类 13. BTC 主导率 · 14. 恐贪逆向 有几条是链上独有的：资金费率、未平仓量、多空比、链上订单簿——数据透明、CEX 拿不到。这也是"链上合约"这个选择真正的价值所在。 从数据到页面，一共六个模块落地的文件是这些： 文件 ...

记录一次换赛道（2026-07-06）承认一条路走不通，比修好它更难 新币模拟跟单这条路，我走了很久。 这天不再往里面加策略了，而是把一件早就该写下来的事写下来：经 http://0.0.0.0:8501/ 验证，模拟跟单新币完全不赚钱。 然后转了方向——用策略交易主流币，BTC、ETH、SOL 这些。 先把结论摆出来数据本身没有再辩的余地： 总交易 2301 笔，全部是新币 / meme 币 总亏损 −$1,876 平均每笔 −3.7% 涉及 518 个不同代币，全是 Sol / Bsc / Base 链上的垃圾币 亏钱不稀奇，稀奇的是 518 个代币、2301 笔之后，还是同一个方向的负收益。这说明问题不在某一次判断，而在策略依赖的那个市场本身。 盘一下手上的牌转赛道之前，先看清楚自己有什么。第一轮盘点是这样的： 资源 状态 能干什么 GMGN API Key ✅ 有 DEX 链上交易 SOL/ETH/BSC/Base——不支持 BTC Helius Key ✅ 有 Solana RPC 节点 C ...

记录一次例行巡检（2026-06-22）巡检看到的是数字，要找的是那个不该只出现一次的原因 10:14 做了一次例行巡检。这天没有改任何代码，只是看。 但看完之后，有些事必须记下来。 巡检的输入只有一样东西：当前时间点，每个数据源的最新一条记录。所谓巡检，就是把"现在"和"应该的样子"对一遍。 先看还活着的T+0 是 10:14，当前 active version 是 v1.23（activated 2026-06-22 10:12:59）。几条主链的数据都在跳： 数据源 末笔时间 距 T+0 sim_decisions 2026-06-22 10:12:29 2.2 分钟前 sim_trades（SELL） 2026-06-22 08:52:51 82 分钟前 new_tokens — 1.8 分钟前（1159/h，OK） sim_market_snapshots（v1.25 CG） — 1.9 分钟前（OK） sim_smart_money_snapshots（v1.26） — 2.0 分钟前（OK，1 ...

记录一次全量验证（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 ...