2026-06-21 日志：Cloudflare 全家桶、两版潜意识指南、不玩手机定时器

一、Cloudflare Pages：从 GitHub Actions 到手动 wrangler 的最短路径

1.1 起因

博客原来部署在 GitHub Pages（ningfeiyu.github.io），后来把自定义域名 ningop.com 迁到 Cloudflare Pages。GitHub Actions 里的 cf-pages.yml 虽然配了 CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID，但跑完总是失败，日志里只报 Authentication error [code: 10000]。

1.2 关键发现

• wrangler 登录状态存在冲突：/root/.wrangler/config/default.toml 里存了旧 token cfut_iHVZ9SYSX9aPZB8r7mI9xNbcExWZHt0detRIz9GCf30162b5（这是能 deploy 的 token）；但 GitHub Actions 用的是另一个 token cfut_oCG3kDEzfUVzWpQ9ChGl5qTLJjL2Lv85wf47wIXqbcee95e5（只有 Worker Scripts Edit，不能 Pages Deploy）。
• 本地环境变量会覆盖配置文件：跑 npx wrangler pages deploy 时如果 export CLOUDFLARE_API_TOKEN=...，会导致认证失败；不设 env var、直接用配置文件里的 token 反而能过。

1.3 最终可用命令

# 本地构建 + 部署（无需 export token）
cd /root/ningfeiyu.github.io
hugo --buildFuture
unset CLOUDFLARE_API_TOKEN
npx wrangler pages deploy public --project-name=ningop-blog --branch=main

1.4 GitHub Actions 还要不要留？

留着，但只做 hugo --buildFuture 构建产物检查；真正部署靠 wrangler。以后要全自动，得在 GitHub Secrets 里存对的 Pages Deploy token（需要 Account > Cloudflare Pages > Edit 权限）。

二、transfer-api Worker：UNLIMITED_SURF_API_KEY & WORKER_API_KEY 的关系

把 transfer-api（unlimited.surf → OpenAI/Anthropic 兼容中转）部署到 unlimited-transfer-api.eri.workers.dev。

2.1 两个 Secret 的作用

2.2 逻辑（代码里写死）

// validateWorkerApiKey
if (env.WORKER_API_KEY) {
  // 设置了 WORKER_API_KEY → 客户端必须传这个，否则 401
  // Worker 内部用 UNLIMITED_SURF_API_KEY 请求上游
} else {
  // 没设置 → 客户端传任意 key（或不传）都行
  // Worker 直接用 UNLIMITED_SURF_API_KEY 请求上游
}

2.3 今天踩的坑

• 手动在 Dashboard 加了 WORKER_API_KEY（值写成了 xx_xzl...，其实想复用上游 key）→ 导致所有请求 401，因为客户端传的是 ua_xzl...（上游 key），不匹配。
• 解法：Dashboard 删掉 WORKER_API_KEY → Worker 回到兼容模式 → 客户端传 ua_xzl... 直接能用。

2.4 验证通过的端点

# 健康检查
curl https://unlimited-transfer-api.eri.workers.dev/health
# {"ok":true,"worker":"unlimited-transfer-api"}

# 模型列表（OpenAI 兼容）
curl https://unlimited-transfer-api.eri.workers.dev/v1/models

# Anthropic 兼容
curl https://unlimited-transfer-api.eri.workers.dev/v1/messages \
  -H "Authorization: Bearer ua_xzlV4MJYfn9JDjacEPXcQrFaYEWCS0or" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-opus-4-7-20260101","messages":[{"role":"user","content":"PONG"}]}'

三、潜意识改造指南：两个版本、同一天上线

3.1 版本 1：90 天工程版（subconscious-reprogramming-guide）

• 核心：视觉化 + 重复 + 情绪深度
• 结构：识别隐性程序 → 三把钥匙 → 晨晚 7/9 分钟 → 90 天三阶段 → 5 个陷阱 → AI 加速
• 适合：想要完整体系、愿意长期执行的人

3.2 版本 2：72 小时 AI 压缩版（subconscious-ai-programming）

• 核心：把 LLM 当「潜意识编译器」，AI 生成音频脚本 + Agent cron 推送 + 具身 prompt
• 结构：72 小时三天计划 → 3 条 AI 安全守则 → 5 个反直觉 → 接 90 天长程
• 适合：想快速看到效果、习惯用 AI 工具的人

3.3 共同的坑：日期写错

两篇 frontmatter 都写了 2025-06-15，Hugo 按日期倒序分页（pagerSize = 5），导致首页完全不显示新文（排到第 3-4 页）。 修正：改成 2026-06-19 / 2026-06-21 → 重新构建部署 → 首页即刻出现。

最佳实践：写新文时，先改日期为今天，再写内容。

四、每日 7 点不玩手机：cron 定时器的时区坑

4.1 创建任务

cronjob create \
  --name "提醒不玩手机" \
  --schedule "0 7 * * *" \
  --deliver telegram \
  --prompt "每天 7 点发一条不玩手机提醒..."

4.2 为什么没触发

• Hermes cron 用服务器时区（EDT，UTC-4），不是北京时间
• 0 7 * * * 在 EDT = 北京时间 19:00
• 当时是北京 09:13，当然没触发

4.3 修正

北京 7:00 = EDT 前一天 19:00 → cron 应写 0 19 * * *

cronjob update --job_id e901a7be5fa2 --schedule "0 19 * * *"

4.4 经验

Hermes cron 没有时区参数，只认服务器时区。
要北京时间 HH:MM → 算出 EDT 时间（北京 - 12h，夏令时），再写 cron。

五、今天可复用的「最小可行配置清单」

5.1 博客部署

# 1. 写文章（日期=今天）
# 2. 本地化图片
python3 scripts/localize_images.py content/posts/xxx.md
# 3. 构建
hugo --buildFuture
# 4. 部署（别 export token）
unset CLOUDFLARE_API_TOKEN
npx wrangler pages deploy public --project-name=ningop-blog --branch=main

5.2 Worker 部署

cd /root/transfer-api
# 只需设 UNLIMITED_SURF_API_KEY（Dashboard 或 wrangler secret put）
# WORKER_API_KEY 故意不设 → 兼容模式最省事
npx wrangler deploy

5.3 定时提醒

# 北京 7:00 = EDT 19:00
cronjob create --schedule "0 19 * * *" --deliver telegram ...

六、明天的 3 件事

1. GitHub Actions 存对的 Pages Deploy token，跑通全自动 push→deploy
2. 把 transfer-api 的 wrangler.toml 里的 account_id 补上，本地部署不再依赖 .wrangler/config
3. 早 7 点不玩手机，看一眼日出/天空，做完今天最重要的 1 项任务再碰手机

今天最大的收获不是部署通了，而是搞清楚了 「哪个 token 能干什么」、「时区怎么换算」、「日期写错会发生什么」——这些坑下次不会再踩了。