inbox-screener

name	inbox-screener
description	扫描 raw/ 下的 inbox 目录（rss-inbox/、wechat-inbox/、newsletter-candidates.md），对每篇候选文章调用 web-content-reviewer 评分，≥49 触发 llm-wiki 入库。统一管理所有自动抓取源的文章筛选。
version	1.320.0 — 2026-08-05 22:05: 32nd round 1-ingest（22:05 轮：wechat 50 → step0 二轮清 11 [viking sim=0.80 ×2 + CloudQ sim=0.91 + plugfest sim=0.95 + harness-实践 source_url dup + 6 <1KB shells] + quick-classify 33 skip [vendor NVIDIA ×6 + workbuddy ×3 + officeace ×3 + event/hackathon/waic/互动指南/全日程 ×6 + education 研修班/公开课 ×3 + competition ×2 + academic_meta ×2 + listicle ×2 + legal + emotional 力挺 + no-ai + marketing-summary + career 测开 body-confirmed + product-integration + livestream] + 4 documented pre-move [higress URL 一致 + gartner 3636B + 叶小钗训练营 body-confirmed + 看不懂python报错 tutorial] → 6 genuinely-new score; rss 34 → step0 10 slug-dup [crewai ×3 + interconnects #22 + kueue + lessons-2b + opinionated-guide + database-credentials + video-editing + state-of-blog source_url dup] + 4 skip + 19 documented pre-move [source_url 全部与 pitfall 表一致] → 1 genuinely-new score; 7 篇评分：**1 MERGE ingest [爆删80%系统提示词 AI寒武纪 vxc=56 → claude-code-context-engineering-anthropic-thariq 第 3 来源，跨号传播同 Thariq rules 文 + 互补角度 5 条]** + 3 new domain-reject 入档 [Colyseus vxc=56 平台教程 #19 / 腾讯研究院卖token vxc=72 经济分析 #20 / 陶哲轩 ICM vxc=72 观点文 #21] + 3 reject [英伟达-ilya vxc=21 stars=2 veto / 技术与叙事 vxc=35 / Opus5 突发 vxc=48]。⚠️ 0-ingest 连续 37 轮止于本轮（1 MERGE）。31st consecutive clean-exit 前的 0-ingest 记录：36 轮。30th consecutive 0-LLM clean exit（10:51 轮：wechat 110 → step0 87 [<1KB shells 多数 + slug-dup/source_url] + quick-classify 17 skip [vendor NVIDIA ×6 + officeace + siggraph + event/hackathon/waic/互动指南/会议日程 ×5 + plugfest + product-integration + no-ai 泰坦 + career 测开 body-confirmed + academic_meta 直播回放 + marketing-summary 农业AI] + 6 score 全人工 doc-pattern 拦截 [8-个 python 教程 vxc=25 档 + 中科院研修班 education + workbuddy vendor ×2 + 看不懂python报错 tutorial 文档示例 + 10个skill listicle] → 0 LLM; rss 24 → step0 10 slug-dup [crewai ×3 + interconnects ×2 + Netflix kueue + lessons-2b + opinionated-guide + database-credentials + video-editing, 全与 08-02 入档 slug 一致] + quick-classify 6 skip [domain_sso / title_digest / service-topology / dashboard / vpn组网 / no-ai] + documented premove 18 [AWS ML 平台教程 ×12 + AWS China Blog ×3 (BaaS vxc=35 / text-only-llm-sft / Athena) + interconnects #23 vxc=40 + Netflix device-capabilities + kimi-k3 hyperpod cross-slug, 全部 source_url 与 pitfall 表一致] → 0 LLM; candidates 0 → 0 ingest。⚠️ 本轮修复 quick-classify listicle/education/vendor 盲区（详见 2026-08-05 pitfall 条目：'8-个' digit-hyphen 与 '10个skill' CJK 前缀变体此前每轮标 score 靠人工拦截）。29th (2026-08-04 16:14): wechat 19 → step0 4 [CloudQ sim=0.91 + plugfest sim=0.95 + 2 <1KB shells] + quick-classify 15 skip [vendor NVIDIA ×7 + event/hackathon/waic/interactive ×4 + career 测开 body-confirmed + legal 起诉 + emotional 力挺 + marketing-summary 农业AI + no-ai 泰坦合金] → 0 LLM; rss 33 → step0 11 + quick-classify 6 skip [domain_sso / title_digest / service-topology / dashboard / vpn组网 / no-ai] + documented premove 15 [AWS ML 平台教程 ×12 + interconnects artifacts-23 + Netflix device-capabilities + text-only-llm-sft, 全部 source_url 与 pitfall 表一致] + 1 scored reject [后端即服务 BaaS vxc=35, AWS China Blog BaaS 家族首例已入档] → 0 ingest）。28th (14:56): wechat 31 → step0 5 [viking sim=0.80 + CloudQ sim=0.91 + plugfest sim=0.95 + 2 <1KB shells] + quick-classify 26 skip [vendor NVIDIA ×6 + officeace ×3 + event/hackathon/waic/interactive/competition ×6 + livestream + academic_meta ×2 + education ×2 + legal 起诉 + emotional 力挺 + career 测开 body-confirmed + marketing-summary 农业AI + no-ai 泰坦合金 + product-integration 瑞幸] → 0 LLM; rss 0; candidates 0 → 0 ingest）。25th-23rd (03:58-01:52): 连续 0-ingest 轮，详见 已知坑 表 2026-08-01/08-04 条目 + references/2026-08-04-bedrock-automated-reasoning-vxc56-platform-tutorial-reject.md；23rd 轮入档 Bedrock 平台教程 vxc=56+stars=4 仍 domain-reject，打破 '大概率 vxc<49' 启发式**新入档：Bedrock 平台教程 vxc=56+stars=4 仍 domain-reject，打破 '大概率 vxc<49' 启发式**（23:17 轮 viking 未出现——extractor 86s kill 时仅写入 19 文件 vs 前几轮 20-27，kill 时点决定写入子集，属正常波动，勿因缺 viking 疑漏检）。0-ingest closeout 只 stage cron-status.log 并 --no-verify commit（勿 git add -A）；step0 与 extractor 并行时必须在 extractor 结束后重跑 step0（见 已知坑 2026-08-03 条目）
category	wiki
related_skills	["web-content-reviewer","llm-wiki","wiki-pipeline","rss-to-wiki-pipeline","wechat-mp-rss-extractor","newsletter-link-extractor","tinyfish-web-agent"]

Inbox Screener

统一筛选所有自动抓取 pipeline 沉淀到 inbox 中的候选文章。

⚠️ LLM 评分 API 配置（2026-07-22 实测）：

• OpenCode Go 主力：https://opencode.ai/zen/go/v1/chat/completions，model deepseek-v4-flash，需要从 ~/.hermes/config.yaml 读 opencode-go 的 api_key
• OpenCode Go 不可用时：切 DeepSeek deepseek-v4-flash
• 双 provider 都失败时：→ 手动启发式评分

背景

Pipeline	输出位置	内容类型
rss-to-wiki-pipeline	raw/rss-inbox/	RSS 全文/摘要 — 文件已含完整正文
wechat-mp-rss-extractor	raw/wechat-inbox/	微信公众号文章
newsletter-link-extractor	raw/email-inbox/candidates.md	Newsletter URL 列表

评分流程

inbox-screener 扫描 inbox
    ├── 0. 过期 inbox 文件预清理（2026-07-10 added）
    │     inbox 文件常因提取器已入库但未删除 inbox 副本而累积。
    │     在调用 LLM 评分前，先对每个 inbox 文件做轻量级去重：
    │     a. 小文件删除（首步，2026-07-20 改为无条件）：<1KB 的 inbox 文件直接删除（空壳/截断），
    │        不论是否含有 source_url 字段。extractor 每轮产生多个 <1KB 占位文件（有完整 frontmatter
    │        但 body 为空），source_url 匹配前先清理，避免被误认为有效候选。
    │     b. slug 匹配：去掉 .md 后缀后的文件名若已存在于 raw/articles/ 中，直接删除 inbox 文件
│        ⚠️ 2026-07-31 实测：slug 匹配是唯一能抓住「同号重发」的层——同一公众号用新 /s/UID
│        重发同一文章时，source_url 匹配（c）必然 miss（URL 不同），但文件名 slug 与 raw 完全一致。
│        只写 source_url 匹配的 ad-hoc step-0 脚本会漏过此类文件，使其进入 LLM 评分浪费 API。
│        命中后用 body similarity ≥0.7（difflib，去 frontmatter 按行 strip 比较）或 entity 引用
│        grep 复核，防标题同名不同内容。详见 references/2026-07-31-wechat-republish-new-url-dedup.md
    │     c. source_url 匹配：读取 inbox 文件的 source_url 字段，在 raw/articles/ 中搜索，
    │        若找到则删除 inbox 文件（URL 重复）
    │     实测效果：76 个 inbox 文件全部是已入库副本，预清理后 inbox=0，节省了 LLM 评分费用。
    │     ⚠️ 清理脚本陷阱：代码中必须先做无条件 <1KB 删除，再做 source_url 匹配。否则 extractor
    │        新写入的占位文件（<1KB + 有 source_url）会经 source_url 匹配 evades 清理，留存到候选列表。
    │
    │     ⚡ RSS 领域无关文件积累清理（2026-07-25 新增）
    │     Step 0 的 source_url 匹配只能清除已入库的副本。但 domain-irrelevant RSS 文件
    │     （服务拓扑、DBA、VPN、SSO、仪表板等）没有匹配的 source_url（它们从未被入库），
    │     却在多轮 cron 中持续积累。这些文件 >1KB 且无 source_url 匹配，step 0 不会触及。
    │     2026-07-25 实测：8 篇 domain-irrelevant RSS 在 wechat-inbox 清理后仍残留于
    │     rss-inbox（0 new inbox 来自本轮 extractor），来自之前 cron 的积累。
    │     修复：在 step 0 清理后、构建 candidates 前，对 RSS 文件做标题级领域预过滤
    │     （见下方"RSS 领域相关标题预过滤"的 DOMAIN_SKIP_TITLE 列表）。匹配标题模式
    │     的 RSS 文件直接删除（不进评分，不留存）。2026-07-25 实测：8 篇全部清理，
    │     rss-inbox=0，不会在下轮 cron 中重新加载。
    │     判断原则：宁留勿清——只有当标题明确指向非 AI 领域（数据库迁移、VPN 组网、
    │     SSO 配置、仪表板布局、设备自定义 OS 安装）时才删除。AI 领域的 RSS 即使
    │     评分低也留给下一轮（不会积累，新一轮 extractor 通常会覆盖旧文件的 source_url 黑名单）。
    │
    ├── 1. URL 黑名单预检查（最重要！）
    │     扫描 raw/articles/ 的 source_url:/url: 构建黑名单
    │     ⚠️ 必须 strip YAML 引号：val = m.group(1).strip().strip('"').strip("'")
    │     ⚠️ RSS feed URLs 常含追踪 query params（如 ?source=rss----xxx），
    │        blacklist 必须 strip query params 后再匹配：url.split('?')[0].rstrip('/')
    │     黑名单命中 → 跳过（已入库）
    │
    ├── 2. WeChat inbox
    │     <1KB → 直接删除（空壳文件）
    │     ≥1KB → Lifestyle 关键词过滤 → AI 关键词预过滤（同 RSS）→ 快速内容分类 → LLM 评分
    │     文件大小用 `os.path.getsize()`，不用 `len()`
    │
    ├── 3. RSS inbox
    │     <1KB → 跳过（空壳）
    │     ≥1KB → 读取文件内容（已含完整正文）
    │         内容充足 → AI 关键词预过滤 → 快速内容分类 → LLM 评分
    │         内容不足（<3KB）→ Jina fetch 补抓再评分
    │
    │     ⚡ RSS AI 关键词预过滤（2026-07-01 实测：31 篇 → 9 篇送 LLM，节省 71% API 调用）
    │     EN_AI_KEYWORDS = ['agent', 'llm', 'model', 'ai', 'machine learning', 'deep learning',
    │                       'training', 'inference', 'transformer', 'neural', 'claude', 'gpt',
    │                       'anthropic', 'openai', 'bedrock', 'sagemaker', 'harness',
    │                       'agentic', 'multi-agent', 'rag', 'mcp', 'context', 'prompt',
    │                       'skill', 'coding agent', 'autonomous', 'fine-tun', 'rlhf',
    │                       'dpo', 'sft', 'post-training', 'open source', 'governance',
    │                       'cvpr', 'segmentation', 'detection', 'vision', 'world model',
    │                       '3d', 'video generation', 'multimodal', 'diffusion', 'genie', 'omni']
    │     CN_AI_KEYWORDS = ['模型', '训练', '推理', '智能体', '多模态', '大模型',
    │                       '深度学习', '神经网络', '视觉', '检测', '识别', '生成',
    │                       '代码', '编程', '架构', '框架', '自动', '部署',
    │                       '微调', '强化学习', '生成式', '语义', '理解', '优化']
    │     命中 ≥1 个关键词（EN 或 CN）→ 送 LLM 评分；<1 → 跳过
    │
    │     ⚡ RSS 领域相关标题预过滤 — LLM 评分前的第二道节省（2026-07-25 新增）
    │     在 AI 关键词预过滤之后、LLM 评分之前，增加一道标题级领域相关性检查。
    │     某些 RSS 文章虽然通过 AI 关键词检查（命中 model/ai/训练等），但标题明确指向
    │     非 AI/ML 领域（数据库、网络、SSO、服务拓扑等）。这些文章走 LLM 评分肯定 domain-reject，
    │     提前过滤可节省 API 调用。2026-07-25 实测：12 篇 RSS 通过 AI kw 检查→4 篇 domain pre-filter
    │     拦截→4 篇送 LLM（全部 vxc≤35, 0 ingest）。
    │
    │     预过滤标题模式（title.lower() substring 匹配）：
    │     DOMAIN_SKIP_TITLE = [
    │         'service topology', 'observability', 'distributed tracing',
    │         'aurora postgresql', 'postgresql', 'mysql', 'database migration',
    │         'site-to-site vpn', 'vpn组网', '动态ip',
    │         'entra id', 'iam identity center', 'sso', 'identity',
    │         'highcharts', 'dashboard', 'mobile layout',
    │         'custom os installation', 'deepracer device',
    │         'transform your sales', 'sales organization', 'quick your new',
    │         'kueue', 'batch compute',  # data infrastructure
    │         'plugfest', 'wireless charging', 'hardware standard',  # non-AI hardware
    │     ]
    │     ⚠️ 裸 'identity' 模式过宽 — 假阳性（2026-07-31 实测）
    │     DOMAIN_SKIP_TITLE 中的裸 `'identity'` 子串会匹配任何含 "identity" 的标题，
    │     包括 AI Agent 安全/认证文章："Authenticate with Private Key JWT using
    │     Amazon Bedrock AgentCore Identity"（AWS China ML）因 H1 含产品名
    │     "AgentCore Identity" 被 domain_identity 拦截——实际是 agent 通过
    │     Private Key JWT client assertion 向 downstream IdP token endpoint 认证
    │     （AWS KMS 签名）的 Agent 集成认证架构，非 IAM 身份管理运维文。
    │     预期拦截对象（Entra ID / IAM Identity Center / SSO 管理）已被
    │     'entra id' / 'iam identity center' / 'sso' 覆盖，裸 'identity' 应移除。
    │     判定原则：DOMAIN_SKIP_TITLE 模式必须匹配"领域"，不能匹配"产品名/功能名"。
    │     含 agent/JWT/IdP/token endpoint/KMS 等 Agent 认证信号的标题，
    │     即使命中基础设施词也要先确认核心主题是 AI 应用还是基础设施运维。
    │     详见 references/2026-07-31-domain-identity-agent-auth-false-positive.md
    │     ⚠️ 关键实现陷阱：标题提取可能失败 → 必须加文件名级兜底匹配
    │     某些 RSS feed（如 AWS China ML blog）的文章正文中第一个 `# ` heading 可能不是文章真实标题
    │     （markdown 插件自动生成的章节标题覆盖了 frontmatter 后的 H1）。如果 DOMAIN_SKIP_TITLE
    │     只匹配提取到的 title，而 title 提取返回了错误的文本（例如 "Security without sacrifice"
    │     而非 "Building multi-Region visualizations with Highcharts"），那么 domain skip 会整体失效。
    │     2026-07-27 实测：highcharts 和 sales-org 两篇 RSS 因 title 提取错误而未被 DOMAIN_SKIP_TITLE
    │     拦截（标题提取为 "Security without sacrifice" 和 "About the author"），继续留存到候选列表。
    │     修复：在标题匹配之外，**始终加文件名级兜底**——将 fname.lower().replace('-', ' ')
    │     .replace('.md', '') 作为第二匹配源。rss domain pre-filter 的实现代码应检查：
    │     title_match 成功 → 用 title 匹配 DOMAIN_SKIP_TITLE
    │     title_match 失败或结果明显不是文章标题 → 用 fname（去连字符后）再次匹配
    │     或更简单：始终用 title AND fname 两个匹配源做 OR 判断。
    │     注意：这些标题模式与入库后的 domain-reject 检查共享同一灵感来源，但作为
    │     pre-filter 时不要求 100% 精确——宁放勿杀。当标题同时含 AI 信号（如
    │     "Aurora PostgreSQL + pgvector for AI embeddings"）时不应拦截。区分标准：
    │     文章核心主题是 AI/ML 应用还是基础设施运维。标题前半句通常揭示核心主题。
    │
    |     ⚡ 实体关键词去重 — LLM 评分前的三层去重（2026-07-02 实测）
    │     提取候选标题中的独特关键词（≥4 字母英文词），与 entity slug 做交集。
    │     命中 ≥3 关键词重叠 → 跳过。必须排除通用停止词（amazon, aws, bedrock, model, ai, agent 等）。
    │     在密集覆盖领域（AI/Cloud/MCP），source_url 黑名单是主要去重手段，entity dedup 仅辅助。
    │
    |     ⚡ V6 去重增强（2026-07-05 实测）
    │     用 inbox 文件名中的关键片段 grep entities/ 目录。
    │     2026-07-05 实测：72 篇 WeChat 评分后有 2 篇的 entity 文件名几乎与 inbox 文件名一致。
    │
    |     ⚠️ WeChat URL 两种格式使 `split('?')[0]` 产生 100% 假阳性 DUP
    |     WeChat URL 格式：(1) `/s/UNIQUE_ID`（路径式），(2) `sn=...`（query param 式）。
    |     `split('?')[0]` 对两种格式均失效——仅适用于 RSS/博客 URL。
    |     去重优先级：(1) path-based 用 `re.search(r'/s/([A-Za-z0-9_-]+)', url)`；
    |     (2) query-based 用 `re.search(r'sn=([^&]+)', url)`；
    |     (3) `split('?')[0].rstrip('/')` 仅用于非 WeChat URL。
    |
    |     ⚠️ `grep -rlF $URL` 匹配 body 内容中的 URL 产生假阳性 DUP
    |     V6 检查必须区分 frontmatter 级匹配 vs body 级匹配。
    |     优先解析 frontmatter `source_url:` 行，不要依赖 body 全文 grep。
    |
    │     ⚡ 快速内容分类 — LLM 评分前节省 API 调用的二次过滤
    │     必须 CASE-INSENSITIVE，连字符/空格归一化。
    │     ⚠️ Body 匹配假阴性风险：body 级别的 substring 匹配可能将高价值 AI 文章（如DeepSeek
    │     创始人梁文锋AGI哲学文）误判为"竞赛通知"——因为文章正文可能提及benchmark竞赛成绩\n    │     来增益说服力，但匹配器将"竞赛"二字的出现等同于"竞赛通知文"。判定原则：
    │     - 优先基于 title 做 skip 判断（title 是文章主题最可靠信号）
    │     - body 匹配只做辅助参考，且必须加 title-AI-signal 守卫
    │     - 对于 competition/event/recruitment 等易在正文以"上下文提及"出现的类别，
    │       若 title 含 AI/ML 信号词（agi/deepseek/agent/model/智能体等）则不 body-skip\n    │     详见 references/2026-07-24-quick-classification-body-match-false-negative.md
    │     - 新闻聚合/速递（"腾讯研究院AI速递"）→ skip LLM
    |     - 产品公告（纯营销语言）→ skip LLM
    |     - 官方账号"技术摘要"模式 → skip LLM
    |     - 平台/基础设施组织新闻 → skip LLM
    |     - 产品事故/额度重置报道 → skip LLM
    |     - 职业/HR/观点文 → skip LLM
    │       实现模式（title 级）：`'困局与突破' in t or '测开' in t` 触发后，再检查 body 的 career 信号
    │       （`'这篇文章想讨论的不是' in body or '自问自答' in body or '不是想证明' in body or '但我更关心' in body`）。
    │       注意：'测开'（测试开发）出现在标题中不代表文章是 career philosophy——需要 body 级 self-referential
    │       framing 确认。2026-07-26 实测："测开的困局与突破"（27KB, 京东技术, 10 AI kw hits）经 body
    │       career signal 确认后拦截。
    |     - 招聘/HR 帖 → skip LLM
    |     - 活动报名/论文分享会 → skip LLM
    | - 竞赛/大赛/黑客松/码道争锋/开发者大赛/挑战赛 → skip LLM
    |       **Body-level event catch (2026-07-28):** 当标题无 event 关键词但 body 含"黑客松"/"hackathon"/"扫码报名"/"奖池"等信号时，也应在 quick classification 阶段拦截。标题带 AI 关键词的 hackathon/event 文章是标题级预过滤的已知盲区——AI Agent 竞赛活动标题自然嵌入 agent/ai/model 等关键词（如"48小时：挑战 AI Agent 能否真正解决企业问题！"），标题模式放行，但 body 中明确的 event 信号（"小宿科技环球黑客松·北京站"）可拦截。实现：`BODY_EVENT_SKIP` 列表 + `check_body_content_classification()`, 见 `templates/prescreen-pipeline.py`。
    |     详见 references/2026-07-24-wechat-event-ai-keyword-prescreen-bypass.md。
    |     - 新闻摘要/关键词列表 → skip LLM (关键词: 速递, 关键词Top, 每周关键词, AI速递, 一周综述, weekly roundup, weekly digest)
    |     - 学术评论/观点文 → skip LLM
    |     - 资料/指南发放 → skip LLM
    |     - 月度产品动态 → skip LLM
    |     - 官方公告 → skip LLM
    |     - 书籍/课程广告 → skip LLM
    |     - 情绪化新闻 → skip LLM
    │     - 视频嵌入为主的内容（clean text <1000 chars）→ skip LLM
    │     - 短摘要/占位营销文（body 检查：含"以上为摘要内容"或"扫描下方二维码" + clean text <2000 chars）→ skip LLM
    │     2026-07-25 实测：农业 AI 助手（vxc=42, stars=4）因 744B + "以上为摘要内容"标记被 quick classification 放行→LLM 评分后 domain-reject。
    |     - 教程/综述类 → skip LLM
    │       实现模式：`'教程' in t or '入门指南' in t or '从零开始' in t`。
    │       ⚠️ 注意：许多 Python 标准库/语法教程不以"教程"为标题（如"看不懂 Python 报错？80% 的报错三行就够"并不含"教程"二字）。
    │       LLM 评分会正确 reject 纯教程文（vxc=25-36），标题级别预过滤不 catch 的留给 LLM 兜底。
    │     - 营销/产品推广/tokens限时免费 → skip LLM
    │       实现模式：`'全自动' in t or '事半功倍' in t or '一键生成' in t`。这些模式在纯营销标题中高频出现。
    │       ⚠️ 注意：vendor 官方营销号的标题模式已在下方 Vendor 条覆盖。
    │       2026-07-26 实测：OfficeAce AI 全自动表格处理被 pattern 拦截。
    |     - listicle/合集 → skip LLM
    |     - 品牌/营销/设计教程 → skip LLM
    |     - 学术期刊排名 → skip LLM
    |     - 金融/财经新闻 → skip LLM
    |     - 硅谷/行业评论 → skip LLM
    |     - 超级计算机/排名新闻 → skip LLM
    |     - 产品 Q&A/FAQ（"答网友问"）→ skip LLM
    | - 法律/诉讼新闻 → skip LLM
    |       实现模式：`'起诉' in t or '诉讼' in t`。法律纠纷/诉讼报道，即使标题含 AI 公司名（如"美国牧师起诉 OpenAI"），核心是法律新闻而非技术分析。
    |       ⚠️ 注意：`'告' in t` 单字过宽（"预告"、"公告"、"告一段落"），不要用单字匹配。`'起诉'` 和 `'诉讼'` 是法律语境的特有词，假阳性极低。2026-07-28 实测：美国牧师起诉 OpenAI（夕小瑶科技说）body AI keywords≥3 但纯法律新闻，vxc 应 <20。
    | - 开发框架/工具介绍（非 AI/ML）→ skip LLM
    │     - 教育/产教活动（产教协同/高校公开课）→ skip LLM
    │     - 产教协同/高校公开课（2026-07-25 实测：华为云高校公开课、中山大学公开课等教育报道全部 vxc≤15）→ skip LLM
    │     - 论坛/峰会/WAIC 活动预告 → skip LLM
    │       实现模式：`'全日程' in t or '会议日程' in t or '活动预告' in t or '互动指南' in t or 'waic' in t_lower`。注意：AI 关键词在活动标题中常见但不应放行。
    │       `'互动指南' in t` 覆盖两类：独立"互动指南"（如"Agentic AI 大会互动指南在手"）和复合"大会互动指南"。要求 title 级别的空格归一化匹配。
    │       2026-07-26 实测："AI 真的跑进业务了吗？GIAC 2026 深圳站 15 大专题全日程"标题含"AI"和"全日程"被 pattern 拦截。
    │       2026-07-26 实测："7月18日，WAIC京东论坛共探AI进入物理世界"（1825B 短事件通知）因标题含"WAIC"被 pattern 拦截。
    │       2026-07-29 实测："7.24-25 深圳 Agentic AI 大会｜互动指南在手"（3967B, feed_name=阿里云云原生）因标题含"互动指南"被 pattern 拦截。
    │     - 产品上线/推出/发布公告 → skip LLM
    │       实现模式：`'推出' in t and ('企业版' in t or '服务' in t or '产品' in t or '上线' in t)`。
    │       或 `'全量上线' in t`。排除纯产品介绍（如 "推出新一代推理模型" 是技术文章）。
    │       2026-07-26 实测：Higress Serverless 企业版被 pattern 拦截。
    |     - 学术社区元内容（论文出分/Rebuttal/顶会精讲）→ skip LLM
    │       实现模式：标题级别 `'出分' in t or 'rebuttal' in t or '顶会' in t or '精讲' in t`。
    │       ⚠️ '顶会' 也出现在技术文章中（"顶会论文32篇精讲"实际是直播回放而非技术分析）。
    │       2026-07-26 实测：NeurIPS 出分 + Rebuttal 回文文章被 pattern 拦截（vxc=25）。
    |     - Listicle/合集（"10个skill/X个工具/必备"）→ skip LLM
    │       实现模式：`re.match(r'^\d+\s*个', t)` 或 `re.match(r'^\d+\s*种', t)` 正则匹配标题前缀
    │       或 `'个skill' in t` / `'个工具' in t` 等子串匹配。不要用单数字前缀（如 "48小时" 可能是实战文章）。
    │       2026-07-26 实测："8-个真正能减少重复代码的-python-标准库"被 numeric-prefix pattern 拦截（vxc=25）。
    |     - 行业/标准活动（Plugfest/承办/无线充电等非AI硬件）→ skip LLM
    |     - 产品集成/接入开放平台公告 → skip LLM
    │       实现模式：`'接入' in t and '开放平台' in t`。纯集成公告，无 AI/ML 技术深度。
    │       2026-07-26 实测：华为云码道接入瑞幸咖啡 AI 开放平台被 pattern 拦截。
    │     - Vendor 官方营销号（NVIDIA AI前沿/英伟达/OfficeAce/AIGC峰会/产品教程广告）→ skip LLM
    │       2026-07-29 实测：vendor title 模式补充。常见 vendor 营销标题（空格归一化后匹配）：
    │       `'nvidia培训' in t or 'nvidia dgx spark' in t or 'nvidia ai 前沿' in t or 'siggraph 主题演讲' in t or 'officeace' in t`
    │       这些模式在 vendor 官方号发布的非技术营销文章标题中命中率 >90%，假阳性极低。
    │       对比纯品牌名匹配（如 "nvidia" in t 匹配任何 NVIDIA 文章）更精确。
    │       2026-07-27 实测：Vendor 产品名自营销（OfficeAce 办公产品矩阵、WorkBuddy 培训宣传等）标题含"轻松搞定""立即体验"等营销短语，但核心仍是产品推广而非技术内容。建议在 vendor 营销模式匹配中加入产品名黑名单。
    │     ⚠️ 2026-07-25 实测：vendor 官方营销号标题 "NVIDIA AI 前沿" 中有空格（"AI 前沿" vs "AI前沿"），
    │        quick classification 的 title substring 匹配可能因空格问题失败。必须对匹配模式做**空格归一化**：
    │        在比较前对 title/body 做 `' '.join(text.split())` 压缩连续空格，同时保持 CASE-INSENSITIVE。
    │        同理适用于其他含空格的英文+中文混合 vendor 名（如 "Amazon Bedrock" 匹配模式需显式覆盖空格变体）。
    ⚠️ 2026-07-29 实测补充：`' '.join(text.split())` 仅压缩多空格→单空格，但对**无空格→有空格**变体
    失效——vendor 模式的 `'nvidia培训'`（无空格）在 `'nvidia 培训 | ...'`（单空格）中匹配不上。
    确保模式覆盖的两种方案（二选一）：
    (a) 对匹配源做全空格消除：`t_norm = title.lower().replace(' ', '').replace('\u3000', '')`
        再与无空格的 vendor 模式比较。
    (b) 在 SKIP_TITLE 列表中同时保留无空格和有空格变体：
        `'nvidia培训' in t or 'nvidia 培训' in t`
    推荐方案 (a) 优先——单次 normalize 全局生效，不会漏掉新增 vendor 模式。
    实测（2026-07-29）：全空格消除后全部 4 篇 NVIDIA vendor 文章被正确拦截，
    而 `' '.join()` 因保留单空格漏放 100%。

    ⚠️ 2026-07-29 实测 v2：全空格消除后手工编写的 vendor 模式容易被手误（typo）。
    空间移除后的英文模式是连续字符串（如 "NVIDIA DGX Spark" → "nvidiadgxspark"），
    手工输入时极易漏字母（2026-07-29 实测：`'nviadgxspark'` 漏了 "di" 导致 2 篇未拦截，
    vs 正确 `'nvidiadgxspark'`）。因为空间移除后的字符串失去视觉分界，人类短时记忆
    无法可靠重现 "nvidia"+"dgx"+"spark" = "nvidiadgxspark" 的连接。

    推荐替代方案 — **English prefix extraction**（避免手写连续字符串）：
    ```python
    def norm(s):
        return s.lower().replace(' ', '').replace('\u3000', '').replace('\t', '')
    def english_prefix(s):
        \"\"\"Extract English-only prefix (stop before first CJK char).\"\"\"
        result = ''
        for c in norm(s):
            if '\u4e00' <= c <= '\u9fff' or '\u3000' <= c <= '\u303f':
                break
            if c.isascii() and (c.isalnum() or c in '-_'):
                result += c
        return result

    VENDOR_PREFIXES = {'nvidiadgxspark'}  # single source of truth
    pref = english_prefix(title)
    if pref in VENDOR_PREFIXES:
        # vendor marketing — skip
    ```
    原理：`english_prefix()` 从实际文章标题自动提取空间消除后的英文前缀，
    再与准确 hand-typed 的 vendor prefix 集合比较。直接在 vendor prefix 集合中
    写入正确的字符串（通过 `print()` 调试实际前缀来确认），避免手写匹配逻辑时
    重复键入同一空间消除字符串。

    调试确认方法：
    ```python
    title = open('raw/wechat-inbox/nvidia-dgx-spark-*.md').read().split('---')[-1]
    t = [l for l in title.split('\n') if l.startswith('# ')][0][2:].strip()
    tn = t.lower().replace(' ', '').replace('\u3000', '')
    pref = ''
    for c in tn:
        if '\u4e00' <= c <= '\u9fff' or '\u3000' <= c <= '\u303f': break
        pref += c
    print(repr(pref))  # "nvidiadgxspark" — copy this into VENDOR_PREFIXES
    ```
    这个 workflow 避免了"凭记忆猜空间消除字符串"的所有 bug 类。

    ⚠️ 2026-07-29 实测 v3：**`english_prefix` 对含 CJK 的 vendor 模式有盲区。**
    `english_prefix()` 在遇到第一个 CJK 字符时 break，因此 vendor 名中的 CJK 部分（如
    "NVIDIA AI 前沿"中的"前沿"）被丢弃。`english_prefix("NVIDIA AI 前沿 | 打造...")` 返回
    `"nvidiaai"`（停在"前"之前），无法匹配 `VENDOR_PREFIXES = {'nvidiadgxspark'}` 中的任何条目。
    但全空格消除字符串 `t_norm = title.lower().replace(' ', '')` 中的 `'nvidiaai前沿'` 确实包含
    vendor 全名，子串匹配 `'nvidiaai前沿' in t_norm` 正确命中。

    **推荐用全空格消除字符串的 substring 匹配代替 english_prefix**，因为：
    - substring 匹配同时覆盖纯 ASCII vendor（nvidiadgxspark）和含 CJK vendor（nvidiaai前沿）
    - english_prefix 将 CJK 截断后无法区分"nvidiaai"（NVIDIA AI 的英文前缀）和"nvidiaai前沿"
      （完整的 NVIDIA AI 前沿 vendor 名），可能产生误匹配
    - 全空格消除字符串的可读性更差（连续字符串）但只需要一次 `in` 检查，不需要额外函数调用

    若仍坚持用 english_prefix，必须在 VENDOR_PREFIXES 中同时纳入纯 ASCII 前缀和含 CJK
    vendor 名的完整空间消除字符串，做两层检查：
    ```python
    pref = english_prefix(title)
    if pref in VENDOR_PREFIXES or any(p in t_norm for p in VENDOR_PATTERNS):
        # vendor marketing — skip
    ```

    详见 references/2026-07-25-vendor-name-spacing-quick-classification.md
    │     - 产品上线公告（"全量上线"）→ skip LLM
    |     - 活动招募/热招 → skip LLM
    |     - 个人告别/离职声明 → skip LLM
    | - 直播预告/直播推荐/直播回放/活动通知 → skip LLM
    |       实现模式（title 级）：`'直播预告' in t or '活动预告' in t or '直播回放' in t`；
    |       body 级：`'直播推荐' in body or '巅峰对谈' in body or '即将开启' in body or '直播亮点' in body`。
    |       ✦ 模板常量：`BODY_EVENT_SKIP` in `templates/prescreen-pipeline.py` 包含这些 body 级 event 信号。
    |       ⚠️ 2026-07-27 实测：DataFun "Agent 从演示到生产：腾讯云 CloudQ 与 OPPO GUI Agent 对话 Harness Engineering"
    │       （vxc=35, stars=4）被 LLM 误判为技术文章——event signal "直播推荐" 仅在 body，title 看起来像技术文。
    │       LLM 评分 prompt 看标题 + 正文摘要，被编排的话题列表（执行控制框架/工具调用安全/多 Agent 协作）欺骗
    │       给了 stars=4。**必须同时检查 title AND body 的 event signals**，不能仅依赖 title 级 skip。
    │       当 title 无 event signal 但 body 含 event 标记时，即使 LLM 给了高分也应在 post-scoring domain check 拒绝。
    │     - 大会互动指南/会议日程/互动指南 → skip LLM
    |     - 主题演讲/专题演讲 → skip LLM
    |     - 热招/诚聘/正在热招 → skip LLM
    | - 搞笑大赏/搞笑集锦 → skip LLM
    | - 力挺/怒赞 → skip LLM
    |       实现模式：`'力挺' in t or '怒赞' in t`。个人立场声明/感情宣泄类文章，即使标题含 AI 公司名或模型名（如"黄仁勋力挺中国开源模型"），核心是情绪表达而非技术分析。
    |       ⚠️ 注意：`'挺'` 单字过宽（"产品价值挺高"、"模型表现挺不错"——程度副词/口语化表达与政治立场声明不同），必须用双字 `'力挺'`。2026-07-28 实测："黄仁勋力挺中国开源模型，马斯克：True"（夕小瑶科技说）AI 关键词命中 7+ 但纯社交情绪报道，vxc < 20。
    │
    └── 4. Newsletter candidates（先黑名单 → 域名过滤 → 启发式 → 再 fetch）
          blacklist 检查必须在 Jina fetch 之前！
          blocklist 域名命中 → 跳过
          URL 启发式模式命中 → 跳过
          其他 → Jina fetch → LLM 评分
          ⚡ DeepSeek 可用时 newsletter LLM 评分用薄 adapter（2026-07-31 实测，2026-08-04 canonical 化）：
          canonical score-inbox-files.py 只读 rss/wechat-inbox，不读 fetched 内容。
          adapter 流程：blacklist+blocklist 预检查 → 免 fetch 启发式 skip
          （API docs / 新闻站 / 纯产品页直接跳过）→ fetch（**2026-08-05 实测 Jina r.jina.ai 对全部域名 403，
          direct urllib + browser UA 已是主路径**——用 `scripts/newsletter-direct-fetch.py`；
          fetch 前先清空 /tmp/newsletter-inbox 防上轮残留文件混入评分，fetch 后核对文件数 == URL 数，
          详见 references/2026-08-05-newsletter-jina-403-direct-fetch.md）→
          写 /tmp/newsletter-inbox/*.md（inbox-style frontmatter + H1）→
          复用 canonical prompt 格式评分（batch 5）→ post-scoring domain check。
          **canonical 脚本：`scripts/newsletter-score-adapter.py`**（2026-08-04 新增，
          本会话从 ad-hoc 脚本 canonical 化：batch 5 / 402 short-circuit / 长度错配
          单篇重试 / secret 经 sys.argv[1] / 已修 `import os` NameError）。
          用法：`source ~/.wiki-cron.env && python3 ~/.hermes/skills/wiki/inbox-screener/scripts/newsletter-score-adapter.py "$DEEPSEEK_API_KEY" /tmp/newsletter-candidates.json /tmp/newsletter-score-results.json`
          candidates.json 构造：`[{"fname":"slug.md","source":"newsletter"}, ...]`（fname 为 /tmp/newsletter-inbox 下文件）。
          2026-08-04 实测：6 候选 → 3 reject（HF model-card vxc=1 / MSLK vxc=42 / weightythoughts 观点文 vxc=6）→ 3 ingest
          （qwen38-max vxc=49 NEW、anthropic-cyber-evals vxc=64 NEW、kimi-k3-mi355x vxc=49 MERGE→deploying-kimi-k3-on-aws）。
          ⚠️ prompt 含字面 JSON 花括号时用字符串拼接，`.format()` 会 KeyError。
          详见 references/2026-07-31-newsletter-deepseek-scoring-adapter.md
          ⚠️ 说明：manual-heuristic-score.py 只处理 inbox 文件（.md），不处理 newsletter URL。
              在 heuristic 模式下，newsletter URL 需单独逐个评估：
              域名/黑名单检查 → Jina fetch → 阅读内容 → 手动评分 → ingest/reject。
              🔗 详见 `references/newsletter-heuristic-curl-extract-workflow-2026-07-21.md`
              — 包含 curl → text extraction → 手动评分的完整工作流（Jina 不可用时替代路径）。
              ⚠️ **Newsletter HTML text quality陷阱（2026-07-29）：** curl 直抓的 HTML 含大量
              JSON-LD/导航/页脚/JS 噪音，简单位标签剥离后送入 LLM 的文本质量极低（vxc 被系统性压到
              2-15 的假阴性水平）。anthropic.com 文章从 v=1（噪音文字）到 v=4（正确政策立场）的差异
              完全由提取质量决定。LLM 评分前必须先 strip script/style/nav/footer，再定位文章正文区域
              （最长连续 >50 字符行块）。详见 `references/newsletter-html-text-extraction-quality.md`。

              ⚡ Cron 模式下 newsletter 处理规则（2026-07-22）：
              当双 API 耗尽 + cron 模式（无用户在场），newsletter 手动评估性价比极低——耗时 5-10min，结果几乎全是 reject（产品文档/观点文/官方公告/被封锁页），且无用户确认边界决策。
              规则：cron 模式 + 双 API down → 跳过 newsletter 手动评估，保留 candidates.md 不变，让下一轮 LLM-available 的 cron 处理。
              理由：(1) newsletter URL 不排队——下轮 LLM 可用时一起批量评分；(2) 手动评估的时间成本在 cron 模式下不可接受；(3) 低通过率的 newsletter（约 5-15%）不值得逐一审查。
              例外：明确高价值 URL（arxiv.org/论文/anthropic.com 博客等高价值域名）可快速 fetch 摘要页评分决定。