个人网站落地：从资料梳理到内容后台与部署

本案例根据 Niall 的《AI 打造自己的个人网站》整理。项目主体是原作者的个人网站，不是本站对外承诺的客户交付案例；实施顺序与问题来自原文，复用清单为整理建议。

起点：资料很多，网站结构还没有

作者已经在 Wolai 中积累了博客、项目、工作流和设计复盘，但这些资料主要面向自己。单独分享文档，难以决定访客先看什么、接下来去哪里，也难以完整表达个人形象。

这次项目从“想做一个个人网站”开始，逐步形成主站、内容门户、管理后台与部署维护流程。AI 承担了大量工程工作，但选内容、定设计和验收仍由作者完成。

作者先让 AI 读取已有文档，再用 DB Skill 梳理网站目的与可展示材料，随后通过 Canvasight 整理首页、作品、关于、工作流等信息结构。

接下来没有立即做正式视觉稿，而是先生成一个可点击原型。作者逐个检查入口、页面和文案，调整顺序，也删除不适合放进网站的内容。

第一版允许部分内容继续跳转到 Wolai，没有等待所有内容网页化再上线。这个选择让原型承担了范围确认的任务，也让后续设计知道需要哪些页面和公共组件。

正式设计由作者在 Figma 中完成：先建立变量、文本样式和基础组件，再画具体页面。

随后，AI 读取设计信息并整理成 design.md，把颜色、字号、行高、圆角和组件约定带到代码侧。开发顺序是先公共组件，再具体页面。

作者还把“必须复用已有组件和变量”写进项目规则。这样第二个页面的按钮不必重新生成一套相似样式，亮暗主题也能先在组件层检查。

人的职责是判断视觉是否合适，AI 负责修改代码和执行检查，页面完成后再验证有没有影响其他页面。

主站上线后，作者发现跳回 Wolai 会打断前台的阅读体验，于是继续建设内容门户。原文中的 Blog、Harness、Codex 和 AI 内容最终共用一套后台、数据库与图片存储，通过路径区分内容。

该项目当时采用 Astro 服务端渲染、React 交互、Tiptap 编辑器和 SQLite。这里记录的是原作者的技术选择，不表示制作个人网站必须使用同一组合。

统一后台的意义，是让日常发布成为内容操作，而不是每写一篇文章就修改一次网页源码。

文章导入是原文中一个具体的返工点。最初希望直接把 Wolai 全文粘贴到后台，再自动上传图片，但这条路径反复失败，调整并发也没有彻底解决。

原文并没有确认唯一根因，因此不能把问题简单归结为某个浏览器限制。作者最终换了实现路径：在后台粘贴文章链接，由服务端通过 Wolai API 读取页面与内容块。

新的处理链包括：

即使接通 API，非标准文档格式仍可能需要人工检查。导入成功和阅读效果正确，是两个需要分别验收的结果。

操作	原文中的流程	需要检查什么
修改站点代码	GitHub 提交后打包，通过 SSH 上传 ECS，再更新 Docker 服务	新服务健康状态和页面表现
发布文章	后台导入、预览、发布	正文格式、图片与链接
更新内容系统	先备份数据库，再部署新版本	健康检查失败时能否恢复

原文还记录了独立 OSS 凭据、限制到必要操作、密钥不进入 Git 和部署日志等做法。涉及账号和授权的决定仍由作者确认。

需要保留一个边界：内容系统描述了失败恢复流程，但主站当时尚未具备同样明确的自动恢复逻辑。不能把某个子系统的能力写成整个站点都已经完成。

作者记录了主站、内容门户、数据后台和部署的落地过程，也描述了后续通过推代码或后台发文章来维护网站的方式。

这个案例不把原文的个人支出当作通用预算，也不把阶段性工时当作所有人的交付周期。真正值得复用的是实施顺序：先选内容和确认范围，再定设计规则；出现导入问题后改变实现路径；上线后继续补齐维护能力。