复盘

记录一次心跳的修复（2026-09-10）最危险的不是进程死了，而是它还活着，却已经很久没说过一句话 这天前后处理了几件看起来不相干的事：换掉一个 VLM 模型、给一个本地转发进程补 timeout、修交易 worker 的心跳、核正一份自动判定、读一份策略审计。等它们在记录里排到一起才发现，说的其实是同一件事——每一个长期运行的环节，都得持续向系统证明自己还活着。一旦它不再说话，系统不会立刻崩，它只会安静地做出一个错误的判断。 下面按当天实际处理的顺序记。 从一条 130 秒的规律开始监控里最先扎眼的是这个数：交易 worker 每隔约 130 秒就重连一次，节律几乎不抖。 反复核过之后，这个 130 秒不是巧合——它刚好等于连接守卫的超时阈值 + 平均一次重连所需的耗时。也就是说，重连不是网络断了，是被守卫"误判"成断了：它等了太久没等到该有的时间戳刷新，就按超时处理，断线，重连，然后 130 秒后再来一遍。日志里这种由"陈旧"引发的心跳超时，一次会话里数到了 3885 次。 顺着 _last_success_ts 往下挖连接守卫的判定本身 ...

记录一次重连风暴的排查（2026-09-09）心跳超时说的从来不是"连接断了"，而是"没人告诉它还活着" smart_money_trader 的日志里堆着几千次心跳超时。表面看是网络不稳，但一台机器如果真烂到每两分钟断一次，它早该被停掉了——交易进程却一直在跑，仓位也没乱。所以这次不猜，先把它拆开看。 这一天的活，从头到尾只有一件事：把"到底是谁在超时"查清楚。 修不修得好是第二步。 先看清风暴的形状先把原始日志预解析了一遍，而不是凭印象判断。 reconnect_preanalysis.json 记录的这场风暴，时间跨度是 2026-08-18T22:00:00 到 2026-09-05T13:57:21。进程侧的 _HEARTBEAT_TIMEOUT 是 120.0 秒，stall_profile.jsonl 里的分析确认了一件事：重连的节奏大约是 每 130 秒一次——正好对上"超时阈值 + 重连周期"。 预解析里还埋着一个更早的坑。第一次统计出来的心跳数是 4355，但这个数字是错的：它把 47 ...

记录一次研究框架的固化（2026-08-16）研究的成本不在跑一次回测，而在第五次重复研究同一个已经被否定的方向。 08-16 这天没有跑新策略，而是把"以后怎么研究新策略"这件事，固化成了文档。 起因是下午的一次毕业提议——想把唯一赚钱的那条策略从小仓升到标准仓。结果自己的数据把提议推翻了。于是那天明白：比定策略更急的，是先定"研究策略的流程"。 一张卡，8 条规矩那天落盘的第一份文件是 NEW_STRATEGY_RULES.md，8 条硬规则： R1：未填策略卡禁止写代码 R2：新策略必须先核对已 KILL 族边界，不在 KILL 表才能进入预注册 R3：预注册必须冻结 3 个独立 gate + 自动毕业 / halt 动作，主人不手动执行命令 R4：策略 KILL 后必须回写 KILL 族边界，避免重复踩坑 R5：预注册冻结后禁止调整阈值，调整必须重写预注册 R6：毕业 / 停止决策由智能体自动判断，主人保留否决权 R7：新策略必须资源隔离（独立预算、独立 watchdog、独立 OOS 跟踪），不污染现有运行策略 ...

记录一次给策略立规矩（2026-08-13）找一条新腿的价值，不如记下一条"以后别再走"的死路。 08-13 跑完两组回测，屏幕上的收益几乎全是负的。那天做的不是继续找，而是把"以后不能再做什么"一条条写下来。 因为一次失败的验证，如果不落成规矩，下次还会用另一种形式再失败一遍。 两组被数据拒绝的腿先看当天跑出来的东西。两组的配置完全一致：12 币 / 5000 根 1h 主网 K 线（约 208 天）、24h 持有、120min 冷却、5% 止损 / 15% 止盈、手续费 1bp。行情门控用的是"12 币 24h 收益均值 > +2%"，样本内 / 样本外切分点沿用 2026-08-01（即 07-31 之后的真样本外）。 第一组：低动量做多（LONG 低动量反转） 配置 笔数 总收益 胜率 回撤 A 上涨限定 TOP1 74 −29.63% 50.0% 39.06% B 不限 regime TOP1 169 −36.63% 48.5% 55.79% D1 上涨限定 ...

记录一次策略的体检（2026-08-05）一条策略的体质，不是它今天赚了多少，是它亏的时候怎么亏。 08-05 白天做了一次修复。修完一处，按惯例要给场上的策略重新量一遍收益——把"修之前"和"修之后"分开看，否则修了等于没修。 这次体检的对象是两条在跑的策略：24 小时持有周期的反转策略 factor_ic，和看资金面的 market_flow。下面这份，是那天的体检记录。 修复之后，先把基线钉住修完一处代码，最危险的不是改错，是默认它就修好了。 所以每次修复之后我都要重做一遍收益体检。它有两个作用：一是确认修复本身没带来副作用，二是把新的 realized_pnl 固定下来，当作下一段比较的基线。 08-05 修复完成时，账户的 realized_pnl 停在 +$19.74。这个数字本身没有好坏，它只是一个起点——后面所有"修复后表现如何"的判断，都要拿它当尺子。这一点很关键：如果基线没钉住，后面看到的一切变化，都分不清是策略的功劳还是记账的噪声。 两条策略，两种体质体检不能把它们塞进一张表里比绝对值，因为两条策略的仓 ...

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

记录一次看板数据丢失的修复（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( ...