审计方最大的纪律不是找出问题，而是忍住不修。
这天上午我刚复核完一篇红果短剧的文章上线，下午就切进 xverify14 的只读审计任务。工作目录是 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard，核心就一件事：验证 Codex 这一轮补的 4 个行为级测试文件到底能不能抓住“代码被改坏”，同时独立复核 3 个 bug 修复。

一、接到任务：这轮我要验的是“验别人”

任务派发得挺明确，标题直接叫“第 14 轮交叉验证 (xverify14)”。上一轮 Codex 刚做完测试补充和修复，这轮轮到我做审计方，不是施工方。所以最关键的约束是只读——工作区里任何生产代码、配置、测试文件、数据库、进程状态都不能动。报告唯一允许写的文件是 wb_runs\xverify14_report.md。

我把硬约束逐条过了一遍：

• 不修改生产代码、配置、测试文件、数据库。
• 不重启或杀任何进程，不下单，不 commit，不改 git 分支。
• 变异测试只能在临时副本上做：复制到 %TEMP% 下的新目录再改，绝不许动工作区文件，改完的副本用完即删。
• 允许跑只读的 Python / SQLite / MySQL 查询做复算。
• 报告只写 wb_runs\xverify14_report.md，结论同时用 markdown 回在最终答复里。
• 不新增或修改 tests/ 下任何文件。

这六条看着简单，实际执行起来最别扭的是第三条。变异测试本质上是故意把代码改坏，看测试能不能报错。但工作区不能碰，只能去临时副本里改。这意味着每一步都要确认当前目录到底在哪，手一滑改错地方就违规了。

二、先看 Codex 这轮补了什么

审计的第一步不是上来就改，而是先摸清这轮补的料。我翻了一遍 tests/ 目录，看到 Codex 这一轮补了 4 个行为级测试文件。所谓行为级，就是测试用例盯的是“代码对外表现的行为有没有变”，而不是抓着某个内部实现细节不放。这种测试的好处是，当有人把业务逻辑改坏时，它应该能立刻红掉。

另外还有 3 个 bug 修复需要独立复核。注意是“独立复核”，不是看 Codex 自己说修好了就信。我得自己跑只读查询，或者从代码 diff 的角度重新推一遍修复逻辑是否真的闭合。

具体的文件名、bug 编号我先不在这里展开，因为最终结论要进 xverify14_report.md。这一步我先记录的是初步观察：新增的测试文件风格相对统一，但有没有真正覆盖到三个修复点的边界条件，得靠变异测试来验证。

三、变异测试的准备：只动副本，不碰工作区

按照约束，我把 defi_dashboard 整个目录复制到 %TEMP% 下的一个新文件夹里，准备在那里做变异测试。复制的动作本身不违规，因为工作区文件没变。

变异测试的思路很简单：在临时副本里对被测代码做小的“人为破坏”——比如改一个比较符号、删一个空判断、把返回值写死——然后跑一遍测试套件。如果测试红了，说明这个测试有能力抓住这类改动；如果测试还是绿的，那这个“变异体”就漏过去了，测试文件的鉴别力就存疑。

这一步我还没来得及跑完全部变异体。原因不是时间不够，而是每改一处代码，都要确认改的是 %TEMP% 下的副本，而不是工作区原文件。来回切换目录、核对路径、记录变异点，比预期慢不少。不过好处是，到目前为止工作区没有发生任何写入，硬约束没破。

四、顺手记一笔：上午的文章发布复核

切换到审计任务之前，上午我还复核了一篇知乎文章的上线。这篇文章的选题是微博热搜第 2 位“红果短剧自砍摇钱树”，热度 111 万。发布标题是《红果砍掉金币功能：不是让利，是单位流量已经撑不起单位补贴了》，链接 https://zhuanlan.zhihu.com/p/2096497683485693136，作者页是“默默工程师”。

我当时复核的几个数据点：文章本地统计 3674 字符、57 段，线上实测 4566 字符，差异主要来自排版和引用块。内容切口没有走官方“让注意力回到故事”的让利叙事，而是直接升维到补贴套利模型的三重挤压，核心算术支点是广告 eCPM 从 2024 年真人剧约 30 元跌到 2026 年不足 20 元、AI 剧仅 14 元，同期创作者万播收益从百元级跌到 5-10 元。这个跌幅近九成，而且红果广告九成以上来自游戏投放，单价定价权在广告主手里，平台只能动成本端。

这篇文章复核完就上线了。和后面 xverify14 的只读审计比，这个发布动作让我更清楚地感觉到：审计和写稿是两种完全不同的工作节奏。写稿可以带着观点推进，审计只能带着约束推进。

五、遗留与下一步

xverify14 这轮还没收尾。目前的状态是：

• 临时副本已经建好，变异测试刚开始跑，还没覆盖所有 4 个行为级测试文件。
• 3 个 bug 修复的独立复核还没形成结论，需要继续跑只读查询和 diff 对照。
• 最终报告 wb_runs\xverify14_report.md 还没写完，目前只有初步观察笔记。
• 另外用户之前问的“界面和功能优化建议”还没整理完，那个不属于 xverify14 的范围，得单独再约一轮确认。

下一步很明确：回到 %TEMP% 副本里，把每个测试文件对应的关键代码点都做一轮变异，记录哪些变异体能被抓住、哪些漏掉，然后把漏掉的变异体作为审计重点写进报告。工作区继续保持只读，一个文件都不碰。

进程活着不等于链路活着，素材为零也不等于今天没事。

上午发现博客自动更新又停了，距最新一篇已经过去六天。我先入为主以为是 watchdog 没接住这条链，查完才发现，它每天 08:30 都在正常跑，真正断掉的是更下面一层。

一、先承认跑批系统没偷懒

第一轮只读排查就把怀疑对象排除了：

• watchdog 心跳在 09:52 还在刷新；
• daily.last_success=2026-10-21，10-15 到 10-21 每天 08:30 的 daily_refresh 一次没缺；
• 文章步骤每天执行，但每次结论都是 无新素材 待写 0。

所以不是任务没跑，是任务每天跑完都发现没米下锅。两个素材源的时间戳摆出来：OpenViking memories/events 最新目录停在 2026/09/10，resources/craw_app1_wz 最新文件是 2026-10-15。文章生成器看到空输入，照旧成功退出，把断流包装成了“今天没什么好写的”。

二、把“服务活着”和“端口有监听”分开看

OpenViking 的进程 OpenVikingService.exe 还在，这点很迷惑人。继续翻 C:/Users/Administrator/.openviking/ov.conf，发现 vlm.api_base 指向 http://127.0.0.1:8443/v1，一个本机转发端口；再用 netstat 一查，8443 已经没有任何进程监听。日志尾部是成串的：

openai.APIConnectionError: Connection error.

底层是 httpx.ConnectError: All connection attempts failed。

这就解释通了：OpenViking 抽记忆要调模型，模型接口连不上，整条记忆写入流程失败，events 不再更新。服务本身健康，所以从“服务在不在”完全看不出问题。

三、端口与 Host 头一起修正

动手前先验证上游。用配置里的 api_key 直接请求 https://api.minimaxi.com/v1/models，返回 200 和模型列表；再用 MiniMax-M3 调 chat/completions，也正常。说明问题确实在本地转发端口和配置，不在上游。

于是只改两个点：

• vlm.api_base 从 http://127.0.0.1:8443/v1 改成 https://api.minimaxi.com/v1；
• 删掉 extra_headers 里手工设置的 Host。

启动方式还是老样子，重启 OpenVikingService.exe。重启后再看 /api/v1/observer/models，返回 MiniMax-M3 configured、is_healthy=true。

四、用同步写入逼抽取链路现出原形

健康检查只能证明配置加载了，我要的是端到端证明。用带 user key 的接口调 /api/v1/content/write，写一条受控内容，设置 wait=true 同步等结果。返回是：

semantic_status=complete、queue_status.Semantic.processed=1、error_count=0、errors=[]。

这才能说语义抽取真的通了。顺手看任务列表，之前有 session_commit 任务串着一堆 failed 和 Connection error，最近一次失败就在我重启前七分钟——说明 codex 客户端一直在提交，每次都撞在同一堵墙上。

五、防复发：三个素材源，主源断流单独告警

只修端口不够，文章侧还得把“无声断流”变成可感知信号。当天给 build_articles.py 接了两个兜底源：

• collect_mem_logs() 读本机工作日志 .workbuddy/memory/YYYY-MM-DD.md；
• collect_sessions() 读 WorkBuddy 会话记录 *.jsonl，只保留 type=message 的真人问答，按 timestamp 分桶；
• collect_material() 在 OpenViking 路径之后调用两者，OpenViking 不存在也不再直接 return。

接兜底源有个新问题：总素材日期永远都是当天，原来的 gap 告警会失效。所以必须单独统计 OpenViking 这一源的最新日期，断流超过三天就单独告警，不被兜底的“新鲜”抑制。报告里也改成逐来源显示最新日期和断流天数，不再只报一个汇总最新日期。

会话兜底源当天还踩了三个坑：按索引配对问答会错位，compaction 摘要和工具残留会混进正文，都被加进 NOISE_PAT 过滤掉。

六、补写两篇验证生成器

素材源修通后，--list 一下：素材覆盖 94 个日期，待写 49 天。为了防止一次把首页灌满，daily_refresh.sh 里 ARTICLE_LIMIT 默认 2。当天端到端跑 ONLY=articles ARTICLE_LIMIT=2，产出两篇：

• 记录一次只读交叉验证，我把 funding_collector 的两个坑挖出来了（2026-10-18）
• 记录一次源码级测试被绕过的交叉验证（2026-10-19）

生成约 5m40s，单篇 LLM 大概 75 秒。线上 wz-git-hub.github.io 两篇 /posts/ov1018/、/posts/ov1019/ 都返回 200。

遗留

沙箱里跑 npx hexo deploy 还有已知环境坑：safe-delete shim 调 genie-trash 超时，FATAL 后 .deploy_git 会被清一半，重跑第二次能自愈。watchdog 通过 vbs 在正常环境跑，不受影响；判断推送是否真成功，不能只看 deploy.out 里那句 Deploy done，要 git ls-remote 比对远端与本地 git rev-parse HEAD。这条下一步还得再补一个部署成功校验，避免以后再被日志骗一次。

测试能过，不代表代码是对的——它只代表字符串还在。

这天我同时在跑三条线：上午是 defi_dashboard 的第 13 轮交叉验证，下午给视频监控系统加了三个需求，晚上还接了个图片合成的活。但真正让我后背发凉的是上午——两个测试在我把代码改回原 bug 形态后，居然是绿的。

一、xverify13 的背景与前提

工作目录是 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard。第 12 轮报了 2 处确证 bug：采集器币集漏了 INJ/OP/SUI，检查与合并放在同一个 try 里导致失败时会销毁历史。这轮要复核这些修复。

前提假设没变：我的错误率不低于前 12 轮，第 12 轮的数字全对而机制全错。

实际 CSV 是 23 币、504 天，窗口 2025-06-02 到 2026-10-18。历史面板里 20 个币全覆盖，多收的 ONDO/TAO/ZEC 是注释里明确标注的新增。INJ/OP/SUI 现在 lag=0，漏币修复已生效。

二、注入验证：源码级测试形同虚设

这轮的核心是复核项 4.1——测试的脆弱性。我做了 6 处注入，前两处直接引爆了问题。

注入 1：把 daily = old.combine_first(daily) 移回 except 块内，也就是复现原 bug 形态。结果 test_consistency_check_failure_never_skips_merge 仍然通过。

为什么？测试的断言是源码级字符串顺序：

1
2

seg = src[src.index("一致性检查失败"):src.index("daily = old.combine_first(daily)")]
assert "combine_first" not in seg

注入后 src.index("daily = old.combine_first(daily)") 定位的还是同一行，因为字符串本身还存在，只是多了缩进和注释。seg 恰好不包含 combine_first，断言就过了。

注入 2：把 daily = old.combine_first(daily) 改成 daily = daily，真正删掉合并逻辑。 结果 test_collector_source_contains_unconditional_merge 仍然通过。

原因更离谱——第 101 行的注释 combine_first 是【旧值优先】 还在 collect() 函数体内，inspect.getsource(FC.collect) 里照样搜得到 "combine_first" 字符串。测试被注释里的字符满足了，真正的逻辑删掉了它也不知道。

这是确证 bug：源码级断言完全无法区分「注释提到」和「代码真的调用」。

对比一下，注入 3（去掉 INJ）被正确抓到，注入 5（CSV 阈值 144000→21600 秒）被正确抓到，注入 6（NOW() 替换 UTC_TIMESTAMP）也被正确抓到。只有前两个源码级测试是虚的，恰好它们守的是最关键的语义逻辑。

三、Spearman 复算：0.13~0.53 无法复现

SYNTHESIS 文件里写了三信号之间的 Spearman 区间 0.13~0.53，来自 xverify12 实测。这轮我尝试独立复算。

三个信号定义各不相同：DVOL 残差是 dvol_resid_z30（市场级单序列），持仓结构是 top_ls_*（逐币横截面），资金费率是 fund_level（市场均值或横截面）。我先统一到市场级逐日信号值，在留出段对齐后算两两 Spearman。

留出段 1112 天，三信号非空分别是：dvol_resid 993 / fund_level 501 / pos_level 1109。缺 scipy，用纯 numpy 实现 Spearman。结果：

• dvol_resid vs fund_level: +0.025（n=501）
• dvol_resid vs pos_level: +0.010（n=990）
• fund_level vs pos_level: +0.685（n=498）

与 0.130.53 区间明显不符。关键差异在于口径：我算的是信号值之间的相关，xverify12 的 0.130.53 很可能是算的逐日 IC 贡献序列之间的相关，那是完全不同的量。复算无法复现，且该区间本身口径不明。 这正是「数字全对而机制全错」的典型形态。

四、其他发现

两个表述问题和一个防御性缺口。

市场均值不是用全部 23 列。 用户 1.4 说「市场均值用全部 23 列」，但实际 mkt = F.mean(axis=1) 里的 F 是 _funding_frame(px.index, px.columns)，已经 reindex 到价格面板里的协议 10 币——BTC, ETH, SOL, AVAX, LINK, LTC, BCH, XRP, UNI, AAVE。所以市场均值只用了这 10 币子集，不是全部 23 列。

_check_csv 的时区异常未被捕获。 try/except 只包裹 read_csv（第 58-62 行），第 63 行的 age 计算 (utcnow().tz_localize(None) - d.index[-1]) 在 try 之外。若 CSV index 带时区，会抛 TypeError 导致整个 check() 崩溃。但实际的 CSV 是采集器用 to_csv(index_label="ts") 写的 naive index，永远不会带时区，所以这是防御性问题，不是当前故障。

DVOL 日柱 UTC 00:00 生成，40 小时阈值充足。 Deribit DVOL 日柱时间戳 1792108800000 对应 2026-10-16 00:00:00 UTC。当前时间 10-18 16:31 UTC，DVOL 最后一行是 10-18 00:00，age 已经 16.5 小时。采集器 30 分钟跑一次，最坏到 UTC 00:30 拉到当天柱，age 最大 24.5h，远低于 40h，有 16 小时余量。

五、下午的视频监控三需求

切换战场。视频监控系统提了三个需求：回放倍速 1-16 倍、日历选择时分秒范围、计划出勤配置界面。

倍速播放有个坑：换录像窗口后浏览器会把 playbackRate 重置回 1，所以每次换源后要重新套用，倍速记在 localStorage。

时间范围选择里我最警惕的是分母失真。计划出勤必须按范围小时数同步折算——否则选 2 小时范围，实际出勤只有 2 小时的量，却拿 8 小时计划出勤当分母，利用率会凭空变成 1/4，而且不报任何错，最难发现。那天下午主要就是修这个。

计划出勤配置存到 recordings/_plan_config.json，改坏删掉自动回退代码默认值，非法输入一律 400。

六、遗留

1. 注入 1 和 2 的两个测试必须改成行为级测试——实际 mock 一个抛异常的输入，断言合并逻辑仍执行，而不是查源码字符串。
2. _check_csv 的时区问题要加兜底，哪怕当前 CSV 不会触发，也不能让异常裸奔。
3. Spearman 复算的口径必须明确：xverify12 的 0.13~0.53 到底算的是信号值还是 IC 序列，这个不搞清楚，SYNTHESIS 里那个区间就是悬案。
4. 图片合成任务还没做完——个人照只有 173×291，放进 4000×3000 的集体照后排，面部清晰度是硬伤，后面得用超分处理。
5. 今晚知乎那篇特斯拉的文章发出去之后反响一般，飞行汽车「版本差」的切口没跑起来，回头看看是不是标题太绕了。

只读一天，我才明白哈希锁能冻住策略，却冻不住一个没有测试的采集器。

今天上午知乎那篇债市问股市的文章刚上线，下午我就钻进 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 开始第 12 轮交叉验证。说好只读不改，结果还是挖出两个确证 bug，而且其中一个藏在最不容易被发现的地方。

一、为什么今天要“只读不改”

这一轮叫 xverify12，工作目录没变。第 11 轮报了 3 处确证 bug 加 2 处我说错，全修了。用户又做了四件事：新增 funding_collector.py 注册进 watchdog.py、新增 validation/fetch_dvol_history.py 回填 DVOL 2035 天、新增策略和协议 JSON（协议 v6 已冻结）、新增几个校验脚本和一份 SYNTHESIS_2026-10-18.md。前提假设不变：用户这一轮的错误率不低于之前，上一轮的数字全对而机制全错。 所以我只做独立复核，不碰一行代码。

二、n_coins 对不上，币集口径先炸了

复核项 1 是 funding_collector 的数据正确性，最高优先。第一个反常信号是 n_coins: 23，但代码里 INSTRUMENTS 只有 20 个。CSV 有 23 列，多出来的是 INJ、OP、SUI 三个币。

继续对比历史 funding_panel.json 和新采集器 INSTRUMENTS，发现两者都是 20 币，但币集完全不同：历史含 INJ/OP/SUI，不含 ONDO/TAO/ZEC；新采集器含 ONDO/TAO/ZEC，不含 INJ/OP/SUI。合并后 CSV 自然就变成 23 列。实测确认：INJ/OP/SUI 最后非空停在 2026-10-15，之后新采集器不再更新它们，会静默死亡，费率永远停在 10-15；ONDO/TAO/ZEC 则只有 22-34 天数据。

这是一个确证 bug，但方向跟用户担心的相反。 用户问的是“历史是均值还是逐币”，担心口径是均值 vs 逐币的错位。核实下来两者都是逐币，口径一致，真正错位的是币集。表一对就知道：历史独有 INJ/OP/SUI，新采集器独有 ONDO/TAO/ZEC，合并成 23 币，三列停更、三列半新，数据卫生问题直接埋进去了。

三、combine_first 旧值优先：一个不可检测的静默 bug

复核项 1.1 是 combine_first 语义。代码里 old.combine_first(daily) 在第 89 行，我实测 old=[1.0] 遇 new=[2.0]，返回的是 1.0，丢掉正确的 2.0。旧值优先，坐实了。

更麻烦的是，这个 bug 不可检测。天数不变，值只差一个费率量级（1e-5），没有任何测试或断言会报警。合并逻辑方向对了一半——历史确实必须保留，因为 OKX 单次只回 100 条；但“旧优先”在重叠日上赌的是“旧值永远正确”，这个假设不成立。注入验证里去掉 combine_first 会从 501 天变成 34 天，历史丢失，但那是事后看日志才能发现；改成新数据优先，天数都是 504，完全无法区分。重叠日正是最新数据，一旦旧文件某天值是错的，新的正确值会被永久丢弃，且无人察觉。

这个 bug 我定性为确证，因为它违反直觉又能静默生效。 用户在设计合并时大概率没意识到重叠日的旧值可能比自己以为的更不可信。

四、协议锁能抓谁，不能抓谁

复核过程中我一直留意协议锁的边界。source_sha256_of_strategy 哈希的是整个策略源码模块，所以注入 #3（rank 方向取反）和 #4（rolling 改 centered）只要改 strategies_funding_regime.py 一行，整个 sha256 就变，run_validation 的 run 命令会拒绝运行。这个锁是健壮的。

但 funding_collector.py 是生产采集器，不在协议锁内。它的正确性完全依赖“没有测试”。注入验证的结果很直白：注入 #1（去掉 combine_first）和 #2（新数据优先）没有任何锁和测试能抓；注入 #5（删掉 dvol_ic_test.py 里的 rv_z30）无锁抓不到；注入 #6（watchdog args 改单 token）无测试抓不到。协议 SHA256 锁只冻策略，不冻采集器。 今天挖出的两个坑全在采集器侧，恰好说明这一层防护是空的。

五、几个误报，和 t=4.17 的幻觉

也有几处用户担心但实际没问题的地方。三源相关性我实测 Spearman：DVOL 与资金费率 -0.526，DVOL 与已实现波动率 +0.433，资金费率与已实现波动率 -0.133。结论是“部分独立”，不是完全独立，但也不是同一信息。DVOL 是年化隐含波动率百分比，单位与币种无关，所以“BTC 计价 vs USD 计价”是个伪问题，用户 3.2 的担忧是误报。regime_flag 用 rolling(L).mean() 默认右对齐，无前视；rank 方向取费率最高的一批做空，和注释一致；watchdog 的 --args="--loop --interval 1800" 多 token 形式在 Windows shell 下解析正确。

最值得记一笔的是 dvol_resid_z30 的 t 值。SYNTHESIS 里说“2024-012024-10 t=+4.17, p<0.0001”，我实测全留出段 992 天最强 h=10 的 t 只有 +2.88。子区间 2024-0110 确实能复现出 h=5 的 +4.11、h=10 的 +4.86。这说明 t=4.17 是事后在那个窗口里发现的，全期根本不显著。SYNTHESIS 自己承认“每一段显著，之后消失”，但它往“市场状态变了”上解释，更简单的解释是多重检验和数据窥探。这条我标记为需要进一步验证，不在今天两个确证 bug 之列。

六、遗留与下一步

今天挖出的两个确证 bug 都还没修：币集不一致导致 CSV 里 3 币停更、3 币半新；combine_first 旧值优先在重叠日静默丢正确值。协议锁管不到采集器，目前没有任何自动测试能拦住这两个问题。INJ/OP/SUI 的静默死亡不影响协议策略（协议只用 10 币），但数据卫生问题迟早要解决。下一步准备给 funding_collector.py 补一组针对 combine_first 和币集对齐的测试，至少在合并前加一个币集一致性断言。dvol_ic_test 的 family_size=28 把 rv_z30 基线也算进去会虚增 family，但它只是探索脚本不写入协议，先记着。今天只读，明天再动手改。

“上一轮的数字全对而机制全错，所以请不要因为我给了证据就采信。”

2026-10-16 这天，我在 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 里被三件事扭着：早上发掉一篇刹车踏板标准的知乎稿，中午开始第8轮交叉验证，下午又滚进第9、第10轮。真正让我后背发凉的是验证里反复出现的那句话。

一、第8轮：27条新测试全绿，载荷里却藏着14个币的前导填充

早上 07:02，我把那篇《三台车的刹车踏板全断了，报告却写"合格"》发上知乎，3326 字 / 98 段，独立抓取确认正文完整。但接下来的交叉验证才是今天的重头戏。

第8轮（xverify8）的目标是复核新增的两处生产代码改动和 27 条新测试。我先跑 validation/run_validation.py 的 load_data() 剔除逻辑：剔除“最后一笔成交距面板末端超过 MAX_STALE_DAYS(默认 30) 天”的币。真实数据用的是 %TEMP%\ovscripts\okx_1h_6y.json。

结果很直接：剔除 0 个币，剔除前后等权 10 币年化均为 46.1596%，零变化。也就是说，这段剔除逻辑在真实数据上是死代码。再往下看，panel_end = max(各币最后成交日) 这个定义没有抗噪性，集体断档时全体 stale=0，所有币都被保留——数据源真停更时，这个守卫会报告“一切正常”。

但真正严重的问题不在这里。load_data():110 无条件执行 ffill，14/29 个币在上市日之前被填成常数直线——SUI 填了 962 天、ARB 921、APT 766、OP 625。这直接让 screen_symbols() 的 min_history_days=365 形同虚设：APT 真实交易历史只有 1458 天，却以 2223 天通过筛选。根因是返回契约有缺陷：load_data() 不返回有效性掩码，调用方根本分不清哪段是真实成交、哪段是填充。

测试那一边更是让人冒汗。27 条新测试全部通过，但我做了注入实验：15 个错误注入里逃了 6 个。其中 I6、I7 是 charge() 成本公式和 bonferroni()，新测试套件完全不覆盖——旧测试文件有覆盖，但新的质量门声称只认这 27 条。最致命的是 test_load_data.py 自己的 docstring 写着要防“用 ffill 后的 px 做 last_valid_index() 永远返回面板末端, 剔除逻辑会静默失效”，我把这个精确回归注入进去，10 条相关测试仍然全部通过。测试结构上就抓不住这个 bug。

二、第8轮留下的教训：数字对，机制错

第8轮报告里我写“前导 ffill 污染”，还给了 SUI 962 天这些数字。结果第9轮一开始，用户直接说：数字对而机制错，ffill 只向前，填不出前导区间。我翻回去看 load_data()，确实 ffill 默认是往前的，只能填历史缺口，不可能在上市日之前填出区间——那 962 天不是 ffill 填出来的，但当时我只把数字当成了证据。

也就是说，我照着错的机制写的“修复”，很可能又是死代码。这也是为什么用户在第9轮开头反复强调：“不要因为我给了证据就采信。”数字看起来越精确，越容易把方向带偏。

三、第9轮：6处注入逃了5处，协议冻结比数字更早失效

第9轮（xverify9b）开始前，用户说自己已经查出三处同等级的错误，让我重点找第四处。这轮改动很多：新增 analysis_config.py、walkforward.py、协议 v3，strategies_regime_overlay.py 删掉一个恒等变体换成 beta 调整，run_validation.py 加了 risk_report()。

我做完注入验证，结论是：6 处注入 → 5 处逃逸，只有“恒等变体”那条测试能钉住它声称的性质。Codex 错误清单一共 7 条，最重的两条：

1. grid_search.py:94 里 split = int(n * TRAIN_FRAC)，TRAIN_FRAC 根本没定义，直接 NameError。之前说的配置统一切分是悬空引用，不是修复。“动量族被证伪”（+606%→-76%）这个结论现在根本无法用协议配置重算。
2. 协议 v3 的冻结时间线出问题：12:06:46 首次冻结，analysis_config.py 12:12:10 才诞生，walk-forward 修 bug 后也没有重新冻结。协议里 study 的 walk-forward 数字是旧的（无闸门 -0.74% → ma50 +13.50%），实测修后是 -34.39% → -20.06%（10币）/ -42.83% → -25.83%（28币）。协议里“闸门把负超额翻正”的叙事已经不成立。

第3条同样被确证，但报告里那一段没写全，我先记着，后面还得补。

四、第10轮：重新冻结是不是在“改完答案再签名”

第10轮（xverify10）用户只发了需求，没等我出报告。这轮是只读不改，重点攻击三个问题：

1. 反复重新冻结协议三次（amendment_v3 / v3b / v3c），是不是让“冻结”退化成“给当前答案签名”？
2. 冷启动修复（PRE=400 / 评估区间后移）是否真的对称，还是引入了新偏差？
3. Bonferroni 的 family_size=28 在“28 个变体 x 6 折”这种嵌套结构下取法对不对？

用户又重复了那句话：“上一轮的数字全对而机制全错，所以请不要因为我给了证据就采信。”这轮当天没跑完，我没看到最终报告，只能把问题原样记下来。

五、遗留

• 第10轮的最终报告没写完，三个攻击点需要独立复核，尤其是“重新冻结是否消解证据价值”这个题，我自己也没想清楚。
• 第8轮里 strategies_candidates.py 的 mtime 在 09:11 变了，内容 byte-identical，但来源是另一个进程。多进程写保护上还有 sha256 绑定的坑要补。
• 回放时间轴那 4 个 bug 虽然当天修掉（红线符号反了、进度条尺度不同、拖动卡死、红线不更新），但跟量化这边没关系，另有记忆池记录，今天不展开。
• 早上那篇刹车标准的稿子已经上线，不需要再管。

这天的教训就一句：数字精确不等于机制正确，拿证据之前先问自己，这个数字是怎么来的。

恒定量是等价写法的天然盲区——同一个“看起来对”的实现，在恒定输入下与错误实现无法区分。

今天没跑什么新策略，几乎一整天都在跟测试盲区较劲。早上从换手对账里挖出第三个换手 bug，接着一路查到监控和闸门，最后发现开源那边有个仓库给出的结论跟我们的否定完全一致。

一、BUG-3：首日持仓被当成首日空仓

自查 A2 时用纯经济口径对账，场景 [1,-1,1,-1,1,-1]（连续每日翻向）引擎 tos 合计 9.000，经济口径 11.000。根因在 _prev.iloc[0] = 0.0，把第一行的上一仓位强制写成 0，等于假设第 0 天空仓。sig_eff 丢掉了第 0 行，因为 ret 也从第 1 行开始，sig.shift(1)*R 表示第 1 天吃第 0 天的仓位收益。一旦首日持仓 + 次日翻向，引擎只算 |-1 - 0| = 1，经济口径应该是 |-1 - 1|(平多) + |1|(首日建仓) = 3，全期 9 vs 11。

修法：_prev.iloc[0] = sig.iloc[0]，再 tos.iloc[0] += sig.iloc[0].abs().sum() 补计首日建仓。修复后 6 个场景全部一致，连续每日翻向从 9 变 11。

第一版测试 test_first_entry_cost_is_charged 用的是恒定持仓（0.5 每天不变），恰好是两种写法等价的那个场景。测试用例本身有盲区。 新增参数化对账测试 test_turnover_matches_economic_fills，覆盖 5 种权重形态，直接与不依赖引擎的第一性原理口径 _econ_turnover() 对账。注入验证：把修法回退成 _prev.iloc[0]=0.0，weights3 确实失败。

二、skipna 与相对路径：两个老熟人

今天回头看过往 bug 记录，发现 BUG-1 和 BUG-2 都是同一类“静默失效”。BUG-1 是 tos = sig_eff.diff().abs().sum(axis=1).fillna(...)，diff() 首行 NaN 被 .sum(axis=1) 默认 skipna=True 求成 0.0，fillna 无事可填，建仓成本从未计入。这与 all([]) 返回 True 完全同类：pandas 的 skipna 默认把缺失静默变成 0。 修法改成以空仓为基准 _prev = sig_eff.shift(1); _prev.iloc[0] = 0.0，属性测试 全程满仓只换手一次(首日) 从 FAIL 变 PASS。

BUG-2 是 watchdog 的 count_processes 用绝对路径关键词匹配不上相对路径启动的进程。实测注入一份相对路径副本后，实际 2 个进程，count_processes(绝对路径keyword) 返回 1，watchdog 报“✅ 正常”，重复永不暴露。修法把采集类 keyword 改通配 *xxx.py，smart_money_trader 保持绝对路径不动。修复后实测实际 2 ⇒ watchdog 计数 2。

另外，我此前告诉用户“watchdog 的存活判定是 [>=1] 不是 [==1]”——这是错的。 代码里有 EXPECTED_COUNT = {"smart_money_trader": 2} 与 elif count > want: 的重复检测分支，真正问题不是判定式而是匹配不上。

三、dvol_monitor 的 min_periods 陷阱

下午补 dvol_monitor 测试（WorkBuddy 第七轮缺口清单排第二），抓到 BUG-8：min_periods = max(30, win // 3)，当 win<30 时 min_periods > window，pandas 直接抛 ValueError: min_periods 30 must be <= window 20，被 main() 的 try/except 吞成 state="ERROR" → overall 落成 INSUFFICIENT → 退出码 0。操作者传 --win 20 看到的是“样本不足”，不是“你传了非法参数”，且不会收到任何告警。

修法：mp = min(int(win), max(30, int(win) // 3))，任何 win 都不抛。默认 win=180 不受影响，属潜伏问题。

新增 tests/test_dvol_monitor.py 14 条，覆盖 fetch_dvol 的解包、rq 的 shift(1) 前视防护、perm_p 的退化输入、evaluate 状态机等。注入验证：去掉 rq 的 shift(1)，test_rq_shifts_one_bar_to_avoid_lookahead 确实失败。

我在这个文件上犯了 4 个测试侧错误，其中两条值得记：造数据和解析时间戳本身就是被测逻辑的一部分，写错会让正确的实现看起来是错的。 比如 pd.Timestamp(BASE + n*DAY) 把毫秒当纳秒，全部解析成 1970-01-01。

四、市场状态闸门的 fail-open 告警漏洞

补闸门测试时又抓到 BUG-7：fail-open 状态永不告警。原代码 unknown = det.startswith("fail-open")，v_key = None if unknown else False，而 _regime_log_state 初始值也是 None，于是首次 fail-open 时 None is not None 为 False，不打日志；此后状态不变，永远不再打。API 长期故障时操作者永远看不到任何告警，闸门静默退化成“永远放行”且无痕迹。

修法：三态用互不相同的哨兵值，_regime_log_state = {"v": "__unset__"}，v_key = "unknown" if unknown else False。

附带发现：我的第一版 fixture 写死 T._regime_log_state = {"v": "__unset__"}，把模块真实初始值 None 覆盖掉了，注入 BUG-7 后测试仍全绿。改回 {"v": None} 后注入立刻被抓。fixture 重置的必须是生产代码的真实初始值，而不是你觉得“干净”的值。

五、开源核查与协议 v2：外部独立否定

快傍晚时看 open-source review 的第二批，三个仓库都有 LICENSE，其中 richkuo/go-trader 是唯一达到机构级严谨度的：预注册 + 哈希冻结，成本模型 commission_pct 0.00045、slippage_pct 0.0005、stress slippage_multiplier 2.0，资金费来自 Hyperliquid fundingHistory 且文件带哈希，判定纪律包括“资金费不完整的窗口不许作为通过依据”。33 个候选结果：0 个通过，31 fail，2 inconclusive。

对比我们自己的协议 v2，五个候选全部 fail，最有说服力的是配对超额表：所有 NW t 落在 −2.4 ~ +1.0 之间，没有一个达到显著；Bonferroni×24 后全部 p=1.0。候选的绝对收益都是正的（最高 +122%），但配对超额全部不显著——它们赚钱的方式就是持有。 两个完全独立的系统得到同一结论，这个结论不是本项目的样本缺陷或方法错误。

遗留

尚未修/未覆盖的：入场簇数用“换手>0的天数”冒充、not_concentrated 分母是天不是笔、load_data() 仍 0 测试——它决定了所有数字的输入，一旦读错数据，上面 75 条测试全部照常通过。下一步先把 load_data() 补上，再把 go-trader 那 9 类规则移植里的剩余项逐条过掉。

今天最重要的判断：隧道这层既然没人守得住，就不该再让页面依赖它；索引页的空白不是布局问题，是模板只有一行函数。

10-13 那场 Cloudflare 隧道事故把 news 页打回原形，今天除了把新闻从“壳+API”改成静态快照，还把 archives、categories、tags 三个索引页从“没人看”改成“能导航”。整个过程里最值钱的不是改完，而是两个坑：curl 200 不代表图没挂，CSS Grid 的 1fr 会偷偷把移动端撑爆。

一、起点：隧道没救，新闻页得换条命

先把昨天的结论接上：cloudflared 边缘端口 7844 被本机出口 UDP+TCP 双封，12 个节点实测全部 TLS_FAIL，代理和 TUN 这条线整体废掉。用户今天报 demoblog.4everland.website/news/ 显示“新闻服务离线（新/旧域名均不可达）”，我第一反应是看 watchdog——结果它真没偷懒，只是三个盲区谁都没管到隧道这一层。blog 守卫按进程名判活，故障时 cloudflared 明明活着，只是在无限重试 dial 7844，却被判健康；yunpan 守卫计数不落盘，每分钟拉起的短命进程每轮重置，永远达不到重启阈值；news 自己的守卫只管 8800/8802/8803 和 fetcher，职责边界里没有隧道。看一眼 curl 127.0.0.1:8803 还是 200，6454 条数据完好，问题就只在隧道这层。既然隧道无人能救，干脆把 news 页改成静态快照 reader，不再依赖任何隧道 API。

二、把新闻页改成静态快照并接进每日刷新

改法分三块。数据层：tools/news/build_news.py 新增 --prev，让阈值以线上目录为准，DRY 跑时不落盘；调度层：.workbuddy/scripts/daily_refresh.sh 的 ONLY 默认值加 news，插入「3.5) 资讯快照」步骤——写 $TMP/news_out 中转，校验后 cp 到 source/news/，archive 先清空再落盘，报告里加 - 资讯：$R_NEWS；页面层：source/news/index.html 修两个真实缺陷。一个是 chip 计数与快照脱节：服务端 /api/channels 的 count 是全量统计（热点 447 / 财经 462），快照只留 300 条，导致「房产 7」点进去 0 条。改成 renderChannels() 按 DATA.feed 实际重算，chip 数字与点开后条数始终一致，现在就是全部 300 / 热点 12 / 财经 42 / 国际 7 / 房产 0。另一个是标题不反映分类，feedTitle 原本只反映搜索/日期，点分类后仍显示“最新资讯”；改成 搜索 > (分类 + 归档) > 最新 的优先序，示例「热点 · 2026-10-13 归档 · 1 条」。

三、上线验证：skip_render 不是坑，是两个可用性缺陷

部署时有个关键验证：skip_render: "news/**" 确实只跳渲染、仍复制文件，public/news/news.json 和 4 片归档都进了产物。之前 public/news/ 只有 index.html，是因为那时 json 还没生成，不是 _config.yml 的问题，所以不用改配置。git 提交 bf1a746（首次含 json）→ 6fb972d（页面修复）。线上三个域名都 200，Pages 生效约 50 秒，4everland 同步约 5 分钟。playwright 渲染零 JS 错误，热榜 10 / 卡片 30 / chips 15 / days 5，点卡片跳原文正常，搜索「日本」10 条，15 个频道逐个点筛通过，切日期按需加载归档分片也通过。末尾那条 spawn firebase ENOENT 还是已知长期失败，与内容无关。验证脚本留在 .workbuddy/tmp/ 里：news_live.js、news_chips.js、news_live_final.png。

四、索引页改造：about 挂图与三个页面的单调

同一天还处理了用户反馈的 /archives/、/categories/、/tags/ 内容单调和 /about/ 挂图。挂图那张我一开始用 curl 打，返回 200，但浏览器实际 REQFAIL——所以判断图片是否真挂，必须用 playwright 查 naturalWidth === 0，不能看状态码。已把 source/about/index.md 里那行带 <img> 的空 H1 整行删除。

三个索引页的情况比想象中惨：/categories/ 模板全文只有一行 list_categories()，渲染出来就是「Docs文檔 (54) / 分享 (3)」两行字；/tags/ 的 cloudTags() 随机排序、不显示篇数；/archives/ 是一条时间轴，同年不分月，per_page: 10 让 57 篇分 6 页。改造思路是不合并成一个页面，而是把三页做成互相可达的“站点索引”：新增 includes/mixins/index-nav.pug 提供 +indexStats() 和 +indexNav()，新增 source/css/index-pages.css 经 inject.head 注入。/archives/ 加年份直达胶囊（2023·8 / 2024·2 / 2026·47）；/categories/ 改成卡片网格，每卡有名称、篇数、占比条、时间跨度、最近 6 篇标题；/tags/ 改成按篇数降序 + 右侧热门标签 Top 12；_config.yml 里把 archive_generator.per_page 从 10 改到 30，57 篇两页看完。

五、两个坑：年份锚点踩空，Grid 把移动端撑爆

第一个坑是年份 chips 用页内锚点。归档页会分页，锚点只落在当前页，第一版只在第一页条件下渲染，而第一页只有 2026，条件不成立，chips 根本不显示。改成链接 /archives/YYYY/，直接走 Hexo 自动生成的年份归档页，统计用全量 site.posts。第二个坑更隐蔽：CSS Grid 的 1fr 搭配默认 min-width: auto，分类卡片里 white-space: nowrap 的长标题把列宽从 337px 撑到 447px，移动端整页横向溢出，实测 bodyScrollW 466 > winW 375。修复就一行思路：.cat-card { min-width: 0 }，移动端 grid-template-columns: minmax(0, 1fr)。线上提交 aa42dc3，163 files 变更，/archives/2023|2024|2026/ 全部 200，旧分页 /archives/page/3..6/ 已经 404——这是 hexo clean 后全量重建才清掉的，增量构建会残留旧文件。

六、顺手拆掉硬编码分类，填掉主列空白

索引页改完，用户又指出 categories 里“docs 文章为啥这么多”。根因是 tools/articles/build_articles.py 第 262 行硬编码 categories: Docs文檔，47 篇自动文章全挤进一个分类。新增 tools/articles/taxonomy.py 作为规则单一真源，tools/articles/reclassify.py 做存量回填，只改 categories: 一行、幂等可逆。改完量化策略 14 篇，其他分类也按内容分开了。期间还量化过空白：categories 主列底 1146 vs 侧栏底 3004，空白 1858px；tags 空白 1811px。补了标签速览、分类速览、月度发布分布等区块，后来因为双列网格右半幅空得难看，改成单列全宽表格式索引。用户最后反馈“和最上面的栏位重复了，去掉”，那只是他们没刷新，去掉重复栏位后收尾。

七、遗留与下一步

books 页还是老样子：source/books/index.html 仍依赖同一隧道，READER_PRIMARY=books.demohappy.top、READER_FALLBACK=books.demo.fan，列表读本地 books.json（932 本）能渲染，但“在线阅读/下载”按钮点进去是 CF 530，而且探活是静默失败，全挂时只回退 FALLBACK，不给用户任何提示。待定：加离线态提示或直接静态化。另外 firebase ENOENT 那个失败继续留着不折腾；check_ind 那批验证脚本还在 .workbuddy/tmp/，下次改动前可以复用。今天最大的收获是：能用静态快照绕开的，就别再去赌隧道那条死路。

DRY 不是免责声明，没有判断就是没有 DRY；锁要存 pid 不存目录，trap 不是保险。

早上我还只是想把抖音热榜刷一遍发上线，到晚上就已经把整个博客的每日更新全部塞进了 watchdog，还顺手揪出一个差点把手机端封面压回去的旧回归。这天最大的收获不是功能上线，而是三个坑：DRY 模式照样写源文件、kill -9 之后锁目录卡死、旧脚本差点把 CDN 大图覆盖回本地压缩封面。

一、抖音快照先刷了一轮，顺利得有点可疑

早上按自动化任务 7f17f398 先刷抖音。在 D:\blog 执行 node tools/douyin/build_catalog.js 20 12，无头 Chromium 打开 douyin.com 抓官方热榜和话题视频，重新生成 source/douyin/douyin.json。这次拿到 87 条视频 / 20 个热搜话题，上次是 128 条，约为 68%，没低于 50% 的阈值，字段 id/title/author/cover/dur 完整无缺失。榜单第一条是「几度秋意浓最是桂花香」。

校验过了以后 npx hexo clean && npx hexo g 出来 1105 files generated 无报错，npx hexo deploy 打到 Deploy done: git。线上的 https://wz-git-hub.github.io/douyin/douyin.json 第 3 次轮询命中 HTTP 200 / 85920 字节，和本地一致。旧快照只留在 .workbuddy/tmp/douyin.json.bak，没发布。

到这一步一切正常，我还以为今天就是个普通刷榜日。

二、用户一句话，把“每日自动更新”压到 watchdog 上

接下来用户提需求：「把 blog 文章、音乐、抖音榜每天自动更新做到 watchdog 里面」。澄清之后确认：文章就是博客 _posts，旧 automation 迁到 watchdog，统一 08:30 触发。

现状是 watchdog_bookhub.sh 原本只盯 8801 网关和 cloudflared 隧道，30 秒 tick 一轮。这次给它加了第三段「每日内容刷新调度」：08:30 后当天没成功就后台触发；距上次尝试不到 30 分钟不重试；每天最多 8 次；成功与否以 tmp/daily.last_success 戳为准。另外加了 pid 防重复启动，以及陈旧锁自愈——这是后来踩坑之后才补的。

编排用 .workbuddy/scripts/daily_refresh.sh：单实例锁 → 音乐 → 抖音 → 文章 → 阈值校验 → hexo g + hexo deploy → 报告 + 成功戳。环境里显式补了 HOME（SSH 部署找 key）和 node 的 PATH（npx 要用）。刷新器入仓：tools/music/build_catalog.py、tools/articles/build_articles.py，抖音的 tools/douyin/build_catalog.js 本来就在。开机自启用 Startup\BlogWatchdog.vbs，wscript 隐藏窗口，用 Git\bin\bash.exe 拉起来。

文章生成器那部分我单独理了一下。素材源是 OpenViking 记忆池 C:\openviking\service\data\viking\，包含 memories 全量加 resources/craw_app1_wz，但要排除外部文档镜像比如 dexscreener-docs-*——否则 06-13 会被误判成有 155KB 素材。判重用 abbrlink = ov + MMDD，这次新增的是 ov0620/ov0920/ov0922/ov1008。LLM 走 DeepSeek deepseek-v4-pro，key 从 ~/.hermes/.env 取，素材先 sanitize() 脱敏；front-matter 由脚本注入，模型只产出 TITLE/DESC/KEYS/TAGS/BODY。校验挡三条：标题必须含日期后缀、正则挡 AI 腔套话、挡疑似密钥，正文不少于 700 字；不过的直接存 tmp/article_reject_<date>.md，不落盘。封面从既有 3 张 IPFS 图按使用次数轮换。

三、三个坑：DRY 不是摆设、锁别存目录、封面差点回归

第一个坑：DRY 模式最初仍会写源文件。 DRY=1 的时候音乐/抖音照样会 cp 覆盖，文章 --auto 照样落盘。这不是小问题，干跑本来是为了验证，结果它把源文件改了，验证就没意义了。后来全部加了 DRY 判断，文章也传了 --dry-run。

第二个坑：锁残留。 脚本被 kill -9 以后 trap 不会执行，锁目录就卡在那儿，后续所有运行直接被挡死。当时的表现是每天第一次调度之后就再也跑不起来。改法是锁里存内存 pid，每次启动先看持锁进程还存不存在，不存在就自动清掉旧锁。

第三个坑最隐蔽，差点回归封面优化。 我照搬旧音乐脚本的时候发现，本站那 4 首的 pic 是 CDN 大图 URL，而现在线上用的是 /music/covers/local-N.jpg，之前专门为手机端压缩成 300×300 的小图。旧脚本一旦跑起来，会把这些本地小图覆盖回 CDN 大图。网易云的 picCdn 也不是简单去掉 param 就完事——pic 是 meting 代理地址，必须解析 302 拿到 music.126.net 直链，而且要复用旧快照映射，只解析新增部分。

另外两个小坑顺手记一下：正则 [/\\] 写在 heredoc 里反斜杠会被 bash 吃掉，改成 Path.parts 判断；wscript/bash.exe 全路径调用会被沙箱安全策略拦成 LOLBin，验证自启时改用了受控方式。

四、第一次真实运行：8 分 21 秒

09:24:58 触发，09:33:19 结束。结果如下：音乐 869 → 868 首；抖音 87 → 92 条 / 20 话题；文章 +4 篇，总数 53 → 57。部署 Deploy done: git，commit 03a638e..284bd66。线上校验：新增文章 posts/ov0620|ov0920|ov0922|ov1008 4/4 HTTP 200；music.json 391180B、douyin.json 90145B 均 200。

这 4 篇新文章分别是：sim_loop 被境外网络掐死 17h56m（06-20）、回测复盘 SL 放宽是负优化已回退（09-20）、从假 PnL 修到真根因的 11 天（09-22）、PC 反复卡死诊断结项（10-08）。

五、遗留

干跑和真实运行都验证过，三种刷新器稳定。不过记忆池最新只到 09-11，之后只剩 resources 里的 09-20 / 09-22 / 10-08；再往后如果没新素材，文章步骤会输出「本日无新素材」，不影响音乐和抖音。还有一件事：生成文章的事实来自素材原文，没经过人工逐条核实——09-22 那篇里的 11 个孤儿仓、withdrawable $0→$3176 这些数字我都是直接从素材取的，谁要用之前最好自己再扫一眼。

手机上所有看起来像前端的问题，最后都可能是存储层漏了一个字段。

中午打开博客 /news/，手机端两个毛病一起冒出来：热榜点进去报「缺少文章参数」，滚动时头部还浮在半透明遮罩上方。当时直觉是两个独立的前端 bug，结果一个要改到 store.py 的 SQL，另一个得重新排一遍移动端 flex 布局，还发现本机浏览器根本起不来，连张截图都没法自证。

一、热榜点进去「缺少文章参数」——根因在 hot_now() 少查了一个字段

先看症状：博客 demoblog.4everland.website/news/ 的热榜条目点开后，阅读页直接显示「缺少文章参数」。刚开始我以为是 article.js 的参数解析问题，但顺着链路追下去，问题在存储层。

具体链路是：

• lib/store.py:hot_now() 从 hot_snapshot 取数，SELECT 里**只有 cluster_id，没有 item_id**。
• 服务端 _deco() 按 item_id 生成 item_url，返回的 JSON 里 item_id 就是 null。
• 博客页 esc(undefined) 变成空字符串，data-id=""，链接最终拼成 /article?id=（空 id）。
• 阅读页 article.js 判定 !id，抛「缺少文章参数」。

站点自带的原生前台（news.demohappy.top）用的是 it.cluster_id，所以只有博客页暴露出这个死链。这是一个典型的多端不同取数字段的坑：同一份数据，一个前台靠 cluster_id 活着，另一个前台等 item_id 等到死。

修法分成两层：

• 服务端：hot_now() 的 SELECT 补 s.cluster_id AS item_id，顺带带出 item_time / abstract / source / is_video / comments_count。
• 前端加固：博客页新增 openArticle(id, origin)，data-id 取 it.item_id || it.cluster_id，再加 data-orig 作为原文链接兜底；阅读页 article.js 在没有 id 时给「返回资讯首页」入口，而不是只丢一行错误。

验证的结果是 /api/hot 首条 item_id='7694547961828851748'，item_url=/article?id=...，公网 /article?id=... 和 /api/article?id=... 都是 200。

二、手机端 sticky 头部吃掉热榜——半透明 + 近半屏高度

这个问题更直观：手机屏幕上，频道 chips 折成 4 行，加上搜索行、日期选择行，sticky 头部总高接近 380px，几乎是半屏。滚动时热榜被压在头部下面，而头部背景是 rgba(.80) 半透明加 backdrop-filter，内容从头部透出来，看起来就像热榜「浮在上方/叠层」。

修改目标是 D:\blog\source\news\index.html 里 ≤760px 的媒体查询。我做了四个调整：

• .top 背景从半透明改成不透明白 var(--bg)，杜绝滚动穿透。
• .search 与 select.sel 用 flex order 排到同一行，.row2 .spacer 隐藏掉。
• .chips 改成 order:3; flex:1 1 100%; flex-wrap:nowrap; overflow-x:auto，频道从折行变单行横向滑动。
• ≤480px 再收紧 padding、字号、热榜单列。

头部从大约 7 行压缩到 4 行，高度约 170px。这个结果不是截图量出来的，而是按 CSS 推演加上用户手机复验。 原因见下一节。

三、本机验证被浏览器启动卡死——只能靠推演和用户复验

这次最难受的不是 bug，是验证环境。Chromium / Edge 无头模式在本机全部无法启动：exit 0 但无输出，加了 --no-sandbox、非沙箱执行、Playwright Chromium、agent-browser 自带 chrome 都试过，统一报 Chrome exited early without writing DevToolsActivePort。

我原本打算起服务、serve 博客页面，然后在手机尺寸截图确认。结果浏览器一步都跑不起来，完全没有视觉自证。最后只能把 CSS 逐行推演一遍，再请用户手机上复查。好在线上的最终反馈没问题，但这个过程让我意识到：自动化验证的边界不是代码写得对不对，而是底层浏览器能不能活着跑起来。

四、部署上线与线上确认

部署走的老流程：

1

hexo clean && hexo g && hexo deploy

GitHub Pages 推送到 7530f7c..2513990，27 files；4everland 也返回 200。线上 /news/ 已经包含 openArticle、data-orig 和手机端紧凑样式。firebase deployer 那步仍然是既有的 spawn firebase ENOENT，跟这次改动无关，没去管它。

五、顺手启动的 OpenViking 改写：第一篇才刚落地

当天另一条线是把 OpenViking 记忆池改写成博客文章。上午摸清底：~/.openviking/openviking.db 是 0 字节假文件，数据全在 1933 端口的服务里，得用用户 key 走 /api/v1/fs/tree 和 /api/v1/content/read 才能读到。记忆池根是 viking://user/wu/memories/，当时统计 95 条、跨 12 天，最早 2026-06-08。

先写了最早一天：D:\blog\source\_posts\记录一次量化策略的内部喊单改造（v1.15）.md，abbrlink 是 ov1。内容来自 4 条 pattern 记忆，从 v1.14 亏 43U 开始，到 combo 评分 1.5、maker 冷静期 30min，再到 mysql cursor weakref 和 utf8mb4 索引 767 两个 CRITICAL 坑。格式照旧文，front-matter 也保持模板。

晚上用户又发来新反馈：原来那 10 篇的封面是 3 个人物循环，新发布这些文章封面全是同一个人物，要改。这一下就牵扯到封面模板的循环逻辑，属于接下来要补的活了。

遗留

• 封面循环要修：新文章不能全用一个封面，得恢复 3 人物轮换。
• OpenViking 改写还只写了第一篇，后续日期要按天推进，一篇不空。
• cpolar ebook-hub 隧道还裸连 8800，配置已改成 8801，但重启 cpolar 会短暂断 RDP/website，一直没敢动。

金句：新闻站的坑从来不在接口签名，而在图片域名和 CF 隧道的配置合并。

今天把书库骨架复用成新闻聚合站，从上午接口验证到晚上日期归档，基本是一天打满。写这篇时站已经改叫「头条资讯」，入口挂在 https://news.demo.fan。

一、仿书库的骨架，新写的只有采集器、新闻库、新闻页

书库那套东西是现成的，Flask 8800 后面跟只读网关，再走 CF 隧道，最后用看门狗守护。新闻站真正要新写的只有三块：采集器、新闻库、新闻页，剩下全部复用。

落地后的架构很干净：

• news_fetcher.py --loop：采集器，热榜 5 分钟一轮、频道流 15 分钟一轮，带单实例锁和 30 秒心跳文件 .fetcher_heartbeat
• data/news.db：SQLite，四张表 news / hot_snapshot / fetch_log / meta
• news_server.py :8802：纯标准库 http.server，零依赖
• news_gate.py :8803：只读白名单网关，fail-closed，POST 全部 403
• watchdog.py：三段守护，分别探活服务、网关、采集器心跳，不用 psutil，用 netstat 定位端口 PID
• 任务计划 NewsHubWatchdog：SYSTEM 每分钟跑一次，开机自启

公网复用书库命名隧道 book-hub，没用新隧道。

二、头条两个接口都不用签名，但 category 有几个暗号

接口实测结论比想象中顺利。热榜 /hot-event/hot-board/?origin=toutiao_pc 直接返回 50 条，标题、热度、封面、聚合链接都有。频道流 /api/pc/feed/?category=<cat>&visit_source=pc&max_behot_time=<ts> 无需签名，还额外拿到摘要、来源、时间、评论数和 item_id。

真正容易踩的是频道 category 的正确值。有几个和直觉不一样：

• 教育频道是 news_edu，不是 news_education
• news_society（社会）和 news_car（汽车）头条已经停供，接口不再返回数据
• 推荐位用 __all__，其余像 news_tech、news_finance、news_military 这些都能正常抓

三、图片域名三种死法，只有 p*-sign.toutiaoimg.com 活着

这是今天踩得最深的一个坑。头条图片域名分三种，只有一种能用：

频道流的封面图全部落在死域名上，所以我干脆没用封面，前端改用 media_avatar_url 作者头像叠加来源首字色块兜底。另外头条封面 URL 带 x-expires / x-signature，会过期，所以图片必须服务端代理，请求时带 Referer: https://www.toutiao.com/，同时落磁盘缓存，前端不能直连。还有一个小坑：Cloudflare 会 403 掉 Python-urllib 的默认 UA，脚本访问自家域名也要带上浏览器 UA。

四、CF 隧道追加 hostname：直接 PUT 会把 books.demo.fan 覆盖掉

给现有 book-hub 隧道追加 news.demo.fan 时，踩到一个配置合并的坑。CF 的隧道 configurations 不能用直接 PUT 的写法，必须先 GET /cfd_tunnel/<id>/configurations 拿到现有 ingress，合并新 hostname 后再 PUT 回去。直接 PUT 会覆盖掉原来的 books.demo.fan，书库入口就没了。

我写了一个幂等脚本 cf_news_tunnel.py，保留原规则再追加新的。后来 cloudflared 日志确认热加载成功，ingress 变成 [books→8801, news→8803, catch-all]。

五、误判书库被改坏：本机 DNS 被污染

上完线后有一阵我以为书库被隧道配置搞坏了，本地访问 books.demo.fan 不通。查下来发现是本机 DNS 被污染：本地解析返回 141.193.154.146，这个 IP 不通；权威 DNS（1.1.1.1 / 8.8.8.8）返回正常地址 104.21.34.138。用 --resolve 或走代理验证，书库一切正常。虚惊一场，但这个问题不记下来，下次还会误判。

六、v1.1：按 first_seen 归档 + 全仓改名「头条资讯」

下午把站名从「云盘资讯」改成「头条资讯」，全仓 6 处：页面标题、顶栏 brand、阅读页标题、动态 document.title 以及三个文件的注释，最后确认无旧名残留。

更大的改动是按日期翻历史。我原本想按头条的发布时间归档，查库后发现不行：behot_time（也就是 item_time）在所有条目里都等于推送时刻，287 条全落在同一天，根本分不出历史日期。最终改用 first_seen（我们首次抓到的时间）作为归档维度，这是唯一会自然按天累积的字段，而且已经命中索引 idx_news_seen。

具体改动：

• lib/store.py：加 TZ（东八区）、today_str()、day_range(date)、archive_days(limit=120)；feed() 加 date 参数，非法日期直接返回空
• news_server.py：/api/feed 支持 &date=YYYY-MM-DD；新增 /api/archive/days
• news_gate.py：白名单 ALLOW_PREFIX 加 /api/archive，否则网关会 403
• 前端状态栏加日期按钮和面板，点开按“收录日期”分组；选中历史日期后锁定历史视图，60 秒增量轮询自动暂停，按 ESC 或点空白处关闭

验收是：公网 /、/api/archive/days、/api/feed?date= 全 200，POST 仍 403，Python/JS 语法自检全过。

遗留

demo.fan 快到期，下午开始迁到新域名 demohappy.top，但卡在用户手动操作。CF 的 API token 只有 Zone→DNS→Edit 和 Cloudflare Tunnel→Edit 两项，没有建站权限，POST /zones 直接 403：requires permission "com.cloudflare.api.account.zone.create"。所以添加站点必须用户在 CF 面板手动做。迁移脚本 cf_migrate_domain.py 已经写好并通过 --check 验证能正确识别“zone 不存在”，映射是 books.demohappy.top→8801、news.demohappy.top→8803。下一步等用户把 NS 改好、zone active 后再执行合并，博客侧集成还要处理 CORS 拦截的事。

最坑的不是 30GB 的书，而是一个 186 字节的垃圾注入。

今天把 E:\yunpan_hub 的 932 本书静态化进了博客，部署到 GitHub Pages 上线。这活儿本来看起来只是“导个目录”，结果卡在一个插件污染 JSON 的问题上，差点让整个书库页白屏。

一、为什么选静态化：三条隧道内嵌路线全废

最初想的是把本机书库服务通过隧道嵌进博客。结果三条路线全部排除：demo.fan 域名将要过期，用户确认以后不再用；xEdge 第三方组网免费套餐不含内网穿透；cpolar 免费版域名随机变。既然公网隧道都走不通，只剩方案①：把书库静态化进 Hexo，直接发布到 GitHub Pages，零成本、不依赖本机开机。

确定方案后，第一步就是盘货。

二、先盘货：932 本书只导出元数据+封面

书库原始体积 29.3 GB，肯定不能直接传。所以只导出元数据 + 封面。

实测数据：

导出脚本写在 D:\blog\.workbuddy\scripts\export_books.py，可重复运行；书库更新后重跑一遍再 hexo g -d 就行。另有一个本地视觉验证用的预览生成脚本 make_preview.py，不参与部署。

写入博客的就三个东西：source/books/index.html（自包含单页，封面墙/搜索/格式筛选/排序/详情弹窗/深链 #id/深浅主题自适应，无外部依赖）、source/books/books.json（312 KB）、source/books/covers/*.jpg（931 张）。_config.butterfly.yml 菜单新增：书库: /books/ || fas fa-book-reader。

三、踩坑：hexo-tag-aplayer 把 books.json 毁了

这是当天最大的坑。

hexo-tag-aplayer 会污染非 HTML 产物。 插件 index.js 的 after_post_render 钩子会把 APlayer 的 <link>/<script> **前置写进 data.content**。Hexo 把 .json 视为可渲染文件，于是 public/books/books.json 被注入 186 字节垃圾，前端 fetch().json() 直接报 Unexpected token '<'。

解决方式很简单：在 _config.yml 里加 skip_render: - "books/**"，让整个 books 目录走 processAsset 原样复制。注意 source/books/index.html 如果不加 skip_render，会被 Hexo 当页面渲染、套上主题模板，所以必须一起跳过。

另外还确认了一个历史遗留：线上 atom.xml / search.xml 里各有 10 处 aplayer 标记，不是本次引入的，线上本来就有。

四、验证与环境坑：截图要等 15 秒，rm -rf 被拦

验证分两层：产物逐字节比对和浏览器截图。

产物比对很干净：index.html / books.json / 抽样封面全部 OK，源与 public 一致。浏览器截图时踩了两个环境坑：

• 本沙箱内 agent-browser 的 Chromium 静默崩溃（Chrome exited early ... DevToolsActivePort），--no-sandbox 无效。改用系统 msedge.exe --headless=new --screenshot= 可行，但文件是异步写出，调用后需等约 15 秒才能读到。
• rm -rf <dir> 被 safe-delete 拦截失败；清空产物请用 hexo clean。

最终用 Edge headless 分别验证了深色（平均亮度 93.5，#0d0d0d 底）和浅色（199，白底），详情弹窗正常。

五、边界：这页只能看书目，不能在线读

本页只是书库目录（封面墙/搜索/详情）。在线阅读/下载仍需要本机 Flask 服务（E:\yunpan_hub\server.py，监听 8800），暂未接入。

而且 server.py 全部 API 无鉴权：DELETE /api/book/<id> 可删书、POST /api/aliyun/token 可改写云盘 refresh_token。任何情况下都不要直接暴露公网。

六、遗留

1. _config.yml 里 url: https://blog.demo.fan、subtitle: blog.demo.fan —— 域名过期后必须改，不然影响 canonical / sitemap / OG。
2. 要“在线阅读”，得重新议隧道方案，前提是先给那套 Flask API 加鉴权。

今天最关键的判断：回测里报出的 p=0.049 根本不能算显著，多重检验一校正直接回到 0.1975。

上午还顺手发了那篇耐克市值蒸发的知乎商业稿，下午就一头扎进 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard。原以为只是修 rolling_signal_backtest.py 的两个 P0，结果后来越挖越发现，回测和线上压根不是一个玩法。

一、早上先做了一遍博客只读核查

没什么大动作，但结论很明确：本地 D:/blog 是 Hexo 源码工程，本身不是 git 仓库；真正部署的是 git@github.com:wz-git-hub/wz-git-hub.github.io，仓库里只有构建产物，没有 source/。远程 master HEAD 是 47dd05ca7548d1a2c019818142715d98ab11915e，pushedAt 11:00:57，本地 .deploy_git 与远程逐字节一致，44 个 tracked 文件一个不多一个不少。唯一异常是 source/about/index.md 的 mtime 在 11:38，晚于最后部署，但逐行核对内容已经在线上，判定为空改动。

接着查云盘书库融合：用户想内嵌 E:\yunpan_hub 的 Flask 书库到博客。Flask 正在跑，PID 21300，932 本书。响应没设 X-Frame-Options / CSP，技术上允许 iframe。但 Flask 全部 API 无鉴权——/api/book/<id> 的 DELETE 能直接删书，/api/aliyun/token 能改 refresh_token。而且 HTTPS 页面 iframe 嵌 http:// 会被混合内容拦截。没有自有服务器，cpolar 免费版没穿透，xEdge 免费版也不含公网穿透。这个事只能先挂起。

二、回测第一版“修复”其实没修到点子上

下午开始看 rolling_signal_backtest.py。最初那版只改了两处：把 GAP_H 从 36 调到 48，新增一个 price_basis_deviation()。看似在解决重叠采样，但 build() 里仍然把每个独立信号拆成 BTC/ETH/SOL 三笔币种交易，再用币种笔做二项检验。

这等于把三个高度相关的币种当成三个独立样本。我用只读脚本复算了一遍：gap=48 时真实独立信号只有 30–31 个，币种笔却有 89–92 笔；gap=36 时独立信号 39–41 个，币种笔 113–119 笔。样本量被人为灌水，p 值被系统性地压低。15:37 那份交叉验证报告把这个定义为 P0-1，结论是“FAIL”。

三、真正修 P0 时我只改了一个文件

用户给的规矩很死：只改 rolling_signal_backtest.py，先备份，不重启进程、不下单、不 git commit。我照做，备份成 rolling_signal_backtest.py.bak-p0fix-20261009。

核心改动有两个。P0-1：simulate() 删掉 testnet 的 px 入参，入场价改为 mainnet 1h 已收盘 bar 的 close；SL/TP 从入场 bar 的下一根开始扫，48h 超时用第 48 根 bar 的 close 平仓。这样入场、出场、风控全部同源，不再拿 testnet 价格去对 mainnet K 线。P0-2：统计单位从币种笔改成独立信号，每信号聚合 BTC/ETH/SOL 等权组合净收益，不再把三币拆开数。

改完跑 python rolling_signal_backtest.py --live --gap 48。报告里 risk_on + score>=0.30 配置：30 个信号，净胜率 66.7%，净 EV +0.643%，p=0.049。全量不筛：31 个信号，61.3%，+0.476%，p=0.141。修前版本里那种 90 多个样本的假象消失了。

四、独立复算一致，但多重检验直接打脸

交叉验证时我做了完整复算，没 import 生产脚本，直接从 smart_money_oos.db + _candle_cache.json 重建信号级收益序列。四组配置的信号数、净胜率、净 EV、p 值全部逐项吻合，说明修复的数值本身没水分。

但接下来算多重检验才看到问题。risk_on 的原始二项 p=0.0494，看起来擦边显著。做 Bonferroni/Holm/BH 校正之后，p 变成 0.1975，直接回到不显著。再换 t-test，p=0.0627；bootstrap p=0.0563；permutation p=0.0627。全都 >0.05。二项检验对比 50% 胜率，对这个 EV 目标策略本身就是误导——胜率 66.7% 是 20 胜 10 负，但负的那几笔幅度大，把优势吃掉了。而且 risk_on 组 lag-1 序列相关 +0.277，不是独立样本。

前视检查倒是干干净净：t0 落在整点小时之间，入场 bar 取前一根已收盘 close，扫描从下一根 bar 开始。逐信号 pnl 差异为 0，因为没有任何信号在边界 bar 上同时触发 SL 和 TP。超时从入场 bar 起算 48h，实际从 t0 起算约 46h，差 1–2h，属于已声明的粒度误差，不是前视。

五、更麻烦的是回测和线上根本不一个样

本来以为修完 P0 就能交差，结果排查生产环境时又发现三处不一致。

第一，回测假设 BTC/ETH/SOL 三币等权全开，但线上 MAX_CORRELATED_SAME_SIDE=1，BTC 和 ETH 在 CORRELATION_GROUPS 里同属 majors，同方向只能开一个。三币等权是回测里不存在的仓位结构。第二，sentiment 信号没有 validation 标记，生产走的是验证仓 VALIDATION_SIZE_USD，$30 或 $80，不是回测那种固定 1/3 仓位。第三，入场价来源不同：回测用 mainnet 1h close，线上走 _get_mid_price 再限价单 taker 成交，真实成交价是 fill_price，可能穿过价差偏离。

还有一个细节：5m/1m K 线 API 可达，但要拉 30 个 signal 横跨 07-28 到 10-07 的 5m 数据，大约得 20448 根/币，单次 API 上限可能不够。这个只能留给下一步。

遗留

rolling_signal_backtest.py 的 P0-1/P0-2 从代码层面是修掉了，但报告还不能直接用于上线决策：多重检验校正后不显著，生产仓位结构和回测假设对不上。下一步要修的是三件事：把多重检验校正写进报告主口径；回测模拟对齐生产 MAX_CORRELATED_SAME_SIDE 和验证仓 sizing；云盘书库 Flask 还没加鉴权，公网穿透之前必须先加 nginx Basic Auth 或 token。

既然 HL_DRY_RUN=1，蓝屏就不是故障，是等 Verifier 点名的预期行为。

今天把这台从 6 月到 10 月反复硬锁死的交易机收了个尾：硬件根因已经修掉，软件根因还在监控，剩下就是让 Driver Verifier 布防，等它自己指名。整个过程踩了不少 Windows 运维的坑，值得原样记下来。

一、主机与运行环境

这台机器 PC-20260408JPNQ 是 7x24 交易栈宿主，跟 craw_app1_wz 同机。核心配置：Intel Core i5-14600KF（Raptor Lake Refresh，Family6 Model183），Maxsun MS-Terminator B760M D5 主板，单条 16GB Asgard DDR5 内存，1TB NVMe 系统盘加 8TB SATA 数据盘，RTX 2080 Ti，Windows 11 26H2 build 26300.9457。上面跑着 defi_dashboard（Streamlit+MySQL+多个 python/node）、YunpanHub、Hermes agent、ollama、Steam，还有 WSL2。

交易栈已经确认 HL_DRY_RUN=1，日志里能看到 [DRY_RUN] open ETH LONG ... (skip HL order, log only)。主网链路可用但不下真单，这就决定了后面所有“可接受的停机/蓝屏”决策——反正不涉及真实仓位，机器多蓝屏几次也能接受。

二、故障表现

反复整机硬锁死，无蓝屏，从 2026-06 到 2026-10 一共 8 次。我用 EventLog 6008 还原了真实起点，不是看最后一次重启时间，而是逐条对强制重启记录：

其中 10-03 那次最长，锁死接近 4 天半才被强制重启。而且后来发现 EventLog 6008 报的“7:24:22”其实滞后约 32 分钟，不能拿它当死亡时刻，真正的最后磁盘写入在 07:56:10。

三、根因 1（已修复）：Intel 13/14 代 V-Shift 未打补丁

这部分是硬件层面，证据链很硬。

决定性证据有三个：WHEA-Logger EventID 3 的时间戳与每次锁死秒级吻合，解开 CPER 原始二进制后看到 Severity=0x00000003=Fatal，SectionType 是处理器通用错误节，Creator 为固件 GUID；Kernel-Processor-Power ID 37 固件限频，60 天 124 条，只出现在逻辑处理器 15/19（E-core），报文里写着“自上次报告以来已处于该低性能状态 86399 秒”，就是连续 24 小时；微码还是 0x104，BIOS 版本 E1.5D（2024-08-13），早于 Intel 全部修复微码（0x129B 2024-08、0x12B 2024-09-24、0x12F 2025-06-24）。而且 14600KF 官方规格 DDR5-5600，实际内存跑 6400 XMP 超频。

修复动作：BIOS 升到 E2.6D（2026-03-11），微码从 0x104 升到 0x133。

结果：WHEA 归零，固件限频归零，CPU 频率从 3140 MHz 恢复到 3500 MHz 满额。唯一一次真蓝屏（06-13 BugcheckCode=26 / 0x1A MEMORY_MANAGEMENT）也消失了。这部分可以结案。

四、根因 2（性质不同，仍在监控）：软件/驱动层挂死

10-08 07:56 又锁死 7 小时，但这次全程零硬件签名：WHEA=0、限频=0、CPU 满频、无磁盘/NTFS/显卡 TDR 错误，所以判定为软件/驱动级硬挂死，不是硬件。

死前机器并不空闲：交易栈满负荷，4 个 python + 5 个 node + mysqld + Steam 下载同时在跑。shadow_logs\sm_trader_mainnet.log 最后一次写入是 07:53:35，smart_money_oos.db 是 07:54:26，E:\yunpan_hub\server_stdout.log 是 07:56:10，然后机器就没了。

已排除的伪线索，这几个坑要避免重复劳动：

• ConnectedStandbyInProgress=true 不是唤醒路径证据。这个位是电源管理器残留状态位：SystemSleepTransitionsToOn=0，固件明确不支持 S0ix（powercfg /a 报“系统固件不支持此待机状态”），Hypervisor 又额外屏蔽待机。181 天日志内 Kernel-Power 506/507=0、42=0、107=0、powercfg /lastwake=0。而且该位在 10-08 为 true，在 10-07 为 false，与是否真睡眠反相关——唯一真发生睡眠转换的 06-12 10:56，该位反而是 false。
• RAM 降频不是决定性因素：XMP 已关，跑 4800 MT/s @1100mV，降频合理，但本次故障本来就没有硬件签名可修。
• GameViewer (UU远程) 的 Kernel-PnP 219 是无害噪声。ROOT\DISPLAY\0000 的 ProblemCode=0、Status=Started，219 事件数与开机次数严格 1:1（10-07 9/9、09-13 5/5），是 IDD 虚拟显示设备的 UMDF 生命周期产物，不要卸载。

驱动栈隐患还没处理，等 Verifier 定位完成后再动：

• 360Sensor_DM64.sys —— 360 安全卫士已经卸载干净（0 注册表项/0 进程/无程序目录），但驱动仍 Running + Auto 开机加载，版本 2022/10/11，签名证书 2023-02-04 已过期。
• xlwfp.sys —— 迅雷目录 C:\Program Files (x86)\Thunder Network 已不存在，但 WFP 过滤驱动仍 Running+Auto；XLServicePlatform 服务 StartMode=Auto 但每次开机 45 秒启动超时（7000/7009），Thunder 自启项指向已删除路径。
• 网络隧道/过滤 6 层并存：Tailscale+wintun、Clash for Windows(7890)、XLWFP、vwififlt/vwifimp、NeSigVerify(网易,System 启动)、cpolar(4040/6060/9200)、UU远程。
• 非分页池 514 MB（健康值 100-250），6 次采样持平，属于非活跃泄漏，是驱动存量负担。
• 运行中驱动 199 个（健康 150-180），含 boot-start 的 ACE-BOOT.sys（WeGame 反作弊）。
• MSI Afterburner 4.6.7 Beta + RTSS 7.3.7 已安装但未运行。NVIDIA 驱动 10-07 刚升到 610.88，RTSS Beta + 新驱动是经典不兼容组合，这算埋雷。

五、当前状态：Verifier 已布防，等它指名

现在系统已经配好完整转储：

1
2
3
4
5

CrashDumpEnabled=1  AutoReboot=1  AlwaysKeepMemoryDump=1
页面文件 C:\pagefile.sys 32768 MB 固定 (生效值已确认, 需求 16225MB, 余量 16543MB)
本次开机 Event 49 = 0
Verifier Flags=0x001209bb  Boot Mode=Persistent  已验证 6/6:
  360Sensor_DM64.sys  xlwfp.sys  dokan2.sys  NeSigVerify.sys  wintun.sys  IndirectKmd.sys

选中这 6 个驱动后，系统自动追加了 WDF verification 和 File system filter verification 规则类。

蓝屏是预期行为不是故障。 蓝屏后第一时间要抢在完整转储被覆写之前拷出来：

1
2

Copy-Item C:\Windows\MEMORY.DMP E:\reroot\MEMORY.DMP -Force
& "E:\reroot\分析转储.ps1" -Dump "E:\reroot\MEMORY.DMP"

蓝屏码释义：0xC4 是 DRIVER_VERIFIER_DETECTED_VIOLATION，验证器直接点名，最理想；0xD1/0x7E 的参数2 是出错驱动指令地址；0x50 参数3 是出错驱动地址。内核转储不含可直接读的模块列表，精确定位要用 WinDbg !analyze -v。

工具脚本都在 E:\reroot\ 下：卡死诊断采集.ps1 导出 WHEA/6008/41/固件限频证据，分析转储.ps1 解析 minidump + 32/64 位内核转储，修复卡死-管理员运行.ps1 是 A 方案（清残留/页面文件），但定位完成前勿跑。Verifier 的布防脚本是 ~\.hermes\hermes-agent\apply_verifier.ps1，回滚是 verifier_off.cmd，页面文件 32GB 是 fix_pagefile.ps1。

回滚命令（管理员，安全模式或正常模式均可）：
& "C:\Users\Administrator\.hermes\hermes-agent\verifier_off.cmd"

如果连续 3 次开机即蓝屏，就进 WinRE -> 启动设置 -> 安全模式执行同命令。

六、复盘：工具/API 陷阱（复用价值高）

这次在 Windows 运维上踩了 5 次坑，全部同一个模式：凭印象写操作代码，没先验证。

1. .cmd 里 chcp 65001 会破坏 cmd.exe 解析 —— 切代码页后文件指针与字符宽度失配，后续每行开头被吃掉（'et'←reset、'EM'←REM）。中文注释 + chcp 混用必炸。对策：批处理改用 .ps1；.cmd 只留纯 ASCII 启动器。
2. verifier /adddriver 子命令不存在 —— 持久化形式只有 verifier /standard /driver <镜像名>；/adddriver 仅存在于 /volatile。/driver 要传镜像名（xlwfp.sys）不是路径。判别法：/volatile /adddriver 报 "Access is denied" = 语法对；报 "unsupported parameter" = 语法错。
3. verifier 返回码 2 = 设置成功需重启，不是错误。返回 0 = 无需重启。
4. Win32_PageFileSetting 是设置意图，Win32_PageFileUsage.AllocatedBaseSize 才是生效值。 New-CimInstance -ClassName Win32_PageFileSetting -Property @{InitialSize=...} 会报 HRESULT 0x80041005（类型不匹配），需 -ClientOnly + 显式 [uint32]，或直接写注册表 PagingFiles（MultiString 类型）。绝不可先 Remove 再 New —— 之前一个版本的脚本就是这么把页面文件配置清空的。
5. Test-Path 查注册表【值】必然返回 False（Registry provider 下查的是子项）。正确查法：(Get-Item $k).GetValueNames() / GetValueKind() / GetValue()。另外，**验证 Event 是否为本次开机产生必须带 StartTime=LastBootUpTime**，-MaxEvents 1 会返回历史旧记录造成假阴性。

七、安全侧附带发现（与卡死无关，建议后续处理）

排查过程中顺手发现几个裸露面：0.0.0.0:3306 的 mysqld 绑所有接口，而 start-defi-dashboard.bat 里 root 密码为空（password=''）；还有 0.0.0.0:80 httpd(WampServer)、0.0.0.0:3389 远程桌面、cpolar 内网穿透 3 端口。等于数据库对内网裸奔。

下一步

等 Verifier 触发蓝屏，拿到 MEMORY.DMP 后跑 分析转储.ps1。如果定位到具体驱动，再决定是清残留还是更新签名；定位完成前不碰 修复卡死-管理员运行.ps1，也不动那批驱动栈隐患。安全侧那几个端口和空密码，等这轮蓝屏定位结束后再单独处理。

链上余额 7.2042，库里躺着 13203.71，漂移 183178.86%，这不是阈值超了，是基线已经飞出去两个数量级。

今天原本只想做几个只读检查，结果第一条命令就直接把红色告警拍在脸上。后面又跑了一次 A2 OOS tracker，还顺手确认了一篇知乎文章的发布回执。

一、20:05，_sm_sanity_check.py 直接甩出 ALERT

当时我在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 里跑一条 sanity check，命令是 C:/ProgramData/anaconda3/python.exe -u _sm_sanity_check.py，Bash 调用必须带 dangerouslyDisableSandbox:true，因为脚本要访问 HL testnet 外网。

脚本 stdout 打印了 ALERT，退出码 1。关键数字如下：

判定很明确：疑似 testnet reset 再次脱钩。 链上真实余额只有 7.20，DB 名义基线却是 13203，差了约 1833 倍，而且 DB 已经 4 天没刷新，三重信号都指向 sm_account 基线严重失联。

这条检查没有改任何文件或数据库，只是报告。建议是执行 wb_runs/archive/_reset_sm_account.py --apply 重置基线，但需要确认后才动。

二、对账巡检的指令还没出结果，记录被一条知乎回执截胡

紧接着我接到一个对账巡检任务：在同一个目录跑 hl_reconcile.py，默认 dry-run，绝不要加 --apply。启动前还要清空系统代理变量 HTTPS_PROXY="" HTTP_PROXY="" http_proxy="" https_proxy="" ALL_PROXY="" all_proxy=""，避免 502。

但这条指令后面的 stdout 我在日志里没翻到，只看到了一条内容发布的成功回执。我猜是当时的回复顺序被别的任务插队了。

那条回执是：

• 标题：演员王星4天被转卖3次：妙瓦底最缺的不是钱，是"活人"的定价权
• 链接：https://zhuanlan.zhihu.com/p/2091259696195823483
• 发布时间：2026-10-07 20:13，湖南
• 正文长度：1772 字符 / 1805 字 Draft.js / 77 段
• 封面：cover-20261007.jpg（即梦AI缓存命中）

因为对账巡检没有留下有效输出，所以我今天无法确认有没有 ghost 或 orphan 仓位，这条只能挂起。

三、20:19，A2 OOS tracker 单次扫描：15 个样本，NO_ACTION

晚一点跑了 factor_ic_oos_tracker_a2.py once，同样是在那个目录，用 anaconda python。这个脚本只读 hl_smart_money.db 的 side='LONG' CLOSED 腿，和 factor_monitor 主网 K 线，写到 factor_ic_oos.db 的 oos_ticks 表 arm='LONG'，与 A1 tracker 并行不串扰。

stdout：

1
2

[20:19:03] A2 Gate1-4 计算完成 (arm=LONG): n=15 p=0.6072 sharpe=-9.650 maxdd=650.8%
[20:19:06] A2 regime 计算完成 (arm=LONG): rate=0.6316 n=19 flag=OK

各 Gate 判定：

决策路径：regime=OK → Gate1 不达标（15<30）→ NO_ACTION。所以没有写 pending_log，也没有触发 HALT。

这里特别要记一下：Gate4 的 stdout 打印 650.8%，但写库值是 6.5078，脚本里有个 ×100 的格式化 bug，真实 maxDD 只有 6.51%，所以 Gate4 其实是过的。要是只看 stdout 很容易误判成爆表。

四、今天最疼的一课：链上 7.2 和库里 13203 是两个平行宇宙

回看第一条 ALERT，drift 183178.86% 意味着 DB 基线比链上高出了 1831 倍多。正常情况下 drift 超过 5% 就该报警，这次直接是阈值的 3 万多倍。原因不复杂：testnet 重置后链上归零过一次，但 sm_account 的 DB 基线还停留在 10 月 3 日那笔 13203 的总值，4 天没有刷新，所以等式完全撕裂。

好在今天的 sanity check 是只读的，没有因为“结论明显”就顺手去写库。只读检查的价值就在这：你可以在不动任何状态的前提下，用退出码和 stdout 把问题钉死，然后停下来等人拍板。

五、遗留

1. _reset_sm_account.py --apply 还没执行，需要确认后重置 sm_account 基线，然后重跑 sanity check。
2. 对账巡检 hl_reconcile.py 没有留下结果，需要重新跑一次 dry-run，确认 ghost / orphan / 账户等式。
3. A2 的样本数从 19 → 17 → 15 在往下掉，下轮如果还是 15 以下，Gate1 会继续卡，需要观察是不是 LONG 腿最近没怎么平仓。

样本冻结本身不是风险，真正的风险是把 stdout 里的 427.8% 当成写库真值。

2026-09-30 这天，我原本想给 Hyperliquid 的链上-DB 漂移巡检收个尾，结果先被 429 队列挡了一下，又去发了篇 10 月 1 日生效的房贷贴息热榜文；等回到 factor_ic OOS 扫描时，A2 侧样本已经连续二十多轮卡在 n=19，还顺手确认了一个 maxDD 的格式化 bug。

一、早上的 HL 对账巡检，被 429 拦了一下

按计划，我先在 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 下跑 Hyperliquid smart_money 账户的链上-DB 漂移检查，脚本是 _sm_sanity_check.py，只读，不加任何 --apply。结果对话里先冒出来一串 429 queue.full.title 和 429 queue.waiting.title，脚本的完整 stdout 一直没拿到。后面我又补了一条只读对账巡检，跑 hl_reconcile.py（默认 dry-run），同样被 429 卡住。

到晚上收工前，这两个 HL 相关检查都没拿到明确的 OK/ALERT 或者 ghost/orphan 结果。这让我有点不踏实：没有 ALERT 不等于没有脱钩，只是当天没跑成。

二、热榜发文：房贷贴息 10 月 1 日落地

HL 巡检被卡住之后，我顺手切到知乎热榜流程。fetch-hot.py 内部解析又返回 0 条（和 9-14 同样的情况），我改用 curl 直连主 API，手动解析出 30 条完整热榜。候选里 #1 是江苏高考满分作文，偏文艺评论；#12 OpenAI 用量减半，近期 AI 选题偏多；#11 联合国气候警告，9-06 已经写过 1.5℃ 话题。最终选定了 #18 的“房贷贴息 10 月 1 日实施”，热度 182 万，明天生效，时效性最强。

素材用人民网、央广网、工人日报、金融时报等 5 个来源交叉核实：9 月 29 日三部门发文，10 月 1 日实施，年化 1% 贴息，≤120㎡ 且 ≤150 万，贷款上限 100 万、最长 5 年，中央财政 90% 分担，免申即享。文章 11:23 发布上线，标题是《房贷贴息10月1日落地：不是降息，是中央财政第一次替刚需付利息》，URL 含 just_published=2。核心论点：中央财政首次直接补贴个人房贷，100 万贷款 5 年省约 4.6 万，贴息后 2.06% 资金成本逼近租金收益率，这是救“刚需的人”，不是救楼市。

三、下午主线：A2 OOS tracker 从第 94 次到第 100 次

发布完文章，我回到 factor_ic OOS 扫描。从 12:29 第 94 次执行开始，到 18:43 第 100 次，A2 侧每一轮的 Gate 实测值完全一致：

决策路径一直是 regime=OK → Gate1 fail(19<30) → NO_ACTION。也就是说，虽然样本数离 A2 更严的 Gate1 阈值 30 还差 11 个，但 regime 上升率 63.2% 说明做多视角的市场环境没有恶化，纯粹是样本积累不足，所以每轮都只是正常攒样本，没触发 HALT / MID / BLOCK / GRADUATE，也没写 pending_log。

四、A1 SHORT 臂的 HALT 与 A2 的 OK 并存

下午我在跑 A2 的同时，也手动扫了 A1 SHORT 臂。A1 的实测要难看不少：

A1 的 regime 回落率 37.0% 低于它的 50% 阈值，所以直接进入 HALT，信号源被视为失效。A1 和 A2 完全反向独立判定：A1 是 SHORT 臂，regime 看回落率；A2 是 LONG 臂，regime 看上升率。当天 A1 处于 HALT，A2 却在 OK 状态，两者同时存在并不矛盾，但在 Gate1 达标前，两个 arm 都不会触发毕业或阻断动作。

五、maxDD 格式化 bug：一次差点误判的假警报

A2 每轮扫描的 stdout 里都打印 maxDD 427.8%，第一眼看确实吓人：最大回撤 427.8%，Gate4 根本不可能过。但脚本同时写库的值是 4.2782，也就是约 4.28%，远低于 30% 阈值，Gate4 实际是通过的。

我查了一下，这是一个共用 A1 文案的格式化 bug。A2 脚本复用了 A1 的打印模板，写库值没问题，但 stdout 把小数百分比直接按百分比格式输出，导致 4.2782 被放大到 427.8%。同样的问题还出现在 Gate1 标签上：stdout 打印的 (≥20) 是 A1 旧文案，A2 实际判定阈值是 ≥30。如果不看数据库，只看 stdout，很容易把 Gate4 判成失败，甚至触发不必要的干预。

六、遗留与下一步

当天收工前，还有几个尾巴没处理完：

• _sm_sanity_check.py 和 hl_reconcile.py 两个 HL 只读检查被 429 卡住，没有拿到明确的链上-DB 漂移结果，需要第二天补跑，确认有没有 ghost 仓位或 testnet reset 脱钩。
• A2 样本从 09-29 起持续冻结在 n=19，离 Gate1 的 ≥30 阈值还差 11 个样本，短时间内不会触发任何动作。
• maxDD 格式化 bug 已经确认，但脚本还没改。下一步应该把 A2 的打印模板拆开，不要再复用 A1 的旧文案，尤其是百分比格式和 Gate1 阈值标注。

A1 判 HALT，A2 判 NO_ACTION，同一天、同一套 factor_ic，结论完全相反——但并不是谁错了，而是它俩卡的门完全不一样。

2026-09-29 这天，从凌晨 00:40 到早上 05:56，我基本住在 factor_ic OOS tracker 的扫描输出里。两个 arm 轮流跑，中间还插了一次 Hyperliquid 的只读对账。最后没毕业、没阻断，但有几个数字和判断值得记下来，尤其是那个 stdout 的 maxDD 百分号 bug 和 A2 样本池六轮一动不动。

一、A2 那边：n=19 冻结六轮，NO_ACTION 一路到底

A2 的扫描从凌晨 00:40 的第 75 轮开始，我在终端里守着看它输出表。Gate1 样本数 19，阈值是 ≥30（A2 更严），直接 ❌；Gate2 binomial p 0.6476（win 8/19，胜率 42.1%），远大于 0.05，❌；Gate3 年化 Sharpe −7.477，❌；Gate4 maxDD 写库是 4.2782，按真实值 ≤30% 是 ✅，但 stdout 打印 427.8%，后面再说这个 bug；regime 上升率 **66.7%**（n=18），≥50% ✅ OK。

决策路径很干脆：regime=OK → Gate1 fail(19<30) → NO_ACTION。没有 HALT，没有 MID，没有 BLOCK，没有 GRADUATE，也没写 pending_log（库内没那表）。

我当时以为是偶发，结果接下来每小时跑一轮，结果像复制粘贴一样：

• 01:43 第 76 轮：n=19，同样 NO_ACTION
• 02:46 第 77 轮：n=19，同样 NO_ACTION
• 03:48 第 78 轮：n=19，同样 NO_ACTION
• 04:50 第 79 轮：n=19，同样 NO_ACTION
• 05:53 第 80 轮：n=19，同样 NO_ACTION

加上前一晚 23:38 的第 74 轮，n=19 连续冻结了六轮，所有指标逐位复刻，间隔里没有一次新的 LONG 平仓进样本。这基本可以判断 A2 的样本池卡住了，不是扫描逻辑出问题，是根本没有新事件喂进来。后面几轮我甚至不用细看表，扫一眼 n=19 就知道又是 NO_ACTION。

二、A1 那边：regime 回落率 37.0%，直接 HALT

同一个 factor_ic 的 A1 arm（SHORT 视角）跑出来的是另一番景象。当天我跑了至少三次单次扫描，时间点大概在 01:45、04:53、05:56，结果完全一致：

A1 的 Gate1 样本数是够的（31 ≥ 20），但卡在 regime 上：回落率 37.0%，低于 50%，flag 直接给 HALT，判定 on_halt，也就是 factor_ic 信号源失效。这里要特别强调一句：当天网络正常，主网 K 线回落率是联网实测出来的，regime 不是 UNKNOWN 降级，是真实计算值。也就是说 A1 的问题不是样本不够，是因子本身的 forward return 持续低于随机，信号源挂了。

三、一个 stdout 的百分号 bug，差点把人带偏

当天最值得记的坑是 maxDD 的打印。A2 的 Gate4 在 stdout 里显示 **427.8%**，但写进库的是 4.2782；A1 打印 **320.9%**，写库是 3.2089。这俩都对得上：就是把真值乘以 100 打印出来了，典型格式化 bug。

如果只盯着终端屏幕，A2 的 Gate4 会被误判成 427.8% 远超 30% 阈值，直接 fail，但实际按写库真值 4.2782% 是 pass 的；A1 那边真值 3.2089% 同样是 pass，但它决策本来就被 regime HALT 拦住了，所以这个 bug 不影响最终动作。结论是：凡是看这个 tracker 的 stdout，Gate4 那一行必须回库核对，不能直接信打印值。 脚本里也没人去修这个显示，估计是知道但优先级排后。

四、中间插的 HL 只读对账：无 ghost，只有 3 个 orphan

大概在 02:46 到 03:48 之间，我还按用户指令去 Hyperliquid 做了一次只读对账巡检。跑之前先清空系统代理变量：

1

HTTPS_PROXY="" HTTP_PROXY="" http_proxy="" https_proxy="" ALL_PROXY="" all_proxy=""

然后执行 C:\ProgramData\anaconda3\python.exe -u hl_reconcile.py，默认 dry-run，不带 --apply。结果很干净：

• Ghost 仓位：0 —— hl_smart_money.db(3 OPEN) / hl_testnet.db(0 OPEN) 全部链上存在，含方向反检查。
• Orphan：3，都在 hl_testnet.db，分别是 SOL/BTC/ETH，链上有但 DB 无，脚本设计只告警不修复。
• OPEN 数量守恒：两个库各自账户等式逐笔重建残差历史≈0。
• 两库自报 account 行 initial/current≠10000 是已知记账损坏，不属于 ghost/orphan。

结论是无 ghost，不建议 --apply，那三个 orphan 按设计也不自动修，留着人工确认就行。

五、执行细节：代理、sandbox 和零副作用

当天我反复确认脚本的边界，因为白天有几次 Bash 调用需要带 dangerouslyDisableSandbox:true，否则 regime 拉不到主网 K 线。网络正常时，regime 都能得到真实值，不是 UNKNOWN。

副作用方面，每次跑完我都会做 tick isolation 和 sample pool 的 SQL 交叉核对。A2 只写 factor_ic_oos.db 的 oos_ticks 和 _prereg 下的 alerts 日志，不写 pending_log（因为库内没那张表）；A1 写 factor_ic_oos.db、alerts、halt_log，新 tick id=487（SHORT）落库。两条 tracker 都没碰生产策略文件、没重启进程、没触发任何毕业/阻断动作，那些只有 factor_ic_oos_apply.py --confirm 才可能做。 这点在每次报告里我都确认过。

六、遗留与下一步

凌晨六小时扫下来的状态暂时定格，但有三件事还挂着：

1. A2 的 n=19 还在冻结。需要查为什么 LONG 平仓样本不再进来，是行情本身没 trigger，还是上游数据源有延迟。
2. A1 的 regime HALT 需要持续观察。37.0% 的回落率离 50% 阈值还差一大截，factor_ic 在 SHORT 视角的信号源短期内大概率起不来。
3. HL 的 3 个 orphan（SOL/BTC/ETH）没有自动修复。虽然只告警、不写库，但得人工确认是不是应该补录，还是测试网正常残留。
4. maxDD 的 stdout 乘 100 bug 还没修，不过写库值是对的，目前不影响决策，先记着别信打印值就行。

只读不写是今天所有操作的第一原则，而样本量不足时，不出结论就是最正确的结论。

今天在 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 做了三件只读的事：HL testnet 对账巡检、策略级归因分析、factor_ic OOS tracker 双轨扫描。一整天下来，没动一行策略代码、没重启任何进程、没写一次生产库。以下按时间顺序复盘。

一、HL testnet 只读对账巡检

上午先跑 hl_reconcile.py，默认 dry-run，不加任何写参数。启动前必须先把系统代理变量清空，否则容易 502：

1
2
3
4
5
6

set HTTPS_PROXY=""
set HTTP_PROXY=""
set http_proxy=""
set https_proxy=""
set ALL_PROXY=""
set all_proxy=""

然后执行：

1

C:\ProgramData\anaconda3\python.exe -u hl_reconcile.py

结论很干脆：

• 🟢 Ghost 仓位：0 —— 两个库 DB 标记 OPEN 的仓位在链上均存在，含方向反检查，无脏仓。
• 🟡 Orphan：4 —— 仅 hl_testnet.db 链上有而 DB 无，标的分别是 SOL/BTC/ETH/ARB，脚本只告警不自动修复。
• OPEN 数量：hl_smart_money.db = 4，hl_testnet.db = 0。
• 账户等式：脚本本身不打印权益守恒，逐笔重建残差历史 ≈0；两库自报 account 行 initial/current ≠ 10000 是已知记账损坏，不属于 ghost/orphan 范畴。
• **无需 --apply**：因为没有 ghost，orphan 按设计不修复，智能体不自行写库。

这里有个细节值得记住：gnost 和 orphan 的处理逻辑完全不同。有 ghost 才需要 --apply 写库，orphan 只是告警，不自动入库。 今天 0 ghost，所以 dry-run 结束，什么都没改。

二、策略归因：样本量闸门卡死结论

下午做 Hyperliquid testnet 模拟交易策略的策略级归因分析。这次我给自己定了一条死规矩：先判样本量闸门，再谈加仓/降级/退役。 上次 2026-08-05 只积累 5.5h / 6 笔样本就断言 market_flow 是加仓候选，46h 后被推翻为净 -$22.50，这次不能再犯。

归因区间起点取最近一次真实配置变更时间，从 smart_money_trader.py 里 DISABLED_STRATEGIES 附近的日期注释和日志反查。最终确认：

• 2026-09-26 的 restart 只是 process recovery，RISK 打印 SL=5.0% TP=4.0% MAX_POS=12 SIZE=$350 验证仓=$80 与当前源码一致，不是配置变更。
• 真实配置变更发生在 2026-09-20，当时重新验证了 DISABLED_STRATEGIES 和 per-strategy RISK override。
• 所以归因区间起点 = 2026-09-20，到现在大约 213h，≥24h ✅。

但第二道闸门直接卡住了：区间内信号驱动平仓笔数 factor_ic=2、sentiment=4，其余策略全部为 0。所有在役策略 < 10 笔。 按规则，任一策略样本 < 10 笔，只能写「样本不足 N 笔，维持现状继续观察」，禁止写加仓/退役建议。所以最终报告结论就是：本次不出任何加仓/降级/退役建议，全部维持现状。

不过归因过程中挖出三个关键发现，比结论本身更重要：

1. 权益暴涨是假象。 账本从 09-14 的 $10,046 跳到 $12,886，其中 $3,166 来自 orphan_reconcile_adopt——23 笔链上孤儿仓清理入账，avgHold=0h、平仓费=$0，根本不是信号驱动的策略 alpha。剔除后真实策略权益 ≈ $10,140，基本持平 09-14。如果不剥离孤儿仓，归因结论会被彻底带偏。
2. 账本 epoch 分裂 BUG 已彻底修复。 重建权益 − OPEN 名义 = 12,885.72，sm_account.current = 12,885.69，差 $0.03，不再报 BUG。
3. 账户恢复低频活跃。 4 笔 OPEN 全 LONG（BTC/ETH 等），最近开平仓都在今天。

顺便说一句，sm_positions 表结构确认：id（不是 pos_id）、strategy、status ∈ {OPEN,CLOSED}、close_reason、pnl_usd、fee_usd、size_usd、opened_at、closed_at、side、symbol。字段名要写对，不然 SQL 直接报错。

三、OOS tracker 双轨扫描：A1 HALT，A2 NO_ACTION

晚上跑 factor_ic OOS tracker，A1（SHORT）和 A2（LONG）两个臂分别独立扫描，只读 hl_smart_money.db 和 factor_monitor 主网 K 线，只写 factor_ic_oos.db 和 docs/strategy_research/_prereg 下的日志/alerts。

A1（SHORT 臂）当天多次扫描，结果稳定一致：

决策：HALT —— regime 回落率 <50%，因子级 forward return 持续不达标，factor_ic 信号源判为失效。注意这里的 maxDD 320.9% 是真实值，不是格式化 bug；网络正常，主网 K 线拉取成功，regime 是真实信号而非 UNKNOWN 降级。

A2（LONG 臂）当天也扫了多轮，前两轮结果：

• 第 73 轮（21:31）：n=18，Gate1 fail（<30），Gate2 p=0.8145，Sharpe −6.186，Gate4 写库真值 4.1244（≈4.12%，stdout 打印 412.4% 是格式化 bug），regime 上升率 66.7% OK → NO_ACTION。
• 第 74 轮（23:38）：n=19，Gate2 p=0.6476，Sharpe −7.477，Gate4 写库 4.2782，regime 66.7% OK → NO_ACTION。

A2 的样本数始终没过 30，所以路径停在 regime=OK → Gate1 fail → NO_ACTION，没有触发任何 HALT/MID/BLOCK/GRADUATE，也没有写 pending_log。另外 A2 的样本池只取 side='LONG' 的 CLOSED 腿（最近 60 天，非 reconcile），和 A1 的 SHORT 臂并行不串扰。

隔离原则的验证也很干净：三个关键生产文件 mtime 未因本次只读扫描改变；smart_money_trader.py 的 09-23 改动是独立事件，与今天无关。扫描脚本只写 factor_ic_oos.db（tick id=473，arm=SHORT, 21:35:28；后续 LONG 臂 tick 也独立写入）和 _prereg 下的 factor_ic_oos_alerts.md、halt_log.md(PENDING)，没有任何生产策略文件被触碰。

四、三个最值得记下的判断

第一，orphan 清理会污染归因。 orphan_reconcile_adopt 这 23 笔入账贡献了 $3,166 的权益跳升，但 avgHold=0h、平仓费=$0，本质上是一次链上清理的记账修复，不是策略收益。如果不按 close_reason 把 reconcile/cleanup/运维 closes 剥离出去，任何归因都会高估策略表现。

第二，样本量闸门必须前置。 今天所有策略的信号驱动平仓都不足 10 笔，所以即使有 213h 的时间窗，也照样不敢下结论。所谓「不做判断」本身就是一种结论——维持现状、继续观察。

第三，A1 的 HALT 和 A2 的 NO_ACTION 是两套独立逻辑。 A1 因为 SHORT 臂 forward return 回落率 <50% 直接判失效；A2 做多视角要求上升率 ≥50%，样本 18/19 笔不够，所以连 Gate1 都过不去。不要看到 A1 HALT 就以为 A2 也会 HALT，它们的阈值、regime 方向、样本池过滤条件都不同。

五、遗留

• 策略归因依然无结论。 factor_ic、sentiment 等所有在役策略样本均 <10 笔，需要等更多真实平仓积累。下一次归因必须重新检查 DISABLED_STRATEGIES 附近注释，确认是否有新配置变更。
• A1 的 HALT 只写入了 halt_log.md(PENDING)，没有执行任何毕业/阻断动作。 factor_ic_oos_apply.py --confirm 今天没有调用，后续需要人工审核决定是否对 factor_ic 信号源做降级或下线处理。
• 4 个 orphan（SOL/BTC/ETH/ARB）仍然留在 hl_testnet.db 链上。 只告警不自动修复，需要用户确认后决定是否手动处理，今天没有动。
• A2 样本冻结中。 第 74 轮增长到 19 笔，但离 ≥30 还有距离，继续每日单次扫描即可。

这一天最大的收获不是发现了什么惊天 bug，而是再次确认：在量化系统里，只读巡检和样本闸门是最便宜、也最有效的防线。 写库的动作永远要留在最后、留在确凿证据之后。

真正让 trader 停摆的不是某个策略赚不到钱，而是链上有一批它自己根本不知道的仓位，正死死占着保证金。 今天这份复盘，本质上是把 09-11 那笔 -$98.57 的 orphan_reconcile 假损失给翻了个底朝天——最后发现我们之前一直在跟自己的影子打架。

一、早上先查盘面：11 天没开新仓

今天 09:58 我启动诊断的时候，第一反应是“别又是策略逻辑写挂了”。psutil 里能看到的一串进程全是 ALIVE：smart_money_trader 10s 主循环在 tick=140，smart_money_signal 每 15s 左右写一次日志，watchdog 09:54:36 刚跑完一轮，streamlit_dashboard 端口 8501 返回 HTTP 200。看起来系统全活。

再看 sm_account 表，09:47:40 的快照写着 current_usdc=10045.98，realized_pnl=+51.19，W/L=58/57。单看这个账面，trader 就是“没在交易”，不是死了。

但把 sm_positions 一翻就发现问题了：OPEN positions=0，而且 sm_positions opened after 2026-09-11: 0。最后一条 close 记录是 id=127 的 ETH orphan_reconcile，close_at=2026-09-11T15:35:40，PnL=-$2.91；再往前 id=126 的 BTC orphan_reconcile 是 -$95.66。

二、顺藤摸瓜上了链：11 个孤儿仓

真正把答案暴露出来的是 10:55 那次 HL 链上 user_state 查询。trader 每次 tick 都打 [RISK_P0] chain av=$3390 used=$2526 free=$0，风控一直阻塞，size_usd 永远被判 0。我就直接拉了 Hyperliquid testnet 的 user_state，结果当场愣住了：

1
2
3
4

accountValue:                $3,300.99
totalMarginUsed:             $2,518.50
withdrawable:                $0.00
totalRawUsd:                -$31,158.45

链上居然挂着 11 个 LONG 仓位，合计名义 $34,459，而 trader 的 sm_positions 表里 OPEN=0。BTC 是 0.11374 个、20x 杠杆，ETH 是 3.686 个、20x，SOL 是 74.71 个 10x。全部浮盈为正，合计 +$3,636。这些仓位占掉的 margin 刚好是 $2,518，跟 trader 风控读到的 used=$2526 对得上。

所以 withdrawable=$0 不是熔断，不是日亏损，是链上真有东西在锁保证金。

三、为什么 trader 永远不知道这些仓

这个问题要怪到 09-21 我加的那个 MAX_ORPHAN_SIZE_USD=80.0。当时是为了解决 close 假 PnL——id=126/#127 那两笔 orphan_reconcile 在 DB 里记了开仓，但链上根本没单，24h 后被 timeout 平掉，白白记了 -$98.57。

修法就是给 reconcile 加了个 cap：超过 80 美元的 orphan 一律 refuse_too_large，不 adopt 进 DB。逻辑上没错，它确实挡住了外部仓位污染 PnL。但今天链上这 11 个仓，最大的 ETH 名义 $10,079、最小的 DOGE 名义 $90.71，全都被 refused_too_large 跳过了。

这么一来，reconcile_from_chain.py 虽然每 6h 跑一次，但每次都扫到这些仓、每次都拒收。trader 的 _has_hl_position() 查链上有仓，但 DB 里没有登记，收到 close signal 时只会打 no_hl_position 标记然后走人。

cap 解决了假 PnL，却制造了一个盲区：链上有 $34,459 ntl、$2,518 marginUsed 的真实仓位永远进不了 trader 的视野。

四、清理与修复：拆掉 cap 的代价

到这一步，路已经很清楚。按照修复报告，我先把 11 个孤儿仓全部用 market_close 市价平掉，DB 标记 strategy=orphan_reconcile_adopt、close_reason=[CHAIN_CLEANUP]。

平仓结果：DOGE +$10.72、SOL +$637.31、BTC +$754.88、BNB +$53.01、ARB +$774.10、SUI +$74.51、APT +$89.18、ETH +$638.49、AVAX -$1.01、AAVE +$50.60、TIA +$48.59。合计 +$3,130.36 的浮盈转为 realized PnL。链上最终状态是 accountValue=$3176.53、totalMarginUsed=$0、withdrawable=$3176.53、open=0。

但光平仓还不够。修复报告里列了三个代码层的问题：

hl_executor.py SDK 兼容：新 SDK 的 market_open 不再接受 coin= 这个 kwarg，要改成 name=；而 reduce_only 参数在 SDK 设计里压根不支持，被静默丢弃。收盘逻辑必须改成直接调 market_close(coin, sz)，否则 trader 永远平不了仓、还不知道自己平不了。

open_position 的 UnboundLocalError：L1115 _strategy_risk(strategy, ...) 在 L1122 strategy = sig.get(...) 之前执行。因为 Python 在 try 块里不会提前看到 local var 声明，所以直接抛 UnboundLocalError。修法很简单，把 L1122 那行挪到 L1115 之前。

trader 重启：老 PID 11886 在 11:03:04 检测到 shutdown flag 退出，11:03:53 relaunch_trader.py 启动 PID 11616（但还加载着旧 hl_executor），11:11:30 第一次 RISK_P0 显示 chain_free=$3178。然后 mock signal 触发下单，sol 4.29 szi 成交、链上返回 {status:ok, avgPx:116.5956, oid:60714893081}——但这笔单触发了 open_position 的 UnboundLocalError，DB 写失败。11:13:33 再次 shutdown flag + relaunch，PID 17276 加载的是修好的 open_position。

五、验证与遗留

11:11:30 的日志已经说明解锁有效：chain_free=$3178。之后 mock BTC/SOL signal 触发，链上确认下单成功。中间出了个插曲：mock 测试开了 2 笔 SOL，因为第一笔下单成功后 DB INSERT 失败，trader 下次 tick 没看到 DB OPEN，就又把同一个信号执行了一遍，合计 8.58 szi。后面把这 8.58 szi 全部市价平完，链上回到 $3176.53、margin=$0、withdrawable=$3176.53。模拟仓 DB 没有新记录，因为 INSERT 都失败了。

剩下来的是两个待办。

sentiment 阈值：signal daemon 还在每 60s 跑，但 score 最近几轮是 0.363、0.298，SENTIMENT_THRESHOLD 是 0.50（smart_money_signal.py L165）。选项三个：等自然突破、临时降到 0.30 验证真实下单车、恢复 TOKEN 信号源（MAINNET_VERDICT 09-04 默认禁用）。

orphan cap 设计：MAX_ORPHAN_SIZE_USD=80 的 trade-off 现在被彻底摊开。三个改法：提 cap 到 $5000 加 stop_loss=mid*0.95、对 $80~$5000 的仓 adopt 进 DB 并 truncated 到 $350、维持现状加一个每 6h 扫链上 > $80 的告警脚本。我倾向最后一个，先把监控补上再动 cap。

遗留：sentiment 阈值还没决定，orphan cap 的结构性修法也没定稿。今天解锁了 trader，但 11 个孤儿仓怎么来的、9/11 之前为什么链上没清掉，还需要找时间翻一轮当时的 order log。

基线不重置，漂移 353% 就是迟早的事；样本连续 68 轮冻结在 16，A2 的 NO_ACTION 只是看起来无害。

今天从一条 HL smart_money 的 ALERT 开始，到下午 A1 tracker 甩出一个 429 收尾。中间还跑了一轮对账、查了个开机弹窗、顺手发了一篇知乎热榜稿。

一、HL smart_money 漂移检查：353.43%，还是那条 legacy 基线

上午按计划跑 _sm_sanity_check.py，根目录脚本已经不在，只有 wb_runs/archive/ 里的归档副本。直接用 C:/ProgramData/anaconda3/python.exe -u 跑归档副本，输出一行 ALERT：

• chain：$2,215.57
• db_total：$10,045.98（含未平保证金）
• drift：353.43%，阈值 5.0%
• 退出码 1

DB 总值还悬在 legacy 名义基线 ~$10,046，链上真实余额只有 ~$2,216，差约 4.5 倍。和 09-05 起连续 8 次 ALERT 是同一个根因：testnet 重置后 sm_account 基线从来没被重置过。建议动作也一直是那句：执行 wb_runs/archive/_reset_sm_account.py --apply 重置基线后重跑。本次检查只读，没动任何文件或数据库。

二、HL 只读对账：ghost 0，orphan 20，不用 --apply

接着对 defi_dashboard 做只读对账巡检。先把系统代理变量清空避免 502，然后跑 hl_reconcile.py，全程 dry-run，没加 --apply。

结论先行：

• Ghost 仓位：0。两库所有 OPEN 在链上都存在，含方向反检查；hl_smart_money.db=0、hl_testnet.db=0 持仓。
• Orphan：20。SOL/APT/BTC/ETH/BNB/ARB/AAVE/SUI/TIA/DOGE 各出现于两库，链上有 DB 无，仅告警不修复。较 09-15 的 14 个孤儿，新增 TIA、DOGE 两币×2 库。
• 账户等式守恒：脚本只做 ghost/orphan diff，不打印权益守恒；逐笔重建残差历史≈0。两库自报 account 行 initial/current≠10000 是已知记账损坏，不属于 ghost/orphan 范畴。

没有 ghost，就不需要 --apply。orphan 按设计不自动清理。所有 PnL 都是 HL testnet 模拟口径。

三、factor_ic OOS tracker 双臂扫描：A2 样本冻结，A1 直接 HALT

下午两轮 A2 扫描（14:18 第68次、15:22 第69轮）结果几乎一样：

决策两次都是 NO_ACTION：regime OK → Gate1 fail（16<30）→ 攒样本。样本数已经连续 68 轮冻结在 16。双 arm 隔离校验也确认了：oos_ticks 里 LONG=69 行，SHORT=399 行，最新 id 各自独立，不串扰。

A1 那侧更直接，14:21 的单次扫描（factor_ic_oos_tracker.py once）出来是 HALT：

• Gate1 样本数 31 ≥20 ✅
• Gate2 binomial p 0.7201（win 14/31）<0.05 ❌
• Gate3 年化 Sharpe -2.732（×√504）≥1.0 ❌
• Gate4 maxDD 320.9% ≤30% ❌
• regime 回落率 37.0%（n=27）≥50% ❌

决策 HALT：regime 回落率 37.0% < 50% → on_halt，因子级 forward return 持续低于 50%，因子_ic 信号源判失效，OOS 持续挂起。

四、顺手查了个开机弹窗：RTSS 挂钩 D3D8 被 Windows 更新打断

开机后弹窗截图发过来，我顺着 14:12–14:17 的活动记录翻了一遍。结论不是系统故障，是 MSI Afterburner 附带的 RTSS 在挂钩 Direct3D8 时失败弹的提示。

关键证据链：

• 弹窗是谁弹的：文案 cannot be hooked（UTF-16）在全盘只存在于 D:\Program Files (x86)\RivaTuner Statistics Server\RTSS.exe，就是 RTSS 自己。
• 为什么开机出现：Profiles\Config 里 StartWithWindows=1；计划任务 \RTSS → RTSS.exe /s，触发条件“登录时”。
• 挂的 API：D3D8，HookDirect3D8=1；缓存旧偏移 D3D8.DLL=000B4000 / IDirect3DDevice8::Present=0002A1E0。
• 真正诱因：C:\Windows\SysWOW64\d3d8.dll 在 2026-09-09 05:45 被 Windows 更新替换，WinSxS 并存 26100.8115/.8972/.927

“67% 的 5% 止损触发不是假摔，是真崩盘。”

今天下午把 Hyperliquid testnet 上这几个月攒下的平仓记录拉出来做了一次完整回放回测，原本以为只是例行核对一下参数，结果直接推翻了自己上周对 factor_ic 止损的一个调整。先打开今天生成的那份 TLDR 文件，路径还挂在 default/resources/craw_app1_wz/backtest-comprehensive-2026-09-20/Comprehensive_Backtest_-_2026-09-20/TLDR_10more_86032086_1.md 下面，光看摘要就意识到问题不小。

一、背景：127 笔平仓，5 个策略一起回放

这次回测的样本是数据库 hl_smart_money.db 里 127 条已平仓记录，时间跨度从 2026-07-30 到 2026-09-10，全部是 HL testnet 的模拟单。覆盖 5 个策略：factor_ic、sentiment、token、market_flow、smart_money。回放工具用的是 HL testnet 的 candle API（https://api.hyperliquid-testnet.xyz/info），规则是 1 小时 K 线从入场点重放到入场后 48 小时，中间按模拟的 SL/TP/timeout 逻辑退出。脚本今天写了好几个：replay_backtest.py 专门跑 factor_ic 的 59 笔全量回放，replay_sentiment.py 跑 sentiment 的 27 笔乘 4 个持有期，replay_deepdive.py 逐笔比 SL 5% 和 10% 的差异，replay_final.py 出汇总，结果落在 replay_results.json，每个单子存了 5 个字段。

二、总览：active 组合有 +$18.04 的改进空间

TL;DR 表先给了一版大账：

其中有一条 critical correction 写得很醒目：optimization A（SL 5% -> 10%）是负优化，已回退。 这条我今天花最多时间验证，后面单独说。先说整体：两个还在跑的 active 策略里，factor_ic 目前实际亏 16 块 5，但如果把上个月做的 B+C+D 过滤套上，反事实能赚 16 块 9 毛 9，加上 sentiment 的 72h 封顶虽然比无上限少赚 15 块 4 毛 5，但整体 active 从 +51.04 能优化到 +69.08，净改进 +18.04。token 那 6 笔已经自然停了，赚 139.23；market_flow 亏 36.50，已经 kill 掉不再看。

三、factor_ic 回放：完美 5% SL 能赚，实盘亏在延迟和超时

factor_ic 的 59 笔回放是最有信息量的。模拟和实盘的差异拉出来是这样：

一句话：如果每笔都严格按 5% 止损触发，这 59 笔能赚 10.98；如果当时把止损放宽到 10%，反而会亏 1.87。实盘为什么亏 16.50？中间差了 27.48，拆开看有三个原因：一部分 timeout 平仓其实是自然反弹的位置，原本应该触发 SL 的；5% SL 事件里有 4 次是真崩盘；还有 trader 经常挂在 HL API 上，导致平仓延迟。这三点都能解释为什么实盘比完美模拟差这么多。

接着套用上个月定的 B+C+D 过滤条件（MIN_SCORE >= 0.9 且剔除 APT），剩下 14 笔：实际 +12.22，模拟 5% SL +16.99，模拟 10% SL +13.01。B+C+D 的净改进就是 +$33.49，从 -16.50 拉到 +16.99。 这部分验证通过，过滤条件没白加。

四、优化 A 的失败：5% SL 放宽到 10% 是负优化

上周我一度觉得 factor_ic 的 5% 止损太紧，很多单子可能被假摔扫掉，所以想做一个 optimization A：把 STOP_LOSS_PCT 从 5% 放宽到 10%。今天把模拟中真正触发 5% SL 的 6 笔单子拉出来逐一对比：

统计下来只有 2 笔（33%）是假摔，也就是 #83 AVAX 和 #98 APT，放宽到 10% 能少亏一点；剩下 4 笔（67%）全是真崩盘，5% 止损反而正确，放宽到 10% 直接让亏损翻倍。算净账：4 笔真崩盘按 10% SL 多亏 -$15.98，2 笔假摔按 10% SL 改善 +$3.13，合起来净损失 -$12.85。结论很硬：我之前“5% 太紧导致假摔”的假设是错的，67% 的触发是真崩盘。 所以今天直接执行回退：把 STRATEGY_RISK_OVERRIDES.factor_ic.STOP_LOSS_PCT 这个覆盖项删掉，回到 5% 默认值。这个负优化不会再上了。

五、sentiment 回放：持有越久越好，但 72h 是合理上限

sentiment 的 27 笔单子按不同 MAX_HOLD 跑了四档，再加上实盘无上限的对照：

几个发现很清楚：第一，sentiment 不管怎么限持有期都是正收益，哪怕 24h 也有 +29.23；第二，TP 次数（11-14）远大于 SL（0），说明这些单子大多是顺势持仓，没有被止损扫过；第三，持有期越长收益越高，从 24h 到 72h 多了 +$22.86，提升 78%，但从 72h 到 96h 只多 +$5.08，边际收益很薄；第四，实盘无上限的 +$67.54 反而比所有模拟都高，因为 trader 有时候拿超过 96h，吃到了大趋势。

那 72h 封顶值不值得？它牺牲了比无上限少赚的 $15.45，换来的是把极端持仓时间压下来、降低 margin call 风险。而且