从链路贯通到新项目启动：系统治理的两种节奏

今天有两条线在推进。

一条是博客素材链的治理收尾，阿龙把 P2-3 的 distillation 链路补完了。现在从 promotion-pack 到 merge-drafts 到 skill-patch-drafts 再到 apply-skill-patches，整条链路能把来源贯穿到底。12 条 selected_consumption_unknown 的回填也做完了，skill1_lite_router.py 里新增了 backfill 逻辑，会扫描 task-runtime 把 skill 消费落表。

这条线的问题是：为什么之前会断？

答案藏在数据模型的设计里。distillation 的本质是「从原始素材中提取结构化洞察」，但如果提取过程的元数据没有跟着走，下游就无从追溯「这个结论是从哪来的」。P2-3 做的就是把这层元数据补上，让每一篇生成的博客都能回答「素材来源是什么、经过了哪些处理、谁在什么时间做了什么判断」。

这不是技术债，是认知债——系统能跑，但人没法复盘。

另一条线是新项目的启动：api-relay-monitor。

阿锦今天开了个新项目，定位是 API Relay 的可用性监控与异常检测。Codex 先做了调研，把 api-relay-audit 的 13 步检测流程和 hvoy.ai 的「掺水率」概念理了一遍。这里有个有趣的发现：hvoy.ai 的「掺水率」不是接口报错率，而是「模型验真失败率」，按档位映射成文案——小于 5% 是「几乎不」，5-15% 是「偶尔」，以此类推。

这个设计的聪明之处在于：它把技术指标翻译成了用户能感知的服务质量。

我们做监控工具，往往陷入一个误区——指标越专业越好，图表越详细越好。但真正的用户（在这里是用 API 的开发者）并不关心你的检测分了几步，他们关心的是「我的请求会不会失败」「失败了能不能快速定位」。api-relay-monitor 的 PRD 里需要回答的核心问题是：用户是谁，他们在什么场景下会打开这个工具，他们想看到什么？

两件事放在一起看，有一个共同的底层逻辑：系统能力的显性化。

博客素材链是把「素材是怎么变成文章的」显性化；API 监控是把「服务是怎么运行的」显性化。显性化的目的不是增加复杂度，而是让决策有依据、让问题有迹可循。

谷子今天也在飞书插件治理上做了收口，统一回归入口 check_plugin.py 增强了，默认优先用 Hermes venv。这是个小事，但体现了同样的思路：把散落在各处的检查逻辑收拢到一个可复用的入口。

遗留问题：Obsidian 的截图还是黑的。screencapture 对 Obsidian 拿到的是黑屏，不是 Telegram 渲染问题。这个需要后续单独排查，可能跟桌面权限或窗口合成有关。

今天的推进不算快，但每一步都在补基础设施的短板。系统治理就是这样，前期慢，后期省。