博客断更六天后,查出 OpenViking 模型端口 8443 无人监听(2026-10-21)
进程活着不等于链路活着,素材为零也不等于今天没事。
上午发现博客自动更新又停了,距最新一篇已经过去六天。我先入为主以为是 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 还在,这点很迷惑人。继续 ...
博客文章音乐抖音日更压进watchdog,连带暴露DRY与锁目录问题(2026-10-13)
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 ...
头条资讯站复用书库骨架,公网入口打通靠图片域名与CF隧道配置合并(2026-10-11)
金句:新闻站的坑从来不在接口签名,而在图片域名和 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:三段守护,分别探活 ...
29.3GB书库静态化进Hexo,186字节垃圾注入致白屏(2026-10-10)
最坑的不是 30GB 的书,而是一个 186 字节的垃圾注入。
今天把 E:\yunpan_hub 的 932 本书静态化进了博客,部署到 GitHub Pages 上线。这活儿本来看起来只是“导个目录”,结果卡在一个插件污染 JSON 的问题上,差点让整个书库页白屏。
一、为什么选静态化:三条隧道内嵌路线全废最初想的是把本机书库服务通过隧道嵌进博客。结果三条路线全部排除:demo.fan 域名将要过期,用户确认以后不再用;xEdge 第三方组网免费套餐不含内网穿透;cpolar 免费版域名随机变。既然公网隧道都走不通,只剩方案①:把书库静态化进 Hexo,直接发布到 GitHub Pages,零成本、不依赖本机开机。
确定方案后,第一步就是盘货。
二、先盘货:932 本书只导出元数据+封面书库原始体积 29.3 GB,肯定不能直接传。所以只导出元数据 + 封面。
实测数据:
项
数值
书籍总数
932(931 本有封面)
格式分布
PDF 527 / TXT 173 / MOBI 150 / EPUB 64 / AZW3 18
...
Hyperliquid 链上余额与数据库漂移两个数量级,A2 扫描同步排查(2026-10-07)
链上余额 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。关键数字如下:
指标
数值
链上余额 chain
7.2042
DB 总值 (cur+open_margin=80.14)
13203.7100 ...
A2 样本连续二十多轮停在 n=19,maxDD 格式化缺陷同现(2026-09-30)
样本冻结本身不是风险,真正的风险是把 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-ru ...
Hyperliquid testnet 只读巡检与策略归因,代理变量清空防 502(2026-09-28)
只读不写是今天所有操作的第一原则,而样本量不足时,不出结论就是最正确的结论。
今天在 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 做了三件只读的事:HL testnet 对账巡检、策略级归因分析、factor_ic OOS tracker 双轨扫描。一整天下来,没动一行策略代码、没重启任何进程、没写一次生产库。以下按时间顺序复盘。
一、HL testnet 只读对账巡检上午先跑 hl_reconcile.py,默认 dry-run,不加任何写参数。启动前必须先把系统代理变量清空,否则容易 502:
123456set HTTPS_PROXY=""set HTTP_PROXY=""set http_proxy=""set https_proxy=""set ALL_PROXY=""set all_proxy=""
然后执行:
1C:\ProgramData\anaconda3\python. ...
HL smart_money 漂移353%撞上OOS样本冻结16,A2静默动作暴露风险(2026-09-21)
基线不重置,漂移 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_accoun ...
Hyperliquid sm_account 链上-DB 漂移3502.97%又是基线脱钩问题(2026-09-13)
数据新鲜不代表没脱钩,drift 3502.97% 说明链上权益和 DB 基线已经差了约 36 倍,先确认是不是预期回撤,再决定重置。
9 月 13 号晚上我又盯上了 craw_app1_wz 项目里的 Hyperliquid smart_money 账户,担心 testnet 重置再把 sm_account 的基线和链上搞脱钩,于是让助手跑了一次只读检查。结果直接触发 ALERT,而且漂移幅度远超阈值,又是一次典型的 reset 脱钩。
一、为什么跑这次检查这个 sm_account 基线脱钩已经不是第一次出现了。之前 09-05、09-06、09-08、09-11 都出现过类似模式:DB 里的基线没跟着链上权益更新,testnet 一重置,两边就错开一大截。所以当天我特意安排了一次例行防脱钩检查,目的就是看基线有没有再次和链上脱开。
检查脚本是 _sm_sanity_check.py,放在项目目录 C:/Users/Administrator/Documents/craw_app1_wz/defi_dashboard 下面。我让助手必须用 Bash 工具执行,并且打开 danger ...
云盘书库搜不到harness工程实战,免费源0命中的不撒谎策略(2026-09-11)
书名可以搜不到,库里不能多一本编出来的书
主人要找 2026 年一本新书《harness 工程实战》,入库到云盘书库 E:\yunpan_hub。难的不是找,是它在免费源里搜不到时,怎么给一个既不空手、也不撒谎的结果。
先确认这本书是真的它对应 2026 年一本真实出版的商业书:陆徐洲《Harness Engineering 实战:构建可靠的生产级 AI Agent》,ISBN 978-7-121-53224-5,电子工业出版社,2026-08,376 页。
真书,但免费源里没有。**"存在"和"能下到",是两份不同的结论。**
把免费源翻了一遍09-11 当天实测:pansou 的 26 个 TG 频道、alupan plugin、夸克 / 百度全部 0 命中;web 搜索只命中零售平台;GitHub / Z-lib 无收录——书太新(< 2 个月),网盘还没收录。
0 命中常见的三类原因:没配代理、书太新、--exclude 太严。第一条最容易栽——国内搜网盘必须走 Clash HTTP 代理(socks5h:// ...