本期数据：抓取 16 个源 · 筛选 20 条 · 覆盖 8 个领域

数据源：OpenAI · Google DeepMind · arXiv · Nature · ScienceDaily · New Scientist · Ars Technica · TechCrunch · GitHub · Stack Overflow · NPR · 阮一峰

🔥 头条 #

1. SpaceX 估值飙升至 2.6 万亿美元，短暂超过亚马逊 #

来源：TechCrunch · 领域：商业 📈

SpaceX 的估值自上周五股票开始交易以来增加了 1 万亿美元，在盘中短暂超过亚马逊。这标志着太空科技公司估值的历史性里程碑——一家从未盈利的火箭公司，市值已逼近全球前五。

分析师解读：SpaceX 的估值逻辑已脱离传统航天制造业，更像一家”太空基础设施平台”。Starlink 的经常性收入 + 可重复使用火箭的成本优势 + NASA 合同的现金流，构成了投资者眼中的飞轮效应。但 2.6 万亿的估值意味着市场已定价了至少十年的增长预期，任何发射失败或星链增速放缓都可能引发剧烈回调。

🔗 阅读原文

2. OpenAI 向 SEC 提交保密 S-1，IPO 进程正式启动 #

来源：OpenAI Blog · 领域：AI/商业 💰

OpenAI 确认已向美国证券交易委员会提交了保密版 S-1 注册声明。这是 IPO 进程的第一步，具体上市时间尚未确定。

分析师解读：保密提交意味着 OpenAI 可以在公开披露前与 SEC 多轮沟通财务细节。考虑到其年化收入已超百亿美元、估值传闻达万亿级别，这将是继 Meta 之后科技界最大的 IPO 之一。但 OpenAI 的治理结构（非营利董事会控制营利实体）将是 SEC 审查的焦点，也是投资者的最大不确定性。

🔗 阅读原文

3. 全自主无人机首次杀死人类士兵 #

来源：New Scientist · 领域：军事/AI/伦理 ⚠️

乌克兰国防工业高级官员透露，两年前进行了一次测试：全自主无人机被设定为摧毁指定区域内任何目标，并造成了确认的人员伤亡。这是全自主武器系统首次在实战中导致人类死亡。

分析师解读：这条新闻的意义远超技术层面。它标志着”人在回路中”原则在实战中首次被突破——机器自主做出致命决策。国际人道法对此几乎没有先例可循。联合国关于致命自主武器系统（LAWS）的讨论已持续十年，但一直停留在道德声明阶段。这一事件可能成为推动国际立法的催化剂，也可能被其他国家视为先例而加速部署。

🔗 阅读原文

🤖 AI 前沿 #

4. NVIDIA 开源 Nemotron 3 Ultra：550B 参数混合 Mamba-Transformer #

来源：arXiv (cs.CL) · 领域：AI/学术 🔬

NVIDIA 发布 Nemotron 3 Ultra——550B 总参数、55B 活跃参数的 MoE 混合 Mamba-Attention 模型。预训练 20 万亿 token，支持 100 万 token 上下文，推理吞吐量比同级公开 LLM 高约 6 倍。已开源全部检查点和训练数据。

分析师解读：Mamba 架构的线性复杂度 + MoE 的稀疏激活 = 推理成本的大幅下降。NVIDIA 的算盘很清楚：卖 GPU 不够，还要做模型生态。开源 550B 模型是针对 Meta Llama 和 Google Gemma 的直接竞争——用”最强开源模型”的标签绑定开发者，反哺 GPU 销售。6 倍吞吐量的说法需要在实际部署中验证，但混合架构方向已被业界广泛认可。

🔗 阅读原文

5. OpenAI 推出部署模拟方法，发布前预测模型行为 #

来源：OpenAI Blog · 领域：AI/安全 🛡️

OpenAI 引入”部署模拟”方法，使用真实对话数据在模型发布前预测其行为表现，以提高安全性和评估准确性。

分析师解读：这本质上是用”数字孪生”思路做 AI 安全——在模型接触真实用户前，先用历史数据模拟它的行为边界。考虑到 OpenAI 正在准备 IPO，任何安全事故都会直接影响估值，这套方法的推出时机并非巧合。如果有效，它可能成为行业标配的”发布前安全检查”。

🔗 阅读原文

6. OpenAI 收购 Ona，扩展 Codex 云环境 #

来源：OpenAI Blog · 领域：AI/商业 🏢

OpenAI 计划收购 Ona，为 Codex 提供安全持久的云环境，使长时间运行的 AI Agent 能够跨企业工作流执行。

分析师解读：Agent 需要持久化的运行环境——代码要跑、文件要存、状态要保持。Ona 解决的正是这个基础设施问题。这笔收购说明 OpenAI 把 Codex 从”代码助手”升级为”Agent 平台”的战略意图。长期看，AI Agent 的运行环境可能成为新的云服务品类，与 AWS/Azure 形成交叉竞争。

🔗 阅读原文

7. Anthropic 暂停 Claude Agent SDK 按 token 计费 #

来源：Ars Technica · 领域：AI/行业 📊

Anthropic 原定 6 月 15 日将 Claude Agent SDK 从订阅制改为按 token 计费，但在生效前一天突然暂停。该变更将大幅增加重度用户成本。

分析师解读：这是用户反馈倒逼产品决策的典型案例。按 token 计费在财务上更合理，但对于用 Claude 跑自动化 Agent 的开发者来说，成本可能翻 5-10 倍。暂停说明 Anthropic 在”商业化”和”生态留存”之间选择了后者——在 Agent SDK 市场尚未稳固时，流失开发者比短期收入更重要。但这个决策不会是永久的，他们大概率在重新设计阶梯定价方案。

🔗 阅读原文

8. rsync 的争论：AI 生成代码引发开源社区激烈辩论 #

来源：阮一峰 · 领域：开源/AI 💬

rsync 最新版本 3.4.3 被发现由 Claude 生成，引发开源社区轩然大波。维护者回应称 AI 发现的漏洞大量涌现，精力不足以手动修补，因此转向”AI 写代码 + 人类写测试”模式。

分析师解读：这不只是一场技术争论，而是开源维护模式的拐点。像 rsync 这样几十年历史的核心工具，维护者老龄化是现实——没有年轻的志愿者愿意啃几十年前的 C 代码。AI 生成代码可能是唯一的可持续路径，但”谁来负责任”的问题没有答案。Tridgell 的模式（AI 写代码、人写测试）可能成为模板，但需要配套的审计工具和文化转变。短期内，社区信任裂痕会扩大。

🔗 阅读原文

9. AI 客服漏洞：简单提示词即可破解 Instagram 账户 #

来源：Stack Overflow / 阮一峰 · 领域：AI/安全 🔓

Meta 的 AI 客服存在严重漏洞：攻击者只需发送一段提示词声称邮箱变更，AI 就会修改目标用户的注册邮箱。美国前总统奥巴马的账户就这样被破解。

分析师解读：这是一个经典的”混淆代理”（confused deputy）问题，只是代理变成了 LLM。AI 客服被赋予了修改用户资料的权限，但 LLM 无法可靠地区分”真实用户请求”和”社会工程攻击”。教训很直接：永远不要让 AI 直接操作有安全后果的动作。AI 应该是”建议者”而非”执行者”，最终修改操作必须经过传统认证流程。这个漏洞会影响所有正在部署 AI 客服的公司。

🔗 阅读原文

🔒 安全 #

10. Secure Boot 证书 6 月 24 日到期，Windows/Linux 用户需紧急更新 #

来源：Ars Technica · 领域：安全 ⏰

三个用于验证系统启动固件数字签名的微软证书将于 6 月 24 日过期。未更新的系统可能无法正常启动。

分析师解读：这是 IT 运维的”Y2K 式”事件——影响面极广（几乎所有现代 PC），但只要及时更新就没事。问题在于长尾设备：工控机、医疗设备、ATM 机等不常更新的系统。这些设备一旦无法启动，恢复成本极高。企业 IT 部门应在本周内完成全量扫描和更新。

🔗 阅读原文

11. FIFA 世界杯内部系统漏洞可修改全球电视直播信号 #

来源：TechCrunch · 领域：安全 🏟️

安全研究人员发现 FIFA 在线平台漏洞，可访问多个内部系统，包括一个可能允许她控制每场世界杯比赛电视直播信号的系统。

分析师解读：世界杯正在进行的背景下，这个漏洞的严重性不言而喻。如果被恶意利用，攻击者可以插入虚假内容、中断直播、甚至传播虚假信息。这暴露了大型体育赛事的数字化基础设施安全投入严重不足的问题——转播系统的安全审计往往是赛前几天才做，而非贯穿全年。

🔗 阅读原文

🔬 科学 #

12. Nature：98 量子比特离子阱量子计算机实现全连接 #

来源：Nature · 领域：量子计算 ⚛️

Quantinuum 发布 Helios 量子计算机，基于 QCCD 架构的 98 量子比特离子阱处理器，实现全对全连接，性能超越经典计算能力。

分析师解读：全对全连接是离子阱相对于超导量子比特的核心优势——每个量子比特都能直接与任何其他量子比特交互，无需中间转发。98 量子比特的规模虽不及 IBM 的超导芯片（已超 1000），但离子阱的保真度和连接性使它在特定算法上更有优势。Quantinuum 正在走”精度优先”路线，与 IBM 的”规模优先”路线形成差异化竞争。

🔗 阅读原文

13. 超导突破：纳米级表面设计显著提高超导温度 #

来源：ScienceDaily · 领域：物理 🔋

瑞典研究人员发现，通过在超薄超导材料下方进行纳米级表面雕塑，可使其在更高温度和更强磁场下保持超导状态。

分析师解读：室温超导仍然是材料科学的圣杯，但这条路走得很慢。这项工作的亮点不在于温度提升幅度（可能只有几开尔文），而在于方法论——通过几何工程而非化学掺杂来调控超导性质。如果这个方法可以推广到更多材料体系，它可能打开一条全新的超导工程路径。

🔗 阅读原文

14. 人类可能拥有隐藏的再生能力 #

来源：ScienceDaily · 领域：生物 🧬

科学家通过两阶段治疗，将哺乳动物的愈合反应从疤痕形成转向再生。动物实验中成功恢复了截肢后的骨骼、关节、韧带和肌腱。

分析师解读：如果人类确实保留了再生能力的”开关”，这将彻底改变创伤医学。但从小鼠到人类之间的转化率极低——大多数在小鼠身上有效的再生疗法在临床试验中失败。这项研究的价值更多在于机制发现：理解为什么哺乳动物”选择”了疤痕愈合而非再生，可能比直接尝试再生更有临床意义。

🔗 阅读原文

15. 北极海洋到达生态临界点 #

来源：New Scientist · 领域：环境 🌊

北极海冰消失使更多阳光进入海洋，促进浮游植物生长，但耗尽了关键营养素，可能严重影响食物链上层动物。

分析师解读：这是典型的”级联效应”——海冰减少 → 光照增加 → 浮游植物爆发 → 营养素耗尽 → 食物链断裂。问题在于这种转变可能是不可逆的：一旦北极生态系统重组完成，即使气温回落，也回不到原来的状态。对渔业和原住民社区的影响将是深远的。

🔗 阅读原文

🌍 国际 #

16. 特朗普伊朗协议主导 G7 峰会，重大问题悬而未决 #

来源：NPR News · 领域：国际新闻 🌐

美国-以色列主导的伊朗战争震动了全球经济。G7 峰会上特朗普宣扬与伊朗的临时协议，但霍尔木兹海峡的航运仍未恢复正常。

分析师解读：霍尔木兹海峡承载着全球约 20% 的石油运输。即使达成停火协议，航运保险费率的上升和船东的观望态度意味着全球供应链的恢复有滞后效应。能源价格的不确定性将持续影响通胀预期，可能推迟各国央行的降息计划。

🔗 阅读原文

17. 五角大楼用 AI 写国会报告，150 万人员使用生成式 AI #

来源：Ars Technica · 领域：AI/政策 🏛️

美国国防部首席技术官表示，五角大楼正使用 Google Gemini for Government 工具生成国会要求的年度报告。原本需要 200 小时人工撰写的报告，现在 5 小时即可完成。

分析师解读：用 AI 写政府报告，表面是效率提升，深层是”谁对内容负责”的问题。如果报告中的分析出错（AI 幻觉），导致国会做出错误决策，责任链条如何追溯？更值得关注的是”150 万人员使用”这个数字——意味着美军已在全军范围内部署生成式 AI，这不是试点，而是规模化应用。军用 AI 的治理框架远未跟上部署速度。

🔗 阅读原文

📱 科技产品 #

18. Android 17 推送到 Pixel 手机和手表 #

来源：Ars Technica · 领域：科技 📱

Google 发布 Android 17 和 Wear OS 7，引入新多任务处理功能、家长控制、安全工具和智能手表升级，同时将最新 AI 模型带到设备端。

分析师解读：Android 17 的关键词是”AI 下沉”——将云端 AI 模型压缩后部署到手机端，实现离线推理。这对隐私保护有利（数据不出设备），但也对芯片 NPU 提出了更高要求。Google 选择 Pixel 优先推送的策略，继续用软件差异化来卖硬件。

🔗 阅读原文

19. Google Gemini 智能音箱 6 月 25 日上市，售价 $100 #

来源：Ars Technica · 领域：科技产品 🔊

Google 发布新一代智能音箱，搭载 Gemini，支持更自然的对话交互。售价 $99.99，这是 Google 近六年来首款新智能音箱。

分析师解读：智能音箱市场在 Alexa 疲软后需要一个重新激活的契机。Google 选择 Gemini 驱动而非传统 Assistant，意味着智能音箱从”指令执行器”转向”对话伙伴”。$100 的定价是消费电子的甜点价位，但成功与否取决于 Gemini 在嘈杂家庭环境中的实际表现。

🔗 阅读原文

20. Snap 发布 AR 眼镜 Specs，研发超十年终于面世 #

来源：TechCrunch · 领域：科技产品 👓

Snap 发布了研发超过十年的 AR 眼镜 Specs。这是第六代智能眼镜，首次面向开发者销售，价格不菲。

分析师解读：Snap 的坚持值得尊敬——在 Google Glass 失败、Magic Leap 沉寂的背景下，持续迭代了六代产品。但 AR 眼镜的核心瓶颈不是硬件而是”杀手级应用”：没有让人非戴不可的理由。开发者版的面世意味着 Snap 正在构建生态，但距离消费者普及至少还有 3-5 年。

🔗 阅读原文

📊 本期统计 #

可信度分布：⭐⭐⭐ 源头直供 12 条 · ⭐⭐ 高质量媒体 8 条

本日报基于 RSS 源大全 中验证通过的 RSS 源生成。筛选标准：重要程度 > 领域多样性 > 时效性。

RSS 鏃ユ姤鐢熸垚宸ヤ綔娴?

閫傜敤鍦烘櫙 #

• 鐢ㄦ埛瑕佹眰鐢熸垚 RSS 鏃ユ姤銆佹瘡鏃ヨ祫璁€佷粖鏃ユ柊闂?- 鐢ㄦ埛瑕佹眰浠?RSS 婧愭姄鍙栧苟绛涢€夐噸瑕佹柊闂?- 鐢ㄦ埛瑕佹眰鐢熸垚淇℃伅绠€鎶?

RSS 婧愭竻鍗? #

瀹屾暣婧愭竻鍗曞弬瑙佹枃绔狅細[RSS 婧愬ぇ鍏╙(https://bsheepcoder.github.io/2026/06/17/rss-source-collection/)

瀹為檯浣跨敤鐨勬簮锛堝凡楠岃瘉鍙闂級 #

鎶撳彇绛栫暐 #

鎵归噺鎶撳彇 #

1. 灏嗘墍鏈夋簮鍒嗕负 5-6 鎵癸紝姣忔壒 5-6 涓簮
2. 浣跨敤 webfetch 宸ュ叿骞惰鎶撳彇姣忔壒
3. 瓒呮椂璁剧疆 15 绉?4. 澶辫触鐨勬簮璺宠繃锛屼笉闃诲鍏朵粬婧?

鎶撳彇娴佺▼ #

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

绗?鎵癸細瀛︽湳婧愶紙arXiv x4 + Nature + ScienceDaily锛?绗?鎵癸細AI 瀹樻柟 + 绉戞櫘锛圤penAI + DeepMind + Google AI + New Scientist锛?绗?鎵癸細鎶€鏈獟浣擄紙HN + GitHub + Ars Technica + TechCrunch + Stack Overflow锛?绗?鎵癸細缂栫▼璇█锛圧ust + Go + Python + TypeScript + Kotlin锛?绗?鎵癸細涓枃 + 鏂伴椈 + 瀹夊叏锛堥槷涓€宄?+ OneV's Den + NPR + NHK + BleepingComputer锛?```

## 绛涢€夋爣鍑?
### 绛涢€夌淮搴︼紙鎸夋潈閲嶆帓搴忥級

1. **閲嶈绋嬪害**锛?0%锛夛細鏄惁涓虹獊鐮存€ц繘灞曘€侀噸澶т簨浠躲€佸奖鍝嶅箍娉?2. **棰嗗煙澶氭牱鎬?*锛?0%锛夛細纭繚瑕嗙洊 AI銆佺瀛︺€佸畨鍏ㄣ€佸晢涓氥€佹柊闂荤瓑澶氫釜棰嗗煙
3. **鏃舵晥鎬?*锛?0%锛夛細浼樺厛閫夋嫨 24-48 灏忔椂鍐呯殑鏂伴椈

### 绛涢€夋暟閲?
- 鍥哄畾閫?**20 鏉?*
- 姣忔潯鍖呭惈锛氭爣棰樸€佹潵婧愩€佸垎绫汇€佹憳瑕侊紙2-3 鍙ワ級銆佸師鏂囬摼鎺?
### 鎺掑簭瑙勫垯

鎸夐噸瑕佺▼搴︿粠楂樺埌浣庢帓鍒楋紝涓嶆寜鏃堕棿鎺掑簭銆?
## 鏂囩珷鏍煎紡

### 鏂囦欢鍛藉悕

rss-daily-YYYY-MM-DD.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

### Front-Matter

```yaml
---
title: "RSS 鏃ユ姤 路 YYYY-MM-DD"
date: YYYY-MM-DD 08:00:00
categories:
  - [鎶€鏈? 淇℃伅鑾峰彇]
tags:
  - RSS
  - 鏃ユ姤
  - 淇℃伅鑾峰彇
description: "YYYY骞碝鏈圖鏃?RSS 鏃ユ姤锛屼粠 N 涓彲淇℃簮涓簿閫?20 鏉￠噸瑕佽祫璁紝娑电洊 AI銆佺瀛︺€佸畨鍏ㄣ€佸晢涓氥€佸浗闄呮柊闂荤瓑棰嗗煙锛屾寜閲嶈绋嬪害鎺掑垪銆?
---

姝ｆ枃缁撴瀯 #

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

> 鏈棩鎶ュ熀浜?RSS 婧愬ぇ鍏ㄤ腑楠岃瘉閫氳繃鐨?RSS 婧愯嚜鍔ㄦ姄鍙栫敓鎴愩€?> 鏁版嵁婧愶細鍒楀嚭瀹為檯鎶撳彇鐨勬簮鍚嶇О
> 鍏辨姄鍙?N 涓簮锛岀瓫閫?20 鏉★紝鎸夐噸瑕佺▼搴︽帓鍒椼€?
---

## 1. [鏍囬]

**鏉ユ簮**: xxx | **鍒嗙被**: xxx

鎽樿鍐呭锛?-3 鍙ヨ瘽姒傛嫭鏍稿績淇℃伅锛夈€?
[闃呰鍘熸枃](url)

---

## 2. [鏍囬]
...

---

## 鍏充簬鏈棩鎶?
锛堥檮缁熻琛ㄦ牸锛氶鍩熷垎甯冦€佹潵婧愬垎甯冿級

閮ㄧ讲 #

鐢熸垚鏂囩珷鍚庢墽琛屾爣鍑嗛儴缃叉祦绋嬶細

1

npx hexo clean; if ($?) { npx hexo g }; if ($?) { ... deploy }

娉ㄦ剰浜嬮」 #

• 鎶撳彇閲忓緢澶э紙arXiv 鍗曟簮鍙繑鍥?500KB+锛夛紝webfetch 浼氳鎴柇锛岄渶鍏虫敞鎴柇鍐呭
• 閮ㄥ垎婧愬彲鑳戒复鏃朵笉鍙闂紙缃戠粶/浠ｇ悊锛夛紝璺宠繃鍗冲彲
• 鏃ユ姤鏃ユ湡涓虹敓鎴愭棩鏈熺殑绗簩澶╋紙濡?6 鏈?17 鏃ユ櫄涓婃姄鍙栵紝鐢熸垚 6 鏈?18 鏃ユ棩鎶ワ級
• 涓嶈鍖呭惈閲嶅鏂伴椈锛堝涓簮鎶ラ亾鍚屼竴浜嬩欢鏃跺彧淇濈暀涓€鏉★紝閫夋嫨鍙俊搴︽渶楂樼殑婧愶級
• 鍔犲瘑鏂囩珷涓嶅弬涓庢棩鎶?

为什么需要 RSS #

在算法推荐泛滥的时代，RSS 是唯一让你主动选择信息源的方式。没有算法干预、没有广告插入、没有注意力收割——你订阅什么，就收到什么。

本文所有 RSS 源均经过实际访问验证，标注可访问性（✅ 可访问 / ⚠️ 需代理 / ❌ 不可访问），并按可信度分级。

可信度分级 #

一、学术 / 科研（最值得信） #

二、AI 方向 · 官方 & 一线机构 #

三、技术 / 编程 / 开发者 #

综合技术媒体 #

编程语言官方博客 #

开发者社区 #

四、中文高质量博客 #

更多中文独立博客：访问 chinese-independent-blogs，含数百个带 RSS 的中文博客 OPML 导入包。

五、综合新闻（选订 2-3 个即可） #

新闻类建议少而精，2-3 个足矣。多了只会制造焦虑。

六、播客 RSS（音频内容） #

七、RSSHub 路由（网站不提供 RSS 时） #

很多平台原生不带 RSS，用 RSSHub 桥接。建议自建 RSSHub 实例（docker run -d -p 1200:1200 diygod/rsshub），公共实例不稳定。

完整路由表：https://docs.rsshub.app/

八、安全 / 资讯 #

推荐订阅组合 #

不要贪多。以下是一个合理的起步组合（约 15 个源）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

学术源头（3个）
├── arXiv cs.AI / cs.LG
└── Nature News

AI 官方（3个）
├── OpenAI Blog
├── Google DeepMind
└── Hacker News frontpage

技术媒体（3个）
├── GitHub Blog
├── Ars Technica
└── 阮一峰

编程语言（2个，按你用的语言选）
├── Rust / Go / Python / TypeScript（选1-2）

新闻锚点（1-2个）
├── NPR News
└── BBC World（需代理）

播客（1-2个）
├── Lex Fridman
└── Latent Space

一天信息量约 50-100 条，30 分钟可扫完。

RSS 阅读器推荐 #

信息过滤策略 #

订阅只是第一步，真正的价值在于过滤：

1
2
3
4
5
6
7

RSS 抓取
  ↓
按可信度加权（⭐⭐⭐ 保留正文，⭐⭐ 给摘要，⭐ 只给标题）
  ↓
LLM 去重 + 摘要
  ↓
输出每日信息简报

这个流程可以用 Python + feedparser + LLM API 实现，形成一个个性化的信息聚合器。

什么是 GitHub Pages #

GitHub Pages 是 GitHub 提供的静态网站托管服务。它直接从 GitHub 仓库读取 HTML/CSS/JS 文件，通过 CDN 分发到全球，无需自己搭建服务器。

核心定位：为项目文档、个人博客、开源项目主页提供零成本的静态站点托管。

工作原理 #

请求流程 #

1
2
3
4
5
6
7

用户访问 https://username.github.io/repo/
          ↓
GitHub Pages CDN 节点（全球分布）
          ↓
从仓库的特定分支读取静态文件
          ↓
返回 HTML/CSS/JS 给浏览器

构建方式 #

GitHub Pages 支持两种模式：

1. 直接部署模式（Deploy from a branch）

1
2
3

仓库分支（如 master/main 或 gh-pages）
  ↓ 直接提供文件
GitHub Pages CDN

适用于已经构建好的静态文件（如 Hexo 的 public/ 目录直接推送到仓库）。

2. GitHub Actions 构建模式

1
2
3
4
5

源码分支（如 main）
  ↓ GitHub Actions 自动构建
构建产物
  ↓
GitHub Pages CDN

适用于需要编译的项目（如 Jekyll、Hugo、Next.js 等），GitHub 自动运行构建流程。

域名机制 #

用户站点（username.github.io）是特殊的：

• 仓库名必须与用户名完全匹配
• 访问根域名 https://username.github.io 时直接提供内容
• 每个账户只能有一个用户站点

项目站点的 URL 格式是 https://username.github.io/repo-name/，注意末尾的路径前缀。如果使用 Hexo，需要在 _config.yml 中配置 root: /repo-name/。

配置方法 #

1. 通过分支直接部署 #

最常见的 Hexo 部署方式：

1
2
3
4
5

# _config.yml
deploy:
  type: git
  repo: https://github.com/username/username.github.io.git
  branch: master

执行 hexo deploy 后，public/ 目录的内容会被推送到仓库的 master 分支，GitHub Pages 直接从该分支提供文件。

2. 通过 GitHub Actions 部署 #

在仓库中创建 .github/workflows/pages.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

name: Deploy to GitHub Pages

on:
  push:
    branches: [ main ]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npx hexo generate
      - uses: actions/upload-pages-artifact@v3
        with:
          path: public

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v4

3. 自定义域名 #

在仓库的 Settings → Pages → Custom domain 填入域名，然后：

DNS 配置（二选一）：

1
2
3
4
5
6
7
8

# 方式一：CNAME 记录（推荐）
blog.example.com  CNAME  username.github.io

# 方式二：A 记录（指向 GitHub Pages IP）
blog.example.com  A  185.199.108.153
blog.example.com  A  185.199.109.153
blog.example.com  A  185.199.110.153
blog.example.com  A  185.199.111.153

GitHub 会自动为自定义域名签发 HTTPS 证书（通过 Let’s Encrypt）。

使用限制 #

免费账户 vs 付费账户 #

关键限制：免费账户的私有仓库不能使用 GitHub Pages。 这意味着如果想用加密功能保护源码，必须升级到 GitHub Pro。

流量限制 #

• 每月 100GB 带宽：超过后站点会被暂时禁用，下月自动恢复
• 每小时 10 次构建：频繁推送会触发限制
• 站点大小上限 1GB：包括所有 HTML/CSS/JS/图片文件

对于个人博客来说，100GB/月的带宽绑绑有余。正常访问量（每天几百到几千 PV）不会触及限制。

内容限制 #

GitHub Pages 明确禁止以下用途：

• 商业交易：不能用作在线商店、支付页面
• 内容分发网络（CDN）：不能纯粹作为文件下载服务
• 非法内容：违反 GitHub 服务条款的内容
• 自动化生成的低质量内容：SEO 垃圾站

GitHub Pages 的定位是项目文档和个人博客，不是通用的 Web 托管服务。

技术限制 #

Jekyll 与非 Jekyll #

GitHub Pages 默认使用 Jekyll 构建仓库中的文件。如果使用 Hexo、Hugo 等其他静态生成器，需要在仓库根目录添加一个空的 .nojekyll 文件，告诉 GitHub 不要用 Jekyll 处理。

Hexo 的 hexo-deployer-git 会自动处理这个问题。

私有仓库的 Pages 问题 #

这是用户最常遇到的坑：

1
2
3

公开仓库 + GitHub Pages → ✅ 正常工作
私有仓库 + GitHub Pages + 免费账户 → ❌ 404
私有仓库 + GitHub Pages + GitHub Pro → ✅ 正常工作

如果你把仓库改成私有后发现站点 404，原因就是免费账户不支持私有仓库的 Pages。

解决方案 #

方案一：改回公开

Settings → Danger Zone → Change visibility → Make public

方案二：升级 GitHub Pro

$4/月，支持私有仓库的 Pages，同时获得更多功能（更多 Actions 分钟数、更大存储等）。

方案三：用其他托管服务

• Vercel：免费支持私有仓库部署，自动 HTTPS，全球 CDN
• Netlify：类似 Vercel，免费套餐也很慷慨
• Cloudflare Pages：免费，带宽无限制

这些服务对私有仓库的静态站点部署都是免费的。

与 Hexo 的配合 #

Hexo + GitHub Pages 是最常见的静态博客组合：

1
2
3
4
5

hexo clean && hexo generate && hexo deploy
  ↓
public/ 目录推送到 GitHub 仓库
  ↓
GitHub Pages 自动部署

常见问题 #

1. 部署后页面 404

检查 _config.yml 中的 root 配置：

• 用户站点（username.github.io）：root: /
• 项目站点（username.github.io/blog）：root: /blog/

2. 样式丢失

通常也是 root 配置错误，导致 CSS 路径不对。

3. 自定义域名后 404

仓库中需要有 CNAME 文件，内容为你的域名。Hexo 的 hexo-deployer-git 会自动创建。

4. HTTPS 证书未生效

GitHub 会自动签发证书，但 DNS 传播需要时间，通常等 1-24 小时。

总结 #

GitHub Pages 的核心价值：

• 零成本：公开仓库免费托管静态站点
• 零运维：不需要自己管理服务器、CDN、SSL 证书
• 与 GitHub 生态集成：代码和站点在同一个地方

核心限制：

• 仅支持静态内容：不能运行后端代码
• 私有仓库需要付费：免费账户只能用公开仓库的 Pages
• 流量上限 100GB/月：对个人博客绑绑有余

适用场景：个人博客、项目文档、开源项目主页。不适用：商业网站、需要服务端逻辑的应用、高流量站点。

为什么用 Hexo 做认知管理 #

知识管理的核心痛点不是”存”，而是”找”。传统的笔记软件（Notion、Obsidian、语雀）各自封闭，数据无法被搜索引擎和 AI 直接检索。而 Hexo 作为一个静态博客生成器，天然具备三个优势：

1. 数据即文件 — 所有内容是本地 Markdown，无平台锁定
2. 结构化索引 — search.json 提供机器可读的全文索引
3. 公开可检索 — 部署到 GitHub Pages 后，内容可被 Google 和 AI 搜索引擎索引

这个项目不是”写博客”，而是构建一个个人知识的外化系统：把学过的知识用结构化的方式记录下来，既便于自己检索，也能被 AI 工具消费。

技术栈 #

项目结构 #

1
2
3
4
5
6
7
8
9
10
11
12

blog/
├── _config.yml                # Hexo 主配置（站点信息、URL、部署）
├── _config.butterfly.yml      # 主题配置（导航、侧边栏、评论）
├── scaffolds/post.md          # 文章模板（含 front-matter 骨架）
├── source/
│   ├── _posts/                # 文章 Markdown 源文件
│   ├── about/                 # 关于页
│   ├── categories/            # 分类页
│   ├── tags/                  # 标签页
│   └── img/                   # 图片资源
├── public/                    # 构建产物（hexo g 生成）
└── .deploy_git/               # 部署临时目录（自动生成）

配置原则：主题配置改 _config.butterfly.yml，不改 node_modules/ 里的默认文件。

文章命名规范 #

文件名是 URL slug 的来源，直接决定可检索性。采用 {领域前缀}-{子主题}.md 格式：

规则：

• 全小写，连字符分隔
• 禁止纯数字后缀（Python1.md ✗ → python-intro.md ✓）
• 禁止下划线（AI_History.md ✗ → ai-history.md ✓）
• 子主题描述性强，能从文件名推断内容

Front-Matter 设计 #

每篇文章的 YAML 头部是 AI 和搜索引擎消费的元数据，所有字段必填：

1
2
3
4
5
6
7
8
9
10

---
title: "文章标题"
date: 2026-06-17 12:00:00
categories:
  - [技术, 人工智能]
tags:
  - AI
  - 强化学习
description: "50-150字摘要，会被 search.json 索引，供本地搜索和 AI 检索使用。"
---

设计要点：

• categories 用二级分类 [大类, 子类]，与文件名前缀对齐，分类页据此自动组织
• tags 2-5 个，第一个必须与文件名领域前缀对齐
• description 是最重要的字段 — 被 search.json 全文索引，AI 检索时优先读取。必须 50-150 字，单行不换行，引号成对闭合
• mathjax: true 按需添加（因 per_page: false，需逐文章开启）

内容索引策略 #

系统提供三种检索方式，覆盖不同场景：

策略一：读取源文件（最可靠） #

直接读取 source/_posts/ 下的 Markdown 源文件，数据最新、含完整 front-matter 和原始内容。适合修改单篇已知文章。

策略二：解析 search.json（最轻量） #

1
2
3
4
5
6

{
  "title": "文章标题",
  "url": "/2026/06/17/hexo-cognitive-management/",
  "content": "纯文本内容（去除HTML标签）",
  "tags": ["Hexo", "认知管理"]
}

构建后生成在 public/search.json，含 title、url、content（纯文本）、tags。适合全文搜索和按标签筛选。

策略三：解析 db.json（最完整） #

db.json 是 Hexo 的数据库快照，含 Post（完整元数据 + 原始 Markdown + 渲染 HTML）、Tag、PostTag 三张表，适合需要精确查询或获取渲染后 HTML 的场景。

自动化部署流程 #

修改文章或配置后，执行标准部署流程：

1
2
3

hexo clean          # 清理 public/ 和 db.json
hexo generate       # 重新构建
hexo deploy         # 推送到 GitHub Pages

部署是幂等的 — hexo-deployer-git 会自动清空 .deploy_git/ 目录，复制 public/ 内容，生成提交信息 Site updated: YYYY-MM-DD HH:mm:ss，然后 force push 到远程 master 分支。

GitHub Pages 收到推送后自动构建，1-2 分钟后线上生效。

认知管理的闭环 #

这个系统的价值在于形成闭环：

1
2
3
4

学习 → 记录（Markdown + 规范化 front-matter）
     → 索引（search.json + db.json）
     → 检索（本地搜索 / AI 工具 / 搜索引擎）
     → 复用（找到旧知识，应用到新问题）

传统笔记的问题在于”写了就忘”。这个系统通过结构化命名、强制 description、机器可读索引三个机制，确保写下的知识可被找到、可被 AI 消费、可被搜索引擎收录。

总结 #

这个 Hexo 项目不是传统博客，而是一个面向 AI 时代的个人知识库：

• 文件即数据，无平台锁定
• 命名规范保证 URL 可读性和分类一致性
• description 字段是 AI 检索的关键入口
• search.json 提供机器可读的全文索引
• 一条命令完成构建和部署

核心原则：如果知识不能被找到，就等于没有记录。