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）。

Zur Installation springen

Repository: QianJinGuo/wiki
Letzte Quellaktivität: 9. August 2026 um 03:30
Erkannte Sprache von SKILL.md: Chinesisch
Sterne: 1
Forks: 1

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.

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

Der Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.

Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer

6 Dateien

SKILL.md

Quellanweisungen · Schreibgeschützte Vorschau

Zurück zur Suche Zurück zur Installation

Datei-Explorer

6 Dateien

SKILL.md

Quellanweisungen · Schreibgeschützte Vorschau

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

Quellinformationen

Installationsoptionen

Quelldateien prüfen

Mehr aus diesem Repository

Mehr aus diesem Repository

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（用户同意后）

报告输出规则