用 Opus 半小时把博客从 Typecho 搬到 GitHub Pages
旧博客一直跑在 Typecho 上：PHP + MySQL + Nginx + 主题 + 评论插件。可以工作，但每次想动它都要先盘一遍 PHP 版本、SSL 证书、备份是否完整、主题是否还兼容。维护成本远高于写作成本。
今晚用 Claude Opus 4.7 把整套迁到 GitHub Pages，耗时约半小时。
新架构
- 前端：React + Vite + TypeScript，构建产物推
gh-pages - 内容存储：当前仓库的 GitHub Issues。一篇文章 = 一个 Issue，标签作分类与 tag，评论复用 Issue 评论
- 图片：仓库
assets分支，正文以raw.githubusercontent.com引用 - 后端 / 数据库 / 鉴权：无
- 部署：
actions/deploy-pages，push 即发布
整个站静态，无运行时依赖。
半小时内 AI 完成的工作
① 仓库初始化。 我给的需求是"静态博客 + 内容走 Issues"。Opus 自行选定 React + Vite + TS 栈，生成脚手架、路由（Home / Blog / PostDetail / About）、Issues 列表与详情、评论组件、Markdown 渲染、CI 部署、CNAME 配置。整个过程我只回答了两个澄清问题。
② 历史数据迁移。 旧 Typecho 备份是单个 SQL dump。Opus 直接读 typecho_contents 与 typecho_metas，按文章 / 分类 / tag 关系重建数据，正文中的旧附件 URL 一并改写为新的 raw 路径，结果以 issue 草稿形式产出。我只做抽样验收。
③ DNS 切换。 仓库加 public/CNAME 后 GitHub 侧自动接管，剩余工作只在 DNS 控制台。Opus 给出完整记录清单：4 条 A 记录指向 GitHub Pages 固定 IP，加一条 CNAME 兜底，并附每条记录的作用与 TTL 建议。我按表录入，由它执行 dig 验证生效。
④ 文章发布。 当前这篇即为示例：草稿生成 → review → gh issue create 直接落地为 Issue。无后台，无富文本编辑器，全程 CLI。
几点观察
- 整个过程 AI 处理的不是"写代码"这一项孤立任务，而是连同环境配置、数据迁移、域名、CI、发布流程在内的完整工程链路。每一项单独都不复杂，过去阻碍它们一次性完成的是上下文切换成本。
- 工具链从 Typecho（管理后台 + 编辑器 + FTP）变为 GitHub（仓库 + Issues + Actions），运维面积归零，写作面积反而扩大。
- "迁移"本身被压成了一次对话的副产品。下一次想换栈、换平台、加功能，按相同流程跑即可。
迁移完成。后续文章会陆续以 Issue 形式发出。
版权属于：一名宅。
本文链接：https://zhaiyiming.com/archives/67.html
转载时须注明出处及本声明