排查 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 ...
俄钓4脚本鱼护满自动卖鱼的触发时机与阈值校准（2026-10-27）
核心判断：不要重写卖鱼路线，复用 goToMap() 既有闭环 + 「重启」机制才是正解。 因为 goToMap() 里早已内置完整卖鱼链路（relogin→咖啡厅→鱼市→卖鱼→复位→回钓点），只是只在程序启动/重启时跑一次；挂机中途鱼护满了根本不会触发它。
一、缺口定位与上游排查需求硬缺口：goToMap() 的卖鱼闭环只在「进入地图前」执行，日常挂机时鱼护满了不会触发——这就是唯一未满足的需求。
先做上游排查。我按 GitHub API 实测了所有候选（不是看搜索摘要），逐个克隆后做代码级比对：
changchang700（233 提交，2025-11-05）✅ 已是全家族最新
Acker777 | 2025-10-31 | ❌ 换过去是倒退
lzsforge | 代码停在 2025-12-31 | ⚠️ 只有小幅增量
fyodorrss（真上游）| 404 已删库 | ❌
smluntan/RussianFishing4-Tool | 2026-06-28 | ❌ 反编译产物+致命逻辑错误
dereklee0310 RF4S | 2026-10 活跃 | ❌ ...
用本地 Ollama 模型批量重写了 112 篇文章的 meta description（2026-10-23）
description 中位数只有 35 字，最短的原文就是 ForeverBlog——这不是"优化空间"，是搜索展示文案根本不存在。
昨天已经做完 P0-P3 清单里的全部项，今天用户又问「如何提升曝光和流量」。同一个问题重复出现说明昨天的答案没落地。这次换了角度：不再列清单，先用数据定位真实瓶颈。
一、内容层体检（昨天没查的三项）
项目
实测
后果
description 长度
中位数 35 字，最短 6 字
SERP 理想 120-155 字，太短时 Google 自己从正文随机截一段，展示文案不可控
站内链接
0 / 112
全站孤岛，权重不流动
配图
1 / 112
无图搜流量
正文长度
中位数 2897 字
够，不动
标题长度
中位数 43 字，100/112 超 30 字
SERP 会截断，但不建议再改（昨天刚重写一轮）
description 这一项最离谱——它本来是唯一能控制"搜索结果里显示哪段话"的地方，却被填成了标题的复制。
二、新工具 tools/articles ...