-
Notifications
You must be signed in to change notification settings - Fork 0
AI Weekly Optimization Plan v3
评估周期：2026-09-08 ~ 2026-09-10 数据来源：SkillHub 评测报告 4.3 项（可信任度·国内适配性）+ 用户报「GitHub Pages 周报无中文」实测 + gh-pages 部署事故回滚 目标：把「能用」变「可信」，让国内用户在「不翻墙、不依赖本地模型」的前提下也能拿到完整可信的 AI 周报 最新迭代：v3.4.6（中文翻译回填 + 译文源，已合并本文 §5）
不要让用户为「看不到」「看不懂」「抓不到」三个问题承担任何一项。 把每一项都从「运行时运气」改成「数据资产 / 可拉取服务 / 显式口径」。
| 痛点 | 性质 | 旧做法 | 新做法（v3.4.x） |
|---|---|---|---|
| 看不到：周报无中文 | 数据层 | 翻译是生成时刻的「运行时」调用，失败静默 | 三级取值（缓存 → 远程译文源 → Ollama），译文固化进 news.json / 发布可拉取译文源 |
| 看不懂：信通院数字 vs GVR 数字谁信谁 | 可信度层 | 两套数字并列，等同可靠 | 口径路由条（国内优先 / 海外作对照）+ 图注可核实性标记 |
| 抓不到：翻墙才能拿海外新闻 | 网络层 | 假镜像（HTTP 200 但内容无关）混在 URL_REWRITES | 逐镜像 curl 验 body，假镜像全删；RSS 侧 14/14 全通、真正卡的是排行榜 |
| 刷新漂移：每日刷新把历史周报改写成当期 | 部署层 |
generate_site.py --date 不传时默认「当天-7~当天」 |
refresh_deploy.py 显式传 --date（优先 news.json.date_end，兜底文件名日期） |
触发：用户报「AI_News_2026-08-31.html 被每日刷新改成 9/1-9/8 + W37 的 115 条」
改动（4 files, 56+/6-）：
| 文件 | 改动 |
|---|---|
scripts/refresh_deploy.py |
加 _report_date()：优先 news.json.date_end，兜底文件名日期；显式传 --date 给 generate_site.py；日期与文件名不一致时改写输出名 |
SKILL.md frontmatter |
version 3.4.1 → 3.4.2 |
manifest.json |
version 3.4.1 → 3.4.2 |
CHANGELOG.md |
新增 3.4.2 条目 |
| gh-pages | 从 commit 4f84eeb 取回真版 AI_News_2026-08-31.html（112 条）重新部署 |
根因（必须记住）：generate_site.py 的报告周期默认「当天-7~当天」，--date 视为必填。任何「重生成历史周报」场景都必须显式指定 --date，否则每日刷新会把历史周报逐步改写成当期内容。
回滚历史周报的标准动作：
git show <commit>:AI_News_YYYY-MM-DD.html > delivery/<date>.html
python scripts/deploy_ghpages.py --html delivery/<date>.htmlW36 真版在 commit 4f84eeb（112 条）；真 W37 = 115 条，可用「共 N 条」快速辨真伪。
触发：SkillHub 评测报告 4.3 项（可信任度·国内适配性）三项子项
改动（8 files, 351+/32-）：
| 子项 | 改动 | 文件 |
|---|---|---|
| 触发方式（boundary 4.3） | SKILL.md §1.1 加「真实对话级使用示例」+ references/FAQ.md（16 行新增 9 节） |
SKILL.md, references/FAQ.md
|
| 可信任度·国内适配性 A |
清除假镜像：lmarena.org.cn（域名不存在）、aa-cn.mirror.xyz（返回 mirror.xyz 博客平台）、hf-mirror.com/datasets-server（401）全删；修复 ModelScope：旧实现抓 HTML 页面 0%，改官方 openapi/v1/models 后 OK（/api/v1/models 是 404） |
scripts/aiweekly/leaderboard_sources.py, scripts/aiweekly/leaderboard_fetch.py
|
| 告警人话翻译（D） | 拆 scripts/aiweekly/diagnostics.py（95 行）build_user_hints / print_user_hints；规则表驱动；原报错 ble001 noqa → 用户能懂的「这一项榜单抓失败了，已自动回退到上周快照」 |
scripts/aiweekly/diagnostics.py（NEW）, scripts/generate_site.py
|
SKILL.md |
加 §1.1 真实对话 + FAQ + §8.3 路由表 |
SKILL.md（120 行） |
manifest.json |
version 3.4.2 → 3.4.3 | manifest.json |
为什么这件事单独成版本：评测「可信任度·国内适配性」是用户最急切的痛点（用户原话：「我翻不了墙」），三项子项（A 假镜像、B 假新闻、C 数据口径、D 告警）本版本闭环 A 和 D，B/C 在 3.4.4/3.4.5 闭环。
触发：3.4.3 闭环 A/D 后，对 B 项「翻墙能否拿到国外新闻」给出明确答案——能，RSS 侧 14/14 全通；真正卡国内用户的是排行榜（3.4.3 §8.1 已诚实说明）。
改动（5 files, 166+/51-）：
| 真失效源 | 根因 | 修复 |
|---|---|---|
| 36氪 0 条 | URL 缺 www → 36kr.com/feed 返回反爬 HTML（HTTP 200 但 0 条目） |
改 www.36kr.com/feed（实测 30 条，application/rss+xml） |
| 机器之心 0 条 | RSS 已下线，返回「机器之心·数据服务」落地页（3KB HTML） | 替换为雷峰网 AI 科技评论 www.leiphone.com/feed（20 条） |
| VentureBeat 429 | 对自报爬虫 UA compatible; AIWeeklyReport/4.0 限流，3 次稳定 429 |
统一常量 FEED_UA（浏览器 UA），即时 200 |
结构改动：
-
RSS_FEEDS3 元组 → 4 元组加region（cn/global） -
--check-feeds与fetch_all均分区统计 - 新增
FEED_MIRRORS：HF Blog 主源失败回退hf-mirror.com/blog/feed.xml - 新增
fetch_feed_with_mirror()；国内源全挂时显式告警「中文地板失效」 -
references/data_sources.md源表补 region 列 + 「抓取要点」三条
效果：源健康 12/14 → 14/14（国内 5/7 → 7/7）；端到端抓取 119 条；校验 25/25。
踩过的坑（防止重犯）：
-
references/data_sources.md此前已写「机器之心已失效、已从列表移除」，但代码RSS_FEEDS里还留着它——文档与代码不一致。改源时两边都要同步。 - 源返回 200 但 0 条目时，一定要
print(r.text[:400])看 body；光看状态码判断不了（与 3.4.3 假镜像教训同源）。 - 自报爬虫身份的 UA 会被部分站点限流；RSS 阅读器用常规浏览器 UA 是通行做法。
触发：B 项闭环后，对 C 项「国内用户该信国内源还是海外源」给出明确答案——国内优先，海外作对照，且必须显式标注（不要让用户猜）。
关键认知：市场数据是静态快照注入（WebSearch 核实后 --market-data/--cn-market-data 注入），所以国内适配的关键不是「能不能抓到」，而是两套数字该信哪个——不能把信通院数字和 GVR/Crunchbase 标成同等可靠。
改动（8 files, 135+/13-）：
| 项 | 改动 |
|---|---|
| 市场口径路由条 |
aiweekly/market.py::build_market_routing_note(region)：cn → 「当前口径：国内优先，中国口径（信通院/新浪创投Plus/IT桔子）为主；全球口径属海外机构静态快照，仅作趋势对照，国内无法一手核实」；global → 全球为主；未判定 → 两套并列 |
| 图注可核实性标记 | 6 张市场图注：国内源「✅ 国内公开数据，可自行核对」/ 海外源「🌍 海外机构静态快照 · 作对照」（hover 有说明） |
| region 取值复用 |
region 一律复用 leaderboard_data["meta"]["region"]（排行榜已解析的实际值），不自做第二次网络探测 |
| 模板 | 加 [MARKET_ROUTING_NOTE] 占位 + .market-routing CSS（服务端预渲染，禁 JS 可见） |
| SKILL.md §8.3 | 新增口径路由表 + 国内源 vs 国外源对照说明 |
releases/v3.4.5.md |
GitHub Release notes body（NEW） |
坑（防止重犯）：generate_site.py 里 161 行的 region = _detect_region() 在 _health_check() 函数内，main() 里没有该变量 → 直接写 region=region 报 NameError。改用排行榜 meta.region 一行解决（且不增行数，守住 500 行上限：最终 497 行）。
触发：用户报「GitHub Pages 版周报没有中文翻译」。实测推翻"全都没有"的认知——curl 线上 4 期逐个解析 NEWS_DATA：
| 期 | 总条 | 英文条 | 有中文摘要 |
|---|---|---|---|
| 9/07（最新） | 115 | 47 | 47 ✅ |
| 8/31（回滚版） | 112 | 46 | 0 ❌ |
| 8/24 | 91 | 40 | 0 ❌ |
| 8/17 | 108 | 42 | 42 ✅ |
根因：翻译是运行时 best-effort，调本地 Ollama qwen2.5:7b（19.1s/条，CPU 推理），失败路径 except: return None 静默 → 报告照出但英文原文。且不可补救：本地无 8/24、8/31 的 news.json 快照，RSS 仅留 1 周无法回抓重生成。
详细方案见本文 §五（周报中文翻译方案）。
改动（8 files, 537+/31-）：
| 项 | 改动 |
|---|---|
| 三级取值（治本） | 本地缓存 .translate_cache.json → 远程译文源 --translations-url → 本地 Ollama。前两级不依赖本地模型
|
backfill_translations.py（治标） |
外科手术式回填——直接从已发布 HTML 提取 NEWS_DATA，补译后原样写回。不需要 news.json。支持 --check / --dry-run / --no-ollama / --emit-source
|
patch_signal_cards() |
回填数据 ≠ 回填页面——只改 NEWS_DATA 后「本周市场信号」卡仍是英文（.ms-card 是渲染时生成的静态 HTML）；补 .ms-cn 注解同步 |
RemoteTranslationSource |
aiweekly/translate.py 新增；按 URL 匹配 + title_key 标题指纹轻量校验 |
MIN_CJK_TITLE=1 |
修「短标题被误杀」——"Mother tongue"→"母语" (2 字) 阈值从 3 汉字降到 1 |
译文源 translations.json |
175 条 73KB，按 URL 索引 + title_key 校验；发布到 gh-pages https://elisabeth15501.github.io/ai-weekly/translations.json
|
| 修 3 个真 bug |
translate_items 缓存全命中 return 0（日志误导）→ 返回复用条数；stats["translated"] 从不更新；回填不补 .ms-cn
|
deploy_ghpages.py --extra |
随周报一并发布附加文件（如译文源） |
| SKILL.md §8.4 | 新增翻译机制、译文源用法、历史回填命令 |
回填结果（线上已生效）：
| 期 | 英条 | 回填前 | 回填后 | 校验 |
|---|---|---|---|---|
| 8/31 | 46 | 0/0 | 46/46 | 25/25 |
| 8/24 | 40 | 0/0 | 40/40 | 25/25 |
| 9/07 | 47 | 47/46 | 47/47 | 25/25 |
| 8/17 | 42 | 42/41 | 42/41（模型回显英文） | 23/25 |
诚实保留：
- 8/17 排行榜为空（23/25）：该期榜单抓取失败。榜单是实时数据，无法忠实重建历史快照——拿今天的榜冒充 8/17 会误导读者，故不回填，如实保留。
- 8/17 缺 1 个中文标题：qwen2.5:7b 对该条直接回显英文原文（汉字数 0），判失败是正确行为，非 bug。
| 守护 | 阈值 | 当前值 | 触发动作 |
|---|---|---|---|
generate_site.py 主入口 |
≤500 行 | 498 | 加代码前先 wc -l，告警规则表已拆 aiweekly/diagnostics.py
|
aiweekly/*.py 模块 |
≤800 行 | leaderboard=727 / market=683 / translate=476 | 加代码优先拆模块，勿内联 |
validate_report.py |
24/24 全量 | 4 期均通过（23~25/25 仅历史数据限制） | 改任何代码或 insights.json 都重跑 |
insights.json keywords[].note |
≥60% 含「本周」周相关锚点 | — | 通用 note 会被判失败 |
| 裸 except / XSS | 0 | 0 | 写 try/except 必须有具体异常类型 |
拆模块的坑（防止重犯）：把函数迁到新模块并 from new import f 后，必须删原文件里的 def f 旧定义；否则本地定义阴影 import，旧定义若引用已随迁走的模块级常量会 NameError——被 best-effort except 吞成 warning 静默失效（难察觉）。
国内网络可达性（2026-09-02 实测反转）：LMArena / Artificial Analysis / LLM-Stats / HuggingFace 现均可实时直连（fetch_all_leaderboards 默认 live fetch）。旧结论「LMArena/HF 地理不可达 / SPA 解析器永远 0 行」已过时——现 generate_site.py 不传 --ranking-json 即出实时榜。
排行榜实时化机制（2026-09-02 落地）：scripts/refresh_deploy.py（live fetch → deploy_ghpages → git-credential-wincred 取 PAT 推 gh-pages）+ 每日 09:00 自动化 b318cad6。固定 W36 新闻不变、仅榜随 live fetch 刷新。
| # | Bug | 触发 | 修复 |
|---|---|---|---|
| 1 |
refresh_deploy.py 未传 --date 导致历史周报被改写 |
9/8 用户报「8/31 周报内容变了」 |
fbd1ee8 加 _report_date() 显式传参 |
| 2 |
URL_REWRITES 含 lmarena.org.cn（域名不存在）+ aa-cn.mirror.xyz（返 mirror.xyz 博客平台） |
3.4.3 假镜像清理 |
3b1392c 全删；hf-mirror.com/datasets-server（401）亦删 |
| 3 | 36氪 36kr.com/feed 返反爬页（200 但 0 条目） |
3.4.4 RSS 体检 |
0f001fd 加 www
|
| 4 | 机器之心 RSS 已下线 | 3.4.4 RSS 体检 |
0f001fd 换雷峰网 |
| 5 | VentureBeat 对自报爬虫 UA 返 429 | 3.4.4 RSS 体检 |
0f001fd 统一浏览器 UA FEED_UA
|
| 6 | ModelScope 旧实现（抓 HTML 页）返 0% | 3.4.3 国内榜源修复 |
3b1392c 改 openapi/v1/models
|
| 7 |
_ollama_translate 短标题阈值 3 汉字误杀「"Mother tongue"→"母语"」 |
3.4.6 翻译回填 |
181945c 加 MIN_CJK_TITLE=1
|
| 8 |
translate_items 缓存全命中 return 0（日志误导） |
3.4.6 翻译回填 |
181945c 改返回复用条数 |
| 9 |
Translator.stats["translated"] 从不更新 |
3.4.6 翻译回填 |
181945c 加 n_done += 1
|
| 10 | 回填不补 .ms-cn 信号卡 → 校验失败 |
3.4.6 翻译回填 |
181945c 加 patch_signal_cards()
|
| 11 | 译文源 src_hash 基于已归一化 summary，命中率仅 32% |
3.4.6 翻译回填 |
181945c 改 URL + title_key 校验 → 100% |
本节是 v3.4.6 的核心设计文档，原本是单独方案
周报中文翻译方案.md，本次合并到 v3 wiki。
把线上 4 期全部拉下来逐条解析 NEWS_DATA：
| 期次 | 总条 | 英文条 | 有中文摘要 | 有中文标题 | 状态 |
|---|---|---|---|---|---|
| 9/07（最新） | 115 | 47 | 47 | 46 | ✅ 完整 |
| 8/31 | 112 | 46 | 0 | 0 | ❌ 全无 |
| 8/24 | 91 | 40 | 0 | 0 | ❌ 全无 |
| 8/17 | 108 | 42 | 42 | 41 | ✅ 完整 |
9/07 和 8/17 是完整的，8/31 和 8/24 全裸。
而且 9/07 的中文在页面上是正常渲染的——英文条目 lang='en' 时，中文译文作主标题、英文原文作小字副标题，摘要前还有「中文」徽章。所以不是前端 bug，是数据层那两期根本没翻译。
8/31 特别说明：它是 9/8 那次事故回滚回来的版本（从 commit
4f84eeb取回）。原始那期生成时就没翻上译文，回滚把"没译文"这个状态也一起带回来了。
翻译链路本身是好的，问题在它太依赖生成那一刻的现场条件：
生成报告 → 调本地 Ollama(qwen2.5:7b) 逐条翻译 → 写入 cn_summary/cn_title
↑
这一步失败 = 静默跳过，报告保留英文，不留痕
实测关键数据：
- 单条翻译 19.1 秒（CPU 推理，无独显），每条目要翻 summary + title 两次
- 47 条 × 2 次 ÷ 3 并发 ≈ 10 分钟；新条目多时更久
- 失败路径
except: return None—— 静默，报告照样生成，看不出少了什么
三种情况下会掉中文：
| 场景 | 后果 |
|---|---|
| 生成时 Ollama 没运行（电脑刚开机/服务挂了） | 全部英文 |
| Ollama 在但单条超时（45s 上限，CPU 忙时很常见） | 部分英文 |
| 缓存未命中 + Ollama 不可用 | 全部英文 |
并且不可补救：历史期一旦生成时没翻上，就永久是英文——因为 RSS 只保留约 1 周，本地没有 8/24、8/31 的 news.json 快照（只有 w30/w31/w32），无法重新生成。
.translate_cache.json 里躺着 189 条已翻译的高质量译文，但这个文件没有提交进 git（.gitignore 没排除它，只是从来没 add 过）。
意味着：换台机器 / 重装系统 / 清理工作区 → 189 条译文全部蒸发，全部要重跑 Ollama（189 × 19s ÷ 3 ≈ 20 分钟）。
| # | 动作 | 改什么 | 收益 |
|---|---|---|---|
| 1.1 | 译文缓存入库 |
.translate_cache.json 提交进 git |
189 条译文变版本资产，换机不丢，新机器开箱即有中文 |
| 1.2 | 译文固化进 news.json |
fetch_ai_news.py --translate-en 时把 cn_summary/cn_title 写进 news.json 落盘
|
生成阶段变只读不译，彻底不依赖 Ollama；一次翻译永久有效 |
| 1.3 | 翻译前置到周一生成 | 翻译是慢活（10~30 分钟），放在周一生成时做一次；每日刷新只读缓存不重译 | 每日刷新从 10 分钟降到几秒，且不会因为刷新时 Ollama 不在而丢中文 |
1.2 是关键：现在译文只活在"生成那一刻的内存里"，news.json 里完全没有中文字段（字段只有 title/summary/url/source/publishedAt/category/score）。写进 news.json 后，译文就跟着数据走，还能随 Pages 的"往周数据源"一起发布出去。
v3.4.6 已落地 1.1（部分）+ 远程译文源 1.4：
-
translations.json远程译文源（175 条 73KB）发布到 gh-pages，按 URL + title_key 索引 - 翻译三级取值：本地缓存 → 远程译文源 → Ollama（前两级不依赖本地模型）
- 没本地模型的用户用
--translations-url https://elisabeth15501.github.io/ai-weekly/translations.json即可拿到中文，实测命中率 100% - 1.2 / 1.3 待下个周期（v3.5.x）治理
新增 scripts/backfill_translations.py：直接从 HTML 提取 NEWS_DATA → 补译 → 写回 HTML → 重新部署。
不需要 news.json（本来就没有），属于外科手术式回填。
风险可控：只改 NEWS_DATA 这一个 JSON 块，不动其他结构，回填前后跑 validate_report.py 对比（目标 25/25）。
坑 1：回填数据 ≠ 回填页面
只改 NEWS_DATA 后，「本周市场信号」卡（.ms-card，渲染时生成的静态 HTML）仍是英文 → validate_report.py 的 signals_cn 检查失败（8/31 掉到 24/25）。补 patch_signal_cards() 在 ms-title 的 </a> 后插 .ms-cn 才回到 25/25。
坑 2：译文源 src_hash 对不上（命中率仅 32%）
译文源的 src_hash 基于 HTML 里已归一化的 summary（去掉 "New York Times:" 前缀等），而生成时查缓存用的是 news.json 的原始 summary —— 两者几乎必然不等。远程源改用 URL 匹配 + title_key 标题指纹轻量校验 → 命中率 32% → 100%。
（本地缓存仍用严格 src_hash，本机正确性与远程宽松匹配分开处理）
| # | 动作 | 说明 | 状态 |
|---|---|---|---|
| 3.1 | 修日志误导 |
translate_items 缓存全命中时 return 0，导致"明明翻了 47 条却打印 0" |
✅ v3.4.6 修复 |
| 3.2 | 漏翻告警 | 生成结束时若"英文条目无中文"占比超阈值，明确打印告警 | 🟡 待做 |
| 3.3 | 前端诚实标注 | 未翻译的英文条目显示"未翻译"标记 | 🟡 可选 |
| 3.4 | 修复短标题误杀 |
_ollama_translate 固定阈值 3 汉字，"Mother tongue"→"母语"(2字) 判失败 |
✅ v3.4.6 加 MIN_CJK_TITLE=1
|
第 2 层（回填两期） → 立刻可见，17 分钟 ✅ v3.4.6
远程译文源 → 无本地模型用户也能拿中文 ✅ v3.4.6
第 3.1 修日志误导 → 一行代码，立刻止血 ✅ v3.4.6
第 3.4 短标题误杀 → MIN_CJK_TITLE=1 ✅ v3.4.6
第 1.1（缓存入库） → 189 条译文变版本资产 🟡 v3.5.x
第 1.2 + 1.3 → 治本，下次生成起永久免疫 🟡 v3.5.x
第 3.2（漏翻告警） → 收尾 🟡 待评估
| 方案 | 为什么不推荐 |
|---|---|
| 换云端翻译 API | 违背"自治优先、可选增强"原则；涉及第三方 API 合规（要注明、要授权）；你本身成本敏感、已部署本地 Ollama |
| 在 CI 里翻译 | GitHub Actions 是 Linux runner，装不了你本地的 Ollama 模型；且 CI 路径（mirror.yml）目前已停用（if: false） |
| 重抓历史新闻重新生成 | RSS 只保留约 1 周，8/24、8/31 抓不回来，做不到 |
| 等待本地模型稳定 | qwen2.5:7b 在 CPU 推理下 19s/条，且历史期数据已经回不来——任何"等模型快了"都是伪解 |
| 项 | 值 |
|---|---|
| 翻译模型 | 本地 Ollama qwen2.5:7b（已部署，当前在线） |
| 单条耗时 | 19.1s（CPU 推理，无独显） |
| 译文缓存 | 189 条（.translate_cache.json，未入库，1.5.x 待治本） |
| 远程译文源 | 175 条 73KB（translations.json on gh-pages，URL + title_key 索引） |
| 翻译三级取值 | 1) 本地缓存 → 2) 远程译文源 → 3) Ollama |
| 每日刷新 |
refresh_deploy.py，走默认开启翻译（但三级取值先查远程译文源） |
| CI 路径 |
build_pages_site.py 明写不翻译，但 mirror.yml 已停用，不影响 Pages |
| Pages 来源 | 本地 deploy_ghpages.py 推 gh-pages 分支（不是 CI） |
| 项 | 命令 / 验证 | 通过标准 |
|---|---|---|
| 模块行数硬守护 | wc -l scripts/*.py scripts/aiweekly/*.py |
generate_site.py ≤500；其余模块 ≤800 |
| 校验器全量 | python scripts/validate_report.py --html delivery/AI_News_YYYY-MM-DD.html |
24/24（或 25/25，回填期允许 23/25 因历史数据限制） |
| GitHub Release | gh release list --repo Elisabeth15501/ai-weekly --limit 5 |
新版本标 Latest |
| SkillHub | skillhub skill ai-weekly |
最新版本号一致 |
| gh-pages artifacts | curl -sI https://elisabeth15501.github.io/ai-weekly/... |
HTTP 200 |
| 译文源命中率 | python scripts/backfill_translations.py --check --html <file> |
0 untranslated |
回滚历史周报（某期生成时出问题）：
# 1. 找真版 commit
git log --oneline --all -- AI_News_YYYY-MM-DD.html
# 2. 取回真版
git show <commit>:AI_News_YYYY-MM-DD.html > delivery/<date>.html
# 3. 重新部署
python scripts/deploy_ghpages.py --html delivery/<date>.html回滚 GitHub Release（不要删除，改 yank + 标 pre-release）：
gh release edit vX.Y.Z --repo Elisabeth15501/ai-weekly --prerelease
gh release create vX.Y.Z-fix --target <prev-commit> --notes "..."回滚 SkillHub 版本：SkillHub 不支持版本回退，只能发新版覆盖。建议新版 changelog 开头明示「回滚 vX.Y.Z，原因：...」。
- 立即停止
refresh_deploy.py自动化 -
git log --oneline --all -- AI_News_<date>.html找真版 -
git show <commit>:AI_News_<date>.html > delivery/<date>.html取回 -
python scripts/deploy_ghpages.py --html delivery/<date>.html --extra delivery/translations.json -
curl -sI验证线上 - 修复
_report_date()之类的根因 - 新版本（commit + tag + Release + SkillHub publish）走完整发布链路
SkillHub 评测报告 4.3 项（可信任度·国内适配性）三个子项在 3 个版本里闭环——3.4.3 (A/D)、3.4.4 (B)、3.4.5 (C)。每项都是用户最急切的痛点，且每项都给出了诚实答案（不是粉饰）：
- 假镜像：HTTP 200 不够，必须 curl body 验证
- 国内榜源：旧判断过时，实测 33 次才能给真实命中率
- 市场数据：不是「能不能抓」而是「该信哪套」
经验：每个评测项要给出三层答案——发生了什么（事实）、为什么（根因）、接下来怎么办（治本 vs 治标 vs 兜底）。粉饰评测项会让用户在真实场景里失望。
本周期最重要的认知升级：把 运行时调用 升级为 数据资产。
- 周报中文：运行时翻译 → 译文固化进 news.json + 远程译文源
- 市场数据：运行时 WebSearch → 静态快照 + 口径路由
- 排行榜：运行时抓取 → live fetch + 快照兜底 + 显式 region
经验：任何「慢 / 贵 / 不可重」的操作都应当问一句「这次结果是数据还是缓存」——是数据就入库，是缓存就显式区分。
只改 NEWS_DATA 后，「本周市场信号」卡仍是英文——因为该卡是渲染时生成的静态 HTML，不在 NEWS_DATA 这个 JSON 块里。任何服务端预渲染的区块都要单独 patch。
经验：外科手术式回填时，先 grep HTML 看哪些区块是「数据 JSON」哪些是「预渲染 HTML」，对每个区块单独处理；不要假设「改了 JSON 就完事」。
译文源的 src_hash 用 HTML 里已归一化的 summary 计算，与 news.json 原始 summary 不等——远程源命中仅 32%。改用 URL + title_key 轻量校验后 100%。但本地缓存仍用严格 src_hash。
经验：跨机器/跨时间的数据校验，永远会有归一化差异。策略是「本地严格、远程宽松」——本机正确性优先（避免错译），远程命中率优先（避免漏译）。两者不混用。
9/8 的 429 限流就是因为我 commit + push 了 v3.4.6，但没打 tag / Release / SkillHub publish。本次已把完整发布链路沉淀到 skillhub-publish skill：
git tag -a vX.Y.Z && git push origin vX.Y.Z # 1. tag
gh release create vX.Y.Z --notes-file ... # 2. GitHub Release
skillhub publish $TMP --version X.Y.Z # 3. SkillHub经验：把发布步骤顺序化 + 脚本化，让任何截断（429/超时/session 中断）都能从最近一步续上，而不是重新发明轮子。
按 P0/P1/P2 排序：
| 优先级 | 项 | 来源 |
|---|---|---|
| P0 | 译文固化进 news.json（治本） | §5.4 #1.2 |
| P0 | 译文缓存 .translate_cache.json 入库 |
§5.4 #1.1 |
| P0 | 翻译前置到周一生成 | §5.4 #1.3 |
| P1 | M3：YoY / 预测诚实度 / 市场数据校验 | 旧优化方案第九章 |
| P1 | 钉钉 Webhook 推送（加签） | 旧优化方案 |
| P2 | 漏翻告警（前端可见） | §5.4 #3.2 |
| P2 | 排行榜开放权重 / 学术榜单 | 旧优化方案 |
| 版本 | 日期 | commit | 主题 |
|---|---|---|---|
| v3.4.2 | 2026-09-08 | fbd1ee8 |
P0：修复 refresh_deploy 周次漂移 + 回滚 8/31 周报 |
| v3.4.3 | 2026-09-09 | 3b1392c |
评测对标：触发方式 / 假镜像 / 告警 |
| v3.4.4 | 2026-09-10 | 0f001fd |
RSS 源可达性体检（修 36氪/机器之心/VentureBeat） |
| v3.4.5 | 2026-09-10 | a141c3a |
市场数据口径路由（国内优先） |
| v3.4.6 | 2026-09-10 | 181945c |
周报中文翻译回填 + 远程译文源 |
总改动（v3.4.1 → v3.4.5，含 v3.4.6）：33 files, 1245 insertions, 133 deletions（合并各 commit 统计去重后）
- AI Weekly Optimization Plan — v1（v1.0→v3.3.1，市场板块/排行榜/工程债/跨Agent）
- AI Weekly SkillHub Optimization Plan v2 — v2（v3.3.1→v3.4.0，SkillHub 5 维度评测）
- Data Sources — 信息来源治理规则
- AI Weekly Adversarial Review / AI Weekly Adversarial Review 2026-09-02 — 对抗式审查
- GitHub Release: https://github.com/Elisabeth15501/ai-weekly/releases
- GitHub Pages: https://elisabeth15501.github.io/ai-weekly/
- SkillHub: skillId=154758