云 / 系统
旧的 WordPress 网站陪我用了很多年，积累了文章、图片和职业经历。但为了一个个人网站，持续维护带数据库的内容管理系统，渐渐显得有些大材小用。
我想要一个更快、更好维护，也更有个人风格的网站。同时，我也想试试：AI 编程伙伴究竟能在迁移中帮上多少忙？不是按一下不存在的“自动转换”按钮，而是一起梳理并落实真正的工程决策。
结果就是你正在看的这个网站：通过 Amazon S3 与 CloudFront 提供静态文件的云原生个人网站。旧文章仍然保留，又加入了摄影、专业认证、训练数据、小游戏，以及更完整的项目介绍。
这次迁移的价值，不在于“用 AI 取代 WordPress”，而在于分清哪些内容值得留下，哪些运行负担已经没有必要。
先说清楚，“AI 辅助”指什么
网站在线提供页面，并不需要语言模型参与。否则，普通访客没有得到明显好处，却多了延迟、依赖和复杂性。保持静态，正是我想要的结果。
AI 参与的是构建过程：检查旧资料、提出信息结构、起草和修改文案、生成与重构代码、查找不一致之处、调整响应式布局，以及把重复操作写成脚本。决定权仍在我：哪些内容要留、哪些假设要改、视觉效果是否合适、线上变更能否发布，都由我判断。
因此，更准确的说法是“AI 辅助开发”。AI 用在构建和维护网站时，对外提供服务的系统则保持简单。
1. 改设计之前，先盘点内容
迁移应从实际资料开始，而不是先选一套新配色。调整页面之前，我先收集了 WordPress 的文章、页面、分类和媒体引用，把内容导出为结构化 JSON，并把关联文件复制到本地档案中。
这样就有了两道保障：
- 一份机器可读的内容档案，可以反复转换，不必一再抓取线上网站；
- 一份保留原始图片、文档与证书的媒体档案。
我还核对了 URL、标题、发布日期、内部链接，以及不应意外公开的内容。完整备份不等于公开网站：导出资料可能包含草稿、旧文件、个人信息和证书。保存与发布，必须分别决定。
2. 让内容脱离 WordPress 也能使用
WordPress 中最有价值的，不是主题、插件或数据库结构，而是内容。文章转成 JSON、媒体整理进普通文件目录之后，展示层就可以替换了。
首页用 JavaScript 读取精选文章数据并生成卡片，每篇文章同时保留独立的静态 HTML 页面。这样既方便组织界面，也保留了搜索引擎可以抓取、读者可以直接打开的普通网址。
先保留，再筛选，就不容易因新设计暂时放不下某些资料而丢掉历史。先让档案完整留下，再作编辑取舍。
3. 按读者的需要设计，而不是跟着 CMS 走
WordPress 很容易让网站围绕一串文章展开。新网站则有不同重点：个人简介、项目、职业经历、认证、照片、训练进步、技术笔记，再加一点好玩的东西。
我们直接用语义化 HTML、CSS 与 JavaScript 搭建这些内容，不再套用需要适配无数种网站的通用主题。导航、字体、移动菜单、图片展示和交互细节，都围绕这个网站来设计。
设计是在不断反馈中完成的。打开本地预览，我会指出：终端挡住了手臂、人像裁剪不自然，或者标题换行很别扭，然后马上调整实现。AI 特别适合缩短这一轮轮修改的过程；好不好看仍由人判断，落实到 CSS 则更快。
4. 把旧 URL 和搜索可见性当作正式数据
新首页再漂亮，也不能以多年可搜索内容消失为代价。每篇选中的笔记都有独立网址、清楚的标题、描述和 canonical 地址，并配有 Open Graph、Twitter 分享元数据与 Schema.org 结构化数据，说明文章类型与作者。
站点地图列出核心页面和存档笔记。网站统一使用 Bernd Kuhlen 这个名字，并注明全名 Bernhard Kuhlen。爬虫有明确的抓取规则，读者和搜索引擎也不必运行交互式首页，就能通过普通链接找到文章。
有外链或搜索记录的旧永久链接，应继续有效，或永久重定向到对应的新页面。URL 映射应在迁移前规划，而不是上线后再补救。
5. 让基础设施简单、可靠、少折腾
最终文件保存在私有、加密并启用版本控制的 S3 存储桶中。CloudFront 作为公开入口，通过源访问控制（OAC）访问存储桶，S3 本身不直接作为公开网站暴露。访问强制使用 HTTPS 和现代 TLS，响应头策略补充主要的浏览器安全响应头。
基础设施写在 CloudFormation 模板中，而不只存在于 AWS 控制台的点击记录里。部署脚本更新堆栈，并同步明确允许公开的文件。在本文记录的迁移流程中，还会使 CloudFront 缓存失效。这样，发布能够重复执行，后续变更也有实现依据可供审查。
静态托管把 WordPress 数据库、PHP 运行时、主题更新与插件补丁移出了访客请求链路。运维责任并没有消失，只是范围更小、状态也更容易观察。
6. 先预览，再切换
整个过程中，网站都先在本地的 Nginx 容器后运行。这样可以在上线前检查电脑和手机布局、打开存档文档、试玩游戏，并查看训练图表。
稳妥的切换计划应包括：
- 暂停内容修改，或明确最后一次导出的时间；
- 完整的数据库和媒体备份；
- 在本地和预发布环境核对重要网址；
- 在切换之前准备好的 DNS 记录和证书；
- 保留切回原源站的路径；
- 发布后，从开发电脑以外的环境检查网站。
S3 版本控制和基础设施即代码有助于恢复，但不能替代清楚、可执行的回滚流程。
7. 没有应用服务器，也需要可观测性
静态网站仍可能出故障、遇到爬虫或出现意外流量。CloudFront 访问日志记录请求、状态码、User-Agent 与边缘节点信息，CloudWatch 仪表盘据此展示访问量和 HTTP 状态码分布。日志有明确的保留期限，不无限累积。
地理分布能帮助理解流量来源，但边缘节点位置，以及根据 IP 推断的国家或城市，都不能当作访客身份的证明。运维数据说明的是请求情况，通常不能确定具体是谁。
这些数据也建立了一个有用的基线。与其等别人报告链接坏了，我可以先观察错误趋势，检查被请求的路径。
8. 借迁移之机，做点原来没有的东西
不再受传统博客主题限制后，网站更容易容纳我的个人兴趣：Apple Health 导出的数据变成了按日、周、月汇总的训练视图；证书有了独立档案；照片配上说明；Snake 与 Galaga 两款小游戏也进入了趣味栏目。
它们仍然通过静态资源和浏览器端代码提供。重要的不是换一个更重的平台，而是有了能让小而专注的功能并存的结构。
AI 擅长什么，又需要人盯住什么
重复检查、提出转换方案、做出第一个版本、检查语言，以及把具体反馈应用到多个文件，都是 AI 能帮忙的地方。它也能协助核对内容记录、文章页面、站点地图与部署文件之间的对应关系。
但结果仍要验证。看似合理的链接可能指错位置，代码有效的布局在真手机上也可能很别扭。生成文案可能过于空泛，或者夸大系统能力。基础设施命令的后果，更不是改错一个字那么简单。
最有效的方式仍然是有约束的来回沟通：查看实际系统，限定修改范围，先预览、再测试、后发布。AI 加快了这个过程，却没有替代它。
可以重复使用的迁移清单
- 备份 WordPress 数据库、上传内容和配置。
- 导出文章、页面、分类体系、日期、作者和媒体引用。
- 将内容分类为公开、私密、过时或不确定。
- 创建 URL 清单和重定向地图。
- 选择符合实际要求的最简单的目标架构。
- 构建小型设计系统和可重复使用的内容模板。
- 为应保持可搜索的材料生成独立的语义页面。
- 添加元数据、canonical 地址、结构化数据、robots 规则与站点地图。
- 测试可访问性、响应式布局、链接、文档和错误页面。
- 将基础架构和部署描述为代码。
- 通过备份、监控和经过测试的回滚路径来切换。
- 保留原始档案，直到确认新网站运行可靠。
权衡取舍
并不是每个 WordPress 网站都适合改成静态网站。非技术编辑较多、编辑流程复杂、需要评论或频繁变更服务端数据的站点，仍可能更适合成熟 CMS，或采用静态前端配合无头 CMS。
对通过代码维护的个人网站，我的取舍不同。我放弃了在浏览器里编辑文章的便利，换来更小的攻击面、可预测的交付、版本管理，以及对页面体验的控制。AI 减轻了代码工作流的负担，让这次交换值得尝试。
最后想说
旧 WordPress 网站没有被丢弃，而是被有条理地拆开：内容留下，有用的部分重新整理，展示层重建，基础设施简化。
如果再做一次迁移，我仍会先问：哪些东西必须保留？网站真正需要完成什么？哪些复杂性可以去掉？然后再让 AI 参与工程，而不是先找一个能“取代 WordPress”的 AI 产品。无论它多快、多有帮助，依据始终应是真实文件、实际测试与人的判断。