迁移之后会发生什么：8 天的复利回报
我把博客迁移到 Next.js 后，以为最难的部分已经结束。结果真正的复利才刚开始：6 篇超大指南、更聪明的 AI 助手、原生 newsletter、机器人防护和 SEO 全面升级，全都发生在 8 天内。
8 天前，我用 4 天重建了整个博客后端。我把 485 篇 WordPress 文章迁移到 Next.js，让 Sydney（我的 AI 聊天机器人）重新上线，并把生产站点发布了。
我当时以为故事到这里就差不多了。迁移完成，庆祝一下，继续下一个项目。
我错了。迁移不是终点，而是起跑线。
下面是我网站在 2 月 5 日和今天（2 月 13 日）的对比：
| 功能 | 2 月 5 日（迁移日） | 2 月 13 日（今天） |
|---|---|---|
| 博客文章数 | 485（从 WordPress 迁移） | 492（新增 6 篇超级指南） |
| Sydney AI | 基础 RAG，质量未系统验证 | 已评估、已优化、命中率 81% |
| Newsletter | Beehiiv 嵌入（第三方） | 原生 Supabase + Resend，按兴趣分发 |
| SEO | 基础 sitemap + meta tags | 结构化数据、FAQ schema、llms.txt、AEO |
| 安全 | 仅限流 | Cloudflare Turnstile + 限流 |
| 性能 | 基础 Lighthouse 检查 | 用 Chrome DevTools MCP 做系统化剖析 |
| 特色图 | 手工制作 | AI 生成流水线（Gemini + 自动优化） |
这些改进之所以发生，是因为前一个改进让下一个改进更容易。这就是我原本没预料到的“复利”。
真正的解锁点：你的博客现在是“代码”
从 WordPress 迁到代码栈后，有件事很少有人会提前告诉你：迁移本身不是重点。 真正的重点是迁移后你突然能做到的事。
当你的博客变成 Git 仓库里的 492 个 MDX 文件，而不是 MySQL 数据库里的几百行记录时，一切都会变：
- 每篇文章都是文件：Claude Code 可以大规模读取、搜索和修改
- 每次改动都是 diff：你能精确审查到底改了什么，甚至一次看 50 篇文章
- 每个功能都能组合：newsletter 系统可以直接读取和 AI 聊天机器人同一份文章 metadata
- 每次发布都是命令：
pnpm build && vercel --prod，结束
在 WordPress 里，改 12 篇文章意味着登录 wp-admin，逐篇点开、逐篇修改、逐篇更新，重复 12 次。现在用 MDX + Claude Code？我只要说一句“在现有 12 篇国家公园指南里都加上国家公园 pillar post 的链接”，它就会逐文件读取、在合适上下文里插入合适 cross-link，再把 diff 给我看。12 篇更新，几分钟。
这才是真正的解锁点。不是迁移本身，而是迁移后获得的速度。
4 天写完 6 篇超级指南
迁移后我第一件事是什么？写内容，而且是大量内容。
我已经想写 expat 系列综合指南好几个月了。那种 2,000-4,000 字、真正能帮到准备搬去美国的人处理复杂问题的 pillar post。之前在 WordPress 里做这件事很痛苦：每篇都要手动排版、上传图片、配置 SEO 插件、管理分类。
现在？流水线是这样的：
- 头脑风暴文章结构和大纲
- 写作完整 MDX，并把 SEO/AEO 优化直接写进结构
- 生成特色图：Claude 先读文章，再写 prompt 发给 Gemini 出图
- 优化图片：Python 脚本转 WebP 并压缩
- 上传到 Vercel Blob
- 发布：
git push、vercel --prod、pnpm db:publish - Sydney 立刻可检索：文章同步进 Supabase 并生成 embeddings
这 4 天里发布的内容：
| 文章 | 主题 | 字数 |
|---|---|---|
| Healthcare Guide | 解释 HSA、FSA 与 HDHP | ~3,200 |
| Credit Building | 从零到 720+ 信用分 | ~3,500 |
| Savings & Investing | T-Bills vs HYSA 全面拆解 | ~2,800 |
| Credit Card Rewards | 积分、里程、返现策略 | ~3,000 |
| Relocation Guide | 搬去美国全流程指南 | ~3,800 |
| National Parks | 26 个公园、4 条自驾线 | ~4,200 |
每篇都遵循同一套 AEO 模式：先给答案的开场、对比表、120-180 字的小节、加粗定义、文末 FAQ schema。这类结构是获得 340% 更高 AI 引用率的关键。
国家公园那篇最大，是一个 pillar post，并且回链了我之前写的 12 篇公园评测。我还专门给它做了一个 PhotoGallery 组件，因为连着滚 20 张独立图片真的很难看。现在是干净的网格 + lightbox。简单，但非常有效。
Sydney 变聪明了
我在迁移期间把 Sydney 拉回线上时，她是“能用”的，而且上线前我做过手动测试。她能回答问题、能找相关帖子、能给引用。但手动测试最多告诉你“看起来还行”，它不会告诉你到底“行到什么程度”，也不会告诉你哪里有缺口、如何系统优化。
我当时没有一套可量化的质量评估方法。而没有量化，就没有持续优化。
所以我做了一个 RAG 评估框架。32 条测试查询，覆盖 12 个类别，每条都有我手工整理的 expected results。比如问 “What credit cards should expats get?” 就应该命中 credit building 指南；问 “Tell me about Yosemite” 就应该命中 Yosemite 游记。
然后我测了 30 组不同配置组合：6 个 similarity threshold × 5 个 result count，统一测 hit rate、precision 和 temporal diversity。
结果非常扎眼：
| 指标 | 优化前（默认） | 优化后 |
|---|---|---|
| 命中率 | ~30% | 81.2% |
| 零命中查询 | 30 条里 6 条 | 30 条里 0 条 |
| 时间跨度 | 1.2 年 | 6.7 年 |
最大的坑甚至有点尴尬：OpenAI SDK 在 Next.js 里会静默丢掉 dimensions 参数。Sydney 生成的是 1536 维 embedding，却在 384 维索引里做检索。结果差也就不奇怪了。改成直接 fetch() 调用后，一夜之间就修好。
我还把 Sydney 的 system prompt 扩到了 490+ 篇博客主题。她现在不只懂 AI 和营销，也覆盖国家公园、信用卡、医疗体系和完整 expat 内容库。
你可以用这两个命令自己测：
pnpm eval:rag # 测本地 Supabase
pnpm eval:rag:prod # 测生产环境
现在我终于可以真正衡量“Sydney 有没有变聪明”。这种基础设施，在 WordPress 时代你基本不会去搭。
大规模 SEO + AEO
2026 年做 SEO，不再只看 Google。你还得争取在 ChatGPT、Perplexity、Claude 回答用户问题时被引用。
我在一个周末内把完整 SEO/AEO 栈落地：
传统搜索层：
- 动态 sitemap（639 个页面被索引）
- 结构化数据：Person、WebSite、Article、BreadcrumbList、FAQPage
- RSS feed 分发
- Google Search Console 完成验证
AI 引擎层（AEO/GEO）：
llms.txt：给 AI crawler 的优先内容导航（robots.txt里 GPTBot、Claude-Web、PerplexityBot 都放行）- 每个章节开头都用 answer-first 模式（前 150 字先给关键结论，并加粗）
- 用问题式 H2，对齐用户向 AI 提问的真实表达
- FAQ 区自动识别并渲染为 FAQPage schema
性能层：
我用 Chrome DevTools MCP 对不同页面类型做 profiling：首页、博客列表、文章详情、/ask 页面，逐项定位瓶颈。能在同一个 Claude Code 会话里完成性能 trace、分析、修复，效率高得有点离谱。
结果就是：我现在每篇新文章都会自动带上结构化数据、（有 FAQ 时）自动生成 FAQ schema、并按 AI 可提取格式写作。没有插件，没有手动配置，这是站点的默认行为。
Beehiiv 下线，原生 Newsletter 上线
这件事也挺出乎我意料。我原本在 Beehiiv 上的 newsletter 是“能跑”的：能收邮箱、能发更新。那为什么还要替换？
三个原因：
- 控制权：我需要按兴趣订阅。订阅 “AI & Technology” 的用户不该收到国家公园内容。Beehiiv 免费版做不到。
- 集成性：订阅者数据现在和 Sydney 搜索索引放在同一个 Supabase 数据库里。单一数据源。
- 成本：Supabase（免费层）+ Resend（低量免费层）= 每月 $0。
我做出来的系统包括：
- 双重确认（double opt-in）：订阅 → 验证邮件 → 确认成功 → 欢迎邮件 + 个性化推荐
- 5 个兴趣组：AI、Expat Life、Leadership、Marketing、Travel & National Parks
- 智能匹配：文章分类自动映射兴趣组。我发信用卡指南时，只会通知 “Expat Life” 订阅者
- 每日 cron：Vercel 每天 11 AM PST 跑任务，查过去 48 小时新帖并定向发送
- 去重：
notification_log表确保不会重复发邮件
最实用的细节是：每篇文章底部的订阅表单会根据文章分类自动预选兴趣。比如你在读 AI 文章，滚到订阅区时，“AI & Technology” 的选项已经自动勾上。
听起来从零搭这套系统会很重？实际是一个晚上高强度工作。Supabase migration、API routes、email templates、cron job，Claude Code 搭好了骨架，我把精力放在逻辑和文案上。
安全：平时看不见，出事就来不及
你有一个公开 AI 聊天入口 + 一个 newsletter 订阅入口，机器人一定会盯上。限流我原本就有（Upstash Redis，每分钟 5 次），但我还是想再加一层。
于是上了 Cloudflare Turnstile。它是“隐形 CAPTCHA”：只有系统怀疑可疑访问时才弹 challenge。99% 正常访客完全无感。对机器人来说，就是一道墙。
我先把它接进 /ask（Sydney chat），然后把同一套模式原样复用到 /api/subscribe。同一套验证库，同一套 graceful degradation：
- 环境变量没配置：直接 bypass（本地开发不受影响）
- Cloudflare API 宕机：fail-open（限流作为 fallback）
- Secret key 已配置但 token 缺失：直接拒绝（拦截绕过前端的机器人请求）
可复用性是这段复利故事的关键。newsletter 的 Turnstile 集成只花了几分钟，不是几小时，因为 Sydney 那边的基础设施已经在了。
复利效应
下面这条链路不是我预先规划出来的，而是自然发生的：
迁移到 Next.js（2 月 1-5）
└─→ MDX 文件让 Claude Code 能规模化读改内容
└─→ 6 篇 SEO/AEO 优化超级指南发布（2 月 6-11）
└─→ 新内容暴露 Sydney 搜索质量问题
└─→ 建立 RAG 评估框架并优化 Sydney（2 月 11）
└─→ 内容变多后需要更好的分发（不能只靠 Beehiiv）
└─→ 在 Supabase 上做原生 newsletter（2 月 12）
└─→ 公开端点需要机器人防护
└─→ Sydney + subscribe 接入 Turnstile（2 月 12-13）
这些并不是按顺序计划好的。每一步都会暴露下一步的需求。迁移让写内容变快；内容变快暴露搜索质量问题；搜索修好后你自然想把分发也升级；分发升级后就需要防护。
这就是复利。 每一次改进都不只是“增加一点价值”，而是放大之前所有改进的价值。 :)
而这条链路背后的共同点是什么？我网站的每个部分现在都是“代码”，都可以被程序化读取、测试和修改。这才是最核心的解锁点。
数据汇总
因为我知道你会问：
| 指标 | 数值 |
|---|---|
| 距离迁移完成的天数 | 8 |
| 新增博客文章 | 7（含本文） |
| 新增功能 | 6（newsletter、Turnstile ×2、RAG eval、SEO 栈、PhotoGallery） |
| 更新过的旧文章 | 12+（cross-link、坏链修复） |
| 新增代码行数 | ~5,600 |
| 新增数据库表 | 2（subscribers、notification_log） |
| 新增 API 端点 | 4（subscribe、verify、unsubscribe、cron） |
| 成本增加 | $0/月（全部免费层） |
下一步
我还没做完。复利还在继续：
- 更多 expat 指南：税务策略、签证时间线、银行对比，这个系列还有很长空间
- 让 Sydney 再变聪明：既然现在能量化，我想把 hit rate 推过 90%
- 更多 AI build 深度记录：工具几乎每周都在变，我会边做边写（最新一篇是不会 Swift 做原生 iOS App，结论依旧是：AI 能做 60%，剩下 40% 才是产品）
但老实说，我现在最兴奋的是继续写作。17 年博客生涯里，这是我第一次觉得“发新文章”真的很快乐，而不是一次 45 分钟的 WordPress 体力活。 :D
你有没有经历过这种“迁移或重大技术决策之后的复利效应”？我很好奇：你遇到的第一个“意料之外的解锁点”是什么？
致敬，
Chandler
常见问题（FAQ）
网站开发里的“复利效应”是什么意思？
复利效应指的是：你对网站的每一次改进，都会让下一次改进更快、更容易。 例如从 WordPress 迁到代码栈后，我先获得了 AI 辅助内容生产能力，接着暴露搜索质量问题，再进一步搭建评估框架。每一步都建立在前一步之上。
怎么为 AI 搜索引擎优化博客内容？
AI 搜索引擎偏好结构清晰、先给答案的内容。 核心做法包括：前 150 字给出加粗定义性结论、使用问题式 H2、提供对比表、把段落控制在 120-180 字、并补充 FAQ schema。这些模式最高可带来 340% 的 AI 引用提升。
什么是 RAG 评估框架？
RAG 评估框架用于测试 AI 助手是否能稳定找回并返回正确内容。 它会用预定义查询 + 期望答案（ground truth）做批量测试，输出 hit rate、precision、temporal diversity 等指标，让你能系统优化检索参数，而不是靠感觉调参。
为什么要把 Beehiiv 换成自建 newsletter？
自建 newsletter 可以给你对订阅者数据、兴趣定向和系统集成的完整控制权。 我用 Supabase + Resend 后，拿到了兴趣分组订阅、自动化定向通知，以及每月 $0 的运行成本，同时还和 Sydney 的搜索索引共用同一数据底座。
Cloudflare Turnstile 和传统 CAPTCHA 有什么不同？
Cloudflare Turnstile 是隐形机器人检测，只对可疑流量触发挑战。 传统 CAPTCHA 会让所有用户都做题，Turnstile 对正常访客基本无感。它通过浏览器信号识别机器人，在不打断体验的前提下提升防护。
继续写代码，继续学习，也继续看着这条复利曲线往上走。
