YCX's Blog

F12 抓包发现「视频伪装成图片」，以及 .ts 文件和 BOM 到底是什么

Wed, 14 Oct 2026 00:00:00 GMT

用 Quetta 逛某个站的时候，遇到一件怪事。

页面上没有弹出下载按钮。 但视频确实在播。

于是我做了所有技术人都会做的那件事：F12 → Network。

然后我看到了一个很有意思的东西。

一、Network 面板里滚动的全是「图片」

<div class="mermaid"> flowchart TD A["打开页面播放视频"] --> B["F12 → Network 面板"] B --> C{"观察请求"} C --> D["大量 .jpg 请求<br/>随播放进度不断新增"] C --> E["没有任何 .mp4 / .m3u8 请求"] D --> F["视频明明在动<br/>但网络里全是图片？"] E --> G["视频是逐段加载的<br/>不是一次性一个文件"] F --> H["推断：服务端把视频分片<br/>伪装成了图片"] </div>

现象描述一下：播放过程中，Network 面板持续刷出大量 .jpg 请求，一个接一个；而列表里找不到任何 .mp4 或 .m3u8。

但视频确实在流畅播放。

这个矛盾只有一个解释：

视频不是以"视频"的形式传输的，而是被切成了很多小段，每一段以"图片"的名义加载。

再一深想就不对了 —— 一段视频帧，大小通常几十 KB 到几百 KB。CDN 上"图片"是极其便宜的资源类型（很多 CDN 对图片免流量费、有图片优化/尺寸变体、有独立的缓存规则）。把视频伪装成图片走，等于白嫖了图片托管的带宽和缓存。

这个思路和推理，问了下 AI，印证了：确实是这么干的。

二、动手：改后缀 + 补 BOM

知道原理之后操作就很简单了。

下载 F12 里抓到的那个"图片"，然后：

原始文件：segment-000123.ts      （内容其实是 MPEG-TS 分片）
改名  →：segment-000123.jpg
补头  →：文件开头插入 FF D8 FF
结果  →：能被当成 JPEG 处理

Windows 上的具体做法（PowerShell）：

# 读原始字节
$ts  = [IO.File]::ReadAllBytes("segment-000123.ts")

# JPEG 的 SOI（Start Of Image）标记：FF D8 FF
$bom = [byte[]](0xFF, 0xD8, 0xFF)

# 前面拼上 BOM
$jpg = New-Object byte[] ($bom.Length + $ts.Length)
[Array]::Copy($bom, 0, $jpg, 0, $bom.Length)
[Array]::Copy($ts,  0, $jpg, $bom.Length, $ts.Length)

[IO.File]::WriteAllBytes("segment-000123.jpg", $jpg)

改名 + 改文件头，搞定。

三、`.ts` 到底是个什么文件

.ts 这个后缀有点误导人 —— 它不是 TypeScript。

在这个上下文里，它指的是 MPEG-2 Transport Stream（MPEG-2 传送流），也叫 M2TS。这是直播和流媒体领域的标准容器格式。

它的核心特征：固定长度包 + 同步字节

┌──────────┬──────────────────────────────────────┬──────────┐
│ 0x47     │  184 字节负载                          │ 0x47     │
│ 同步字节  │  （音频/视频/PES/PSI 数据）             │ 同步字节  │
└──────────┴──────────────────────────────────────┴──────────┘
      一个包 = 188 字节，且每个包的第一个字节都是 0x47

0x47（十进制 71）叫做同步字节（sync byte），它是 MPEG-TS 最显著的特征。

设计成"每 188 字节重复一个同步字节"是有明确目的的：

抗错误 / 快速重同步。 广播信号丢了一部分，接收端不用从头解析，只要扫到下一个 0x47 就能重新对齐 —— 这是"打一个同步标记"，和硬盘扇区的同步区、CD 的同步信号是同一个思路。
恒定码率、可交织。 多路音频和视频可以交织在同一条流里，接收端按包头解复用。
不依赖文件可寻址。 广播流不能 seek，所以设计上就是"从头顺序读"。

流媒体里它在哪儿

HLS（HTTP Live Streaming）的经典做法就是把一段视频切成 10 秒左右的小块，每块一个 .ts 文件，播放器按顺序拉：

playlist.m3u8
  ├── seg001.ts   0s - 10s
  ├── seg002.ts   10s - 20s
  ├── seg003.ts   20s - 30s
  └── ...

（DASH 协议现在更多用 fMP4，但 HLS + .ts 依然是兼容性最广的方案。）

所以"播放过程中不断产生新请求"这个特征，本质上就是分片流媒体。 它跟"伪装成图片"没有必然关系 —— 分片是正常行为，伪装是额外加的一层。

四、BOM 是什么：先说狭义，再说广义

狭义：BOM = Byte Order Mark

BOM 最原始的含义是字节序标记，用来告诉程序"这个文本文件是用哪种编码写的"：

编码	文件开头的 BOM
UTF-8	`EF BB BF`
UTF-16 LE	`FF FE`
UTF-16 BE	`FE FF`
UTF-32 LE	`FF FE 00 00`

有了它，一个程序扫一眼开头三个字节就知道后面该怎么解码字节流，而不需要靠猜。

广义：BOM = 文件魔数（magic number / 文件签名）

在文件类型识别里，这个概念被泛化了 —— 靠开头几个字节判断这是什么格式，这在技术圈也被叫作 BOM。

常见的一些：

类型	开头字节（十六进制）
JPEG	`FF D8 FF`
PNG	`89 50 4E 47 0D 0A 1A 0A`
GIF	`47 49 46 38`（就是 ASCII 的 "GIF8"）
PDF	`25 50 44 46`（"%PDF"）
ZIP	`50 4B 03 04`（"PK\x03\x04"）
MPEG-TS	`47`（每 188 字节一个）

JPEG 的 FF D8 FF 里：

FF D8 是 SOI（Start Of Image） 标记
后面的 FF 是下一个标记的第一个字节。JPEG 的结构是"一串标记"，每个标记都以 FF 开头、FF 结尾。典型的 JPEG 紧接着是 APP0/JFIF 段：

FF D8                     ← SOI
FF E0 00 10 4A 46 49 46 00   ← APP0 / JFIF 标识
01 01 00                  ← 版本、密度单位
00 01 00 01               ← X/Y 密度
00 00                     ← 缩略图（无）
...                       ← 后续帧数据
FF D9                     ← EOI (End Of Image)

五、这招究竟骗过了谁 —— 一个需要诚实拆开的部分

这里有个特别容易想错的地方，我第一次也搞反了。

浏览器处理资源，看的是 HTTP 响应头 Content-Type，不是文件后缀，也不是文件头。

服务端返回 Content-Type: image/jpeg，浏览器就把它当图片渲染，哪怕内容其实是 TS 流。

所以在浏览器里，改后缀 + 改文件头本身不会改变任何行为 —— 决定行为的是服务器返回的头。

那为什么这招有用？真正生效的地方是：

环节	谁在看什么	这招有没有用
浏览器渲染资源	`Content-Type` 响应头	❌ 没用
站点的防下载逻辑	URL 路径的后缀	✅ 有用
CDN / 静态服务的类型分类	后缀 + 配置规则	✅ 有用
本地工具的文件类型识别	文件头魔数	✅ 有用
真正的图片解码器	JPEG 段结构	❌ 解不出画面

:::warning 最后一行是最重要的：加上 FF D8 FF 之后，它骗过的是"识别环节"，不是"解码环节"。

真正的图片解码器在读完 SOI 之后，会去找下一个合法标记（FF C0 帧头、FF E0 APP0 等），结果读到的是 47 开头的 TS 包 —— 解析直接失败。所以它不是一个"能显示的图片"，它只是一个"被认为是图片的文件"。 :::

那它到底解决了什么问题？通常是这两种：

① 绕开站点自己的防下载检查。 很多站点的"禁止下载"逻辑很朴素：拦截 URL 里出现 /video/、/media/、.mp4 的请求，或者对已知播放器域名做限制。你改成 .jpg，它的规则就不匹配了。

② 让文件能通过"按扩展名分类"的流程。 比如上传到某个只接受图片的图床/网盘、或者粘贴进某个只认图片的地方。

:::caution 顺便说清楚一件事：改文件头并不会让你"免费把视频存到图床上"。如果你上传的是完整的视频内容，图床不会因为前三个字节是 JPEG 就把它压缩、转码、或者长期保留 —— 多数图床会做内容检测。要真想在图床上传，那叫滥用，而且大部分服务条款明确禁止。 :::

那 Quetta 的下载按钮为什么没弹

Quetta 的下载器是识别到了才弹按钮的（它支持 MP4 / WebM / M3U8 / HLS 这些格式）。伪装成图片的分片不在它的识别范围内，所以没有弹出。这不是 bug，是它没认出来。

顺便说一个我在用的时候观察到的版本差异：

Quetta 在 官网（quetta.net）提供的安装包 里可以下载 YouTube 视频，Google Play 商店版本不行。

同款应用、不同分发渠道、功能不同 —— 这在移动端很常见（渠道审核、功能分渠道灰度、区域策略都可能造成差异）。我没有查到官方对这个差异的明确说明，所以这里只记录我实测到的现象。官网版拿得到 Play 版拿不到的功能，Play 版用户可以考虑从官网获取。

六、Quetta 本身值在哪

抛开这段小插曲，Quetta 这个浏览器我是真在用：

能力	说明
内置广告/追踪拦截	不需要装扩展（支持页面的部分除外）
视频下载器	支持 MP4 / WebM / M3U8 / HLS
原生支持 Chrome 扩展	这是它最大的差异化 —— 移动端浏览器里能直接用桌面扩展
隐私优先	无痕、广告/追踪拦截

支持 Chrome 扩展这一条是杀手级。移动端浏览器普遍不支持扩展，导致很多"网页端能做、手机上做不了"的事做不了。Quetta 直接把这个口子开了 —— 我装了个广告拦截扩展，规则和电脑上完全一致。

七、总结这一个小结

观察到矛盾：视频在播，但 Network 里全是 .jpg，没有视频请求。
推断：视频被切成 MPEG-TS 分片，以"图片"的名义走 CDN —— 白嫖图片托管的带宽和缓存。
.ts 是 MPEG-2 Transport Stream：188 字节定长包，每包开头一个 0x47 同步字节，为抗错和可复用而设计；HLS 分片流媒体的标准容器。
BOM 狭义是字节序标记（UTF-8 是 EF BB BF），广义就是文件魔数 —— 靠开头几字节认类型。JPEG 的 SOI 是 FF D8 FF。
这招骗的是"识别"不是"解码"：浏览器看 Content-Type，图片解码器看段结构；真正被绕过的是站点自己的防下载规则。
Quetta 值在原生支持 Chrome 扩展，官网版和 Play 版功能有差异。

整件事最值得记的一点，其实跟下载无关：

遇到"看到的现象"和"知道的事实"矛盾时，F12 是最短的路。 屏幕上的一切都是别人写好的结果，而 Network 面板里的是真实发生的请求。

这次我只是觉得"没弹出下载按钮有点奇怪"，多按了一次 F12。

别从零写博客：fork 一个 Astro 模板，再让 CI 替你把关

Wed, 14 Oct 2026 00:00:00 GMT

写博客最容易走的弯路，是从"我要做一个博客"开始。

于是你开始：初始化项目、写 HTML 骨架、引入 CSS 框架、做亮/暗色主题切换、写文章列表分页、写目录导航、写 RSS、写搜索、写代码高亮、写 SEO meta……

三个月后你有一个博客框架，和零篇文章。

我这次换了个思路。

一、Astro 是 Cloudflare 官方推荐的框架

先把选型的成本降到零：

Cloudflare 官方文档里有 Astro on Cloudflare 的专门集成指南
静态输出直接推到 Pages，连 adapter 都不需要
因为是官方推荐，社区里针对 Pages 的踩坑方案和 workaround 都是现成的

选型这一步没花我十分钟。

主题也是现成的：Fuwari（MIT），一个完成度相当高的博客主题，开箱有：

亮色/暗色/跟随系统三态主题，带 localStorage 持久化
标签页 / 分类聚合 / 归档 / 搜索
文章目录（TOC）、上下篇导航、阅读时长
KaTeX 数学公式、代码高亮、代码折叠
页面转场动画（Swup）
i18n（10 种语言）
评论、站点地图、RSS
图片懒加载 + 灯箱（PhotoSwipe）

这些随便挑一项从零写，都够我写一个周末。所以我的第一个动作是 fork，不是 new。

git clone https://github.com/saicaca/fuwari.git my-blog
cd my-blog
rm -rf .git && git init

[!IMPORTANT] 这就是"学会助力"的意思。学生思维是"这个东西我不会，我要去学"。工程师思维是"这个东西有人做好了，我要去用"。

我学到的东西不会消失，借来的能力也不会。区别只在于我把时间花在了写文章上，而不是写 <head> 里的 meta 标签上。

博客最重要的是博文。框架能省的时间，就该省下来。

二、CI 只做三件事，每件都有明确边界

fork 完之后我加了三条 GitHub Actions 流水线。先说最重要的一个设计决策：

CI 里不跑 `astro build`

Cloudflare Pages 每次 push 都会完整构建一次。CI 再跑一遍是纯浪费 —— 同样的依赖安装、同样的构建，跑到两台不同的机器上。

所以我做了分工：

Cloudflare Pages  负责：这份源码能不能构建成一个能用的站点
GitHub Actions    负责：这份源码本身写对了没有

构建成功与否，Pages 会在 commit 上写 status，我没必要重复验证。CI 只补 Pages 不管的那部分检查。

流水线 1：`astro check` —— 类型检查

name: Astro Check
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true      # 连推多次时取消旧的，省 Actions 分钟数

permissions:
  contents: read                # 最小权限，默认 token 权限更大

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - uses: actions/setup-node@cdca7365b2dadb8aad0a33bc7601856ffabcc48e # v4.3.0
        with:
          node-version: 22
      - uses: pnpm/action-setup@a7487c7e89a18df4991f7f222e4898a00d66ddda # v4.1.0
        with:
          run_install: false
      - run: pnpm install --frozen-lockfile
      - run: pnpm astro check

注意 @11bd7190... 这种写法 —— action 版本钉死在 commit SHA 上，注释里写上对应的 tag。

# ❌ 别人改了 tag 指向，你下次构建跑的就是新代码
uses: actions/checkout@v4

# ✅ 供应链攻击改不了你的构建产物
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

这不是洁癖。actions/checkout 这种被所有仓库引用的 action，一旦 tag 被劫持就是全网级的供应链事件。个人博客用 SHA 钉死，零成本。

:::tip --frozen-lockfile 是 pnpm 对应 npm ci 的严格模式：lockfile 和 package.json 不一致就直接失败。CI 里必须用它，否则本地偷偷改了依赖但没更新 lockfile，CI 会装出一套和本地不一样的依赖，bug 现场极难复现。 :::

流水线 2：Biome 代码质量

name: Code quality
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71...
      - uses: biomejs/setup-biome@f382a98e582959e6aaac8e5f8b17b31749018780 # v2.5.0
        with:
          version: latest
      - run: biome ci ./src --reporter=github

--reporter=github 让问题直接显示在 PR 的 Files Changed 里，标注到具体行。省掉"CI 红了 → 本地跑一遍 → 对照行号"这一套。

:::warning 这条流水线在 Windows 本地有个大坑。 我的工作区是 CRLF，仓库里存的是 LF。本地跑 biome ci ./src 会误报几十个格式错误，但 CI 是 Linux，是绿的。

也就是说：本地红了不代表代码有问题，但你不能因此就无视它。 要在本地验证，得先把文件转成 LF：

Get-ChildItem -Recurse -Path .\src -Include *.ts,*.astro,*.css,*.styl |
  ForEach-Object {
    $c = [IO.File]::ReadAllText($_.FullName)
    [IO.File]::WriteAllText($_.FullName, $c.Replace("`r`n", "`n"), (New-Object Text.UTF8Encoding $false))
  }

这是 Windows 开发最没劲的地方之一：你没做错，但工具链因为换行符给你制造了一个不存在的问题。 :::

流水线 3：IndexNow —— 主动推送给搜索引擎

这个是我折腾得最值的一条。

背景：Google 在 2023 年下线了 sitemap ping 接口。所以"发布完主动告诉搜索引擎"这件事，主流方案里只剩 IndexNow 还活着。

特性	IndexNow
费用	免费
需要注册账号吗	不需要
参与方	Bing、Yandex、Seznam、Naver
Google	❌ 不参与（走 Search Console sitemap 提交）
归属验证	根目录放一个 `<key>.txt`，内容等于文件名

归属验证那一招很妙 —— 不需要 DNS TXT、不需要账号，只要你的站点上有一个文件。换域名也不用重新验证，把文件一起部署就行。

name: IndexNow
on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  submit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@11bd71...

      # ① 等 Pages 把新版本部署上去
      - name: Wait for the new Pages deployment to go live
        run: |
          set -u
          SITE="https://ycxdev.com"
          for i in $(seq 1 30); do
            if curl -fsS "$SITE/robots.txt" | grep -q "Sitemap"; then
              echo "Site is serving: $SITE"
              exit 0
            fi
            echo "waiting for deployment... ($i/30)"
            sleep 10
          done
          echo "Site did not come up in time, continuing anyway"

      # ② 推送
      - name: Submit URLs to IndexNow
        continue-on-error: true      # 推送失败不该让 CI 变红
        run: |
          URLS=$(curl -fsS "$SITE/sitemap-0.xml" \
            | grep -o '<loc>[^<]*</loc>' | sed -e 's|<loc>||' -e 's|</loc>||' \
            | head -100 | jq -R . | jq -s .)

          jq -n --arg host "ycxdev.com" \
                --arg key "$KEY" \
                --arg keyLocation "$SITE/$KEY.txt" \
                --argjson urlList "$URLS" \
            '{host:$host,key:$key,keyLocation:$keyLocation,urlList:$urlList}' > payload.json

          curl -sS -X POST "https://api.indexnow.org/indexnow" \
            -H "Content-Type: application/json; charset=utf-8" \
            --data-binary @payload.json

这一步里有两个细节是我后来才补上的，都是踩出来的：

:::caution ① 必须等部署生效再推送。 否则你告诉搜索引擎"这个 URL 有新内容了"，它立刻来抓，结果页面 404 —— 这是最糟糕的信号。Cloudflare Pages 构建要一两分钟，所以要轮询等。

② continue-on-error: true。 搜索引擎推送失败是网络波动类的错误，不应该让 CI 变红。变红了就会养成"CI 红了就 rerun"的习惯，真正的构建失败会被淹没。 :::

附赠：Dependabot

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    groups:
      patch-updates:
        patterns: ["*"]
        update-types: ["patch"]
      minor-updates:
        patterns: ["*"]
        update-types: ["minor"]
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]

依赖更新全自动开 PR。patch 和 minor 分成两组（一次提一堆，不会让你收到几十个 PR），major 忽略 —— 大版本变更必须人工判断，不能自动合。

三、整条链路跑起来的样子

<div class="mermaid"> sequenceDiagram autonumber participant ME as 我 participant GH as GitHub participant CI as GitHub Actions participant CF as Cloudflare Pages participant IX as IndexNow participant SE as Bing / Yandex ME->>GH: git push main par 两条流水线并发跑 GH->>CI: Astro Check + Biome CI->>CI: pnpm install → astro check → biome ci CI-->>GH: 状态写回 commit end GH->>CF: Webhook CF->>GH: 拉源码 CF->>CF: pnpm build → dist Note over CF: 构建失败则不动线上版本（原子部署） CF-->>SE: 线上已更新 GH->>CI: IndexNow 流水线启动 CI->>CF: 轮询 robots.txt，等新版本真的上线 CF-->>CI: 就绪 CI->>CF: 抓 sitemap-0.xml CI->>IX: POST {host, key, keyLocation, urlList} IX->>SE: 通知参与方 SE->>CF: 立刻重新抓取新文章 Note over CI: continue-on-error，推送失败不影响 CI 状态 </div>

四、我在这个过程中做的减法

一开始我的 CI 是这样的：

strategy:
  matrix:
    node-version: [18, 20, 22]
steps:
  - run: pnpm astro check
  - run: pnpm astro build      # ← 和 Pages 重复
  - run: pnpm test             # ← 项目里根本没有测试

跑了几次之后删到只剩一个 job、一个 step。原因很简单：

原来的检查	为什么删
Node 18/20/22 矩阵	Pages 只用一个版本，构建矩阵没有意义
`astro build`	Pages 每次 push 都构建，重复且更慢
`pnpm test`	没有测试文件，红的

:::note CI 的成本不是分钟数，是维护成本。 一个总是红的 CI 会被忽略，一个没人看的 CI 等于没有。每加一条流水线，就多一份将来会过期、会误报、会让你养成 rerun 习惯的负担。 :::

删掉冗余检查之后，CI 变成了它该有的样子：一个纯粹的、信号明确的红绿灯。 红了就是真出问题了。

小int小结

选型    → 官方推荐的框架（Cloudflare 文档里有 Astro 集成）
起步    → fork 一个完成度高的 MIT 主题，别从 <head> 开始
CI 1    → astro check：类型检查（Pages 不管这个）
CI 2    → biome ci：代码质量，reporter 直出 PR
CI 3    → IndexNow：免费、无需账号、主动推送搜索引擎
不做    → 不跑 build（Pages 已经跑了）、不跑矩阵（就一个版本）、不跑没用的 test
记得    → action 钉 SHA、--frozen-lockfile、推送失败 continue-on-error、
          push 之后先等部署上线再推索引

用别人的框架 + 让 CI 守住底线，我在这个博客上的"工程投入"大概是一个周末。剩下的全是写文章。

这才是正确的比例。

GitHub + Cloudflare Pages：零成本、无备案、全球 CDN 的个人博客

Tue, 13 Oct 2026 00:00:00 GMT

个人博客这件事最容易犯的错，是一上来就想"我要做个什么"。

我这次反过来做：先确定"最省事的方案能长什么样"，再倒推技术选型。 结果是：

成本       ¥0（Cloudflare 侧；域名另算，见下）
域名       可以完全不买（用免费的 *.pages.dev）
备案       不用（原因后面讲清）
服务器     不用（Pages 是静态托管）
CDN        Cloudflare 全球 anycast，默认就有
HTTPS      自动签发，自动续期

整套东西的核心就一句话：

GitHub 存源码，Cloudflare Pages 跑构建，两边一个 push 打通。

一、整条链路长什么样

<div class="mermaid"> sequenceDiagram autonumber participant ME as 我（本地） participant GH as GitHub 仓库 participant CF as Cloudflare Pages participant CFCDN as Cloudflare 全球 CDN participant U as 读者 ME->>ME: 本地 pnpm build 验证 ME->>GH: git push main GH->>CF: Webhook 通知（仓库变更） CF->>GH: 拉取源码（按 commit SHA） CF->>CF: 按 .nvmrc / package.json 装环境 CF->>CF: pnpm install → pnpm build CF->>CF: 产出 dist/ 静态文件 CF->>CF: 原子替换上线（发布 Production 部署） CF-->>GH: 部署状态回写 commit status U->>CFCDN: 访问 https://ycxdev.com CFCDN->>CFCDN: 就近边缘节点命中缓存 CFCDN-->>U: 返回 HTML/CSS/JS（自动 HTTPS） Note over U,CFCDN: 读者不需要回源，成本也不按流量计费 </div>

几个值得注意的点：

Cloudflare 主动拉代码，不是 GitHub 推产物。所以你的密钥不需要交给 GitHub Actions，Cloudflare 用的是它自己跟 GitHub 的 OAuth 授权。
部署是原子的：新构建完整成功后才切换，失败不影响线上版本。这一点比很多自建方案强 —— 你 push 了一个坏 commit，线上还是好的。
每次 push 都有独立的部署 URL，除了 production 还有一堆 preview 部署，24 小时后自动清理。想看草稿效果随便推。

二、免费额度到底有多少

Cloudflare Pages 免费版（Free plan）的关键数字：

项目	免费额度	说明
站点数量	无限制
构建次数	500 次 / 月	个人博客一天推几次都绰绰有余
单次部署文件数	20,000
单文件大小	25 MiB	所以图片别往仓库里塞特大的原图
构建超时	20 分钟	静态博客一般几秒
带宽	不限流量	Pages 不按流量计费，这是它最大的优势
自定义域名	100 个 / 项目

:::tip "不限流量"这一条要重点说一下。很多静态托管（Vercel Hobby、Netlify 免费版）都有流量/构建额度限制，超了就限速或停服。Cloudflare Pages 免费版不按流量收费 —— 这也是我最后选它的主要原因之一。 :::

关键约束：注册时不要绑信用卡。 绑卡后会进入需要验证的账户体系，一堆原本免费的功能会变成"需要开通付费"。这个博客从头到尾只在免费额度里跑。

三、为什么不用备案

这个是很多国内用户的顾虑，讲清楚原理就不神秘了。

ICP 备案的触发条件是两个同时成立：

① 网站内容/服务器 面向中国大陆境内用户提供服务
② 服务器 部署在中国大陆境内（境内 IP 的机房）

备案才需要。

而 Pages 的机器在 Cloudflare 的全球 anycast 网络上（境外节点）。你的域名解析过去，落到的是境外机房的 IP，不满足第 ② 条，所以不需要备案。

:::warning 需要避开的坑：

不要开 Cloudflare 中国网络（China Network） —— 那个是企业版付费功能，明确要求域名已完成 ICP 备案。开了反而会要求你有备案。
如果你买的是 .cn 域名并做实名认证，注意 .cn 域名本身在境内就有实名要求，这跟站点备案是两件事。 :::

我的站点现在跑在 ycxdev.com 上，走的就是海外 anycast。国内访问速度取决于运营商和跨境链路，但这不是"不合规"的问题，只是延迟问题。

那域名要不要买

分两种情况：

	用免费子域名	用自己买的域名
地址	`xxx.pages.dev`	`ycxdev.com`
花钱	¥0	域名年费（`.com` 通常几十块/年）
备案	不需要	仍然不需要（托管仍在境外）
换托管商	只能改 Cloudflare 项目名	改 NS 记录，随时搬
邮件 / 其他服务	用不上	可以拿去做邮箱、Redirect 等
Open Graph 观感	一般	好

先用 *.pages.dev 把内容跑起来，等真的有内容了再买域名。 我一开始也是纯 pages.dev，后来才换的 —— 换域名只是加一条 DNS 记录 + 在 Pages 里绑一次，站点内容一个字都不用动。

:::note 换域名之后有件事必须手动改，否则线上会静默出问题：

astro.config.mjs  的 site:          → canonical / sitemap / RSS 的绝对地址
public/admin/config.yml 的 site_url → CMS 里生成的链接
.github/workflows/indexnow.yml      → 推给搜索引擎的 host 和站点地址
CF 上绑定的 Web Analytics 站点

这些地方都拿"站点绝对地址"来拼 URL。改域名时漏改一个，canonical 就会指向旧域名，搜索引擎会当成两个站处理。 :::

:::warning 需要避开的坑：

不要开 Cloudflare 中国网络（China Network） —— 那个是企业版付费功能，明确要求域名已完成 ICP 备案。开了反而要求你有备案。
.cn / .com 在境内注册商买域名要做域名实名认证，但这是"域名实名"，跟"网站 ICP 备案"是两件不同的事，别混。
域名买了不等于站点备案了，也不等于需要备案 —— 取决于你的服务器在哪。 :::

四、顺手白嫖的 Cloudflare 设施

Pages 只是入口。同一个账号下免费额度里还有一堆能直接用的东西，我都用上了：

<div class="mermaid"> flowchart LR A["Cloudflare 免费账号"] --> B["Pages<br/>静态托管 + CDN"] A --> C["Pages Functions<br/>10万请求/天"] A --> D["KV<br/>1000 写入/天"] A --> E["D1 (SQLite)<br/>500万行读/天"] A --> F["Workers<br/>10万请求/天"] A --> G["Web Analytics<br/>无 Cookie 无采样"] A --> H["Turnstile<br/>人机验证"] B --> C C --> D C --> G </div>

具体我这个博客用到的：

1. Pages Functions + KV 做阅读量

纯静态站点没法记"这篇文章被看了多少次"，因为静态文件没有后端状态。用 Pages Functions（本质是 Workers）当后端，数据丢 KV：

// functions/api/views.ts （简化）
export async function onRequestGet({ request, env }) {
  const path = new URL(request.url).searchParams.get("path");
  const key = `v:${path}`;
  const n = parseInt((await env.VIEW_COUNTS.get(key)) ?? "0") + 1;
  await env.VIEW_COUNTS.put(key, String(n));
  return Response.json({ views: n });
}

:::warning KV 免费额度只有 1000 次写入 / 天。 一个写入对应一次自增。所以这个计数接口必须做防重 —— 我在前端用 lastCountedPath 保证同一次浏览只计一次。超额了 KV 会直接拒绝写入（不会扣费，但会报错）。这也是为什么阅读量要"点开才显示"而不是放在首屏阻塞渲染。 :::

2. Web Analytics

Cloudflare 的 Web Analytics 免费、无 Cookie、不采样，而且关键是：

它不要求站点托管在 Cloudflare。 *.pages.dev 这种不属于你自己 zone 的域名也能用（拿不到 zone 级功能，但 RUM 可以）。

打开方式就两行：

<!-- Cloudflare 自动注入的 beacon -->
<script defer src="https://static.cloudflareinsights.com/beacon.min.js"
        data-cf-beacon='{"token":"<你的 32 位 token>"}'></script>

:::note 那个 token 本身就是公开的 —— 它必须出现在前端 JS 里才能工作。所以看到别人页面上有这个 token 不构成安全问题，不用当成密钥来藏。 :::

3. OAuth 中转 Worker

我给博客配了一个 Sveltia CMS，需要 GitHub OAuth 登录。GitHub OAuth 的回调地址必须是注册过的绝对 URL，用 localhost 开发时很麻烦。我用一个免费 Worker 做中转，把回调先落到 Worker 上再 302 回本地。

这是 Workers 免费额度（10 万请求/天）最典型的用法。

4. 用不到的（因为要绑卡）

产品	为什么跳过
Cloudflare R2	需要绑卡开通
Cloudflare Images	需要绑卡
Cloudflare Stream	需要绑卡
Workers Paid / Pages 付费增强	需要绑卡
China Network	需要备案 + 企业合同

五、Cloudflare Pages 部署 Astro 的几个坑

Astro 是 Cloudflare 官方推荐的框架之一（他们有专门的 Pages 集成文档），但纯静态输出用 Pages 时不需要 adapter。我踩过的坑：

坑 1：Node 版本不一致导致构建失败

Cloudflare 默认用自己固定的 Node 大版本。本地 node -v 是 20，构建机上可能是 22，某些原生依赖会挂。

解法：加 .nvmrc

坑 2：包管理器必须一致

用 pnpm 就要让 Cloudflare 也用 pnpm。有两种做法：

# 仓库根目录加一个 corepack 声明
"packageManager": "pnpm@9.14.4"

坑 3：自定义响应头（CSP）用错文件名

Cloudflare Pages 的自定义 header 文件名必须是 _headers，放在 public/ 下，会被原样拷到 dist/ 根目录：

public/_headers  →  dist/_headers  →  边缘节点生效

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin

:::tip CSP 一开始我是开着的，结果被内联的 analytics beacon 和几个第三方资源全部挡掉。先上 Content-Security-Policy-Report-Only 观察一段时间，确认没有违规再切成强制模式。 :::

坑 4：构建失败时线上是完好的

这不是坑，是优点，值得单独强调：Cloudflare Pages 的部署是原子的。构建失败就停在原版本，线上不受影响。我有一次 commit 写崩了 markdown 配置，GitHub 上 CI 红了，站点还是好的 —— 改完再推就恢复了。

六、为什么源码一定放 GitHub

这一点我一开始想错过，后来发现是整个方案的地基。

Cloudflare Pages  ┐
                  ├──→ 内容以 GitHub 仓库为唯一来源（single source of truth）
Sveltia CMS       ┘

Pages 只是构建产物。删了重建一条命令，不丢任何东西。
CMS 也只是编辑器，它提交的变更最终是往仓库里 push Markdown 文件。所以 CMS 挂了不影响发布。
有完整历史。哪天想回退到三个月前的某个版本，git revert 一下，Cloudflare 自动重新构建。
迁移成本低。以后想换别的静态托管（Vercel / Netlify / 自建），换的是部署配置，内容文件一个字都不用改。

:::note 我的仓库是 Private。内容里有私人记录，而且 Cloudflare 的 GitHub 集成支持私有仓库 —— 构建机上拿的是只读的短期凭据，源码不会因为部署而泄露。 :::

小结

架构就一句话：GitHub 是唯一真源，Cloudflare Pages 负责构建和 CDN，中间一个 webhook 打通。
成本 ¥0：不绑卡、不用服务器、不备案（域名可选，先白嫖 *.pages.dev 也行）。
不限流量是 Pages 免费版最大的卖点，500 次构建/月对个人博客远远够用。
不备案的原因：备案要求"境内服务器"，Pages 在境外 anycast，两者不同时成立。
顺手白嫖：KV + Functions 做阅读量、Web Analytics 做统计、Workers 做 OAuth 中转、Turnstile 防机器人。
避开要绑卡的：R2 / Images / Stream / Workers Paid / China Network。
小心 Node 版本、包管理器、_headers 文件名这三个构建坑。

现在这个博客从推代码到全球可访问，全程不超过两分钟，成本为零。剩下的时间全用来写东西 —— 这才是博客该有的样子。

在已经部署好的博客上写博客，然后自动流回 GitHub

Tue, 13 Oct 2026 00:00:00 GMT

上一篇讲了怎么把博客部署上去。部署完有个很朴素的困惑：

站点已经是 Cloudflare 上的静态 HTML 了，我怎么在这个网页上直接写新文章？

总不能每次都 vim 一遍、git add、git commit、git push 吧 —— 虽然我实际上就是这么干的（因为要给 AI 写 AGENTS.md 协作）。

答案是一个很漂亮的闭环设计：

        ┌──────────────────────────────────────────────┐
        │                                              │
        ▼                                              │
   Cloudflare Pages（静态站点）                          │
        │                                              │
        │  /admin/ 下跟着站点一起部署了 CMS 的 index.html  │
        │                                              │
        └────────────┬─────────────────────┘            │
                     │                                  │
                     │  保存文章                          │
                     ▼                                  │
              GitHub 仓库（唯一真源）                    │
                     │                                  │
                     │  git push                         │
                     └────────────────────────────────────┘

CMS 跟着站点走，但写入目标是仓库。 站点既是发布产物，也是编辑器。这条回路走通之后，写文章就真的变成"打开网址 → 写 → 点保存"了。

一、为什么选 Sveltia 而不是自己写后台

先说清楚我不想干什么：

方案	问题
自己写后台 + 数据库	那就不是"静态博客"了，要维护服务、要备份数据库
Notion / 飞书文档直接同步	内容不在 Git 里，仓库不再是唯一真源
直接在服务器上编辑文件	Pages 没有文件系统给你编辑

我要的是：一个纯前端、零后端、直接调用 GitHub API 的 CMS。GitHub 就是数据库，commit 就是历史，PR 就是预览。

Sveltia CMS（Decap CMS 的活跃 fork）正好干这个。它是一个单文件 JS，加载就跑，所有读写都走 GitHub API。

二、挂进站点：它只是一个静态文件

CMS 不需要单独部署，把它当普通文件丢进 public/admin/：

<!-- public/admin/index.html -->
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="robots" content="noindex" />
    <title>Blog Admin</title>
  </head>
  <body>
    <script src="https://unpkg.com/@sveltia/cms/dist/sveltia-cms.js"></script>
  </body>
</html>

就这些。Cloudflare 构建时把它原样拷到 dist/admin/index.html，于是：

https://ycxdev.com/admin/         →  CMS

meta robots: noindex 别忘了 —— 否则搜索引擎会收录你的后台。

三、配置：告诉它写到哪去

public/admin/config.yml（这是我博客的真实配置）：

backend:
  name: github
  repo: devycx/MyBlog
  branch: main
  base_url: https://sveltia-cms-auth.<你的-workers-子域>.workers.dev

site_url: https://ycxdev.com

# 顶层媒体目录（供资源库 / Asset Library 使用）
media_folder: src/content/posts/images
public_folder: /src/content/posts/images

collections:
  - name: posts
    label: Posts
    folder: src/content/posts
    media_folder: images        # ← 集合级，相对路径
    public_folder: images       # ← 集合级，相对路径
    create: true
    slug: "{{slug}}"
    extension: md
    summary: "{{title}} - {{published}}"
    fields:
      - { name: title, label: Title, widget: string }
      - name: published
        label: Published
        widget: datetime
        date_format: "YYYY-MM-DD"
        time_format: false
        format: "YYYY-MM-DD"
      - { name: description, label: Description, widget: text, required: false }
      - { name: image, label: Cover Image, widget: image, required: false }
      - { name: tags, label: Tags, widget: list, required: false, default: [] }
      - { name: category, label: Category, widget: string, required: false }
      - { name: draft, label: Draft, widget: boolean, default: false }
      - { name: body, label: Body, widget: markdown }

folder: src/content/posts 正好是 Astro content collection 的目录。所以：

CMS 保存  →  GitHub 上多一个 .md 文件
Astro 构建 →  读同一个目录 → 生成一个页面

中间没有任何转换层。 这是整套设计最舒服的地方。

:::note 那个 draft 开关是真的有用的。站点里过滤草稿的逻辑就一行：

// src/utils/content-utils.ts
getCollection("posts", ({ data }) =>
  import.meta.env.PROD ? data.draft !== true : true
);

PROD 下过滤草稿，本地 dev 时不过滤。所以草稿能在本地预览、发出去也不会上线 —— 我现在手上这批文章就全是 draft: false 状态。 :::

四、OAuth 中转 Worker：为什么必须搞一个

GitHub backend 需要 OAuth 登录。麻烦在于 GitHub OAuth App 的 callback URL 是注册时写死的绝对地址，而你现在是通过 https://ycxdev.com/admin/ 访问的。

回调被 GitHub 打到一个不是 CMS 的 URL，Sveltia 拿不到 code，整个流程断掉。

解决办法是插一个 Worker 在中间：

<div class="mermaid"> sequenceDiagram autonumber participant B as 浏览器（CMS） participant W as OAuth 中转 Worker participant GH as GitHub participant U as 我（浏览器） B->>B: 点 "Login with GitHub" B->>W: GET /auth （带 redirect_uri 与 state） Note over W: state 存 KV / 签名 Cookie，防 CSRF W->>GH: 302 → github.com/login/oauth/authorize<br/>（client_id + redirect_uri = Worker） GH-->>U: 用户授权 GH->>W: 302 回调 ?code=... W->>GH: POST /login/oauth/access_token（code 换 token） GH-->>W: access_token W->>B: 302 回 /admin/，把 token 交给 CMS Note over B: token 存 localStorage </div>

Worker 的职责就三件事：

1. 提供一个固定的、已注册的 callback URL
2. 完成 code → token 的交换（这一步必须在服务端做，
   因为要把 client_secret 藏起来）
3. 把 token 安全地交回浏览器

:::warning Worker 必须持有 client_secret 并在服务端完成 code 交换。如果把 secret 放进 config.yml，那等于公开了这个 OAuth App —— 任何人拿到 secret 就能冒充你的应用换 token。 :::

这个 Worker 跑在 Cloudflare Workers 免费额度里（10 万请求/天），完全够用。命名上我用的是 sveltia-cms-auth-<Pages 项目名>，和站点同名，纯粹为了好记 —— 你随便起，只要和 GitHub OAuth App 里登记的 callback URL 一致就行。

五、保存一篇文章的完整时序

现在把 OAuth 之后的部分补完 —— 这是"反向同步"的核心：

<div class="mermaid"> sequenceDiagram autonumber participant B as 浏览器 CMS participant API as GitHub API participant R as GitHub 仓库 participant P as Cloudflare Pages B->>API: GET /repos/devycx/MyBlog/contents/src/content/posts API-->>B: 文件列表 + 每个文件的 sha Note over B: sha 是乐观锁，用来防覆盖 B->>B: 我在编辑器里写 Markdown<br/>（正文字段 → 文件正文） B->>API: POST /media（上传图片） API-->>B: 图片入库，写回 frontmatter Note over API: 图片直接进仓库 src/content/posts/images/ B->>API: PUT .../contents/src/content/posts/xxx.md<br/>{ message, content(base64), sha } API->>R: 创建 commit（branch: main） API-->>B: 201 Created，新 sha R-->>P: Webhook（push 事件） P->>R: 拉取该 commit P->>P: pnpm install && pnpm build P-->>U: 原子切换到新版本 Note over B,U: 整个过程无感，URL 没变 </div>

几个关键理解：

1. 乐观锁靠 sha。 GitHub 的 contents API 要求更新文件时带上当前的 blob sha。不带就报 422。这样两台设备同时编辑同一篇时会明确冲突，而不是静默覆盖。

2. 图片进仓库，不是图床。 CMS 上传图片走的是 POST /repos/.../contents/<path>，落到 src/content/posts/images/。这正好和我的约定一致 —— 内容以仓库为唯一来源，构建产物可随时重建。

:::caution 图片进仓库的代价是仓库体积不可逆地增长。GitHub 单文件 100MB、仓库建议 <1GB。放原图的话几十篇文章就能顶满。正确做法是上传前压缩（WebP / AVIF，或长边限制在 1600px）。 :::

3. public_folder 的相对/绝对是个真坑。 见下节。

六、卡了我两天的那个坑

当时上传的封面图全都 404。文章在 src/content/posts/，frontmatter 里写的是 images/xxx.jpg，Fuwari 主题里是这样解析的：

// src/pages/posts/[...slug].astro
<ImageWrapper src={entry.data.image}
              basePath={path.join("content/posts/", getDir(entry.id))} />

也就是说它把 images/xxx.jpg 拼成 content/posts/<目录>/images/xxx.jpg，然后通过 Astro 的图片管线去引用。

但问题是：如果 frontmatter 里写的是 /images/xxx.jpg（带前导斜杠），Astro 会当成 public 目录下的资源去找，当然找不到。

所以关键是 config.yml 里 集合级的 media_folder / public_folder 要用相对路径：

# ❌ 顶层用绝对路径 → frontmatter 被写成 /src/content/posts/images/xxx.jpg
media_folder: src/content/posts/images
public_folder: /src/content/posts/images

# ✅ 集合级用相对路径 → frontmatter 被写成 images/xxx.jpg
collections:
  - name: posts
    media_folder: images
    public_folder: images

:::warning 顺便提醒一个 API 名字的坑：Sveltia / Decap CMS 里这个选项叫 public_folder，不是 public_path。写错了不报错，只是 frontmatter 里路径不对，然后你在主题里死活找不到文件 —— 我就是在这上面浪费了一个下午。 :::

我在 config.yml 里直接把原因写成注释了，因为半年后我一定会忘：

# 集合级【相对路径】是关键：
#   media_folder: images  -> 图片实际存到 src/content/posts/images/
#   public_folder: images -> frontmatter 写成相对路径 images/xxx.jpg

七、这套方案的边界

说优点也要说缺点，不然是软文。

优点

零后端成本，CMS 就是一个静态文件
内容、代码、历史全在一个仓库里，git log 就是写作历史
CMS 挂了不影响发布（git push 照样能上线）
换静态托管只需要换部署配置，内容文件一个字不用改

局限

写长文体验一般。 Markdown 编辑器就是个文本框，没有大纲导航、没有实时预览、没有类似 Typora 的所见即所得。写代码文章够用，写散文就一般。
依赖第三方 CDN。 unpkg.com 挂了后台就白屏。可以自己 host 一份 sveltia-cms.js 到 public/admin/，我暂时没这么做。
鉴权粒度粗。 一个 GitHub PAT/OAuth 就是全部权限。多人协作得靠 GitHub 仓库权限管。
不是移动端优先。 手机上写长文体验很差。

:::tip 我的实际用法是混合的：长文用编辑器/AI 写好 Markdown，push 上去；短文、需要图和快速发布的用 CMS。 CMS 的价值不是"取代编辑器"，是"把发布这一步的摩擦降到零"。 :::

小结

CMS 跟着静态站点一起部署，一个 index.html + 一个 config.yml 就完事
写入目标是 GitHub 仓库，靠 folder 直接对上 Astro 的 content collection，中间零转换
OAuth 中转 Worker 解决 callback URL 固定的问题，并且必须把 client_secret 留在服务端
每次保存 = 一个 commit = 一次 Pages 重新构建，这就是"反向同步"的全部含义
public_folder 必须是集合级相对路径，顶层绝对路径会让图片 404
图片进仓库，记得压缩，仓库体积不可逆

整个系统的本质就一句话：GitHub 是数据库，commit 是历史，CMS 是个前端，Pages 是个编译器。 四个组件各司其职，谁都不是数据库，但组合起来就是一个完整的 CMS。

智谱新用户到底送了多少 token？我把资源包页面拉出来数了一遍

Mon, 12 Oct 2026 00:00:00 GMT

打开 https://bigmodel.cn/ 的登录页，右上角挂着一行：

新用户免费赠送专享 2000 万 tokens 体验包！

不用绑卡，进去就有。这个数字听起来很实在，但登录页说的是"约数" —— 我把自己控制台里 财务 → 资源包 → 我的资源包 的明细拉出来看了一遍，实际结构比一行宣传语复杂得多，也更有意思。

一、实际发了几个包

我的注册时间是 2026-10-11，控制台里躺着 6 个包：

资源包	数量	状态	到期时间
【实名认证】500 万 GLM-5.3-Flash 体验包	500 万 tokens	已用完	2026-11-11
【新用户专享】1500 万 GLM-5.3-Flash 资源包	1500 万 tokens	已用完	2026-11-11
【新用户专享】300 万 GLM-5.3-FlashX 资源包	300 万 tokens	已用完	2026-11-11
【新用户专享】20 次图片/视频生成资源包	20 次	生效中	2026-11-11
【新用户专享】200 万通用模型推理资源包	200 万 tokens	已用完	2027-01-11
【新用户专享】100 次搜索资源包	100 次	生效中	2027-01-11

加起来是 2500 万 tokens + 120 次按次计费的调用。

<div class="mermaid"> pie showData title 新用户 token 额度构成（单位：万 tokens） "GLM-5.3-Flash 1500万" : 1500 "GLM-5.3-Flash 实名 500万" : 500 "GLM-5.3-FlashX 300万" : 300 "通用模型推理 200万" : 200 </div>

登录页说的"2000 万"，是前两个包的和（1500 + 500）。另外 500 万是拆开给的，而且生效范围不同 —— 这是接下来最关键的细节。

上图是根据控制台数据整理的数据图，不是界面截图。想看原界面的话，登录 bigmodel.cn 走「财务 → 资源包 → 我的资源包」。

二、这 6 个包不是"通用货币"

第一眼看到 2500 万，很容易以为"随便怎么用都行"。不是。「适用场景」那一列才是真正的约束：

1500 万 + 500 万  →  只适用于 glm-5.3-flash 的推理
  300 万         →  只适用于 glm-5.3-flashx 的推理
  200 万         →  适用于所有按 tokens 计费的基础模型  ← 只有这个是万能的
  20 次          →  只适用于图片 / 视频生成
 100 次          →  只适用于 search-std / search-pro / search-pro-quark / search-pro-sogou

也就是说：

真正"通用"的额度只有 200 万 tokens，占总额度的 8%。剩下 92% 都被绑死在具体模型上。

这直接改变了一套使用策略。你如果拿 GLM-5.3-Flash 之外的模型去跑 agent，能烧的其实只有那 200 万。

:::note 包是按模型粒度拆分发放的，这在国产大模型平台的体验包设计中很常见 —— 既是资源隔离，也是引导你去试它主推的那个型号。理解这一点，才不会在"我明明有 2500 万额度"的时候发现调用报余额不足。 :::

三、4 天烧完

真正让我意外的不是额度大小，是速度。

注册时间 2026-10-11，我今天（10-15）再看，四个 token 包全部「已用完」。

<div class="mermaid"> xychart-beta title "新用户 token 额度消耗" x-axis ["10/11 注册", "10-15 现在"] y-axis "剩余 token（万）" 0 --> 2500 bar [2500, 0] </div>

也就是说：2500 万 tokens，4 天。 平均一天六百万。

而且我并不是高强度使用者 —— 主要是拿它在 opencode / 各种 agent 里跑日常的代码任务和文档处理。所以这里有个很反直觉的结论：

:::warning "2000 万 tokens"听起来像能用几个月的数字，实际上是几天的量级。

原因在 agent 场景的 token 结构，而不是你的问题难度：

一次普通问答              ≈  2k tokens
一次读文件改代码          ≈  15k ~ 60k tokens（含反复读取）
一次完整的 agent 任务     ≈  100k ~ 500k tokens（含多轮工具调用）

一个"就改一行"的任务，模型可能读 8 次文件、调 15 次工具，每次工具结果都回灌进上下文。你看到的是行数，它烧的是上下文。

按这个量级反推：

2500 万 tokens  ≈  agent 任务 × 50~250 次
                ≈  纯聊天     × 1 万次以上

纯聊天能撑很久；带工具调用的 agent，几天就见底。差异是几百倍。 :::

顺便给一个换算是很有用的：控制台的"购买资源包"页里，1000 万 tokens 的新客专享包标价 29.9 元（3 个月有效）。也就是说这 2500 万额度，按购买价折算大概值 70 多元。

70 块钱，4 天。这个数字比任何宣传语都能说明白 agent 到底有多吃 token。

四、怎么用才不亏

基于上面这几点，我总结出四条：

1. 先看「适用场景」，别只看总额

知道通用额度只有 200 万之后，我的做法是：把模型档位分两层。

日常对话 / 简单任务        →  免费模型（不消耗额度）
写代码 / 长上下文 / 复杂推理 →  token 包（优先用绑定的 GLM-5.3-Flash）
                       →  通用额度当"预算外资金"，留给别的模型

2. 别拿它测 prompt

新手最容易犯的错是拿 2500 万去调"这个 prompt 写得好不好"。测 prompt 用免费模型，不要用包。 包是一次性资源，用完就没了。

3. 长上下文别拆碎

同一份文档"问三次"和"一次问清再追问"，后者便宜得多 —— 因为前缀被缓存了。碎片化的提问会让缓存命中率崩掉。

4. 盯住到期日

这是最亏的死法：包还在，过期了，一分没花。这批包的有效期分两档：GLM 模型包 1 个月（到 11-11），通用包 3 个月（到 2027-01-11）。领到之后先看一眼日期，然后安排用掉。

:::tip 注册入口就一个：https://bigmodel.cn/。进去后在控制台创建 API Key，第一次就把 key 存进密码管理器 —— 平台明确说了"API Key 仅在创建时完整展示一次，后续无法查看或恢复"。

顺带一句：平台的资源包页面现在支持按「模型 / 功能 / 工具插件」分类筛选，还有"仅展示可用资源包"的开关。查余额之前记得关掉过滤，不然会以为还有额度。 :::

五、一个额外发现：他们卖的是"尝鲜包"

翻资源包商店的时候，我注意到一个挺有意思的产品设计：绝大部分 SKU 是"尝鲜包"，价格在 2.9 元 ~ 19.9 元之间。

GLM-5.3-Flash 尝鲜包     9.9 元
GLM-5.3 尝鲜包           39.9 元
GLM-OCR 3 折尝鲜包       2.9 元
GLM-Image 3 折尝鲜包     5.9 元
GLM-4.6V 3 折尝鲜包      5.9 元
GLM-4.5-Air 3 折尝鲜包   19.9 元

这不是随便定的价。2.9 元这个价位，意图是让你"无脑点一下"，而不是让你算性价比。平台赌的是你用完尝鲜包之后直接订阅/充值，而不是回头比价。

从用户角度，这反而是好事：

如果你想试某个特定模型（OCR、图像生成、视觉推理），先买它对应的尝鲜包，比直接充值划算得多。 因为尝鲜包是折扣价，而且范围清晰、不需要自己在账单里对账。

这跟前面那个"资源包按模型粒度拆分"是同一个思路的两面：把额度切成小份、绑定到具体能力、用低价降低尝试门槛。

小结

登录页写"送 2000 万 tokens"，实际是 2500 万 tokens + 120 次按次调用，分 6 个包
只有 200 万（8%）是通用额度，其余都被绑死在 GLM-5.3-Flash / FlashX 上 ——「适用场景」列比总额重要
注册 4 天全部用完。agent 场景的 token 消耗是纯聊天的几百倍，别拿聊天量级去估
按购买价折算，这 2500 万大概值 70 多元，四天烧完 —— 这就是 agent 的真实成本
有效期分两档（1 个月 / 3 个月），过期未用是最亏的
想试特定模型，先买对应的"尝鲜包"，比直接充值划算

薅来的东西要有个用完的计划，不然它就是个躺在后台慢慢归零的数字。这次我倒是用完了 —— 只是没想到这么快。

连上 Wi-Fi 才启动 VPN：Windows 计划任务的两个默认陷阱

Mon, 12 Oct 2026 00:00:00 GMT

我的笔记本在学校图书馆连 Wi-Fi 会断网。手机在同一个 Wi-Fi 下好好的。

排查了大半天，最后定位到：是我的 VPN（Clash 系，TUN 模式）启动太早了。

这台笔记本开机后我如果不开 VPN，一切正常。开了 VPN 去图书馆，必断。

一、为什么 TUN 模式的 VPN 会让图书馆连不上网

TUN 模式在干什么

普通代理模式（系统代理 / HTTP 代理）只接管明确配置了走代理的应用。TUN 模式不一样 —— 它在系统里创建一张虚拟网卡，然后把默认路由抢过来：

正常状态：
  0.0.0.0/0  →  192.168.1.1  via  WLAN      (metric 25)  ✓ 生效
  0.0.0.0/0  →  10.0.0.1     via  Clash-TUN (metric 5)   ✗ 被压制

TUN 启动后：
  0.0.0.0/0  →  10.0.0.1     via  Clash-TUN (metric 5)   ✓ 现在生效
  0.0.0.0/0  →  192.168.1.1  via  WLAN      (metric 25)  ✗ 还在表里，但不承载流量

Windows 同时只会用一条默认路由（多条时按 metric 取最小）。TUN 的目标就是把这条唯一的名额抢走，这样才能做到"全局代理"。

但图书馆的 WLAN 有一个特殊之处

家里的 Wi-Fi 连上就是通的。学校图书馆的 WLAN 不是 —— 它通常要过 802.1X（企业级认证） 或 Portal（网页认证）。这个过程有几个硬性要求：

<div class="mermaid"> flowchart TD A["网卡关联 AP<br/>(物理层已连接)"] --> B["4 次握手<br/>拿到 IP / 网关 / DNS"] B --> C{"需要认证吗?"} C -->|家用WiFi| H["可以直接上网 ✓"] C -->|图书馆 802.1X / Portal| D["必须能发出<br/>未认证的 EAPOL / Portal 流量"] D --> E{"TUN 已接管默认路由?"} E -->|否未启动| F["认证包正常走 WLAN ✓"] E -->|是已启动| G["认证包被路由进 TUN<br/>或被 kill-switch 丢弃 ✗"] G --> I["认证一直不完成<br/>= 连上了 Wi-Fi 但没网"] </div>

问题的本质："物理上关联成功"和"能上网"之间，还隔着一个必须依赖默认路由的认证阶段。 而 TUN 恰好在这个阶段把默认路由拿走了。

具体的死法有几种，通常几个一起

<div class="mermaid"> sequenceDiagram autonumber participant W as 开机/唤醒 participant OS as Windows 网络栈 participant AP as 图书馆 AP + 认证服务器 participant V as VPN 客户端 (TUN) participant NIC as 物理网卡 WLAN W->>V: 用户开机，VPN 自启 V->>OS: 创建虚拟网卡，注入 0.0.0.0/0 (低 metric) Note over OS: 默认路由此刻已被 TUN 占据 W->>OS: 开始连接 Wi-Fi OS->>AP: 关联 + 4 次握手 AP-->>OS: DHCP Offer（网关 192.168.x.1） Note over OS: 路由表已有默认路由（TUN 的），<br/>无法改走物理网卡 OS->>AP: 发起 802.1X 认证 / Portal 探测 alt strict-route / kill-switch 开启 AP--xOS: 认证响应被丢弃 Note over OS,AP: ✗ 永远认证不通过 else 认证包被路由进 TUN OS->>V: 认证包进了隧道 V--xAP: 出不去，或回包进不来 Note over OS,AP: ✗ 同样卡死 end V->>OS: DNS 已劫持到隧道内 (1.1.1.1 等) Note over OS,V: 要解析出口域名才能建隧道，<br/>但 DNS 在隧道里 → 先有鸡还是先有蛋 Note over OS: 重试 → 认证失败 → 认证不通过 → 系统拿不到 IP </div>

把上面压缩成一句话：

TUN 模式假设"你已经能上网了"。而图书馆的 WLAN 假设"你还没认证完"。两个假设互相打架。

还有一个更隐蔽的：DNS 死锁。TUN 模式通常会把 DNS 也劫持到隧道内的公共 DNS（1.1.1.1 / 8.8.8.8）。而隧道要建连，得先能解析出口服务器的域名 —— 解析请求被送进一个还没建好的隧道。配置不讲究的客户端就会一直卡在这里反复重试。

:::warning 成熟客户端一般会维护一份 bypass 列表，把出口服务器 IP 和内网网段排除在隧道之外，避免自噬。这份列表配得好不好，直接决定你会不会遇到"自己把自己套进去"。 :::

二、解法：把 VPN 启动推迟到"网络就绪之后"

不要在开机时启动 VPN。等系统告诉你"网络连接已经建立"，再启动。

Windows 里这件事的官方触发器就是 Microsoft-Windows-NetworkProfile/Operational 事件日志的 EventID 10000（网络连接建立）。

任务计划程序 → 创建基本任务 → 触发器 → 自定义 → 事件触发器：

项	值
日志	`Microsoft-Windows-NetworkProfile/Operational`
事件 ID	`10000`
任务	启动 VPN 客户端

我本机跑的任务实际长这样（\用户程序库\Clash Network Start）：

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-21-xxxxxxxx-1001</UserId>
      <LogonType>InteractiveToken</LogonType>
    </Principal>
  </Principals>
  <Settings>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
  </Settings>
  <Triggers>
    <EventTrigger>
      <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Microsoft-Windows-NetworkProfile/Operational"&gt;&lt;Select Path="Microsoft-Windows-NetworkProfile/Operational"&gt;*[System[Provider[@Name='Microsoft-Windows-NetworkProfile'] and EventID=10000]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
    </EventTrigger>
  </Triggers>
  <Actions Context="Author">
    <Exec>
      <Command>"C:\Program Files\YourVPN\YourVPN.exe"</Command>
    </Exec>
  </Actions>
</Task>

<details> <summary>一键注册脚本（PowerShell，管理员）</summary>

$xml = @'
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo><Author>me</Author></RegistrationInfo>
  <Principals>
    <Principal id="Author">
      <UserId>DOMAIN\user</UserId>
      <LogonType>InteractiveToken</LogonType>
    </Principal>
  </Principals>
  <Settings>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
  </Settings>
  <Triggers>
    <EventTrigger>
      <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Microsoft-Windows-NetworkProfile/Operational"&gt;&lt;Select Path="Microsoft-Windows-NetworkProfile/Operational"&gt;*[System[Provider[@Name='Microsoft-Windows-NetworkProfile'] and EventID=10000]]&lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
    </EventTrigger>
  </Triggers>
  <Actions Context="Author">
    <Exec><Command>"C:\path\to\vpn-client.exe"</Command></Exec>
  </Actions>
</Task>
'@

Register-ScheduledTask -TaskName "VPN On Network Up" -Xml $xml -Force

验一下：

Get-ScheduledTask -TaskName "VPN On Network Up" | Select-Object TaskName, State

</details>

三、你问的那两个坑：你的理解是对的，而且很常见

坑 1：默认 72 小时后任务被杀掉

是真的。

Task Scheduler 的 ExecutionTimeLimit（"如果任务运行时间超过此时间，则停止任务"）默认值是 PT72H，也就是 72 小时。文档里的原话是"如果未指定该值，默认使用 72 小时"。

一个开机常驻的任务 —— 比如 VPN 客户端 —— 跑满三天就会被系统主动干掉，而且：

日志里只记一句"任务因超出时间限制而终止（任务已完成）"
不会弹任何提示
你不会意识到是计划任务干的

改法：PT0S = 不限时。

<ExecutionTimeLimit>PT0S</ExecutionTimeLimit>

坑 2：拔电源会停任务

也是真的，而且是两个独立的开关。

任务计划程序创建任务时，GUI 里默认勾着「如果计算机使用电池电源，则停止任务」。这个勾选会写出两个 XML 节点：

<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>  <!-- 电池上干脆不启动 -->
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>          <!-- 运行中拔电就杀掉 -->

两个默认都是 true。表现是：笔记本拔掉电源线的那一瞬间，VPN 客户端进程被计划任务管理器直接结束。

改法：两个都置 false。

<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>

等价的 cmdlet 写法：

New-ScheduledTaskSettingsSet `
  -ExecutionTimeLimit ([TimeSpan]::Zero) `
  -AllowStartIfOnBatteries `
  -DontStopIfGoingOnBatteries `
  -MultipleInstances IgnoreNew

:::tip 我本机这个任务的 XML 里这两个坑都已经改过来了（PT0S + 两个 false）。所以如果你现在遇到的是我之前那个症状 —— 图书馆连不上网但别的地方正常 —— 那就不是这两个默认值的问题，回到第一节的路由抢占去看。 :::

顺带第三个坑：IdleSettings

有些任务里还会看到这一段：

<IdleSettings>
  <Duration>PT10M</Duration>
  <WaitTimeout>PT1H</WaitTimeout>
  <StopOnIdleEnd>true</StopOnIdleEnd>
  <RestartOnIdle>false</RestartOnIdle>
</IdleSettings>

它的含义是「仅当计算机空闲至少 10 分钟时才启动任务」，加上「一旦不空闲就停止」。只有 <RunOnlyIfIdle>true</RunOnlyIfIdle> 时才生效 —— 默认是 false，所以一般无害。

但如果你哪天在 GUI 里手滑勾上了「仅当计算机空闲时才启动任务」，拔电源断网这种玄学问题就又能重现了。

四、EventID 10000 的两个副作用

它不只对 Wi-Fi 触发

EventID 10000 是任何网络配置建立都会触发，包括：

有线网
手机 USB 网络共享
VPN 自己那张虚拟网卡重连
Docker / WSL2 虚拟交换机

所以完全可能出现"VPN 自己断了 → 触发 10000 → 计划任务又去启动 VPN → 反复重启"。

想严格只认 Wi-Fi，把动作改成调一个脚本做判断：

# start-vpn-if-wifi.ps1
$wifi = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' -and $_.NdisPhysicalMedium -eq 9 }
if ($wifi) { Start-Process 'C:\Program Files\YourVPN\YourVPN.exe' }

NdisPhysicalMedium -eq 9 就是 Native 802.11。

事件日志通道必须处于启用状态

Microsoft-Windows-NetworkProfile/Operational 默认是开的。但如果被组策略关掉或者日志被清空过，触发器会静默失效 —— 任务状态显示 Ready，永远不触发，也没有任何错误提示。

验证：

wevtutil gl Microsoft-Windows-NetworkProfile/Operational | Select-String enabled

五、排查这类问题的通用顺序

以后再遇到"某个网络下连不上"，按这个顺序查，能少走很多弯路：

1. 关掉 VPN 试试
   └─ 好了 → 是路由/DNS/防火墙问题，不是 Wi-Fi 的问题
2. route print 看 0.0.0.0/0 有几条、哪条 metric 最小
   └─ TUN 的那条生效 → 就是本文说的抢占
3. nslookup 域名 + ping 网关
   └─ 网关通、域名不通 → DNS 劫持/死锁
4. ipconfig /all 看 IPv4 是不是 169.254.x.x
   └─ 是 → DHCP 续租失败，认证阶段就被卡住了
5. netsh wlan show interfaces 看 认证状态

:::warning 第 2 步是分水岭。如果你看到一个软件的虚拟网卡出现在默认路由里且 metric 最小，那基本可以确定问题出在它身上，不用再往 Wi-Fi 配置上找。 :::

小结

图书馆连不上网的根因：TUN 抢占了默认路由，而 802.1X / Portal 认证必须在认证完成前使用默认路由。TUN 假设"你已能上网"，图书馆 WLAN 假设"你还没认证"，直接对撞。
解法：用计划任务监听 Microsoft-Windows-NetworkProfile/Operational 的 EventID 10000，等网络建立后再启动 VPN。
你记得的两个默认坑都是真的：ExecutionTimeLimit 默认 PT72H（改成 PT0S）；DisallowStartIfOnBatteries / StopIfGoingOnBatteries 默认 true（改成 false）。
还有第三个：IdleSettings 的 StopOnIdleEnd，勾上「仅空闲时运行」就会重现玄学掉线。
EventID 10000 不区分网络类型，严谨点要加 Wi-Fi 判断，否则 VPN 重连会自触发。

Windows 计划任务这玩意儿的默认值都是为"跑一次就完事的短任务"设计的。你一旦用它跑常驻服务，就得把这几个默认一个个翻过来 —— 症状还都是"过几天突然不好使了"，不查根本想不到是它。

DeepSeek 注册送 0 元？去它自家 Harness 领 6 块

Sun, 11 Oct 2026 00:00:00 GMT

先说结论：

DeepSeek 开放平台注册，确实一分钱都不送。 但 DeepSeek 自家的开源 agent harness —— DeepSeek Harness 桌面端 —— 安装后登录，送 6 元体验金。

这两件事在同一个品牌下，但几乎没有互相导流。不专门找的话根本注意不到。

一、先确认一下：开放平台确实没赠送了

很多人（包括之前的我）是 2024 年那批用户，那时候注册送 14 元。后来政策改了，新用户注册打开就是 0 余额：

platform.deepseek.com  →  注册 →  余额：¥0.00

这不是个例。GitHub 上有一堆 issue 和博客在专门讨论"怎么找回消失的新用户额度"，给出的方案清一色是绕路 —— GitHub Models、Cloudflare Workers AI、各种第三方中转。

但那些方案有一个共同问题：折扣、限速、稳定性全都不如直连。

所以我更愿意找官方自己的口子。

二、Harness 是什么

DeepSeek Harness 是 DeepSeek 官方开源的 agent harness，仓库在 deepseek-ai/deepseek-harness（MIT 协议）。它一句话的自我描述是：

DeepSeek Harness: Everything is a Plugin.

架构上是一个 everything-is-a-plugin 的插件化 agent 框架，底座是 Cordis，设计思路来自论文《A Programming Paradigm for Spatiotemporal Composability》。

它能干什么（官方列的四类）：

能力	具体表现
辅助日常工作	整理资料、分析表格、撰写文档、做汇报
写代码 / 改仓库	理解项目、修问题、开发功能、跑测试
查资料、核对信息	搜索、交叉验证、标注来源
处理耗时任务	跑脚本、批量处理文件，后台执行

外加自动化任务插件（按计划执行重复工作）和一个执行轨迹视图（能展开看每次工具调用的细节，方便排查）。

:::note "开发者预览版"，官方明确警告会有不兼容变更。MIT 开源，249k star。定位上它更像"个人助理 + 可编程 agent 底座"，而不是单纯的代码补全工具。 :::

三、6 元怎么领

就三步，没有隐藏条件：

打开 https://www.deepseek.com/zh/harness/，点**「下载桌面端」**
下载安装（官网提供 macOS（Apple 芯片） 和 Windows（64 位） 版本）
用 DeepSeek 账号登录 → 到账 6 元体验金

<div class="mermaid"> sequenceDiagram autonumber participant U as 你 participant W as deepseek.com/harness participant A as Harness 桌面端 participant B as DeepSeek 账户余额 U->>W: 访问 Harness 官网 W-->>U: 下载桌面端 (macOS Apple 芯片 / Win x64) U->>A: 安装并启动 A->>B: 登录（复用 DeepSeek 账号） B-->>A: ★ 到账 6 元体验金 Note over A,B: 无需绑卡、无需充值、无需邀请码 U->>A: 直接开聊 / 跑任务 A->>B: 按 token 计费扣减 </div>

:::warning 别去开放平台找。 那个入口不给。这 6 块是在 Harness 客户端里登录之后才发到同一个账户余额的，我在开放平台后台是看不到"这笔钱从哪来"的标注的，所以很多人以为没到账。 :::

四、6 块能用多久

这取决于你干什么。DeepSeek 的定价是按 token 计费的，V4 系列的价格可以对照官方定价页。

粗略给个体感：

纯聊天 / 读文档      → 几十到上百小时
日常改代码、写脚本    → 几周
长上下文 agent 任务   → 可能一周就没了

:::caution 活动是限时的。我看到的信息是这个体验金有效期到 10 月 6 日。所以如果你现在去装发现没送，大概率是这一轮结束了 —— 但 DeepSeek 这种活动通常会周期性续，盯一下官网就行。 :::

关键还是那句老话：薅来的额度只够让你"试出好不好用"。 觉得好用再自己充值，别一开始就往里塞钱。

五、一个让我更在意的点：Harness 本身

说实话，6 块只是顺手的事。真正让我花时间试的是 Harness 这个项目本身。

它开源的定位不是"我的客户端"，而是**"你也可以写一个自己的 agent"**。

一切皆插件

官方插件列表之外，你可以在「创造模式」里直接跟它对话，让它帮你生成插件。也就是说扩展能力的方式不是去 GitHub 抄一个别人的插件，而是把需求说出来，让它给你造一个。

三种跑法

# 1. 桌面端（那个送 6 块的）
#    macOS(Apple 芯片) / Windows(64 位)

# 2. npx 起 Web UI —— 默认 http://127.0.0.1:3080
npx @deepseek-ai/dsh web

# 3. 源码跑
git clone https://github.com/deepseek-ai/deepseek-harness
cd deepseek-harness
pnpm install && pnpm run build && pnpm dsh web

第 2 种特别有意思：它默认只听 127.0.0.1:3080，跟 opencode 的安全模型一样 —— 默认本机，需要暴露到网络时你得自己显式开。

插件生态有统一的 topic 标记（dsh-plugin），可以按这个标记搜到所有第三方插件。

:::tip 如果我某天想给 opencode 加个 DeepSeek 后端，或者想把 Harness 的某个插件思路搬过去，dsh 开源这点就很关键 —— 至少架构是可以读的。 :::

六、Harness 和 opencode 怎么选

这两个东西形态很像但取向不同。我目前的判断：

	DeepSeek Harness	OpenCode
定位	个人助理 + 可编程 agent 底座	终端优先的 AI 编程助手
架构	一切皆插件（Cordis）	插件 + MCP + LSP + ACP
默认模型	DeepSeek 自家（V4.1 Flash 等）	多 provider，模型自由切换
开源	MIT，249k star	MIT，官方主推
上手	装客户端就能用，零配置	装个 CLI，要配 provider
执行位置	工作区，后台任务	你的项目目录

我的用法是两个都用：写代码还是 opencode 顺手（多模型可切换，终端工作流顺），日常文档/表格/杂活丢给 Harness（开箱即用）。

:::warning 一个务实的提醒：Harness 目前是开发者预览版，官方明说不兼容变更会来。 当主力生产工具之前，做好心理准备。送的那 6 块反正也不心疼。 :::

小结

开放平台注册 0 赠额是事实，不用找了
官方另一个入口在 deepseek.com/zh/harness —— 装桌面端、登录、送 6 元
但更重要的是：Harness 是个 MIT 开源的 everything-is-a-plugin agent 框架，值得单独看
npx @deepseek-ai/dsh web 一行命令起本地 Web UI，默认只监听 127.0.0.1
额度只够试，别当成长期方案

DeepSeek 这个牌子在开源这块其实相当舍得 —— 一个 249k star 的 MIT 项目，白送给你 6 块钱让你用它的模型去跑这个项目。算下来自己都不用花钱试了。

Tailscale 是怎么做到"像在同一个局域网"的

Sun, 11 Oct 2026 00:00:00 GMT

用了大半年 Tailscale，最大的感受不是"网速快"，而是它把一整类问题从根上消掉了。

传统组网你得处理：公网 IP、端口转发、DDNS、路由器防火墙规则、两边能不能互通、运营商 CGNAT……每一个都是单独的坑。Tailscale 的做法是：这些全都不需要你想。

它到底怎么做到的？

一、先说结论：这是"控制平面 / 数据平面"分离的经典范式

理解 Tailscale 只要抓住一句话：

协调服务器只负责"介绍大家认识"，数据从来不经过它。

┌─────────────────────────────────────────────────────────┐
│  控制平面（Control Plane）—— 只交换元数据，永不见明文      │
│                                                          │
│    coordination server                                  │
│    ├─ 认证：这个设备是谁？                               │
│    ├─ 分发：把 peer 的公钥 和 当前可达 endpoint 告诉 everyone│
│    └─ 策略：ACL / 子网路由 / DNS 记录                     │
└─────────────────────────────────────────────────────────┘
                            │
              交换公钥 + endpoint 地址（就这些）
                            │
┌───────────────────────────┴─────────────────────────────┐
│  数据平面（Data Plane）—— 设备之间直连，端到端加密        │
│                                                          │
│    笔记本 100.x.y.z  ◄──── WireGuard (UDP) ────►  家里 PC  │
│                                                          │
│    打洞失败时降级：                                       │
│    笔记本  ◄── WireGuard over DERP(TLS 443) ──►  家里 PC  │
└─────────────────────────────────────────────────────────┘

这个切分带来的直接后果：协调服务器被入侵，攻击者拿到的是一堆公钥和 IP 地址，不是你的文件内容。 数据平面的加密密钥在设备本地，服务器没有。

二、阶段 A：把设备加进同一个 tailnet

<div class="mermaid"> sequenceDiagram autonumber participant D as 新设备（笔记本） participant C as 协调服务器<br/>controlplane.tailscale.com participant A as 已在线的设备<br/>(家里 PC) D->>D: 生成设备密钥 (curve25519) Note over D: 私钥永不离开本机，只上传公钥 D->>C: 发起登录 (SSO / auth key) C->>C: 验证身份，绑定到你的 tailnet C-->>D: 下发节点密钥 + 网络策略(ACL) + DNS 配置 D->>C: 上报本机 endpoint<br/>(公网 IP:随机端口列表) C-->>A: 推送 peer 信息：新设备的公钥 + endpoint C-->>D: 推送 peer 列表：家里 PC 的公钥 + endpoint Note over D,A: 两端现在互相知道对方"是谁"和"在哪" Note over D,A: 但还没有任何一包数据通过 </div>

这里有个容易被忽略的点：协调服务器给的是公钥，不是私钥。 所以它从架构上就不可能解密你的流量。

身份体系是另一层东西。Tailscale 的设备身份有三类密钥：

密钥	作用
设备密钥（machine key）	标识"这是哪台设备"，设备身份的生命周期
节点密钥（node key）	WireGuard 会话密钥，每次连接协商
预授权密钥（auth key / preauth key）	给无头设备（服务器、树莓派、容器）用，免交互加入

第三类在自动化场景里非常有用。我 NAS 上跑的 Tailscale 就是用预授权密钥直接加入的，没有弹过任何登录页面：

tailscale up --authkey=tskey-auth-xxxxx --advertise-routes=192.168.1.0/24

:::note 预授权密钥的泄露风险比密码高 —— 它是可重复使用的，能直接往你的 tailnet 里加设备。所以一般签发一次性（ephemeral）版本，且定期轮转。 :::

三、阶段 B：NAT 打洞，然后直连

拿到对方 endpoint 之后，两台设备同时开始发包，目标是让中间的 NAT 设备在状态表里打开一个洞。

<div class="mermaid"> sequenceDiagram autonumber participant L as 笔记本 (NAT 后) participant D as DERP 中继<br/>(协调服务器附属) participant P as 家里 PC (NAT 后) Note over L,P: 第一步：先经 DERP 完成真正的握手 L->>D: 中继包裹（内含 WireGuard 握手发起） D->>P: 转发给 P P->>D: 中继包裹（WireGuard 握手响应） D->>L: 转发给 L Note over L,P: ★ 隧道已建立，且双方都知道了<br/>对方的 NAT 映射地址:端口 par 同时打洞 L->>P: UDP 直发（经对方 NAT 映射地址） and P->>L: UDP 直发（经对方 NAT 映射地址） end Note over L,P: 双向流量都通过了 → NAT 表已打开 L->>P: ⚡ WireGuard 直连，绕开 DERP P->>L: ⚡ WireGuard 直连，绕开 DERP Note over D: DERP 此后只在心跳阶段参与，不再承载数据 </div>

这是整个设计里最漂亮的一步。DERP 在这里的作用不是"中转流量"，而是"牵个线"：

NAT 穿越的难点在于：你不知道对方在 NAT 后的映射地址，而且通常只有一方能主动建连（对称型 NAT 双方都难）。DERP 让双方先通过中继完成握手，握手过程中双方互相通告了自己的源地址:源端口，然后同时向这个地址发包。

NAT 设备看到"有出站流量到 X:Y"，就会为返回流量在状态表里开一个洞。两边都打，就都开了。

打洞失败怎么办

不是所有网络都允许 UDP —— 有些企业防火墙、有些酒店 Wi-Fi、有些移动网络会直接封 UDP。这时候自动降级到 DERP 中继，数据走 WireGuard over TLS 443：

tailscale status
# 100.x.y.z   laptop   linux   -   直接连接
# 100.x.y.z   nas      linux   relay "iad"   走 DERP 中继

功能完全正常，只是延迟高一点。tailscale netcheck 可以看当前网络的 NAT 类型和 UDP 可用性。

[!TIP] 这也是为什么 Tailscale 在受限网络里"总能用"—— 它有一个永远能通的降级路径。中继走 443/TLS，几乎不可能被企业防火墙完全拦死。

四、拿到"局域网体验"的三层能力

直连只是基础。让人觉得"跟在一个局域网里"的其实是这三样：

1. MagicDNS —— 不用记 IP

tailscale status
# 100.101.102.103  my-nas      linux   -
# 100.104.105.106  my-laptop   windows -

ssh my-nas
ping my-laptop

背后是 Tailscale 内置的 DNS resolver，把 my-nas 解析到 100.x.y.z，再由 netfilter 把这个网段的流量送进 WireGuard 隧道。

:::warning 100.64.0.0/10 是 CGNAT 保留段（RFC 6598）。Tailscale 选它是为了几乎不可能和你的真实局域网冲突 —— 家宽和运营商内网正好也用这个段，所以反向的情况（你的设备真实地址就在 100.x 里）才是要小心的那个。Tailscale 也确实因此和某些 CGNAT 场景下的本地路由撞车，官方文档里明确列了这个已知冲突。 :::

2. 子网路由 —— 访问"根本不在 tailnet 里"的机器

如果家里有一台没装 Tailscale 的打印机或摄像头，可以让装了 Tailscale 的那台 PC 当路由器：

# 在家里 PC 上
tailscale up --advertise-routes=192.168.1.0/24

# 在管理后台批准这条路由（必须手动批准）

批准后，其他 tailnet 设备就能直接访问 192.168.1.0/24，只有一台设备需要装 Tailscale。IP 转发和 SNAT 由 tailscaled 自动开好。

3. Exit Node —— 把整个出口搬到别处

tailscale up --exit-node=my-nas

所有设备的默认流量都从 NAS 出去。典型用途是：人在国外想让国内设备走回国出口，或者反过来。

:::caution Exit Node 和子网路由别同时无脑开。Exit Node 会接管默认路由，容易和本地 VPN（Clash 之类）打架 —— 这也是 Tailscale 和 Clash 共存时最常见的冲突点。配合使用时，一般要么让 Clash 跑在 Tailscale 之上（子网路由/Exit Node 出口），要么反过来明确指定 --exit-node 只处理特定流量。 :::

五、和 OpenTunnel 怎么选

上一篇写了用 OpenTunnel 把 opencode 暴露到公网。这里对比一下，因为两者经常被放在一起问：

	Tailscale	OpenTunnel
形态	私有网络，设备间互联	单点公网入口，一个 URL
暴露面	只有 tailnet 内的设备	任何人拿到 URL 都能访问（要自己加鉴权）
加密位置	WireGuard，内核态，端到端	TLS 在本地终结，盲转发
移动端	装 App	浏览器直接开
适合	多台设备互联、访问内网服务	临时把本地 web 服务甩到公网

实际用法是组合拳：

Tailscale  ──▶  手机安全地回到家里内网
OpenTunnel ──▶  把某个服务单独甩到公网（带密码）

:::tip 如果你只是想让手机访问家里几个服务，只用 Tailscale 就够了，别开 OpenTunnel —— 前者暴露面是"你的设备列表"，后者是"一个公网 URL"。安全边界完全不同。 :::

小结

Tailscale 之所以能用得这么舒服，是因为它把三个本该由用户操心的问题各自交给了正确的层：

身份问题 → 协调服务器（但只管公钥，不管数据）
可达性问题 → DERP 中继做握手辅助 + NAT 打洞，失败自动降级中继
加密问题 → WireGuard 端到端，密钥在设备本地，服务端物理上无法解密

学 networking 的时候，"VPN = 加密隧道"这个印象会束缚你很久。Tailscale 告诉你的是：加密隧道只是数据平面，前面还需要一个不碰数据的控制平面；而可达性问题，可以用"先借道、再打洞、最后直连"的时序来解决。

OpenCode + OpenTunnel：让手机直接和家里电脑上的 AI 编程助手对话

Sat, 10 Oct 2026 00:00:00 GMT

我一直想在通勤路上给家里那台电脑上的 opencode 派活儿 —— 不是远程桌面那种"看着屏幕点点"，是真的把指令发过去，让它自己跑。

试过几条路：

方案	结果
frp 自建服务器	要有台有公网 IP 的 VPS，还得自己运维
Cloudflare Tunnel	要绑自己的域名，配置一堆
Tailscale + 客户端 App	得装 App，网页端不一定好用
SSH 端口转发 + 客户端	手机上没法开 SSH 隧道
OpenTunnel	一条命令，一个 https 网址，手机浏览器直接用

最后这个是 OpenCode 联合创始人 Dax Raad 做的开源项目：anomalyco/opentunnel。

一、它是什么：一个"盲"TLS 隧道

一句话概括它的设计哲学：

服务端只读 TLS 握手的第一个包（ClientHello），拿到 SNI 就知道该转给谁，剩下的一概不看。

这是个很反常规的设计。传统内网穿透（ngrok、frp）的模型是：客户端和服务端之间建立一条隧道，所有流量都经过服务端。所以服务端能看到你的明文 —— 包括密码、cookie、API Key。

OpenTunnel 换了个思路：

                     ┌─────────────────────────────┐
  浏览器  ──HTTPS──▶  │  OpenTunnel Server (443)    │
  （以为在直连）      │  只读 ClientHello 里的 SNI   │
                     └──────────────┬──────────────┘
                                    │ 按 SNI 找到对应隧道
                                    │ （剩余内容原样转发，加密状态不变）
                                    ▼
                     ┌─────────────────────────────┐
                     │  本地 opentunnel client      │
                     │  ★ 持有证书私钥，在这里终结 TLS │
                     │  ★ 服务端从来看不到明文       │
                     └──────────────┬──────────────┘
                                    │ 明文 HTTP
                                    ▼
                     ┌─────────────────────────────┐
                     │  opencode server 127.0.0.1:4096 │
                     └─────────────────────────────┘

关键点：证书私钥在你自己电脑上，服务端从头到尾没有碰过。 它就像一个只认门牌号、然后原样把包裹送过去的快递员 —— 它知道包裹要送给谁，但包裹里是什么它拆不开。

它管这叫 blind TLS tunnel（盲 TLS 隧道）。

二、完整时序图

:::note 下图里的 ROUTE 是默认随机生成的 16 位路由名，ID 是服务端分配给本机的隧道子域名，两者拼起来就是一个完整地址。Mermaid 的标签里不能用尖括号，所以这里用大写占位。 :::

阶段 A：建隧道（一次性）

<div class="mermaid"> sequenceDiagram autonumber participant CLI as 你的终端 participant CLI2 as opentunnel client participant SRV as OpenTunnel Server<br/>(Fly.io :443) participant ACME as ZeroSSL (ACME) participant CF as Cloudflare DNS CLI->>CLI2: opentunnel route add 4096 CLI2->>SRV: POST /api/routes (申请隧道) SRV-->>CLI2: 返回 id，例如 3f2a... Note over CLI2,SRV: 分配唯一子域名 ID.opentunnel.xyz CLI2->>ACME: 申请证书 (ACME DNS-01) ACME->>CF: 验证 _acme-challenge TXT 记录 CF-->>ACME: 验证通过 ACME-->>CLI2: 下发证书 + 私钥（只给客户端） Note over CLI2: ★ 私钥永不离开本机 CLI2->>SRV: 建立 bridge WebSocket（携带密文通道） SRV-->>CLI2: 就绪，开始接收转发 CLI2-->>CLI: 打印 https://ROUTE(随机16位).ID.opentunnel.xyz </div>

注意 DNS-01 这一步：它不验证端口 80，不要求你有公网 IP，只验证 DNS 权限。 这是没有固定 IP 的家庭宽带能拿到正规证书的唯一途径。

路由名默认是 16 位随机字符，而且不会出现在公开的证书透明度（CT）日志里 —— 意味着没人能通过查 CT 日志反查出你的隧道地址。

opentunnel route add 4096
# Added route 21992cc9713e5fc5 → 127.0.0.1:4096
# https://21992cc9713e5fc5.3f2a91c4.opentunnel.xyz

curl -fsSL https://opentunnel.xyz/install | sh
brew install anomalyco/tap/opentunnel
yay -S opentunnel-bin              # Arch
npm install -g opentunnel
cargo install opentunnel-cli

</details>

阶段 B：手机发一条消息（每次）

<div class="mermaid"> sequenceDiagram autonumber participant M as 手机浏览器 participant S as OpenTunnel Server participant C as 本地 opentunnel client participant O as opencode server<br/>127.0.0.1:4096 M->>S: TCP 连接 443，TLS ClientHello<br/>SNI = ROUTE.ID.opentunnel.xyz Note over S: 只解析 SNI，其余字节看不懂也不看 S->>C: 经 bridge WebSocket 转发原始 ClientHello 密文 C->>C: ★ 用本地私钥终结 TLS，拿到明文 HTTP Note over C: 校验证书域名，握手完成 C->>O: HTTP 请求<br/>GET / (Authorization: Basic ...) Note over C,O: 应用看到的是 loopback 对端 O-->>C: 200 + OpenCode Web 界面 C->>S: 用会话密钥加密后回传 S-->>M: 原样转发（浏览器全程以为在直连服务端） </div>

:::note 最后一步是最舒服的地方：对浏览器来说，它就是访问一个普通的 https 站点。没有证书警告，没有客户端 App，没有 VPN 状态栏。它甚至不知道中间有个隧道。 :::

三、最要命的一步：那个随机 24 位密码

隧道跑通之后我差点裸奔到公网上。然后我意识到一个很要命的事实：

README 里写得很清楚： "Route names never appear in public certificate logs, so the URL can't be guessed, but anyone you share it with can reach the service: it is not authentication."

地址猜不出来 ≠ 有鉴权。地址泄露了 = 完全门户大开。

而 opencode 官方文档也直说了：

If OPENCODE_SERVER_PASSWORD is not set, the server will be unsecured. This is fine for local use but should be set for network access.

所以第一步就是打开 HTTP Basic 认证。用户名默认是 opencode，可以用 OPENCODE_SERVER_USERNAME 改。

密码怎么生成

密码强度必须对得起"这个地址现在挂在公网上"这件事。 别用 123456、别用手机号生日、别用你其他服务复用过的密码。

# Linux / macOS / WSL —— openssl 生成，18 字节 = base64 后正好 24 个字符
export OPENCODE_SERVER_PASSWORD=$(openssl rand -base64 18)

# 顺手看一眼长度，确认是 24
echo -n "$OPENCODE_SERVER_PASSWORD" | wc -c

18 字节 = 144 bit 熵，base64 编码后是 24 个字符，且没有 = 补位。这个长度刚好能在密码管理器里一眼输完，又足够长到爆破无望。

:::warning Windows 的 PowerShell 默认没有 openssl.exe（Windows 自带的是 OpenSSH，不是 OpenSSL）。用这个等效实现，长度同样是 24：

$b = New-Object byte[] 18
[System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($b)
$env:OPENCODE_SERVER_PASSWORD = [Convert]::ToBase64String($b).TrimEnd('=').Replace('+','-').Replace('/','_')

- 和 _ 的替换是为了避开 + /，这样密码在 URL、配置文件、shell 历史里都不需要转义。 :::

启动

# 只监听 localhost —— 有隧道就够了，不要在局域网里裸奔
OPENCODE_SERVER_PASSWORD="$OPENCODE_SERVER_PASSWORD" opencode serve --port 4096 --hostname 127.0.0.1

# 手机打开那个 https 网址，弹 Basic Auth
# 用户名：opencode
# 密码：你刚生成的那 24 位

--hostname 保持 127.0.0.1 是个原则性问题：暴露面只留隧道这一个口。你用隧道纯粹是为了穿越 NAT，不是为了让同 Wi-Fi 下的邻居也能连你。

还有一层：`--proxy-protocol`

默认情况下你的应用看到的是 loopback 对端，看不到真实来访 IP。OpenTunnel 官方专门写了份 trust-boundary 文档提醒这件事 —— 意思是：

如果你的应用里有任何基于 127.0.0.1 判断"这是本地可信请求"的逻辑，它在隧道后面是失效的。

需要传递真实来访者地址的话，客户端加：

opentunnel route add 4096 --proxy-protocol v2

只在你的应用确实支持 PROXY protocol 时才开。 乱开会往应用里塞它不认识的请求头。

四、串起来的完整命令

# 1. 生成 24 位密码并记住它
export OPENCODE_SERVER_PASSWORD=$(openssl rand -base64 18)

# 2. 起 opencode，只听 localhost，带 Basic Auth
OPENCODE_SERVER_PASSWORD="$OPENCODE_SERVER_PASSWORD" \
  opencode serve --port 4096 --hostname 127.0.0.1 &

# 3. 开隧道
opentunnel route add 4096
# https://21992cc9713e5fc5.3f2a91c4.opentunnel.xyz

# 4. 手机浏览器打开它，用 opencode / 你的密码登录

想两边同时用（电脑上看 TUI，手机上发消息），加一个终端 attach：

opencode attach http://localhost:4096

两个客户端共享同一份 session 状态，不是两个独立实例。

五、几个值得记的点

为什么是 blind TLS 而不是普通反代

	普通反代（ngrok 类）	Blind TLS（OpenTunnel）
服务端能看到明文	✅ 能	❌ 不能
服务端持有私钥	✅ 持有	❌ 没有
DNS-01 签发证书	依赖服务端	依赖客户端自己
被入侵后的损失	全部流量泄露	只有转发通道，没有内容
延迟	多一跳解密再加密	只读 SNI，开销极小

这本质上是把信任边界画在了正确的地方 —— 中转节点只负责"路由"，不负责"内容"。

它不是什么

不是 VPN。没有全局流量接管，你手机上只有这一个网址是"远程"的。
不是端口转发。只支持 HTTP 应用（"任何支持 TLS 的现代浏览器/设备"），不是任意 TCP。
不是零配置的安全方案。地址保密性来自不可猜测，不来自鉴权。密码必须设。

:::tip 既然是"限时/白嫖性质"的第三方服务，我的取舍是：可以用它做个人开发工具，但不要把生产系统的面板挂在上面。 它本质上是一个公共的流量中转，服务端不做任何端到端的身份认证 —— 信任链完全建立在你那 24 位密码上。 :::

小结

把 localhost 变成一个公网 https 地址，难点从来不是"穿透"，而是在不牺牲加密强度的前提下穿透。OpenTunnel 的答案是：让服务端看不懂数据，只让它认门牌号。

Blind TLS：服务端只读 SNI，证书私钥和明文永远留在本地
DNS-01 签发：不需要公网 IP、不需要域名、80 端口也不用开
16 位随机路由名 + 不进 CT 日志：地址不可枚举
但仍需鉴权：OPENCODE_SERVER_PASSWORD + 24 位随机密码，是这套方案成立的前提
--hostname 127.0.0.1：暴露面只留隧道一个入口

现在我出门在地铁上，动动手指就能给家里的 opencode 派活儿了。写完这段话，我马上试一次。

从 OpenCode 数据页捡漏：我怎么在 30 秒内判断一个免费模型值不值得用

Fri, 09 Oct 2026 00:00:00 GMT

刷 opencode.ai/data 的时候我发现一件事：这个页面远比"谁最火"有用得多。

它的定位是 OpenCode 官方公开的全平台遥测——每小时聚合一次，把每个模型的 token 量、独立用户数、周留存、单会话成本、缓存命中率全部摊开。这个东西平时不显山露水，但它其实是一份公开的、由真实负载产生的模型口碑数据。

我看这张表的方式，和大多数人不太一样。

一、大多数人只看第一眼

排行榜第一是 DeepSeek V4.1 Flash，过去 7 天 50T token。第二是 Muse Spark 1.3 Contributor，37T。第三是 space-bunny，21T。

所以"细心如我"注意到的是——一个没听过的名字，怎么能排到第三？

这个问题问对了。但只到这一步是不够的，因为排名本身信息量很低。

排名靠前可能是因为模型刚发布，热度还没退
也可能是因为少数重度用户刷出了大量 token，而非普通用户真的爱用
榜单是"token 总量"，而 token 总量 ≈ 使用人数 × 人均用量。人均用量差异可以到几十倍

所以关键问题是：这 21T 是一万个人的日常，还是一百个重度用户的肝？

二、真正该看的是留存率

页面底部有一张 Weekly retention 表，定义是：

某模型本周的用户中，下周还在用它的比例。

这才是"好不好用"的直接度量。一个新工具的留存高，说明它进了工作流；留存低，说明大家只是来试新鲜的。

排名	模型	周留存	有效样本
1	MiMo-V2.6-Flash	80.3%	2.8K
2	space-bunny	80.0%	8.2K
3	Muse Spark 1.2 Contributor	78.3%	9.1K
4	Kimi K2.5	77.1%	214
8	DeepSeek V4 Flash	69.3%	272K
11	Muse Spark 1.3 Contributor	67.0%	41K
14	GPT-6 Luna	65.2%	3.5K

这里有两层信息，第二层更值钱：

space-bunny 留存 80%，排第二 —— 一个"限时免费"的模型，能拿到 80% 的周留存，说明它不是薅完就走。
但排行榜冠军 DeepSeek V4 Flash 只有 69.3% —— token 量是 space-bunny 的两倍多，留存却低了 11 个百分点。

注意样本量那一列。DeepSeek 有 27 万个有效用户周，space-bunny 只有 8200。大样本的低留存，比小样本的高留存更可信。

[!IMPORTANT] 榜单告诉你"谁在被用"，留存告诉你"谁被留住了"。前者是流量，后者是产品。

三、把两条曲线叠起来看，才有意思

我把 space-bunny 上线以来（约 9/23）的每日数据拉出来画了一遍：

Token 量（单位 T）：

<div class="mermaid"> xychart-beta title "space-bunny 每日 token 量（单位 T）" x-axis ["9/23","9/30","10/7","10/13"] y-axis "T tokens" 0 --> 11 bar [1.5, 10, 3.9, 3.1] line [1.5, 10, 3.9, 3.1] </div>

日活用户（单位 K）：

<div class="mermaid"> xychart-beta title "space-bunny 日活独立用户（单位 K）" x-axis ["9/23","9/30","10/7","10/13"] y-axis "K users" 0 --> 55 bar [6.9, 50, 25, 19] line [6.9, 50, 25, 19] </div>

把这两张图放一起看，出现了一个很有意思的现象：

10 月初的 10T/天是发布红利，峰值日活 5 万
到了 10/13，token 掉到 3.1T（约 -70%），但日活只掉到 1.9 万（约 -62%）
同期大盘 rank 从 #3 一路掉下来（周环比 -62%）

token 跌幅大于用户跌幅。这意味着：

掉走的是重度用户，留下的是日常用户。

这个结论和 80% 的周留存互相印证 —— 产品本身没垮，只是最初那批薅得最狠的人额度用完了。

读数据到这个程度，才算真的看懂了。

四、还有两个数字：成本和缓存

页面上还有一张 Session cost 表，把"平均每个会话花多少钱"和"平均每个会话多少 token"放在一起：

模型	平均单会话成本	平均单会话 token
space-bunny	$0.0005	778K
mimo-v2.6-flash	$0.0022	1.2M
muse-spark-1.3-contributor	$0.0032	2.2M
deepseek-v4-flash	$0.0286	3.1M
deepseek-v4.1-flash	$0.0500	3.7M
glm-5.3-flash	$0.0851	2.1M

space-bunny 的单会话成本是 DeepSeek V4.1 Flash 的 1/100，而单会话 token 只有它的 1/5 左右。

这直接解释了我体感上的一个疑问：为什么用 space-bunny 感觉更省 token？

再看 Cache ratio：

模型	输入走缓存的比例	缓存 token	未缓存 token
space-bunny	96.6%	20T	709B
deepseek-v4.1-flash	96.1%	48T	1.9T
muse-spark-1.3-contributor	95.3%	35T	1.7T

全平台都在 90% 以上，说明 opencode 的 prompt cache 机制对所有模型都生效。但 space-bunny 的 未缓存输入只有 709B，是所有模型里最低的。

[!TIP] 在 agent 场景里，缓存命中率才是 token 账单的主控变量。一次多轮工具调用的会话，真正的"新信息"往往只有几千 token，其余全是重复的上下文。缓存命中率高 = 你少付 90% 的钱。

这就是为什么我现在觉得 opencode 这套 harness 体感上比 deepseek harness 省 token —— 底层模型差不多，harness 怎么组织 prompt、怎么触发缓存，差出好几倍。

至于"智力"，OpenCode 官方的描述是：space-bunny 是个stealth model（未公布身份的模型），1M 上下文、支持多模态、Zero Data Retention（零数据保留），通过 OpenCode Zen 限时免费提供。

零数据保留这一点对把代码喂给模型的人很重要 —— 官方承诺不留存，我在写一些内部逻辑的时候顾虑就少很多。

五、这套方法可以复用到任何"选型"决策上

把这张表的读法抽出来，它其实是四个通用动作：

1. 看绝对量  →  这个东西有多少人在用？      （看规模，不看排名）
2. 看留存    →  用过的人还回来吗？          （看是否进了工作流）
3. 看单会话  →  一次典型任务花多少钱？      （看真实成本，不是标价）
4. 看分母    →  样本量够不够支撑这个结论？  （防止被小样本骗）

第 4 步是最容易被跳过、也最值钱的一步。前面那张留存榜里，Kimi K2.5 的留存是 77.1%，比 DeepSeek 高出 8 个点 —— 但它的有效样本只有 214 个用户周。这跟"272K 用户周下的 69.3%"是完全不同量级的证据。

:::warning 这张表是 OpenCode 平台的遥测，只代表 opencode 用户的使用模式。你在别的客户端（比如 Claude Code）用同一个模型，结论可能不一样。它的价值在于样本量大、更新快、免费公开 —— 而不是"官方认证的排行榜"。 :::

最后

DeepSeek 现在的模型确实强得离谱，50T token 的周总量和断档式领先的性价比是实打实的。但这次翻数据页最大的收获不是"哪个模型第一"，而是意识到：

判断一个模型好不好用，看榜单是不作数的，要看留存、单会话成本和缓存命中。

space-bunny 是个限时免费的模型，随时可能收费。作为免费轮，它的体感确实是目前 OpenCode 里第一档的 —— 响应快、脑子够用、还零留存。等它收费了，我大概还是会回到 DeepSeek。

但至少现在，我知道自己用的是不是真的好，而不是被热度推着走。

把知乎收藏变成知识图谱：导出 → AI 整理 → GitHub 存档

Thu, 08 Oct 2026 00:00:00 GMT

知乎收藏夹是我用得最狠的功能，也是最容易出事的地方：收藏的时候爽，三个月后再也找不到。

平台不给导出，收藏夹里的文章随时可能被作者删除，链接会 404。所以我这两年一直在做一件事：把它变成自己的资产。

最近把整条链路跑通了，简单说就是三步：

知乎收藏夹  ──导出──>  本地 Markdown  ──AI 整理──>  知识图谱  ──git push──>  GitHub
   （随时会消失）      （Obsidian 直接能看）      （关系被显式化）        （有历史、可回滚）

一、找导出工具：知乎没有官方出口

知乎至今没有给用户任何官方导出接口。收藏夹只是渲染出来给你看的页面数据，所以工具只能走两条路：

路线	做法	优点	痛点
抓 HTML	请求文章页，用 CSS 选择器抠正文	实现简单	选择器一改就全废；知乎反爬会 403
走 API	直接打 `/api/v4/...` 这类内部接口	快、结构化、字段干净	需要 Cookie，容易被风控

我用的这个项目把两条路都做了兜底 —— Export-Zhihu-Collections（JasonJarvan/Zhihu-Collections-MCP）。它后来干脆把整套能力包成了一个 MCP Server，这一点后面会用到。

它的关键设计：

输出结构是给 Obsidian 看的

downloads/
├── 编程/                      ← 一个收藏夹一个目录
│   ├── xxx.md                 ← 一篇一个文件
│   └── assets/
│       ├── 20240101120000.jpg ← 图片本地化，不再依赖知乎 CDN
│       └── ...
├── logs/
└── debug/                     ← 解析失败的页面 HTML 存这里，方便复盘

图片必须本地化。这不是洁癖：知乎的图片 URL 带鉴权参数且会过期，你把 md 存到本地，半年后打开是一堆裂图，等于没存。

私密收藏夹靠 Cookie

[
  {"name": "z_c0", "value": "你的值"}
]

存成 cookies.json 放项目根目录。这个文件等同于你的知乎登录态，别提交到公开仓库。

403 自动降级

HTML 被拦了，自动改走 API；专栏文章走流式下载（几万字带图的长文一次性拉容易断），再加 3 次重试。

去重

跑第二遍不会重复下载。它会检查目标文件是否已存在。

<details> <summary>安装与运行</summary>

git clone https://github.com/JasonJarvan/Zhihu-Collections-MCP
cd Zhihu-Collections-MCP
pip install -r requirements.txt

# 先让脚本自动扫出你的所有收藏夹，写回 config.json
python fetch_collections.py

# 编辑 config.json：确认收藏夹列表 + 输出路径
python main.py

Windows 路径两种写法都认：

{ "outputPath": "D:\\Documents\\ZhihuExports" }
{ "outputPath": "D:/Documents/ZhihuExports" }

</details>

跑完的体感

几百篇下来，真正"抓不到"的只有两类：已删除和需要登录才能看的盐选。剩下 95% 以上都干净落盘了。剩下那些会在 debug/ 里留下现场 HTML，你 F12 一比就知道是 404 还是权限问题。

二、光有 Markdown 不够

导出完成那一刻会有一种错觉：搞定了。

其实没有。你得到的是一千个孤立的文件，而不是知识。它们之间没有任何关系，你收藏过的"什么是 Raft 协议"和"Paxos 论文精读"之间可能存在很强的关联，但 Markdown 不会告诉你。

Obsidian 的图谱视图为什么让人上瘾，就是因为它把这些隐式关系画出来了。但它需要你先手动插链接 —— 一千篇手动插？不可能。

所以第二步是：让 AI 读一遍，生成关系。

我把这个导出工具以 MCP Server 的形式挂给了 Hermes：

{
  "mcpServers": {
    "zhihu-collections": {
      "command": "python",
      "args": ["mcp_server.py"],
      "cwd": "你的项目路径"
    }
  }
}

暴露出来四个工具：

工具	作用
`list_collections`	列出所有收藏夹
`get_collection_info`	收藏夹基本信息（文章数等）
`search_collections`	按关键词搜收藏夹
`export_collection`	导出指定收藏夹为 Markdown

这一步的意义在于：Agent 拿到的不再是"一堆待处理的文件"，而是"一个能按需调用的知识源"。它可以边读边决定下一批导出哪几个收藏夹。

导出完之后，让 Hermes 扫全量 Markdown，产出三样东西：

主题聚类 —— 把零散文章归到有限几个主题下
实体与关系 —— 抽概念、建 [[Obsidian 双链]]
一张入口笔记 —— 每个主题一个 hub 笔记，链到具体文章

产出的知识图谱长这样（结构示意）：

              ┌─────────────┐
              │ 分布式共识  │  ← hub 笔记
              └──────┬──────┘
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
  ┌────────┐   ┌──────────┐   ┌────────┐
  │ Raft   │◄─►│ Paxos    │◄─►│ 线性一致│
  └────┬───┘   └──────────┘   └────┬───┘
       │                            │
       ▼                            ▼
  ┌──────────┐              ┌────────────┐
  │ 领导选举  │─────────────►│ CAP 定理    │
  └──────────┘              └────────────┘

这里有个反直觉的点，值得单独说：

AI 生成的知识图谱质量，取决于它读到的是不是全文。

如果导出的是摘要或者列表页文本，图谱就是"标题聚类"，毫无价值。正是因为工具把正文完整落地了，Agent 才能读懂内容、发现文章之间真正的语义关联。

三、推上 GitHub：给知识加时间维度

最后一步是很多人会跳过的，也是我认为最值钱的一步。

cd ZhihuExports
git init
git add .
git commit -m "sync: 2026-10-08 知乎收藏快照"
git push -u origin git@github.com:devycx/my-zhihu-library.git

GitHub 在这里承担三件事：

1. 版本化 = 知识快照的时间轴

每条 commit 是一次快照。你能精确回答"我什么时候读过 Raft 那篇论文""三个月前我到底收藏了什么"。知乎只会告诉你"你收藏了 800 条"，没有时间维度。

2. 可回滚

知乎文章被作者删了，但你本地有。导出工具某次改坏了格式，重新 clone 一下就回来了。

3. 二次加工的入口

知识图谱是可再生的，但原始 Markdown 不是。有了 GitHub 仓库，我随时可以换一个 Agent、换一套 schema 重新生成图谱，而不用重新抓一遍知乎 —— 知乎的反爬策略是会变的，下次可能就抓不动了。

仓库结构建议

my-zhihu-library/
├── exports/              # 原始导出，尽量不动
│   └── 2026-10-08/      # 按快照日期分目录
├── graph/                # AI 产出的知识图谱
│   ├── 分布式共识.md
│   └── index.md
├── README.md
└── .gitignore
    └── cookies.json      # 关键

把原始数据和加工结果分开，是让图谱能被反复重做的前提。

几个安全上的注意点

:::warning 导出的 Markdown 里通常带作者名、原文链接，部分还有你自己加的批注。如果仓库设为 Public，等于把个人知识库和阅读偏好公开了。我的做法是设成 Private。 :::

:::tip cookies.json 一定要写进 .gitignore。一次 git add . 手滑，它就变成永久历史了 —— 删文件是不够的，要 git filter-repo 或者干脆重建仓库。 :::

四、这套流程其实可以复用

抽象一下，这套东西跟"知乎"没有任何关系：

任意内容源  →  结构化落地  →  LLM 抽取关系  →  版本化仓库

内容源换成 Notion 导出、微信读书书签、YouTube 播放列表、Pocket
结构化落地换成任意导出脚本
后两步一模一样

真正决定产出质量的是第一步落下来的东西够不够完整。抓取的时候多花点心思，别让清洗的活儿留给后面的 AI。

小结

知乎没有官方导出，工具必须自己解决 HTML / API 双通道 + Cookie + 图片本地化 + 断点续传 这四件事
MCP Server 的意义是让 AI 按需调用知识源，而不是一次性喂一堆文件
图谱的价值来自全文，不是标题 —— 抓取质量决定图谱质量
推 GitHub 不只是备份，是给知识库装上时间轴，并保留重新加工的自由

收藏的价值不在于存，在于还能被再次找到。而"再次找到"这件事，本质上就是给散落的碎片补上关系。

YCX's Blog

F12 抓包发现「视频伪装成图片」，以及 .ts 文件和 BOM 到底是什么

一、Network 面板里滚动的全是「图片」

二、动手：改后缀 + 补 BOM

三、.ts 到底是个什么文件

它的核心特征：固定长度包 + 同步字节

流媒体里它在哪儿

四、BOM 是什么：先说狭义，再说广义

狭义：BOM = Byte Order Mark

广义：BOM = 文件魔数（magic number / 文件签名）

五、这招究竟骗过了谁 —— 一个需要诚实拆开的部分

那 Quetta 的下载按钮为什么没弹

六、Quetta 本身值在哪

七、总结这一个小结

别从零写博客：fork 一个 Astro 模板，再让 CI 替你把关

一、Astro 是 Cloudflare 官方推荐的框架

二、CI 只做三件事，每件都有明确边界

CI 里不跑 astro build

流水线 1：astro check —— 类型检查

流水线 2：Biome 代码质量

流水线 3：IndexNow —— 主动推送给搜索引擎

附赠：Dependabot

三、整条链路跑起来的样子

四、我在这个过程中做的减法

小int小结

GitHub + Cloudflare Pages：零成本、无备案、全球 CDN 的个人博客

一、整条链路长什么样

二、免费额度到底有多少

三、为什么不用备案

那域名要不要买

四、顺手白嫖的 Cloudflare 设施

1. Pages Functions + KV 做阅读量

2. Web Analytics

3. OAuth 中转 Worker

4. 用不到的（因为要绑卡）

五、Cloudflare Pages 部署 Astro 的几个坑

坑 1：Node 版本不一致导致构建失败

坑 2：包管理器必须一致

坑 3：自定义响应头（CSP）用错文件名

坑 4：构建失败时线上是完好的

六、为什么源码一定放 GitHub

小结

在已经部署好的博客上写博客，然后自动流回 GitHub

一、为什么选 Sveltia 而不是自己写后台

二、挂进站点：它只是一个静态文件

三、配置：告诉它写到哪去

四、OAuth 中转 Worker：为什么必须搞一个

五、保存一篇文章的完整时序

六、卡了我两天的那个坑

七、这套方案的边界

小结

智谱新用户到底送了多少 token？我把资源包页面拉出来数了一遍

一、实际发了几个包

二、这 6 个包不是"通用货币"

三、4 天烧完

四、怎么用才不亏

五、一个额外发现：他们卖的是"尝鲜包"

小结

连上 Wi-Fi 才启动 VPN：Windows 计划任务的两个默认陷阱

一、为什么 TUN 模式的 VPN 会让图书馆连不上网

TUN 模式在干什么

但图书馆的 WLAN 有一个特殊之处

具体的死法有几种，通常几个一起

二、解法：把 VPN 启动推迟到"网络就绪之后"

三、你问的那两个坑：你的理解是对的，而且很常见

坑 1：默认 72 小时后任务被杀掉

坑 2：拔电源会停任务

顺带第三个坑：IdleSettings

四、EventID 10000 的两个副作用

它不只对 Wi-Fi 触发

事件日志通道必须处于启用状态

五、排查这类问题的通用顺序

小结

DeepSeek 注册送 0 元？去它自家 Harness 领 6 块

一、先确认一下：开放平台确实没赠送了

二、Harness 是什么

三、6 元怎么领

四、6 块能用多久

五、一个让我更在意的点：Harness 本身

一切皆插件

三、`.ts` 到底是个什么文件

CI 里不跑 `astro build`

流水线 1：`astro check` —— 类型检查

还有一层：`--proxy-protocol`