init: AI日报 pipeline 完整代码 + 技能文档 + 运行记录

2026-06-04 10:38:44 +08:00
commit 94e18ce22d
10 changed files with 1728 additions and 0 deletions
--- a/README.md
+++ b/README.md
@@ -0,0 +1,67 @@
 # AI 日报 Pipeline
 每日自动抓取 AI 行业动态，去重→归类→改写→发布到 [blog.ephron.ren](https://blog.ephron.ren)。
 ## 仓库结构
 ```
 ai-daily-report/
 ├── README.md                            ← 本文件
 ├── script/
 │   ├── ai_daily_blog_pipeline.py        ← 主脚本（~1100 行，纯 Python）
 │   ├── run_meta.json                    ← 最近一次运行元数据
 │   └── blog_markdown.md                 ← 最近一次发布的博文
 ├── skill/
 │   ├── SKILL.md                         ← Hermes Agent 技能文档
 │   └── references/
 │       ├── llm-config-auto-follow.md    ← LLM 配置自动跟随机制
 │       ├── mimo-api-performance.md      ← MiMo API 性能基准测试
 │       ├── rendering-guide.md           ← 博文渲染 & 导览格式
 │       └── timeout-config.md            ← 超时配置参考
 └── cron/
    └── config.json                      ← Cron 作业设置
 ```
 ## Pipeline 流程（4 阶段）
 | 阶段 | 做什么 | 是否调 LLM |
 |------|--------|-----------|
 | Stage 0 | 脚本去重（difflib，纯 Python） | ❌ |
 | Stage 1 | LLM 语义去重 | ✅ 1 次调用 |
 | Stage 2 | 并行改写摘要 + 分类 | ✅ 2 次并发调用 |
 | Stage 3 | LLM 生成今日导览 | ✅ 1 次调用 |
 | Stage 4 | 组装 + 发布到博客 | ❌ |
 ## 数据源
 | 来源 | 类型 | 备注 |
 |------|------|------|
 | AI HOT | API | 主要来源，分类齐全 |
 | 橘鸦 AI 早报 | RSS（content:encoded） | 每日 ~09:34 发布 |
 | InfoQ AI | RSS | 英文技术管理 |
 | 量子位 | RSS | 中文 AI 新闻 |
 | MIT 科技评论 AI | RSS | 英文前沿报道 |
 ## 关键配置
 - **Cron**: 每天 10:00 CST 执行，`no_agent` 模式
 - **超时**: 脚本 600s，LLM 600s，RSS 25s，橘鸦 45s
 - **LLM**: 自动跟随 Hermes 主模型配置
 - **去重**: 只去重不精选，保留全部非重复条目
 - **风格**: 无 emoji、无参考编号、无建议/评论、大白话
 ## 上次运行
 来自 `run_meta.json`：
 - 日期：2026-06-04
 - 原始条目：39 | 去重后：38
 - AI HOT：32 | InfoQ：2 | 量子位：5 | 橘鸦：0（超时）
 - 已发布：https://blog.ephron.ren/posts/ai-2026-06-04
 ## 2026-06-04 修复
 修复了橘鸦源长期不工作的问题：
 1. 解析从 RSS `content:encoded` 获取内容，消除第二次 HTTP 请求
 2. 修复正则 `\\s*` → `\s*`（白字符类错误）
 3. 修复 `.*?` → `[^<]*?`（防止概览节渗漏）
 4. 橘鸦超时从 25s 提升至 45s
--- a/cron/config.json
+++ b/cron/config.json
@@ -0,0 +1,14 @@
 {
  "job_id": "76297415d88d",
  "name": "AI日报单任务09:30",
  "schedule": "0 10 * * *",
  "mode": "no_agent",
  "script": "ai_daily_blog_pipeline.py",
  "deliver": "origin",
  "enabled_toolsets": [
    "terminal"
  ],
  "timeout_seconds": 600,
  "last_run": "2026-06-04T10:04:02+08:00",
  "last_status": "ok (with degraded sources)"
 }
--- a/script/ai_daily_blog_pipeline.py
+++ b/script/ai_daily_blog_pipeline.py
--- a/script/blog_markdown.md
+++ b/script/blog_markdown.md
@@ -0,0 +1,198 @@
 ## 导览
 > > 微软与OpenAI正式分家、Anthropic提交招股书、DeepSeek计划融500亿——AI行业正在从“联盟军”转向“诸侯争霸”。
 ## 模型发布/更新
 **1. Grok Imagine 1.5 预览版发布**
 > Grok Imagine 1.5 预览版即日起在 API 中上线，SpaceXAI 持续发力。[X：@cb_doge ↗](https://x.com/cb_doge/status/2062242490745594085)
 **2. MiniMax M3 1M token 解码加速 15.6 倍**
 > MiniMax M3 在 1M token 下解码加速 15.6 倍，FireworksAI_HQ 提供推理支持。[X：@MiniMax_AI ↗](https://x.com/MiniMax_AI/status/2062316914618388758)
 **3. Miso One 开源语音模型：8B 参数、110ms 延迟、一次语音克隆**
 > Miso One 发布 8B 参数开源语音模型，支持一次语音克隆（短样本），推理延迟 110ms，权重已开源，可自托管，API 即将推出，演示已上线。[X：@kimmonismus ↗](https://x.com/kimmonismus/status/2062210845308780639)
 **4. Ideogram v4.0 发布：2K 分辨率和 JSON 提示支持**
 > Ideogram v4.0 发布，原生 2K 分辨率，文字渲染出色，支持 JSON 提示词，可在 Krea 中体验。[X：@krea_ai ↗](https://x.com/krea_ai/status/2062227837130887567)
 ## 产品与工具
 **5. Meta 面向 WhatsApp Business 的 AI 智能体现已全球上线**
 > Meta 为 WhatsApp Business 推出的 AI 智能体面向全球商家开放，按模型 token 使用量收费。[TechCrunch ↗](https://techcrunch.com/2026/06/03/metas-ai-agent-for-whatsapp-business-is-now-available-globally)
 **6. NousResearch 发布 Hermes Agent 桌面应用公测版**
 > NousResearch 推出 Hermes Agent 桌面应用公测版。[X：@SiliconFlowAI ↗](https://x.com/SiliconFlowAI/status/2062042813852995899)
 **7. xAI Grok 语音模型上线 Vapi 平台**
 > xAI 的 Grok STT 和 TTS 语音模型登陆企业语音 AI 平台 Vapi，可用于构建自定义语音智能体。[X：@xai ↗](https://x.com/xai/status/2062209374039499178)
 **8. Grok 模型登陆 Cloudflare AI Gateway**
 > Grok 模型现已可在 Cloudflare AI Gateway 上试用。[X：@xai ↗](https://x.com/xai/status/2062294202625696081)
 **9. OpenShell v0.0.55 发布：新增 Vertex AI 推理支持**
 > OpenShell v0.0.55 发布，新增 Google Vertex AI 推理支持，改进策略可见性、Podman 检测和 GPU 沙箱行为。[X：@NVIDIAAI ↗](https://x.com/NVIDIAAI/status/2062210034109677665)
 **10. Replit 上线 SEO Agent 助应用被发现**
 > Replit 推出 SEO Agent，扫描应用并提供修复建议，帮助应用在网页和 AI 搜索中被发现。[X：@Replit ↗](https://x.com/Replit/status/2062211976995188871)
 **11. OpenClaw 2026.6.1 发布：新增 Windows 节点与技能工坊**
 > OpenClaw 2026.6.1 发布，新增原生 Windows 节点主机、技能工坊和工作板编排，支持 MiniMax M3。[X：@openclaw ↗](https://x.com/openclaw/status/2062288421406785710)
 **12. Reachy Mini 添加 MCP 工具**
 > Reachy Mini 推出公开 MCP canary Space，支持远程工具调用。[Hugging Face：Blog ↗](https://huggingface.co/blog/adding-mcp-tools-to-reachy-mini)
 **13. 刚刚，Meta Skill 来了**
 > GitHub 热门仓库 OpenSquilla 发布，代表 Meta Skill 新动向。[量子位 ↗](https://www.qbitai.com/2026/06/428335.html)
 ## 开发与工程
 **14. Qwen Cloud 全球 AI 黑客马拉松启动**
 > 首届 Qwen Cloud 全球 AI 黑客马拉松启动，5 大赛道，总奖金超 7 万美元（赛道冠军 1 万美元），Devpost 报名。[X：@alibaba_cloud ↗](https://x.com/alibaba_cloud/status/2062113338994172169)
 **15. 洪水韧性新篇章：Google 开源水文建模框架**
 > Google Research 开源基于 PyTorch 的水文建模框架，采用 Flood Hub 相同架构，允许各国气象部门在本地训练 AI 洪水预报模型。[Google Research：Blog ↗](https://research.google/blog/the-next-chapter-in-flood-resilience-open-sourcing-googles-hydrology-framework)
 **16. 文章：导致 Spark 在 Kubernetes 上 OOM 失败的两个错误配置**
 > 迁移 Spark 到 AKS 后，两个配置交互导致 OOM：spark.kubernetes.local.dirs.tmpfs 使 shuffle spill 改用 RAM 而非磁盘。[InfoQ AI ↗](https://www.infoq.com/articles/spark-oom-kubernetes-misconfigurations/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=AI%2C+ML+%26+Data+Engineering)
 ## 行业与公司
 **17. 微软与 OpenAI 分道扬镳——如今双方准备正面交锋**
 > 微软与 OpenAI 合作关系破裂，进入直接竞争。微软 AI 主管 Mustafa Suleyman 称微软需独立证明能力。[The Verge ↗](https://www.theverge.com/ai-artificial-intelligence/942242/microsoft-build-ai-agents-openai-competition)
 **18. 欧盟公布全面技术主权计划，推动芯片与 AI 自主发展**
 > 欧盟推出技术主权计划，扩大本土半导体、AI 和云计算供应链，减少对美亚依赖。[Bloomberg ↗](https://www.bloomberg.com/news/articles/2026-06-03/europe-unveils-sweeping-tech-sovereignty-plan-to-boost-chips-ai)
 **19. Sensor Tower：OpenAI 旗下 ChatGPT 月活已破 10 亿，史上最快**
 > Sensor Tower 估计 ChatGPT 月活于 2025 年 5 月突破 10 亿，增速史上最快；Claude 月活 5600 万，同比增 640%。[IT之家 ↗](https://www.ithome.com/0/959/083.htm)
 **20. 消息称 DeepSeek 首轮融资拟筹集 500 亿元，腾讯、宁德时代等参投**
 > DeepSeek 首轮拟融资 500 亿元，投后估值 3500-4000 亿元。创始人梁文峰出资 200 亿，腾讯拟投 100 亿，宁德时代 50 亿。[IT之家 ↗](https://www.ithome.com/0/959/249.htm)
 **21. Suno 完成 4 亿美元 D 轮融资**
 > Suno 完成 4 亿美元 D 轮融资，估值 54 亿美元，致力于让更多人体验音乐制作。[X：@suno ↗](https://x.com/suno/status/2062183524887675243)
 **22. 宏利香港与阿里云达成 AI 战略合作**
 > 宏利香港与阿里云建立战略合作，共建负责任 AI 创新框架，加速 AI 部署。[X：@alibaba_cloud ↗](https://x.com/alibaba_cloud/status/2062006591377829922)
 **23. 优步每月 1,500 美元的 AI 使用上限为 AI 工具定价提供参考**
 > 优步将 AI 工具月使用上限设为 1500 美元，为行业 AI 定价提供参考信号。[Simon Willison ↗](https://simonwillison.net/2026/Jun/3/uber-caps-usage)
 **24. 世界模型榜首易主！跨维智能登顶 WorldArena**
 > 跨维智能在 WorldArena 上登顶，成为世界模型新榜首。[量子位 ↗](https://www.qbitai.com/2026/06/428435.html)
 **25. 刚刚，Anthropic 提交了招股书！**
 > Anthropic 已提交招股书，预计最快 Q4 上市。[量子位 ↗](https://www.qbitai.com/2026/06/428407.html)
 ## 论文与研究
 **26. 斯坦福大学法学院研究：人工智能的表现优于法学教授**
 > 斯坦福大学法学院研究显示，AI 表现优于法学教授，该结果在 Hacker News 获 104 个 Points。[law.stanford.edu ↗](https://law.stanford.edu/press/ai-outperforms-law-professors-in-stanford-law-study)
 **27. NVIDIA Research 在 CVPR 2026 发表三篇论文：规模化训练实现抓取、自动驾驶与智能体泛化**
 > NVIDIA Research 在 CVPR 2026 发表三篇论文：零样本抓取模型 GraspGen-X、自动驾驶 LCDrive、具身智能体 NitroGen，均基于大规模训练。[blogs.nvidia.com：Blog ↗](https://blogs.nvidia.com/blog/cvpr-research-grasping-driving-agent-training)
 **28. Anthropic 分析 832 个 AI 恶意账户：中高风险攻击者半年从 33% 跃至 56%**
 > Anthropic 分析 832 个被封恶意账户，67.3% 使用 AI 编写恶意软件，中高风险占比半年内从 33% 升至 56%，传统威胁评估失效。[Anthropic ↗](https://www.anthropic.com/news/AI-enabled-cyber-threats-mitre-attack)
 **29. 微软研究：装瓶厂 AI 从聊天到决策**
 > 微软在中西部装瓶厂试点三个月显示，AI 超越聊天进入决策领域，需应对真实风险和可靠性要求。[X：@MSFTResearch ↗](https://x.com/MSFTResearch/status/2062204914223169635)
 **30. 世界模型的功能分类**
 > World Labs 与李飞飞发文梳理“世界模型”概念，基于 POMDP 框架分类，指出当前所谓世界模型本质是同一循环的不同投影（如渲染器）。[X：@drfeifei ↗](https://x.com/drfeifei/status/2062247238143996275)
 **31. 从看懂世界到做对动作，卧安机器人 OneModel 1.7 用一条「隐式通路」打通了具身智能的关键断层**
 > 卧安机器人 OneModel 1.7 通过隐式通路在潜在空间完成信息传导，打通具身智能关键断层。[量子位 ↗](https://www.qbitai.com/2026/06/428703.html)
 ## 人物与花絮
 **32. 黄仁勋与纳德拉共议智能体 AI 时代**
 > 黄仁勋与纳德拉在台北 MSBuild 同台，展示 NVIDIA 与微软从 Windows 到 AI 工厂的协作。[X：@nvidia ↗](https://x.com/nvidia/status/2062228974273716457)
 **33. Satya Nadella 谈微软 Build 大会主旨演讲**
 > Satya Nadella 在 Microsoft Build 主旨演讲，强调共同构建前沿智能生态系统。[X：@satyanadella ↗](https://x.com/satyanadella/status/2062022060176801826)
 **34. Karpathy 的 llm-wiki 项目获超五千星**
 > @karpathy 的 llm-wiki 项目几周内获 5000+ 星，理念是让 LLM 构建并维护可持续进化的维基知识库。[X：@SiliconFlowAI ↗](https://x.com/SiliconFlowAI/status/2062054848762450324)
 ## 观点与教程
 **35. 智能体工程实战窍门全录**
 > @mvanhorn 分享智能体工程方法论：人主导方向、智能体执行，核心为 plan.md 约束行为，总结 22 条实战技巧及完整工具栈。[X：@shao__meng ↗](https://x.com/shao__meng/status/2061974983094755575)
 **36. Anthropic 用 Claude 赋能自助数据分析**
 > Anthropic 用 Claude 自动化 95% 业务分析查询，准确率约 95%，通过智能体分析栈解决概念-实体歧义等三大错误来源。[Claude：Blog ↗](https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude)
 **37. 超越聊天机器人的直接偏好优化**
 > Dharma-AI 在 Hugging Face 博客发文，探讨直接偏好优化（DPO）在聊天机器人之外的广泛应用。[Hugging Face：Blog ↗](https://huggingface.co/blog/Dharma-AI/direct-preference-optimization-beyond-chatbots)
 **38. 演讲：选择你的 AI 副驾驶：最大化开发效率**
 > Sepehr Khosravi 探讨开发效率工具演变，评估 Cursor 和 Claude Code 等优势，为高级工程师提供可行技巧。[InfoQ AI ↗](https://www.infoq.com/presentations/choosing-ai-copilot/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=AI%2C+ML+%26+Data+Engineering)
 ## 总结
 **强信号**
 - **微软与OpenAl分道扬镳，双方开始正面竞争**
  合作终结后，微软AI主管Mustafa Suleyman称公司必须独立证明能力，这意味着微软将不再依赖OpenAI的模型，而是全力押注自研，OpenAI也失去最大云盟友。
 - **Anthropic提交招股书，预计最快Q4上市**
  这标志着安全派AI公司正式进入资本市场，与OpenAI争夺投资者注意，Claude的月活同比增长640%也为其估值提供了底气。
 - **ChatGPT月活突破10亿，成为史上增长最快的应用**
  Sensor Tower数据显示ChatGPT在2025年5月达到这一里程碑，Claude月活5600万，两家头部消费级AI应用的用户粘性正在拉开差距。
 **中信号**
 - **Miso One发布8B开源语音模型，支持一次语音克隆且延迟仅110ms**
  权重已开放、可自托管，意味着实时语音克隆的门槛从专有API降到了个人部署，可能加速语音交互在开发者中的普及。
 - **欧盟公布全面技术主权计划，推动芯片与AI自主发展**
  计划扩大本土半导体、AI和云计算供应链，目标减少对美亚依赖——这将对全球AI公司的合规、市场准入和数据主权产生实质影响。
 **待验证**
 - **DeepSeek首轮融资拟筹500亿元，腾讯、宁德时代参投**
  投后估值高达3500-4000亿元，但融资消息来源为IT之家，未见官方确认。如此大体量的AI融资在国内市场是否顺利落地，存在不确定性。
 - **跨维智能登顶WorldArena世界模型榜首**
  WorldArena的评测权威性尚未被广泛验证，且“世界模型”概念本身缺乏统一标准，需要看后续是否有独立第三方复现其能力。
--- a/script/run_meta.json
+++ b/script/run_meta.json
@@ -0,0 +1,35 @@
 {
  "date": "2026-06-04",
  "slug": "ai-2026-06-04",
  "blog_url": "https://blog.ephron.ren/posts/ai-2026-06-04",
  "public_ok": true,
  "errors": [
    "橘鸦AI早报(重试): TimeoutError"
  ],
  "aihot_sections": [
    "模型发布/更新",
    "产品发布/更新",
    "行业动态",
    "论文研究",
    "技巧与观点"
  ],
  "raw_item_count": 39,
  "stage0_count": 39,
  "final_item_count": 38,
  "has_juya": false,
  "source_counts": {
    "AI HOT": 32,
    "InfoQ AI": 2,
    "MIT科技评论AI": 0,
    "量子位": 5,
    "橘鸦AI早报": 0
  },
  "featured_titles": [
    "Grok Imagine 1.5 预览版发布",
    "MiniMax M3 1M token 解码加速 15.6 倍",
    "Miso One 开源语音模型：8B 参数、110ms 延迟、一次语音克隆",
    "Ideogram v4.0 发布：2K 分辨率和 JSON 提示支持",
    "Meta 面向 WhatsApp Business 的 AI 智能体现已全球上线",
    "NousResearch 发布 Hermes Agent 桌面应用公测版"
  ]
 }
--- a/skill/SKILL.md
+++ b/skill/SKILL.md
@@ -0,0 +1,127 @@
 ---
 name: ai-daily-report-pipeline
 description: |
  Maintain and operate the AI daily report cron pipeline (ai_daily_blog_pipeline.py).
  Covers: script configuration, LLM prompt tuning, data sources, timeout settings,
  output format, and publishing workflow.
 trigger:
  - AI日报 / AI daily report / daily briefing
  - ai_daily_blog_pipeline.py
  - cron job 76297415d88d
  - ai_morning_out / 橘鸦 / AI HOT
 ---
 # AI Daily Report Pipeline
 Automated daily AI news digest that publishes to `blog.ephron.ren`.
 ## Architecture
 - **Script**: `~/.hermes/scripts/ai_daily_blog_pipeline.py` (~1100 lines)
 - **Output dir**: `~/.hermes/scripts/ai_morning_out/`
 - **Cron job**: `76297415d88d`, schedule `0 10 * * *` (10:00 CST daily)
 - **Delivery**: `origin` (back to the chat that created it)
 - **Mode**: `no_agent: true` (script-only, no LLM wrapper)
 ## Data Sources
 | Source | Type | Notes |
 |--------|------|-------|
 | AI HOT | API (aihot skill) | Primary, category-specific |
 | 橘鸦 AI 早报 | RSS (content:encoded) | Publishes ~09:34. Parsed from RSS `content:encoded` field (no article page fetch). 45s timeout. |
 | InfoQ AI | RSS | `feed.infoq.com/ai-ml-data-eng/` |
 | MIT 科技评论 AI | RSS | `technologyreview.com/topic/.../feed` |
 | 量子位 | RSS | `qbitai.com/feed` |
 ## Processing Pipeline (4-Stage Architecture)
 Stages are designed to maximize script work, minimize LLM calls.
 ### Stage 0: Script Dedup (pure Python)
 - Normalize titles: strip punctuation, lowercase, remove stopwords
 - Remove exact duplicates (title match or Jaccard > 0.85)
 - No LLM involved — deterministic
 ### Stage 1: LLM Semantic Dedup
 - Single LLM call to find semantically equivalent items (e.g. same news from different sources)
 - Input: `{index, title, summary}` for each item
 - Output: `{duplicates: [{keep: 0, remove: [1,2]}, ...]}`
 - Removes less-detailed version of each duplicate pair
 ### Stage 2: Parallel Summary Rewrite + Classify (2 concurrent LLM calls)
 - **Stage 2a**: Rewrite summaries + translate titles to Chinese
  - Brand/model names preserved in English (GPT-5, Codex, etc.)
  - Other title text translated to Chinese
  - Summary: max 120 chars, concise Chinese
  - Output: `{summaries: [{index, title, summary}, ...]}`
 - **Stage 2b**: Classify items into sections
  - Sections: 模型与技术, 产品与工具, 开发与工程, 行业与公司, 研究与发现, 观点与评论
  - Output: `{classifications: [{index, section}, ...]}`
 - Both run in parallel via `concurrent.futures.ThreadPoolExecutor`
 ### Stage 3: LLM Guide Generation
 - Single LLM call for "今日观察" (observation/analysis)
 - Input: all item titles + summaries
 - Output: `{guide: [{type, text}, ...]}` JSON array
 - Types: `theme` (1), `strong` (2-3), `medium` (1-2), `risk` (1-2)
 - NO `advice` type
 ### Stage 4: Script Assemble + Publish (pure Python)
 - Merge Stage 2a output (titles+summaries) with Stage 2b output (sections)
 - Assemble markdown: 导览 → 分类新闻 → 总结
 - Publish via Service API (create → publish → PATCH)
 ## User Preferences (CRITICAL)
 - **NO CURATION / NO SELECTION**: Only filter exact duplicates. ALL non-duplicate items must be preserved. Do NOT use words like "精选" (curated/selected) in output. The user explicitly rejected any editorial filtering beyond deduplication.
 - **No emoji** in the output
 - **No reference numbers** like [1][3] — readers can't see what they point to. Strip all `[N]` from guide text via `clean_guide_text()`.
 - **No "主线判断：" prefix** in 导览 section — strip via regex `r'^主线判断[：:]\s*'` in `clean_guide_text()`.
 - **No advice/suggestions** section — no "开发者应该..." type content. Guide types are: theme, strong, medium, risk ONLY.
 - **Concrete not generic** — avoid vague statements like "行业焦点转向XX". Point to specific events.
 - **Plain language** — no academic/formal tone, use 大白话
 - **Concise** — each guide item 2-3 sentences max
 - **Readable formatting** — summary section uses type labels as headers, then bullet-list format:
  ```
  **强信号**
  - **标题**
    内容...
  ```
 - Guide format: `[{type, text}]` JSON array. Types: `theme` (1), `strong` (2-3), `medium` (1-2), `risk` (1-2). NO `advice` type.
 - Structure: 导览 (blockquote, no prefix) → 新闻 → 总结 (type labels + bullet list, grouped by type)
 - Links must be verified accessible before inclusion
 ## Key Configuration
 - **Cron timeout**: `cron.script_timeout_seconds: 600` (in `~/.hermes/config.yaml`)
 - **LLM urllib timeout**: 600s (in script, `urllib.request.urlopen(req, timeout=600)`)
 - **RSS fetch timeout**: 25s per regular feed. 橘鸦: 45s (GitHub Pages, 262KB RSS).
 - **LLM API**: follows the active Hermes model config by default. Current production path is Sub2API (`~/.hermes/config.yaml` → `model.provider: sub2api`, `model.default: findmini/gpt-5.5`, `model.base_url: http://sub2api.ephron.ren/v1`) with `SUB2API_API_KEY` from `~/.hermes/.env`. Keep API key, base_url, and model from the same provider family; do not mix `SUB2API_API_KEY` with Xiaomi/MiMo `base_url`, or the LLM stages will fail with 401 Unauthorized.
 - **max_items**: 30 in `_prefilter_items` — controls LLM prompt size; 38 items worked fine, 30 is conservative
 ## Pitfalls
 1. **Config file is protected**: `~/.hermes/config.yaml` cannot be edited with `patch` tool. Use `sed -i 's/old/new/' ~/.hermes/config.yaml` via terminal.
 2. **橘鸦 timing**: Publishes ~09:34 CST. Script sleeps 120s if empty. Don't run before 10:00.
 3. **橘鸦 regex bug (fixed 2026-06-04)**: The `block_pattern` regex had `\\s*` (two backslashes in source = literal backslash in regex) before `<code>` instead of `\s*` (one backslash = whitespace class). This caused the regex to never match any 橘鸦 items, silently returning empty results. The `first_real_block` qwen-ID regex was also dead (site migrated away from Qwen IDs). **Fix**: (a) split into `fetch_juya_rss` + `parse_juya`; (b) parse from RSS `content:encoded` eliminating the second HTTP fetch; (c) changed escaped backslash to whitespace class; (d) changed `.*?` to `[^<]*?` to prevent overview section from leaking into matches (the overview `<h2>概览</h2>` has no `<code>#N</code>`, but the lazy `.*?` would cross the h2 boundary to find it).
 4. **橘鸦 timeout**: Now uses 45s timeout (up from 25s) because GitHub Pages can be slow and the RSS feed is ~262KB. Content is parsed from RSS `content:encoded` to avoid a second HTTP request for the article page. Falls back to fetching the article page if `content:encoded` is unavailable.
 5. **MiMo token limit**: With the 4-stage architecture, each LLM call handles a smaller prompt (dedup ~3K, summary ~6K, classify ~3K, guide ~5K). max_items=30 is safe. Old single-call approach needed max_items=18.
 6. **Gateway restart needed**: After config changes, `systemctl --user restart hermes-gateway` is required.
 7. **Timeout tuning (USER IS VERY SENSITIVE)**: User explicitly demands timeouts set to 1.5-2x of theoretical time. Being conservative causes repeated failures and user frustration. If theoretical time is ~80s, set timeout to 600s. Never start low and increment — go generous from the start. User said: "一直超时太影响体验了".
 8. **LLM prompt anti-patterns**: Never instruct LLM to "精选" (curate/select). Never ask for [N] reference numbers. Never include "建议" (advice) section. Never include "主线判断：" prefix in theme text. These all produce unwanted output.
 9. **Title translation**: Stage 2a MUST translate English titles to Chinese. Brand/model names (GPT-5, Codex, Gemini, etc.) are preserved in English. All other title text translated. If titles come back in English, check that the Stage 2a prompt includes explicit title translation instruction and the output format includes `"title"` field.
 10. **patch tool and regex**: The `patch` tool's Escape-drift detection can interfere with multi-backslash regex patterns. For complex regex changes in the pipeline script, use `terminal` with `sed -i` or a Python script that reads/writes the file directly.
 ## Files
 - `run_meta.json` — last run metadata (date, slug, url, errors, source counts)
 - `raw_items.json` — raw fetched items
 - `llm_digest.json` — LLM output
 - `blog_markdown.md` — rendered blog post
 ## References
 - `references/timeout-config.md` — timeout values and tuning rules for all script stages
 - `references/llm-config-auto-follow.md` — how the script auto-follows Hermes model config
 - `references/mimo-api-performance.md` — MiMo API performance characteristics
 - `references/rendering-guide.md` — blog post rendering rules
--- a/skill/references/llm-config-auto-follow.md
+++ b/skill/references/llm-config-auto-follow.md
@@ -0,0 +1,29 @@
 # AI Daily Pipeline — LLM Config Auto-Follow (2026-05-30)
 ## Problem
 The daily report script had hardcoded `XIAOMI_API_KEY` / `XIAOMI_BASE_URL` env vars. When the user switches Hermes' main model provider, the script would still use the old provider unless manually updated.
 ## Solution: `resolve_llm_config(env)`
 Added to `ai_daily_blog_pipeline.py` (replaces hardcoded reads in `llm_call()`):
 ```python
 def resolve_llm_config(env: dict):
    """Read Hermes config to get the active provider's API key, base_url, and model."""
    # 1. Read ~/.hermes/config.yaml → model.provider, model.base_url, model.default
    # 2. Read ~/.hermes/auth.json → credential_pool[provider].source (e.g. "env:XIAOMI_API_KEY")
    # 3. Resolve env var name → actual key from .env
    # 4. Fallback to LLM_API_KEY / XIAOMI_API_KEY if auth.json lookup fails
    return api_key, base_url, model_name
 ```
 ## Config Sources (priority order)
 1. `~/.hermes/config.yaml` → `model.provider`, `model.base_url`, `model.default`
 2. `~/.hermes/auth.json` → `credential_pool[provider][0].source` (format: `env:VAR_NAME`)
 3. `~/.hermes/.env` → actual key value
 4. Legacy fallback: `LLM_API_KEY` / `XIAOMI_API_KEY` / `LLM_BASE_URL` / `LLM_MODEL`
 ## Usage
 When user runs `hermes config set model.provider=minimax`, the daily report script automatically uses MiniMax's API key and endpoint on the next run. No script changes needed.
 ## Pitfall
 The script needs `import yaml` — ensure `PyYAML` is installed. It's available in the Hermes venv but may not be in system Python.
--- a/skill/references/mimo-api-performance.md
+++ b/skill/references/mimo-api-performance.md
@@ -0,0 +1,55 @@
 # MiMo-v2.5-pro API Performance Profile
 Empirically tested on `https://token-plan-sgp.xiaomimimo.com/v1` (2026-05-29).
 ## Latency by Prompt Size
 | Prompt Size | Items | Response Time | Status |
 |-------------|-------|---------------|--------|
 | ~500 chars | 1-2 | 2-4s | ✅ Reliable |
 | ~4,500 chars | 15 | ~73s | ✅ OK |
 | ~7,400 chars | 25 | >120s | ❌ Timeout |
 | ~10,900 chars | 35 | >120s | ❌ Timeout |
 | ~19,000 chars | 65-70 | >150s | ❌ Timeout |
 ## Key Constraints
 - **Max reliable prompt size: ~5K chars / ~18 items** for structured output tasks
 - Output token generation is slow (~50-80 tokens/s for large JSON outputs)
 - Simple prompts (<1K) are fast and reliable (2-4s)
 - Latency is **highly variable** — same prompt can take 73s or timeout at 150s
 - Temperature 0.2 used for structured output consistency
 ## Implications for Cron Jobs
 - **Pre-filter aggressively** before sending to LLM: dedupe + source priority + cap at 18 items
 - **Cron timeout 300s** budget: ~35s data fetch + ~80s LLM = ~115s typical, but retries can push to 250s+
 - Set LLM urllib timeout to **150s** (not 300s — it won't help, just wastes cron budget)
 - **Retry 2x max** (not 3x) to stay within 300s cron budget
 - If LLM consistently times out, check if API is rate-limited (test with simple prompt first)
 ## Workaround: Pre-filter Pattern
 ```python
 def _prefilter_items(raw_items, max_items=18):
    """Dedupe + prioritize before LLM call."""
    seen = set()
    filtered = []
    priority_sources = {'AI HOT': 1, '橘鸦AI早报': 1, 'InfoQ AI': 2, '量子位': 2}
    sorted_items = sorted(raw_items, key=lambda r: priority_sources.get(r.get('source_group', ''), 3))
    for item in sorted_items:
        norm = re.sub(r'[^\w\u4e00-\u9fff]+', '', item['title_raw'].lower())
        if not norm or len(norm) < 3 or norm in seen:
            continue
        seen.add(norm)
        filtered.append(item)
        if len(filtered) >= max_items:
            break
    return filtered
 ```
 ## Alternative Providers (tested same day)
 - **Findmini (gpt-5.4)**: `https://api.findmini.top/gpt/v1` — returned 503
 - **OpenRouter (free models)**: returned 429 rate limit
 - **MiMo small prompts**: consistently 2-4s, reliable for simple tasks
--- a/skill/references/rendering-guide.md
+++ b/skill/references/rendering-guide.md
@@ -0,0 +1,65 @@
 # Rendering & Guide Formatting Reference
 ## `clean_guide_text(text)` function (in `blog_markdown()`)
 Strips unwanted artifacts from LLM-generated guide text:
 ```python
 def clean_guide_text(text):
    # Strip all [N] reference numbers
    text = re.sub(r'\[\d+\]', '', text)
    text = re.sub(r'\[N\]', '', text).strip()
    # Strip "主线判断：" prefix
    text = re.sub(r'^主线判断[：:]\s*', '', text)
    # Clean extra whitespace
    text = re.sub(r'\s+', ' ', text).strip()
    return text
 ```
 ## Summary section rendering
 Type labels map: `{'strong': '强信号', 'medium': '中信号', 'risk': '待验证'}`
 Output format per type group:
 ```
 ## 总结
 **强信号**
 - **标题（从text第一句提取）**
  解释内容...
 - **标题**
  解释内容...
 **中信号**
 - **标题**
  解释内容...
 **待验证**
 - **标题**
  解释内容...
 ```
 Title extraction logic:
 1. Try splitting on `：` or `:` — if prefix < 60 chars, use as title
 2. Otherwise, split on `。！？` and use first sentence as title
 ## Title translation (Stage 2a)
 Titles are translated from English to Chinese in Stage 2a. Rules:
 - Brand names preserved: GPT-5, Codex, Gemini, OpenAI, Meta, etc.
 - Technical terms with no good Chinese equivalent: keep English
 - Everything else: translate to natural Chinese
 - LLM prompt explicitly states: "英文品牌名/模型名保留原样，其余翻译为中文"
 ## LLM prompt for guide (as of 2026-05-30)
 Key instructions to LLM:
 - 不要空泛总结（如"行业焦点转向XX"），要指向具体事件
 - 不要引用编号如[1][3]，读者看不到对应关系
 - 不要建议（"开发者应该..."之类删掉）
 - 每条控制在2-3句话以内
 - 用大白话，不要学术腔
--- a/skill/references/timeout-config.md
+++ b/skill/references/timeout-config.md
@@ -0,0 +1,34 @@
 # Timeout Configuration Reference
 ## Timeout Locations
 | Setting | Location | Current Value | Notes |
 |---------|----------|---------------|-------|
 | Script total timeout | `~/.hermes/config.yaml` → `cron.script_timeout_seconds` | 600s | Max time for entire script execution |
 | LLM urllib timeout | `ai_daily_blog_pipeline.py` → `llm_call()` → `urlopen(timeout=...)` | 600s | Single LLM API call timeout |
 | RSS fetch timeout | `ai_daily_blog_pipeline.py` → `fetch_text()` → `urlopen(timeout=...)` | 25s | Per-RSS-feed fetch |
 | 橘鸦 RSS timeout | `ai_daily_blog_pipeline.py` → `fetch_juya_rss()` → `urlopen(timeout=...)` | 45s | GitHub Pages can be slow; 262KB RSS |
 | 橘鸦 fallback page timeout | `ai_daily_blog_pipeline.py` → `parse_juya()` → `urlopen(timeout=...)` | 45s | Only used if content:encoded unavailable |
 | Service API timeout | `ai_daily_blog_pipeline.py` → `blog_api_request()` → `urlopen(timeout=...)` | 25s | Blog publish API call |
 | 橘鸦 wait timeout | `ai_daily_blog_pipeline.py` → sleep(120) | 120s | Wait if 橘鸦 RSS is empty |
 ## Timeout Tuning Rules
 1. **Always set generously** — user explicitly wants 1.5-2x theoretical time minimum
 2. **MiMo API is slow** for long prompts — 18 items with 600s timeout works; 30+ items times out even at 600s
 3. **Config file is protected** — use `sed -i` via terminal, not `patch` tool
 4. **Gateway restart required** after config changes: `systemctl --user restart hermes-gateway`
 ## Theoretical Timing
 - Script without LLM: ~10-15s (fetch + parse + publish)
 - LLM call (18 items): ~60-120s typically, can spike to 300s+
 - Total theoretical: ~80-150s
 - Recommended timeout: 600s (generous, accounts for API variability)
 ## If Timeout Still Occurs
 1. Check `run_meta.json` → `llm_error` field
 2. If `TimeoutError: The read operation timed out` → LLM API is slow
 3. Check if `max_items` was increased — more items = longer LLM time
 4. Consider reducing `max_items` in `_prefilter_items()` back to 18