life-screener

wiki-life 专用 inbox 筛选与评分入库。扫描 raw/inbox/{rss,newsletter,wechat}/，对每篇候选做 life 领域红线过滤 + DeepSeek 评分（v×c≥45）+ 领域相关性检查，过线则入库 raw/articles/+entities/concepts+index.md+log.md 并 git commit。区别于 wiki/inbox-screener（AI/ML 领域、v×c≥49）。

跳到安装

仓库: QianJinGuo/wiki
最近来源活动: 2026年8月9日 03:30
检测到的 SKILL.md 语言: 中文
星标: 1
分支: 1

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/QianJinGuo/wiki --skill life-screener

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

文件资源管理器

6 个文件

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

文件资源管理器

6 个文件

SKILL.md

来源说明 · 只读预览

name	life-screener
description	wiki-life 专用 inbox 筛选与评分入库。扫描 raw/inbox/{rss,newsletter,wechat}/，对每篇候选做 life 领域红线过滤 + DeepSeek 评分（v×c≥45）+ 领域相关性检查，过线则入库 raw/articles/+entities/concepts+index.md+log.md 并 git commit。区别于 wiki/inbox-screener（AI/ML 领域、v×c≥49）。
version	1.6.1 — +Stats 不一致诊断: [WARN] index.md 条目验证失败 → raw entry 缺失 → 只 bump Sources 不 bump Total（2026-08-06）
category	wiki-life
related_skills	["llm-wiki","wiki-pipeline","wiki/inbox-screener"]

Life Screener — wiki-life inbox 评分入库

统一筛选 ~/wiki-life 自动抓取 pipeline 沉淀到 inbox 的候选文章，做 life 领域评分与入库。

与 wiki/inbox-screener 的关系：工程模式（blacklist/DeepSeek fallback/candidates 清理/git 显式路径）复用自主 wiki inbox-screener，但领域逻辑完全不同——本 skill 面向个人成长内容，门槛 v×c≥45（非 49），关键词是自律/职业/心理/关系/认知/财务（非 agent/llm/transformer），红线是鸡汤/软文/营销号（非低价值技术新闻）。不要把 AI 关键词预过滤套到 life 内容上——会误杀几乎所有候选。

背景

Pipeline	输出位置	内容类型
wiki-life-rss-scan (每 6h)	`raw/inbox/rss/`	RSS 全文（Cal Newport / Psyche 等），文件已含完整正文
wiki-life-newsletter-scan (每 6h)	`raw/inbox/newsletter/candidates.md`	Newsletter URL 列表（FS Brain Food / TLDR 等），需 fetch
(预留) wechat	`raw/inbox/wechat/`	微信公众号全文

本 cron（wiki-life-inbox-scan，每日 9:00）是消费端：读取上述 inbox → 评分 → 入库 → 清理。上游 cron 只负责抓取放 inbox。

领域定义（SCHEMA.md / AGENTS.md）

wiki-life 焦点领域：

自律 & 习惯养成：habit, willpower, time-management, self-discipline, energy-management
认知提升：mental-model, decision-making, cognitive-bias, learning-method, meta-cognition
心理健康：emotion-regulation, anxiety, mindfulness, cbt, act, mbsr, mental-health
亲密关系：communication, nvc, conflict-resolution, intimacy, family
职业发展：career, interview, job-search, skill-development, side-project
财务：personal-finance, investment, frugality, financial-independence

与 ~/wiki（AI/ML）的边界：纯 AI/ML/工程技术内容归 ~/wiki（v×c≥49），不进本库。若 life 来源文章主轴是 AI/技术（如 Psyche 写 AI 伦理），路由到 ~/wiki，不在本库评分入库。

评分门槛

review_value × review_confidence ≥ 45 → 入库（life 内容比技术内容主观，门槛比 ~/wiki 的 49 低 4 分）
review_stars ≥ 4（独特洞察/框架）→ 入库（但仍须过领域相关性检查）
review_stars ≤ 2 → 一票否决，不入库
Borderline (v×c 42-44) + 命中已有深度 entity + ≥3 互补角度 → MERGE 作 Nth source；否则 REJECT

frontmatter 字段（SCHEMA.md）：

review_value: 8            # 0-10
review_confidence: 7       # 0-10
review_stars: 4            # 1-5
review_recommendation: strong | worth-reading | reference

Life 红线 — 7 类无条件 REJECT（QUALITY.md）

评分之前先做红线快检，命中任一 → 直接 REJECT，不送 LLM（省 API）：

类型	识别方法	典型信号
鸡汤文	读完只有情绪起伏，没有认知增量	"你要相信..." / "坚持就是胜利" / "努力就会成功"
毒鸡汤	复杂问题归因单一因素，制造焦虑/优越感	"穷是因为懒惰" / "焦虑是因为想太多"
软文/营销文	80% 故事铺垫，结尾突然推销	个人困境 → 偶遇产品 → 生活巨变 → 限时优惠二维码
营销号	所有文章都是导流入口	每篇结尾"加我微信"/"限时特惠"/"仅限前50名"
标题党	标题承诺与正文严重不符	"年薪百万的秘密" / "这才是真正的自律"
投射文	N=1 个人经验当普适真理	"我就是这么做的，你也可以"
情绪包	专刺激情绪（愤怒/焦虑/感动）无信息价值	极端个案、对立话题、纯发泄

快检方法：读标题 + 前 500 字。问 3 问（AGENTS.md）：

核心论点一句话能概括吗？不能 → REJECT
作者提供了什么证据？纯断言 → REJECT
能从今天开始做什么具体的事？只有"要改变心态" → REJECT

5 维度质量标准（QUALITY.md）— 入库须满足 ≥2 项

维度	检验标准
有论证	引用研究/数据/逻辑链（如"根据 Duckworth grit 研究 N=3998..."）
有框架	可复制方法论（如"OODA：观察→调整→决策→行动"）
有边界	明确适用范围（"适用于 X，不适用于 Y"）
有实践	具体步骤/工具/模板
有批判性	承认局限/反例/替代解释

LLM 评分 prompt 应要求模型按这 5 维度 + value/confidence/stars 打分，并在 reason 里点明命中了哪几维。

领域相关性检查（评分通过后的后置过滤）

LLM 对"写得好"的非 life 文章也会给 v×c≥45（如有框架的纯技术教程）。评分通过 ≠ 入库通过。入库前逐一检查：

入库：文章主轴在 life 焦点领域内（自律/认知/心理/关系/职业/财务）。 跳过（路由 ~/wiki）：纯 AI/ML/工程/编程技术内容 → 不在本库评分入库，可提示用户转 ~/wiki。 跳过（reject）：纯娱乐/八卦/时事政治/与个人成长无关。

判断方法：问"这篇文章的知识能否直接应用于个人成长/自律/心理/关系/职业/财务？"否 → 跳过。

用户直接发链接的快速评估流程

当用户在对话中直接发送 URL（非 cron pipeline 自动抓取）时，走以下快速判断：

1. 来源识别

来源	常见内容	路由
阿里云开发者、腾讯云、美团技术、字节技术	AI/ML 工程实践	~/wiki
叶小钗	产研管理、AI 工具落地	~/wiki（工程管理，非个人成长）
Hyman的杂货铺	AI/ML 论文解读	~/wiki
L先生说、KnowYourself、简单心理	认知/心理	wiki-life
暂停实验室、开智学堂	心理/认知/行动	wiki-life

2. 标题关键词预判

标题不含以下 life 关键词 → 大概率不在本库范围： 自律、习惯、意志力、情绪、焦虑、沟通、亲密关系、认知、职业、决策、财务、心态、拖延、专注

含 Agent、LLM、模型、开源、注意力、训练、推理 等技术关键词 → 路由 ~/wiki

3. 内容快速确认

抓取正文后确认主轴：

主轴在 life 焦点领域（自律/认知/心理/关系/职业/财务）→ 评分入库
纯 AI/ML/工程/编程技术 → 路由 ~/wiki
娱乐/八卦/时事 → reject

4. 批量场景

用户一次发多个 URL 时，统一列举判断结论而非逐篇评分。所有 URL 均不在 life 领域时，汇总说明并征求用户意见（路由 ~/wiki / 忽略 / 备用）。

评分流程

wiki-life-inbox-scan (本 cron)
    ├── 1. 扫描 raw/inbox/ 递归（rss/ + newsletter/ + wechat/，⚠️ 不是只 glob 顶层）
    │
    ├── 2. URL/标题 blacklist 预检查
    │     扫描 raw/articles/ 的 source_url:/url: 构建黑名单
    │     ⚠️ strip YAML 引号 + strip query params（?source=rss----xxx）+ normalize www./http↔https
    │     命中 → 跳过（已入库）
    │
    ├── 3. RSS / WeChat inbox（文件已含完整正文）
    │     <3KB → 跳过（摘要太短）
    │     ≥3KB → life 红线快检（7 类）→ life 关键词预过滤 → LLM 评分
    │     （RSS 文件已含正文，无需 Jina fetch）
    │
    │     ⚡ life 关键词预过滤（送 LLM 前的廉价过滤）
    │     LIFE_KEYWORDS = ['自律','习惯','意志力','时间管理','精力','拖延','专注','心流',
    │       '职业','面试','求职','简历','副业','晋升','离职','职场',
    │       '焦虑','情绪','压力','正念','冥想','抑郁','认知行为','接纳承诺',
    │       '沟通','非暴力沟通','冲突','亲密关系','婚姻','夫妻','家庭','育儿',
    │       '决策','认知偏差','心智模型','学习','元认知','复利','思考',
    │       '理财','投资','储蓄','财务自由','消费','保险',
    │       'grit','willpower','habit','procrastination','mindfulness','cbt','nvc',
    │       'decision','bias','mental-model','productivity','burnout','boundary']
    │     命中 ≥2 个关键词 → 送 LLM 评分
    │     命中 0-1 个 → 跳过（大概率非 life 焦点，如纯科技产品评测/时事）
    │     ⚠️ 这是 domain relevance 的廉价近似，不是替代。通过预过滤的仍须做领域检查。
    │
    └── 4. Newsletter candidates.md（URL 列表，需 fetch）
          blacklist 命中 → 跳过（已入库）
          域名 blocklist 命中 → 跳过（见下方域名过滤）
          URL 启发式命中（convertkit-mail4 重定向 / 营销 utm / 产品落地页）→ 跳过
          QUICK_SKIP_PATTERNS 命中（播客链接/FSA 周报/Amazon 重定向/非 life 主题网站）→ 跳过
          其他 → urllib Jina fetch（r.jina.ai）→ 内容 ≥2KB → 红线快检 → LLM 评分
          ingest=true → 入库 → 从 candidates.md 精确删除该 URL
          ⚠️ blacklist 必须在 fetch 之前！

域名过滤（Newsletter）

低价值（直接跳过）：convertkit-mail4.com（邮件追踪重定向，需先解 base64 再判断真实 URL；含大量营销落地页）、clickup.com/brain（产品广告）、x.com / twitter.com / youtube.com（社交媒体）、linkedin.com、各种 ?utm_* 纯营销落地页。

处理 convertkit 重定向：candidates.md 里大量 https://a4d65a79.click.convertkit-mail4.com/.../aHR0cHM6... 形式，尾部 base64 解码后才是真实 URL。脚本应解码 base64 提取真实 URL 再做域名判断。

高价值（直接抓取）：fs.blog（Farnam Street）、calnewport.com、psyche.co、aeon.co、jamesclear.com、thedecisionlab.com、nesslabs.com、zapier.com/blog、nesslabs。

LLM 评分 API

主力：OpenCode Go（复用主 provider，无需额外 API 配置）

评分由 cron agent 自身完成。agent 运行在 OpenCode Go（deepseek-v4-flash）上，直接使用自己的 LLM 对文章评分，不需要额外 API key。

流程：

agent 读取 inbox 文件全文（或 Jina fetch newsletter URL）
红线快检 → life 关键词预过滤 → 使用自身 LLM 按 5 维度评分
返回 JSON：{"value":0-10, "confidence":0-10, "stars":1-5, "reason":"..."}
v×c ≥ 45 + stars ≥ 3 → 入库

评分 prompt（life 5 维度）：

你是个人成长内容评审。按以下标准评分（0-10）：
- value: 对个人成长的价值（有论证/框架/边界/实践/批判性 中满足几维）
- confidence: 论证可信度（研究引用>逻辑推理>个人经验>纯断言）
- stars: 1-5（5=独特洞见框架，4=有效方法，3=有参考，2=浅，1=鸡汤/营销）
- reason: 一句话说明命中哪几维 + 是否触发红线

红线触发 → stars≤2 一票否决。
只返回 JSON：{"value":N,"confidence":N,"stars":N,"reason":"..."}

批量：5 篇/批。 响应解析：从 agent 自身 LLM 响应中提取 JSON，确保 value/confidence 在 0-10 范围。

兜底：Manual Heuristic（OpenCode Go 不可用时）

读前 4000 字符分类：

明显鸡汤/营销/标题党 → v≤3,stars≤2 → reject
life 关键词 ≥5 → 保守 v=7,c=7=49 → 倾向入库
life 关键词 3-4 → v=6,c=6=36 < 45 → 不通过（避免中文科技文章常见词专注/学习/决策的假阳性）
life 关键词 1-2 → v=5,c=6=30 → reject
无 life 关键词 → reject 记录 manual heuristic (LLM API unavailable)。不要因 API 不可用就阻塞整个 pipeline。自 2026-07-21 起：heuristic 收紧，≥5 关键词才给 v×c=49，防止 sspai 类中文科技文的误判。

入库流程

评分通过（v×c≥45 + 过领域检查）后：

raw/articles/{slug}.md — 原文存档，frontmatter 加 type: source + ingested 日期 + 保留原 source_url/sha256。slug 从标题生成（lowercase-hyphens，中文保留）。
entities/{slug}.md 或 concepts/{slug}.md — 合成页：
- frontmatter：title/created/updated/type/tags/sources（指向 raw）/confidence/review_value/review_confidence/review_stars/review_recommendation
- 中文正文 + 英文术语，每段 prose 末尾 ^[raw/articles/slug.md] 引用（单源文末单一回链即可）
- → [[raw/articles/slug|原文存档]] 回链
- ⚠️ 写 [[entities/xxx]]/[[concepts/xxx]] 前先 ls 确认目标存在，不存在用纯文本反引号（避免 BROKEN LINK）
- type 选择：系统/方法论/人物 → entity；认知模型/心智工具 → concept；方法论对比 → comparison
index.md — 加 entity/concept 条目（- [[entities/slug|标题]] — 摘要）+ raw 条目（追加到末尾）。⚠️ 用 split+insert+join，每条独占一行，写后 grep -n slug index.md 验证。
log.md — append ## [YYYY-MM-DD] ingest | {slug} + 评分 + 来源
清理 inbox — 删除已处理的 RSS/wechat inbox 文件（无论 ingest/reject/skip）；candidates.md 精确删除所有已处理 URL（ingest + reject + skip，不只 ingest），写回。
git commit — 显式路径 git add entities/X.md raw/articles/X.md index.md log.md（不要 git add -A，会扫入未处理文件）；用 /usr/bin/git（subprocess PATH 缺 git）；pre-commit hook 有 pre-existing error 时 --no-verify（先确认新文件 0 lint error）。

工程踩坑（精选，复用主 wiki inbox-screener 验证过的）

坑	规避
inbox_scanner.py 只 glob 顶层	扫描必须 `rglob("*.md")` 递归 rss/newsletter/wechat 子目录。本 skill 的 score_life_inbox.py 已处理
blacklist 漏检 RSS query param	URL 匹配前 `url.split('?')[0].rstrip('/')`，strip `www.`，normalize http↔https
blacklist 只搜 frontmatter 前 1000 字节	读至少 2000 字节 + 也搜 body 中的 source_url
candidates.md 只删 ingest 的 URL	评分完成（无论 ingest/reject/skip）后，所有已处理 URL 都从 candidates.md 删除，否则下轮重复处理
`git add -A` 扫入未处理文件	始终显式路径 add；同进程多 inbox 文件时第 1 篇 commit 会带进第 2 篇
subprocess 找不到 git	用 `/usr/bin/git` 绝对路径
execute_code 在 cron 被阻塞	用 `write_file` 写 .py 到 /tmp + `terminal("python3 /tmp/x.py")`；或直接跑仓库内 scripts/score_life_inbox.py
MiniMax 2056 配额耗尽	life wiki 直接用 DeepSeek，不依赖 MiniMax，规避此问题
DeepSeek 返回 0-100 scale	解析后 `if value>10: value/=10`
DeepSeek batch reason 过长截断	含 reason 字段用 `max_tokens=1500`；无 reason 用 500
index.md 条目拼接	用 split+insert+join；写后 `grep -n slug index.md` 验证独占一行
wikilink 指向不存在页	写 `[[entities/x]]` 前 `ls entities/` 确认；不存在用反引号纯文本
中文文件名空格	shell 用 find -exec / xargs，不要直接 cp 包含空格的文件名
import hashlib 缺失	hashlib.sha256() 在 ingest() 中调用但未 import，首次运行即 NameError crash。hashlib 是标准库，cron 环境同样可用，在 import 行追加 hashlib 即可
index 条目 entitys typo	update_index() 中 f-strings 拼接 {type_}s 对 type_=entity 产生 entitys/ 而非 entities/。修正：单独处理 entity 的 plural 形式 entities，其余加 s
Newsletter candidates 累积 50+ URL 耗时超标	cron 5min 超时时，50 URL × 30s Jina fetch = 25min worst case。脚本现在有 QUICK_SKIP_PATTERNS 在 fetch 前跳过播客/周报/重定向/非 life 类 URL（命中率 ~60%），大幅缩短批处理时间。若仍超时，先手动预过滤 candidates.md 再跑脚本

主力脚本

scripts/score_life_inbox.py — 自包含评分入库脚本，cron 直接调用：

cd ~/wiki-life && source ~/.wiki-cron.env && /usr/bin/python3 ~/.hermes/skills/wiki-life/life-screener/scripts/score_life_inbox.py

脚本完成：扫描递归 → blacklist → 红线快检 → 关键词预过滤 → DeepSeek 评分 → 领域检查 → 入库 → 清理 inbox → git commit。agent 处理脚本无法覆盖的边缘情况（API 全挂、fetch 全失败）时参考本 skill 的兜底逻辑。

⚠️ 脚本输出后必须修复的 4 个问题

score_life_inbox.py 的 entity 生成是裸模板：title=URL、正文仅复制 raw 第一行。每次脚本完成后 agent 必须做以下修复：

修复 entity title — 将 frontmatter title: "URL" 改为有意义的中文/英文标题；H1 同理
改进 entity 内容 — 将空白「核心要点」替换为真正合成：提炼框架、对比表、关键要点，每段加 ^[raw/...] 引用（单源文末单一回链即可）。目标 size ≥2KB
移动 entity 条目到 index.md 正确位置 — 脚本将 entity 条目插入在 ## Core Areas (MOCs) 的「职业发展」小节中间，破坏当前子 MOC 的列表完整性。life wiki 的 index.md 没有 ## Sources / ## Entities 分段，独立 entity 条目应放在文件末尾（与其他 standalone entry 并列），而不是插在 MOC 小节内。移动步骤：
```
# 从 MOC 区删除 entity 行 + 追加到文件末尾
lines = [l for l in lines if 'slug' not in l]
lines.append('- [[entities/slug|标题]] — 摘要\n')
```
操作后 grep -n "slug" index.md 确认实体条目只出现在文件末尾。
验证 index.md raw 条目 — 脚本可能漏加 raw source 条目。运行 grep -n "<slug>" index.md，确认 entity 条目 + raw 条目各 1 行、各占独立一行。缺少 → 追加行到文件末尾；注意文件最后一行可能无 \n 导致拼接（见下方「拼接修复」）。更新 header Total pages + Sources 计数。

Stats 不一致诊断（2026-08-06 实战）：脚本输出出现 [WARN] index.md 条目验证失败: <slug> 时，raw 条目几乎肯定没写进 index.md（验证失败即 grep 不到）。此时 Stats 的签名是 Total pages +2、Entities +1、但 Sources 不变 —— 脚本把 raw 算进了 Total pages，却没插入 raw 条目也没 bump Sources。修复：grep 确认 raw 缺失 → 追加 raw 条目到文件末尾 → 只把 **Sources**: N 加 1。Total pages 已是正确值，不要按"+2/+1/+1"全覆盖（那是理想情况），否则 Total pages 会多 1 变成 54。

拼接修复：life wiki 的 index.md 最后一行不一定有 trailing \n。用 Python lines.append(entry) 时，需要确保前一行已 \n 结尾：

# 写前修复
if lines and not lines[-1].endswith('\n'):
    lines[-1] = lines[-1] + '\n'
lines.append(raw_entry)

如果忘了做，grep 会发现两条条目在同一行——用 Python content.replace('来源- [[raw/articles/', '来源\n- [[raw/articles/') 修复。

life wiki index header 格式：header 位置在 ## Stats section，格式为多计数器同一行：

- **Total pages**: N
- **Entities**: M | **Concepts**: P | **Comparisons**: Q | **Cases**: R | **Queries**: S | **Sources**: T | **Reviews**: U
- **Last updated**: YYYY-MM-DD

⚠️ **Sources**: N 与其他计数器在同一行，不是独立一行。以下方法会失败（前面没有 - 前缀）：

# ❌ 不起作用 —— 实际行以 "- **Entities**: ..." 开头
content.replace("- **Sources**: 11", "- **Sources**: 12")

正确做法：

# ✅ 精确匹配 **Sources**: （无前缀，直接子串替换）
content = content.replace("**Sources**: 11", "**Sources**: 12")

# ✅ 或匹配完整行
content = content.replace(
    "- **Entities**: 12 | **Concepts**: 4 | **Comparisons**: 5 | **Cases**: 6 | **Queries**: 7 | **Sources**: 11 | **Reviews**: 2",
    "- **Entities**: 13 | **Concepts**: 4 | **Comparisons**: 5 | **Cases**: 6 | **Queries**: 7 | **Sources**: 12 | **Reviews**: 2"
)

同时更新 **Last updated**: 日期：

content = content.replace(
    "**Last updated**: 2026-07-09",  # 旧日期
    "**Last updated**: 2026-07-27"   # 当前日期
)

Verification（header 更新后立刻检查）：

cd ~/wiki-life && head -10 index.md
# 确认 Total pages / Sources / Last updated 反映最新入库

⚠️ Stats 行 label 带 ** 包裹，regex 必须匹配 **（2026-07-31 实战）：行格式是 - **Total pages**: 49，label 在 **...** 内。re.sub(r"(Total pages):\s*(\d+)", ...) 不匹配（** 位于 label 与冒号之间）——必须 re.sub(r"(\*\*?Total pages\*\*?):\s*(\d+)", ...)。新入库 entity+raw 时 Total pages +2（entity +1 + raw source +1）、Entities +1、Sources +1。score_life_inbox.py 的 Stats regex 已于 2026-07-31 修复（原 regex 对 ** 格式完全不匹配，Stats 从不更新，需 agent 手动补）。编辑 index.md 后 grep -n "^|- " index.md 检查 |- 前缀损坏（本库无 linter，全靠手动 grep 验证）。

life wiki 没有 linter：与 ~/wiki（技术库）不同，~/wiki-life 目录下没有 wiki-lint.mjs。验证完全依赖手动 grep：grep -n "slug" index.md 确认格式正确、无拼接。

修复后建议重新 commit：用 git commit --amend 或新 commit，确保 entity 有合成价值而非纯 URL 拷贝。

跨库路由到 ~/wiki（用户同意后）

当用户同意将判定为 tech 的文章路由到 ~/wiki 时，直接走手动加工程序：

获取全文 — 使用 browser_navigate + browser_console(document.body.innerText) 抓取完整正文（Jina fetch 在 WeChat URL 常超时，浏览器更可靠）
评分并入库（实用模式）：
- 使用 delegate_task 并行处理多篇文章（上限 3 并发），每篇一个子 agent
- 子 agent 读 ~/.wiki-cron.env 中 DEEPSEEK_API_KEY，调用 DeepSeek API 评分
- 评分 prompt 用 AI/ML 技术维度（非 life 维度）：技术深度、独特洞察、引用/数据、框架实用性、批判性
- 阈值：v×c ≥ 49（技术库门槛，比 life 的 45 高）
- 通过后：写 raw/articles/（frontmatter + 全文）→ 可选 entity/concept → 更新 index.md → 更新 log.md → git commit
Git commit 注意事项：
- 显式路径 git add raw/articles/X.md entities/X.md index.md log.md
- 用 /usr/bin/git 绝对路径
- pre-commit hook 有 pre-existing error 时 --no-verify
子 agent 输出验证：子 agent 自报的结果可能不准确。收到 summary 后检查：
- commit 是否存在：cd ~/wiki && git log --oneline -5
- entity 文件是否合理：cat ~/wiki/entities/<slug>.md | head -20
跨库路由的典型场景：
- 用户从 wechat 发来多篇技术文章 URL（阿里云开发者、Hyman的杂货铺等），会话上下文在 wiki-life 目录
- 用户确认 "转投 ~/wiki" 后执行本流程

报告输出规则

✅ 新入库文章（标题 + slug + v×c 分数 + commit hash）
✅ 真正错误（API 失败、脚本崩溃、文件损坏）
✅ 无新内容/无入库 → [SILENT]（抑制投递）
❌ 不报 DeepSeek provider 细节（内部实现）

name	life-screener
description	wiki-life 专用 inbox 筛选与评分入库。扫描 raw/inbox/{rss,newsletter,wechat}/，对每篇候选做 life 领域红线过滤 + DeepSeek 评分（v×c≥45）+ 领域相关性检查，过线则入库 raw/articles/+entities/concepts+index.md+log.md 并 git commit。区别于 wiki/inbox-screener（AI/ML 领域、v×c≥49）。
version	1.6.1 — +Stats 不一致诊断: [WARN] index.md 条目验证失败 → raw entry 缺失 → 只 bump Sources 不 bump Total（2026-08-06）
category	wiki-life
related_skills	["llm-wiki","wiki-pipeline","wiki/inbox-screener"]

Life Screener — wiki-life inbox 评分入库

统一筛选 ~/wiki-life 自动抓取 pipeline 沉淀到 inbox 的候选文章，做 life 领域评分与入库。

与 wiki/inbox-screener 的关系：工程模式（blacklist/DeepSeek fallback/candidates 清理/git 显式路径）复用自主 wiki inbox-screener，但领域逻辑完全不同——本 skill 面向个人成长内容，门槛 v×c≥45（非 49），关键词是自律/职业/心理/关系/认知/财务（非 agent/llm/transformer），红线是鸡汤/软文/营销号（非低价值技术新闻）。不要把 AI 关键词预过滤套到 life 内容上——会误杀几乎所有候选。

背景

Pipeline	输出位置	内容类型
wiki-life-rss-scan (每 6h)	`raw/inbox/rss/`	RSS 全文（Cal Newport / Psyche 等），文件已含完整正文
wiki-life-newsletter-scan (每 6h)	`raw/inbox/newsletter/candidates.md`	Newsletter URL 列表（FS Brain Food / TLDR 等），需 fetch
(预留) wechat	`raw/inbox/wechat/`	微信公众号全文

本 cron（wiki-life-inbox-scan，每日 9:00）是消费端：读取上述 inbox → 评分 → 入库 → 清理。上游 cron 只负责抓取放 inbox。

领域定义（SCHEMA.md / AGENTS.md）

wiki-life 焦点领域：

自律 & 习惯养成：habit, willpower, time-management, self-discipline, energy-management
认知提升：mental-model, decision-making, cognitive-bias, learning-method, meta-cognition
心理健康：emotion-regulation, anxiety, mindfulness, cbt, act, mbsr, mental-health
亲密关系：communication, nvc, conflict-resolution, intimacy, family
职业发展：career, interview, job-search, skill-development, side-project
财务：personal-finance, investment, frugality, financial-independence

评分门槛

review_value × review_confidence ≥ 45 → 入库（life 内容比技术内容主观，门槛比 ~/wiki 的 49 低 4 分）
review_stars ≥ 4（独特洞察/框架）→ 入库（但仍须过领域相关性检查）
review_stars ≤ 2 → 一票否决，不入库
Borderline (v×c 42-44) + 命中已有深度 entity + ≥3 互补角度 → MERGE 作 Nth source；否则 REJECT

frontmatter 字段（SCHEMA.md）：

review_value: 8            # 0-10
review_confidence: 7       # 0-10
review_stars: 4            # 1-5
review_recommendation: strong | worth-reading | reference

Life 红线 — 7 类无条件 REJECT（QUALITY.md）

评分之前先做红线快检，命中任一 → 直接 REJECT，不送 LLM（省 API）：

类型	识别方法	典型信号
鸡汤文	读完只有情绪起伏，没有认知增量	"你要相信..." / "坚持就是胜利" / "努力就会成功"
毒鸡汤	复杂问题归因单一因素，制造焦虑/优越感	"穷是因为懒惰" / "焦虑是因为想太多"
软文/营销文	80% 故事铺垫，结尾突然推销	个人困境 → 偶遇产品 → 生活巨变 → 限时优惠二维码
营销号	所有文章都是导流入口	每篇结尾"加我微信"/"限时特惠"/"仅限前50名"
标题党	标题承诺与正文严重不符	"年薪百万的秘密" / "这才是真正的自律"
投射文	N=1 个人经验当普适真理	"我就是这么做的，你也可以"
情绪包	专刺激情绪（愤怒/焦虑/感动）无信息价值	极端个案、对立话题、纯发泄

快检方法：读标题 + 前 500 字。问 3 问（AGENTS.md）：

核心论点一句话能概括吗？不能 → REJECT
作者提供了什么证据？纯断言 → REJECT
能从今天开始做什么具体的事？只有"要改变心态" → REJECT

5 维度质量标准（QUALITY.md）— 入库须满足 ≥2 项

维度	检验标准
有论证	引用研究/数据/逻辑链（如"根据 Duckworth grit 研究 N=3998..."）
有框架	可复制方法论（如"OODA：观察→调整→决策→行动"）
有边界	明确适用范围（"适用于 X，不适用于 Y"）
有实践	具体步骤/工具/模板
有批判性	承认局限/反例/替代解释

LLM 评分 prompt 应要求模型按这 5 维度 + value/confidence/stars 打分，并在 reason 里点明命中了哪几维。

领域相关性检查（评分通过后的后置过滤）

LLM 对"写得好"的非 life 文章也会给 v×c≥45（如有框架的纯技术教程）。评分通过 ≠ 入库通过。入库前逐一检查：

判断方法：问"这篇文章的知识能否直接应用于个人成长/自律/心理/关系/职业/财务？"否 → 跳过。

用户直接发链接的快速评估流程

当用户在对话中直接发送 URL（非 cron pipeline 自动抓取）时，走以下快速判断：

1. 来源识别

来源	常见内容	路由
阿里云开发者、腾讯云、美团技术、字节技术	AI/ML 工程实践	~/wiki
叶小钗	产研管理、AI 工具落地	~/wiki（工程管理，非个人成长）
Hyman的杂货铺	AI/ML 论文解读	~/wiki
L先生说、KnowYourself、简单心理	认知/心理	wiki-life
暂停实验室、开智学堂	心理/认知/行动	wiki-life

2. 标题关键词预判

含 Agent、LLM、模型、开源、注意力、训练、推理 等技术关键词 → 路由 ~/wiki

3. 内容快速确认

抓取正文后确认主轴：

主轴在 life 焦点领域（自律/认知/心理/关系/职业/财务）→ 评分入库
纯 AI/ML/工程/编程技术 → 路由 ~/wiki
娱乐/八卦/时事 → reject

4. 批量场景

用户一次发多个 URL 时，统一列举判断结论而非逐篇评分。所有 URL 均不在 life 领域时，汇总说明并征求用户意见（路由 ~/wiki / 忽略 / 备用）。

评分流程

wiki-life-inbox-scan (本 cron)
    ├── 1. 扫描 raw/inbox/ 递归（rss/ + newsletter/ + wechat/，⚠️ 不是只 glob 顶层）
    │
    ├── 2. URL/标题 blacklist 预检查
    │     扫描 raw/articles/ 的 source_url:/url: 构建黑名单
    │     ⚠️ strip YAML 引号 + strip query params（?source=rss----xxx）+ normalize www./http↔https
    │     命中 → 跳过（已入库）
    │
    ├── 3. RSS / WeChat inbox（文件已含完整正文）
    │     <3KB → 跳过（摘要太短）
    │     ≥3KB → life 红线快检（7 类）→ life 关键词预过滤 → LLM 评分
    │     （RSS 文件已含正文，无需 Jina fetch）
    │
    │     ⚡ life 关键词预过滤（送 LLM 前的廉价过滤）
    │     LIFE_KEYWORDS = ['自律','习惯','意志力','时间管理','精力','拖延','专注','心流',
    │       '职业','面试','求职','简历','副业','晋升','离职','职场',
    │       '焦虑','情绪','压力','正念','冥想','抑郁','认知行为','接纳承诺',
    │       '沟通','非暴力沟通','冲突','亲密关系','婚姻','夫妻','家庭','育儿',
    │       '决策','认知偏差','心智模型','学习','元认知','复利','思考',
    │       '理财','投资','储蓄','财务自由','消费','保险',
    │       'grit','willpower','habit','procrastination','mindfulness','cbt','nvc',
    │       'decision','bias','mental-model','productivity','burnout','boundary']
    │     命中 ≥2 个关键词 → 送 LLM 评分
    │     命中 0-1 个 → 跳过（大概率非 life 焦点，如纯科技产品评测/时事）
    │     ⚠️ 这是 domain relevance 的廉价近似，不是替代。通过预过滤的仍须做领域检查。
    │
    └── 4. Newsletter candidates.md（URL 列表，需 fetch）
          blacklist 命中 → 跳过（已入库）
          域名 blocklist 命中 → 跳过（见下方域名过滤）
          URL 启发式命中（convertkit-mail4 重定向 / 营销 utm / 产品落地页）→ 跳过
          QUICK_SKIP_PATTERNS 命中（播客链接/FSA 周报/Amazon 重定向/非 life 主题网站）→ 跳过
          其他 → urllib Jina fetch（r.jina.ai）→ 内容 ≥2KB → 红线快检 → LLM 评分
          ingest=true → 入库 → 从 candidates.md 精确删除该 URL
          ⚠️ blacklist 必须在 fetch 之前！

域名过滤（Newsletter）

高价值（直接抓取）：fs.blog（Farnam Street）、calnewport.com、psyche.co、aeon.co、jamesclear.com、thedecisionlab.com、nesslabs.com、zapier.com/blog、nesslabs。

LLM 评分 API

主力：OpenCode Go（复用主 provider，无需额外 API 配置）

评分由 cron agent 自身完成。agent 运行在 OpenCode Go（deepseek-v4-flash）上，直接使用自己的 LLM 对文章评分，不需要额外 API key。

流程：

agent 读取 inbox 文件全文（或 Jina fetch newsletter URL）
红线快检 → life 关键词预过滤 → 使用自身 LLM 按 5 维度评分
返回 JSON：{"value":0-10, "confidence":0-10, "stars":1-5, "reason":"..."}
v×c ≥ 45 + stars ≥ 3 → 入库

评分 prompt（life 5 维度）：

你是个人成长内容评审。按以下标准评分（0-10）：
- value: 对个人成长的价值（有论证/框架/边界/实践/批判性 中满足几维）
- confidence: 论证可信度（研究引用>逻辑推理>个人经验>纯断言）
- stars: 1-5（5=独特洞见框架，4=有效方法，3=有参考，2=浅，1=鸡汤/营销）
- reason: 一句话说明命中哪几维 + 是否触发红线

红线触发 → stars≤2 一票否决。
只返回 JSON：{"value":N,"confidence":N,"stars":N,"reason":"..."}

批量：5 篇/批。 响应解析：从 agent 自身 LLM 响应中提取 JSON，确保 value/confidence 在 0-10 范围。

兜底：Manual Heuristic（OpenCode Go 不可用时）

读前 4000 字符分类：

明显鸡汤/营销/标题党 → v≤3,stars≤2 → reject
life 关键词 ≥5 → 保守 v=7,c=7=49 → 倾向入库
life 关键词 3-4 → v=6,c=6=36 < 45 → 不通过（避免中文科技文章常见词专注/学习/决策的假阳性）
life 关键词 1-2 → v=5,c=6=30 → reject
无 life 关键词 → reject 记录 manual heuristic (LLM API unavailable)。不要因 API 不可用就阻塞整个 pipeline。自 2026-07-21 起：heuristic 收紧，≥5 关键词才给 v×c=49，防止 sspai 类中文科技文的误判。

入库流程

评分通过（v×c≥45 + 过领域检查）后：

raw/articles/{slug}.md — 原文存档，frontmatter 加 type: source + ingested 日期 + 保留原 source_url/sha256。slug 从标题生成（lowercase-hyphens，中文保留）。
entities/{slug}.md 或 concepts/{slug}.md — 合成页：
- frontmatter：title/created/updated/type/tags/sources（指向 raw）/confidence/review_value/review_confidence/review_stars/review_recommendation
- 中文正文 + 英文术语，每段 prose 末尾 ^[raw/articles/slug.md] 引用（单源文末单一回链即可）
- → [[raw/articles/slug|原文存档]] 回链
- ⚠️ 写 [[entities/xxx]]/[[concepts/xxx]] 前先 ls 确认目标存在，不存在用纯文本反引号（避免 BROKEN LINK）
- type 选择：系统/方法论/人物 → entity；认知模型/心智工具 → concept；方法论对比 → comparison
index.md — 加 entity/concept 条目（- [[entities/slug|标题]] — 摘要）+ raw 条目（追加到末尾）。⚠️ 用 split+insert+join，每条独占一行，写后 grep -n slug index.md 验证。
log.md — append ## [YYYY-MM-DD] ingest | {slug} + 评分 + 来源
清理 inbox — 删除已处理的 RSS/wechat inbox 文件（无论 ingest/reject/skip）；candidates.md 精确删除所有已处理 URL（ingest + reject + skip，不只 ingest），写回。
git commit — 显式路径 git add entities/X.md raw/articles/X.md index.md log.md（不要 git add -A，会扫入未处理文件）；用 /usr/bin/git（subprocess PATH 缺 git）；pre-commit hook 有 pre-existing error 时 --no-verify（先确认新文件 0 lint error）。

工程踩坑（精选，复用主 wiki inbox-screener 验证过的）

坑	规避
inbox_scanner.py 只 glob 顶层	扫描必须 `rglob("*.md")` 递归 rss/newsletter/wechat 子目录。本 skill 的 score_life_inbox.py 已处理
blacklist 漏检 RSS query param	URL 匹配前 `url.split('?')[0].rstrip('/')`，strip `www.`，normalize http↔https
blacklist 只搜 frontmatter 前 1000 字节	读至少 2000 字节 + 也搜 body 中的 source_url
candidates.md 只删 ingest 的 URL	评分完成（无论 ingest/reject/skip）后，所有已处理 URL 都从 candidates.md 删除，否则下轮重复处理
`git add -A` 扫入未处理文件	始终显式路径 add；同进程多 inbox 文件时第 1 篇 commit 会带进第 2 篇
subprocess 找不到 git	用 `/usr/bin/git` 绝对路径
execute_code 在 cron 被阻塞	用 `write_file` 写 .py 到 /tmp + `terminal("python3 /tmp/x.py")`；或直接跑仓库内 scripts/score_life_inbox.py
MiniMax 2056 配额耗尽	life wiki 直接用 DeepSeek，不依赖 MiniMax，规避此问题
DeepSeek 返回 0-100 scale	解析后 `if value>10: value/=10`
DeepSeek batch reason 过长截断	含 reason 字段用 `max_tokens=1500`；无 reason 用 500
index.md 条目拼接	用 split+insert+join；写后 `grep -n slug index.md` 验证独占一行
wikilink 指向不存在页	写 `[[entities/x]]` 前 `ls entities/` 确认；不存在用反引号纯文本
中文文件名空格	shell 用 find -exec / xargs，不要直接 cp 包含空格的文件名
import hashlib 缺失	hashlib.sha256() 在 ingest() 中调用但未 import，首次运行即 NameError crash。hashlib 是标准库，cron 环境同样可用，在 import 行追加 hashlib 即可
index 条目 entitys typo	update_index() 中 f-strings 拼接 {type_}s 对 type_=entity 产生 entitys/ 而非 entities/。修正：单独处理 entity 的 plural 形式 entities，其余加 s
Newsletter candidates 累积 50+ URL 耗时超标	cron 5min 超时时，50 URL × 30s Jina fetch = 25min worst case。脚本现在有 QUICK_SKIP_PATTERNS 在 fetch 前跳过播客/周报/重定向/非 life 类 URL（命中率 ~60%），大幅缩短批处理时间。若仍超时，先手动预过滤 candidates.md 再跑脚本

主力脚本

scripts/score_life_inbox.py — 自包含评分入库脚本，cron 直接调用：

cd ~/wiki-life && source ~/.wiki-cron.env && /usr/bin/python3 ~/.hermes/skills/wiki-life/life-screener/scripts/score_life_inbox.py

⚠️ 脚本输出后必须修复的 4 个问题

score_life_inbox.py 的 entity 生成是裸模板：title=URL、正文仅复制 raw 第一行。每次脚本完成后 agent 必须做以下修复：

修复 entity title — 将 frontmatter title: "URL" 改为有意义的中文/英文标题；H1 同理
改进 entity 内容 — 将空白「核心要点」替换为真正合成：提炼框架、对比表、关键要点，每段加 ^[raw/...] 引用（单源文末单一回链即可）。目标 size ≥2KB
移动 entity 条目到 index.md 正确位置 — 脚本将 entity 条目插入在 ## Core Areas (MOCs) 的「职业发展」小节中间，破坏当前子 MOC 的列表完整性。life wiki 的 index.md 没有 ## Sources / ## Entities 分段，独立 entity 条目应放在文件末尾（与其他 standalone entry 并列），而不是插在 MOC 小节内。移动步骤：
```
# 从 MOC 区删除 entity 行 + 追加到文件末尾
lines = [l for l in lines if 'slug' not in l]
lines.append('- [[entities/slug|标题]] — 摘要\n')
```
操作后 grep -n "slug" index.md 确认实体条目只出现在文件末尾。
验证 index.md raw 条目 — 脚本可能漏加 raw source 条目。运行 grep -n "<slug>" index.md，确认 entity 条目 + raw 条目各 1 行、各占独立一行。缺少 → 追加行到文件末尾；注意文件最后一行可能无 \n 导致拼接（见下方「拼接修复」）。更新 header Total pages + Sources 计数。

Stats 不一致诊断（2026-08-06 实战）：脚本输出出现 [WARN] index.md 条目验证失败: <slug> 时，raw 条目几乎肯定没写进 index.md（验证失败即 grep 不到）。此时 Stats 的签名是 Total pages +2、Entities +1、但 Sources 不变 —— 脚本把 raw 算进了 Total pages，却没插入 raw 条目也没 bump Sources。修复：grep 确认 raw 缺失 → 追加 raw 条目到文件末尾 → 只把 **Sources**: N 加 1。Total pages 已是正确值，不要按"+2/+1/+1"全覆盖（那是理想情况），否则 Total pages 会多 1 变成 54。

拼接修复：life wiki 的 index.md 最后一行不一定有 trailing \n。用 Python lines.append(entry) 时，需要确保前一行已 \n 结尾：

# 写前修复
if lines and not lines[-1].endswith('\n'):
    lines[-1] = lines[-1] + '\n'
lines.append(raw_entry)

如果忘了做，grep 会发现两条条目在同一行——用 Python content.replace('来源- [[raw/articles/', '来源\n- [[raw/articles/') 修复。

life wiki index header 格式：header 位置在 ## Stats section，格式为多计数器同一行：

- **Total pages**: N
- **Entities**: M | **Concepts**: P | **Comparisons**: Q | **Cases**: R | **Queries**: S | **Sources**: T | **Reviews**: U
- **Last updated**: YYYY-MM-DD

⚠️ **Sources**: N 与其他计数器在同一行，不是独立一行。以下方法会失败（前面没有 - 前缀）：

# ❌ 不起作用 —— 实际行以 "- **Entities**: ..." 开头
content.replace("- **Sources**: 11", "- **Sources**: 12")

正确做法：

# ✅ 精确匹配 **Sources**: （无前缀，直接子串替换）
content = content.replace("**Sources**: 11", "**Sources**: 12")

# ✅ 或匹配完整行
content = content.replace(
    "- **Entities**: 12 | **Concepts**: 4 | **Comparisons**: 5 | **Cases**: 6 | **Queries**: 7 | **Sources**: 11 | **Reviews**: 2",
    "- **Entities**: 13 | **Concepts**: 4 | **Comparisons**: 5 | **Cases**: 6 | **Queries**: 7 | **Sources**: 12 | **Reviews**: 2"
)

同时更新 **Last updated**: 日期：

content = content.replace(
    "**Last updated**: 2026-07-09",  # 旧日期
    "**Last updated**: 2026-07-27"   # 当前日期
)

Verification（header 更新后立刻检查）：

cd ~/wiki-life && head -10 index.md
# 确认 Total pages / Sources / Last updated 反映最新入库

修复后建议重新 commit：用 git commit --amend 或新 commit，确保 entity 有合成价值而非纯 URL 拷贝。

跨库路由到 ~/wiki（用户同意后）

当用户同意将判定为 tech 的文章路由到 ~/wiki 时，直接走手动加工程序：

获取全文 — 使用 browser_navigate + browser_console(document.body.innerText) 抓取完整正文（Jina fetch 在 WeChat URL 常超时，浏览器更可靠）
评分并入库（实用模式）：
- 使用 delegate_task 并行处理多篇文章（上限 3 并发），每篇一个子 agent
- 子 agent 读 ~/.wiki-cron.env 中 DEEPSEEK_API_KEY，调用 DeepSeek API 评分
- 评分 prompt 用 AI/ML 技术维度（非 life 维度）：技术深度、独特洞察、引用/数据、框架实用性、批判性
- 阈值：v×c ≥ 49（技术库门槛，比 life 的 45 高）
- 通过后：写 raw/articles/（frontmatter + 全文）→ 可选 entity/concept → 更新 index.md → 更新 log.md → git commit
Git commit 注意事项：
- 显式路径 git add raw/articles/X.md entities/X.md index.md log.md
- 用 /usr/bin/git 绝对路径
- pre-commit hook 有 pre-existing error 时 --no-verify
子 agent 输出验证：子 agent 自报的结果可能不准确。收到 summary 后检查：
- commit 是否存在：cd ~/wiki && git log --oneline -5
- entity 文件是否合理：cat ~/wiki/entities/<slug>.md | head -20
跨库路由的典型场景：
- 用户从 wechat 发来多篇技术文章 URL（阿里云开发者、Hyman的杂货铺等），会话上下文在 wiki-life 目录
- 用户确认 "转投 ~/wiki" 后执行本流程

报告输出规则

✅ 新入库文章（标题 + slug + v×c 分数 + commit hash）
✅ 真正错误（API 失败、脚本崩溃、文件损坏）
✅ 无新内容/无入库 → [SILENT]（抑制投递）
❌ 不报 DeepSeek provider 细节（内部实现）

life-screener

来源信息

安装方式

检查来源文件

同仓库更多 Skills

同仓库更多 Skills

Life Screener — wiki-life inbox 评分入库

背景

领域定义（SCHEMA.md / AGENTS.md）

评分门槛

Life 红线 — 7 类无条件 REJECT（QUALITY.md）

5 维度质量标准（QUALITY.md）— 入库须满足 ≥2 项

领域相关性检查（评分通过后的后置过滤）

用户直接发链接的快速评估流程

1. 来源识别

2. 标题关键词预判

3. 内容快速确认

4. 批量场景

评分流程

域名过滤（Newsletter）

LLM 评分 API

主力：OpenCode Go（复用主 provider，无需额外 API 配置）

兜底：Manual Heuristic（OpenCode Go 不可用时）

入库流程

工程踩坑（精选，复用主 wiki inbox-screener 验证过的）

主力脚本

⚠️ 脚本输出后必须修复的 4 个问题

跨库路由到 ~/wiki（用户同意后）

报告输出规则

Life Screener — wiki-life inbox 评分入库

背景

领域定义（SCHEMA.md / AGENTS.md）

评分门槛

Life 红线 — 7 类无条件 REJECT（QUALITY.md）

5 维度质量标准（QUALITY.md）— 入库须满足 ≥2 项

领域相关性检查（评分通过后的后置过滤）

用户直接发链接的快速评估流程

1. 来源识别

2. 标题关键词预判

3. 内容快速确认

4. 批量场景

评分流程

域名过滤（Newsletter）

LLM 评分 API

主力：OpenCode Go（复用主 provider，无需额外 API 配置）

兜底：Manual Heuristic（OpenCode Go 不可用时）

入库流程

工程踩坑（精选，复用主 wiki inbox-screener 验证过的）

主力脚本

⚠️ 脚本输出后必须修复的 4 个问题

跨库路由到 ~/wiki（用户同意后）

报告输出规则