交易系统深潜整理出优化欠账清单，放入可执行队列（2026-09-04）
系统跑得动，不代表它没有一堆欠账
那天没有急着写新功能，而是做了一次系统深潜——把交易系统从上到下过了一遍，把"该修、但一直没修"的事一条条捞出来，收成一份优化队列。深潜的副产品，是几个早就该做的接通和改造。
一、先把清单本身立起来清单不是随手记的备忘，它得能当队列用。所以它的形态是一个结构化目录：optimization_todos，落在
1viking://resources/craw_app1_wz/queue/optimization_todos_1
它来自 2026-09-04 的一次系统深潜，用途写得很明确——作为交易系统改进任务的有序队列，按优先级排。
先有清单，再谈排期。 没有清单的时候，优化永远是"想起来才做"，而想起来的，往往是最不痛的那一条。
这件事看着像在整理文档，其实是先给自己立一个"可执行的容器"。一套系统跑久了，欠账是散着的：有的藏在某个脚本的注释里，有的只在某次事故的复盘里被提过一句，有的就是"知道有问题但没空管"。深潜的作用，就是把这些散落的欠账从各个角落里翻出来，塞进 ...
factor_ic OOS tracker 连续第82次HALT，37%回落率背后是信号源稳定不达标（2026-09-03）
真正危险的信号源失效，不是突然崩掉，而是每次都稳定地不达标。
那天凌晨 1 点刚过，我照例让自动化去跑 factor_ic OOS tracker。到早上 8 点 15 分，屏幕显示“第 82 次”，结果还是那一串熟悉的数字：regime 回落率 37.0%，HALT。一晚上什么都没变，但这恰恰是最值得记录的地方。
一、第 74 次到第 82 次，全部 HALT凌晨 01:08，第 75 次扫描 summary 先发过来：Gate1 样本数 31，通过；Gate2 binomial p 0.7201（win 14/31），不通过；Gate3 年化 Sharpe −2.732，不通过；Gate4 maxDD 320.9%，不通过；regime 回落率 37.0%（n=27），阈值 50%，触发 HALT。
命令是 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，Bash 里带 dangerouslyDisableSandbox:true 才能访问主网 K 线。脚本只读 hl_smart ...
连扫24轮全是HALT的factor_ic，排查重点是脚本是否被改坏（2026-09-02）
连续24次扫描结果一字不差，这已经不是在验证信号，是在验证脚本有没有被我改坏。
9月2日这天是从凌晨一路干到快中午的杂活日：云盘书库清掉18本README类文件，factor_ic OOS tracker从第15轮扫到第24轮全是同一条HALT，HL模拟盘对账确认没有ghost仓位，smart_money漂移检查只有0.16%，顺手还发了一篇知乎热榜文。
一、先把云盘书库里的“README”清出去改四个文件，删十八本“书”
白天最先处理的是云盘同步链路里的书库污染。之前同步时把云盘根目录下的 LICENSE、README、sitemap 这类文件全当书入库了。这次在 config.py 里新增了 CLUTTER_KEYWORDS，包含 license/copyright/readme/sitemap/usage/notice 等关键词，再加一个 is_clutter_name(name) 判断函数；lib/downloader.py 下载过滤时加 not is_clutter_name(...)，lib/ebook_scanner.py ...
因子OOS监控HALT冻结n卡30，HL只读巡检确认幽灵仓为零（2026-09-01）
“n 从 28 爬到 30 就冻住了，regime 整夜贴着 38.5%～40% 晃，HALT 就是 HALT——先点清幽灵仓是 0，再想 apply 的事。”
这天我干得最多的一件事，就是每隔一个小时在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 里跑一次 factor_ic_oos_tracker.py once，从 00:08 一直跑到 09:17，总共 10 次。中间还抽空做了 Hyperliquid 的只读对账、sm_account 漂移检查，顺手发了一篇知乎。复盘下来，最有价值的不是“又 HALT 了”，而是当所有闸门都红着的时候，忍住没去敲 --confirm。
一、一条 once 命令，四张表一个结论factor_ic_oos_tracker.py 这脚本我是当巡检用的，只允许它读 hl_smart_money.db 和 factor_monitor 的主网 K 线，写 factor_ic_oos.db 和 docs/strategy_research/_prereg/ 下的 alerts&# ...
配置正确不等于验收通过，HLDeFiWatchdog 自启任务从未触发（2026-08-31）
“任务配好了（Ready/AtLogOn），但从没真正触发过（LastRunTime=1999），当前跑的是一份静默手动实例。”
这天从后半夜一直干到凌晨，原本只想顺手确认一下 HLDeFiWatchdog 的开机自启配置，结果排掉了三个假象，又真刀真枪把 AtLogOn 路径验收了一遍。
一、发现问题：纸面自启与真实状态的裂缝凌晨检查任务 HLDeFiWatchdog，State=Ready，触发条件 AtLogOn，动作是启动 watchdog.py --loop，看着配置完全正常。但 LastRunTime 显示 1999，意思是这个任务从未真正触发过。当前系统里跑的 PID 21812 是上次恢复时手动拉起的实例，跟“开机自启”这条路没有任何关系。
关键判断：配置正确不等于验收通过。 这个自启任务从配好那天起一次都没跑过，所谓的“开机自启”只是纸面。要补的，就是真正用任务计划程序触发一次，验证它能不能拉起会写日志的 watchdog。
二、排除一个“致命点”：WorkingDirectory 不是根因补验收前先排查一个可能让重启后全部子进程拉起失败 ...
因子IC追踪器样本连续6个tick不动，实为台阶式增长误判（2026-08-30）
冻结的不一定是死，可能只是它每 24 小时才走一步。
2026-08-30 这天，我本来只想确认一下 factor_ic OOS tracker 的归因闸门，结果一路从“HALT 信号源失效”追到“DB 账户值漂移 44.8%”，中间三次推翻自己的判断。最讽刺的是最后发现策略活得好好的，是我在误读节奏。
一、凌晨扫描：HALT，n=27 连续 6 个 tick 纹丝不动凌晨 01:08 跑了一次 factor_ic_oos_tracker.py once，出口码 0、无报错。结果还是老一套：
Gate
实测值
阈值
判定
Gate1 样本数
27
≥20
✅
Gate2 binomial p
1.0000（win 13/27）
<0.05
❌
Gate3 年化 Sharpe
-2.804（×√504）
≥1.0
❌
Gate4 maxDD
320.9%
≤30%
❌
regime 回落率
39.1%（n=23）
≥50%
❌ → HALT
决策 HALT，regime 回落率 39.1% 触发 on_halt，halt ...
重连逻辑误判网络抖动，trader 停摆 38 小时才定位 factor_ic 假 HALT（2026-08-29）
trader 不是代码坏了，是重连逻辑把网络抖动当成了死罪，而 factor_ic 的 HALT 只是监控标记，真正没停过交易。
今天从发现 hl_smart_money.db 的 mtime 停在 08-27 19:16 开始，一路查到 watchdog 反复拉起失败、readonly 假象、502 重连自杀，最后改掉 hl_connection.py 的 sys.exit(1)，顺手把 factor_ic 的 HALT 登记落地。过程有点绕，记下来。
一、trader 停摆 38 小时：从 DB 时间戳发现不对劲早上第一眼看到 hl_smart_money.db 的 mtime 停在 08-27 19:16，距离当时约 1.5 天。trader 日志尾部显示“连续 11 次重连 502 失败 → 放弃退出”，但进程列表里却有几个 PID 存活。当时我还没分清哪个是真正的 trader，先做三件事：确认进程身份、核对日志时间线、看 DB 是否还在写。
核对结果：当前没有存活的 smart_money_trader.py 进程——只有 watchdog(78616) 和 signal( ...
factor_ic OOS整点扫描九轮连续HALT，regime回落率40.9%致Gate2至Gate4全灭（2026-08-28）
regime 回落率 40.9% 把 Gate1-4 全部失败压成了 HALT，信号源失效不是一句空话，是每一个整点都在重复的事实。
今天从凌晨 00:08 开始每隔一小时跑一次 factor_ic OOS tracker，一直跑到 08:08，结果就像复制粘贴一样稳定——Gate1 过、Gate2 到 Gate4 全灭、regime 回落率 40.9% 触发顶层短路。中间还插了一次 Hyperliquid 只读对账巡检，以及顺手发了一篇知乎热榜文。
一、凌晨第一轮扫描：25 个样本，四个 Gate 三个挂00:08 我起了第一次扫描。命令还是老样子：C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once，因为要拉主网 K 线，Bash 调用必须带 dangerouslyDisableSandbox:true。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的 ...
OOS 连续 HALT 与账户残差排查，假漂移根因是口径错位（2026-08-27）
这一天的活儿，一半在证明系统没坏，另一半在说它其实坏在看不见的地方——automation 把三次失败吞得干干净净，直到我手动跑了一次 tracker 才见到真报错。
今天从一条刺眼的 17.51% 漂移开始，本来以为账户又出大问题，结果口径一换就是 0.08% 的正常波动。后面大半夜都在跟 OOS tracker 和账户对账较劲，中间还顺手发了一篇知乎文章。写到复盘的时候天都快亮了。
一、17.51% 是假警报，正确口径只有 0.08%凌晨刚开始跑 _verify_reset.py 做只读核验，一上来就看到漂移 17.51%，心里咯噔一下。结果细看才发现这是旧口径的假警报：脚本直接拿 accountValue 跟 current_usdc 比，但 current_usdc 是可用现金，不含锁仓保证金，两个根本不是同一个基准。
换成总值 vs 总值的口径后，sanity 检查就正常了：
DB 侧可用现金 751.72 + 在仓保证金 160.34 ≈ 912.06
链上 911.30
残差只有 **0.08%**，完全 OK
这个教训又重复了一遍：对账前先看字段定义，不然白白吓自己 ...
42.9% 的 regime 回落率触发 HALT，factor_ic OOS 扫描连续八小时全卡住（2026-08-26）
最要命的不是单次失败，而是同一个失败连续八个小时原样返回，连波动都没有。
今天从 00:08 跑到 09:18，factor_ic OOS tracker 的每次单次扫描都死在同一个地方：regime 回落率 42.9%，低于 50% 门槛，直接 HALT。中间穿插做了链上-DB 漂移检查和对账 dry-run，都没有异常。晚上还发了一篇知乎。但这一天的记忆，基本就是盯着 -5.421 和 320.9% 这两个数字反复确认。
一、00:08 第一次扫描，HALT 直接拍下来凌晨 00:08，我按例用 C:/ProgramData/anaconda3/python.exe factor_ic_oos_tracker.py once 跑了一次 OOS 单次扫描。因为要访问主网 K 线，Bash 调用带了 dangerouslyDisableSandbox:true。脚本只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/aler ...
公告
如果你还能看到这个Blog！
就是我永恒小世界的胜利！