排查 OpenViking 记忆池在冷启动阶段的字段缺失与索引漂移问题（2026-10-30）
核心判断：当结构化事件抽取出现字段缺失时，必须优先怀疑上游日志解析器的容错逻辑而非下游存储层。
今天主要在处理 OpenViking 记忆池的冷启动阶段遇到的异常。上午十点开始跑批发现 memories/events/ 目录下生成的 JSON 结构里，部分事件的 timestamp 和 source_ref 字段为空值，且向量索引与原始日志之间存在明显的语义漂移。这直接导致下游检索召回率从预期的 94% 掉到了 72%，这在低置信度场景下是不可接受的。
一、现象定位与初步假设异常表征问题最先暴露在 resources/craw_app1_wz/ 落盘的日志里。我拉取了当天 09:30 到 11:00 的原始会话片段，发现当输入语料包含多模态混合内容时，解析器抛出了非预期的 JSONDecodeError。
假设路径初步怀疑是上游 ETL 管道在预处理阶段丢失了时间戳元数据，导致下游 workbuddy/memory/ 摘要生成时无法对齐原始会话 ID。如果仅靠猜测，容易陷入“改字段名”的误区，必须拿到真实报错堆栈才能定界。
二、日志比对与根因锁定关键断点我直接对比了 workbuddy ...
hexo deploy 把站点推成空白？因为用管道看了部署日志
现象：部署"成功"，站点消失一次例行的内容更新，跑完 hexo g 和 hexo deploy，日志最后几行是熟悉的：
1INFO Deploy done: git
刷新线上地址——404。换几个文章页，全是 404。首页偶尔返回 200 但是空白。
登录 GitHub 看部署仓库，最新 commit 是：
1Site updated: 2026-10-23 15:06:59
时间戳是最新的，看起来推成功了。但点进去看文件树——空的。没有 index.html，没有 posts/，只有一个 .git。
根因：工作区被清空，然后推了个空提交hexo-deployer-git 的机制是：把 .deploy_git 当作一个独立的 git 工作区，每次部署时把 public/ 的内容同步进去，然后 commit + push。
关键点在于同步的方式：它不是增量覆盖，而是先清理工作区（相当于 git rm -r 全部内容 + 复制新文件），再提交。这个设计本身没问题——它保证删除的文章不会残留。
问题出在中断。
如果进程在「清空工作区」之后、「复制新文件」完成之前被杀 ...
4everland 自定义域一直报 Invalid Configuration？Cloudflare 橙云是元凶
现象：DNS 明明配对了，平台就是说不对给 IPFS 站点绑自定义域名，在 4everland 控制台填好域名，按要求添加 CNAME 记录：
12类型 名称 内容CNAME blog 23feacba8df54bc88514.cname.ddnsweb3.com
保存，点「Verify」。等几分钟，状态一直是：
12blog.demohappy.topInvalid Configuration
反复删了重建、换浏览器、等了一小时、换了一台机器查 DNS——所有检查都显示 CNAME 是对的：
12$ nslookup -type=CNAME blog.demohappy.topblog.demohappy.top canonical name = 23feacba8df54bc88514.cname.ddnsweb3.com.
记录确实存在，值也对。但平台就是不认。
根因：橙云把 CNAME 变成了 A 记录问题出在 Cloudflare 的代理状态上。
Cloudflare 的 DNS 记录有一个云朵开关：
灰云（DNS only）：Cloudfla ...
Hexo 换域名后 canonical 和 sitemap 还指着旧域？完整迁移清单
换个域名，比想象中麻烦博客从 blog.demo.fan 迁移到 blog.demohappy.top。这件事看起来就是把 _config.yml 里的 url: 改一行、重新部署。
改完确实生效了——页面能打开，只是有两件事没跟着走。
第一件：搜索结果里点进来，<link rel="canonical"> 还指着 blog.demo.fan。这意味着搜索引擎会认为新域名上的每一页都是旧域名内容的副本，新域名的权重永远是零。
第二件：sitemap.xml 里 149 条 URL，全部是旧域。
为什么会这样：三类引用的生命周期不同把「站点里出现的域名」按来源分类，会发现它们的更新方式完全不同：
类型
来源
改 url: 生效吗
canonical / og:url / JSON-LD / sitemap
模板运行时读 config.url
✅ 重新生成即生效
copyright_url（每篇 front-matter）
文章里的字面量
❌ 永远不会变
robots.txt 的 Sitemap: 行
源文件 ...
Ollama 调 API 返回空 content？thinking 模型吃光 num_predict 的排查与修复
现象：请求成功，内容为空批量给博客的 112 篇文章重写 meta description，脚本跑了两天都正常。换到本机模型后，日志开始出现这种记录：
123[1/47] 处理中... 耗时 170.4s 返回内容长度: 0 跳过（内容为空）
HTTP 200，done: true，没有任何报错，就是 message.content 是空字符串。最迷惑的地方在于它慢——一次请求跑满 170 秒才返回，看着像模型在很努力地工作，结果交了个白卷。
先怀疑的是模型没加载完、显存不够、或者 ollama 版本问题。这几个方向全查了一遍，都不是。
根因：推理 token 和正文共用同一个预算出问题的模型是 thinking 型（具备推理链能力的那种，qwen3 系列、deepseek-r1 系列都属于这一类）。这类模型生成回复时，token 消耗分两段：
推理段（reasoning / thinking tokens）—— 模型内部先想一遍
正文段（content tokens）—— 真正返回给你的答案
关键点：这两段共用 num_predict 这个上限。
当时的请求参数是 ...
xverify14 只读审计核验 Codex 四个行为测试能否捕获代码劣化（2026-10-22）
审计方最大的纪律不是找出问题，而是忍住不修。这天上午我刚复核完一篇红果短剧的文章上线，下午就切进 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% 下的新目录再改，绝不许动工作区文件，改完的副本用完 ...
源码改回故障形态测试依然全绿，defi_dashboard交叉验证失灵（2026-10-19）
测试能过，不代表代码是对的——它只代表字符串还在。
这天我同时在跑三条线：上午是 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，漏币修复已生效。
二、注入 ...
第 12 轮只读验证让 funding_collector 两个确证 bug 现出原形（2026-10-18）
只读一天，我才明白哈希锁能冻住策略，却冻不住一个没有测试的采集器。
今天上午知乎那篇债市问股市的文章刚上线，下午我就钻进 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_col ...
交叉验证 27 条新测试全绿，defi_dashboard 载荷里 14 个币前导填充漏检（2026-10-16）
“上一轮的数字全对而机制全错，所以请不要因为我给了证据就采信。”
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 ...
换手对账连续翻向暴露首日持仓被当空仓（2026-10-15）
恒定量是等价写法的天然盲区——同一个“看起来对”的实现，在恒定输入下与错误实现无法区分。
今天没跑什么新策略，几乎一整天都在跟测试盲区较劲。早上从换手对账里挖出第三个换手 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() 补计首日建仓 ...