记录一次 3750% 漂移与双轨 OOS 信号扫描（2026-09-15）

今天最关键的判断：所有自动化和巡检都坚持“只读不写”，否则一次 --apply 就可能把 testnet 重置后的烂基线写进正式库。

从早到晚，我基本没写任何库，却把 Hyperliquid 链上账本、对账脚本、知乎发文、factor_ic OOS tracker 全部过了一遍。几件事表面互不相关，内里都在验证同一件事：脚本告诉你的“正常”和“异常”，到底能不能信。

一、smart_money 漂移检查：第 7 次 ALERT，同一个病根

上午先跑 Hyperliquid smart_money 账户的链上-DB 漂移检查。命令很直接：

cd "C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard" && C:/ProgramData/anaconda3/python.exe -u _sm_sanity_check.py

结果一出来就是红色：

• chain（链上真实余额）：260.9216
• db_total（DB 净值 + 未平保证金）：10045.9839
• drift：3750.19%，阈值只有 5.0%
• db_updated：2026-09-13T21:12:48，数据不陈旧，约 31 小时前

这已经是 09-05 起连续第 7 次 ALERT。DB 名义基线长期悬在 ~10046，链上真实余额只有 ~261，差了约 38 倍。脚本明确提示疑似 testnet reset 再次脱钩，需要执行 wb_runs/archive/_reset_sm_account.py --apply 重置 sm_account 基线后再重跑检查。

但我没执行重置，本次检查只读不写，没碰任何文件或数据库。原因也简单：在没确认链路状态之前，--apply 会把这条错误基线当成新起点固化下来，后面再追账更难。

二、HL 只读对账巡检：无 ghost，14 个 orphan

紧接着跑 hl_reconcile.py，默认 dry-run。这次学乖了，先把系统代理变量全部清空，HTTPS_PROXY=""、HTTP_PROXY="" 一系列，另外根据历史经验补了一条 NO_PROXY="*"，避免 Windows 系统代理导致的 502。

结果 12:00 出来，三件事：

1. 没有 ghost 仓位——两库所有 OPEN 在链上都能对应到，含方向反检查，无需清理。
2. Orphan 14 个，仅告警不修复——SOL、APT、BTC、ETH、BNB、ARB、SUI 这 7 个标的分别出现在 hl_smart_money.db 和 hl_testnet.db 里，链上有、DB 无。脚本设计上就不自动修。
3. 两库 OPEN 数量都是 0，hl_smart_money.db=0、hl_testnet.db=0，持续零持仓。

没有 ghost，所以不需要 --apply；orphan 按设计不修，要清就得再授权。我在报告里特别写了一句：“所有 PnL 为 HL testnet 模拟口径，非真实资金。”别看到几万 USDT 就上头。

三、知乎发文：风控截图 ≠ 发布失败

中午把前一天选好的选题发布了。标题是《理想26.5亿砸向“去宁化”：不是宁德时代不行了，是车企不想再当打工人》，链接 https://zhuanlan.zhihu.com/p/2083163237751834255，正文约 1700 字符，12:00 上线，封面是 cover-20260915.jpg。

发布脚本 publish-py.py 报告成功，但确认页截图出现了知乎风控拦截，错误码 40362，提示“暂时限制本次访问”。一开始我差点以为发布失败，后来用 WebFetch 独立复核了一遍：文章真实上线，标题、正文、核心数据与本地稿件完全一致。那个 40362 只影响发布后的确认页访问，不影响发布结果本身。

这个经验也写进了自动化执行记忆：截图风控页不等于发布失败，以跳转参数 + WebFetch 复核为准。

四、OOS tracker 双轨扫描：一个 HALT，一个 NO_ACTION

下午的重头戏是 factor_ic OOS tracker。A2 做多视角和 A1 做空视角完全并行，各查各的 arm。

A2（arm='LONG'，阈值更严） 的代表性结果：

• Gate1 样本数 16，阈值 ≥30，不通过
• Gate2 binomial p = 1.0000（win 8/16），阈值 <0.05，不通过
• Gate3 年化 Sharpe = -5.080，阈值 ≥1.0，不通过
• Gate4 maxDD 写库 4.1244（真实 ≈4.12%），阈值 ≤30%，真实值通过
• regime 上升率 75.0%（n=16，做多视角），阈值 ≥50%，OK

决策路径：regime=OK → Gate1 fail(16<30) → NO_ACTION（攒样本）。样本已经连续几十轮冻结在 16，没有新 LONG 平仓进池，既不触发毕业也不触发阻断。

A1（arm='SHORT'） 则直接：

• Gate1 样本数 31，阈值 ≥20，通过
• Gate2 p = 0.7201（win 14/31），失败
• Gate3 Sharpe = -2.732，失败
• Gate4 maxDD = 320.9%，远超 30%，失败
• regime 回落率 37.0%（n=27），阈值 ≥50%，失败 → HALT

决策 HALT：regime 因子级 forward return 回落率 <50%，走 on_halt，信号源失效。上午 12:06、下午 14:11、15:15 三轮结果完全一致，网络均正常，主网 K 线拉取成功，不是 UNKNOWN 降级。

五、两个值得记下的小坑

一是 Gate4 maxDD 的格式化 bug：A2 写库值是 4.1244，真实最大回撤约 4.12%，但 stdout 和 markdown 里显示成 412.4%，是 *100 被二次格式化造成的。如果只看输出不看库，会以为回撤 412%，差点误判成风险。

二是 代理变量 502：跑 hl_reconcile.py 和 tracker 需要联网时，必须手动清空 HTTPS_PROXY、HTTP_PROXY、ALL_PROXY 等，还要加 NO_PROXY="*"。这是 Windows 系统代理的老毛病，不是脚本本身的问题。

六、遗留

到晚上为止，sm_account 基线还是没重置。连续第 7 次 ALERT 摆在那里，--apply 这步需要我单独确认后执行。另外 A1 的 HALT 需要在下次扫描时继续观察，如果回落率重新站上 50%，是否解除 HALT 得重新评。A2 样本继续冻结在 16，等新 LONG 平仓进池再看。

这篇文章先记到这里，下一步先把漂移基线处理掉，不然每天打开自动化结果都是同一个 3750%，看了心烦。