量化系统

记录一次优化清单（2026-09-04）系统跑得动，不代表它没有一堆欠账 那天没有急着写新功能，而是做了一次系统深潜——把交易系统从上到下过了一遍，把"该修、但一直没修"的事一条条捞出来，收成一份优化队列。深潜的副产品，是几个早就该做的接通和改造。 一、先把清单本身立起来清单不是随手记的备忘，它得能当队列用。所以它的形态是一个结构化目录：optimization_todos，落在 1viking://resources/craw_app1_wz/queue/optimization_todos_1 它来自 2026-09-04 的一次系统深潜，用途写得很明确——作为交易系统改进任务的有序队列，按优先级排。 先有清单，再谈排期。 没有清单的时候，优化永远是"想起来才做"，而想起来的，往往是最不痛的那一条。 这件事看着像在整理文档，其实是先给自己立一个"可执行的容器"。一套系统跑久了，欠账是散着的：有的藏在某个脚本的注释里，有的只在某次事故的复盘里被提过一句，有的就是"知道有问题但没空管"。深潜的作用，就是 ...

记录一次多策略协作层的搭建（2026-08-07）一条策略是独奏，好几条一起跑就是一支乐队——真正难的是谁也不拖累谁。 08-07 做了一次全栈巡检。不是看单条策略赚不赚，而是看这些进程、这些策略拼在一起，作为一个"协作层"能不能稳。结论是：核心很稳，但辅助层里藏着一个真问题。 下面把那天理出来的东西记一遍。 六个逻辑进程先把家底摆出来。那天所有逻辑进程都在跑： 进程 端口 / 状态 trader 监听 66552，直连 HL，已连续运行 40 小时零 502 错误 sim_loop 模拟循环，本轮已修复并重启 mc_paper 本轮已修复并重启 signal 信号生成，本轮已修复并重启 watchdog 守护 oos 样本外监控 六个全活。但"全活"只是最低标准——真正要查的，是它们各自的输入输出有没有被污染。 三个辅助进程在吃死代理那天现场抓到一个 P1 级 的真问题。 sim_loop、mc_paper、signal 三个辅助进程，继承了一个已经死掉的系统代理 127.0.0.1:7890（C ...

记录一次实时信号架构（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-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-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：把前两份整合成 ...

记录一次 GMGN 接口的摸底（2026-06-07）平台真正的能力边界，从来不在文档里 前一天的教训还热着：trenches 有个 type=completed，文档里没写，但返回的是全网热榜，而前十轮调优一直在最冷的数据源里打转。 所以这天不干别的，把 GMGN 到底有什么接口，从头到尾摸一遍。 为什么不能信文档用第三方数据源做量化，最大的成本从来不是写代码，而是搞清楚它到底能给你什么。 文档的问题有三个：漏的（有的端点根本没写）、错的（写了但已经不返回数据了）、含糊的（写了但字段含义和你以为的不一样）。而交易系统对这三件事全都零容忍——字段理解错一个，整套策略就是反的。 所以这一天的原则很简单：文档只当线索，结论必须自己打出来。 摸的办法：从 npm 包里挖官方客户端 [email protected] 是个 npm 包。它在服务器上跑，跟服务端保持一致——所以它里面写的路径，就是真实存在的路径。 装一个干净的探测目录： 1mkdir _npm_probe && cd _npm_probe && npm init -y && npm i ...

记录一次模拟跟单系统的搭建（2026-06-05）上午还在修一个报错，下午决定从零搭一整套系统 那天的开始很普通——修 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 小时未更新强平 把风控写成常量而不是配置，是刻意的选择。策略是要被反复比较的对象，风控不是。 ...