用 AI 搭建个人博客：从一句话到长期维护

用 AI 搭建个人博客，可以从一段简短的需求开始。具备项目操作能力的编程助手，可以承担环境配置、页面开发、调试和部署准备。建站者则通过说明用途、提供参考、查看原型，逐步确认网站应该呈现的样子。

一句话足以启动项目，后续仍要明确几个实际问题：文章如何发布，设计如何保持一致，功能是否可靠，以及网站上线后怎样继续更新。AI 能完成哪些工作，也取决于工具提供的文件、终端和浏览器能力，以及获得的权限。普通聊天窗口生成的代码，还需要保存为项目，并在相应环境中运行。

从内容需求选择方案

技术方案首先要适应内容的发布方式。以文章、图片和个人介绍为主的博客，可以优先考虑静态站点：内容在发布时生成网页，读者访问时直接读取生成的文件。这种方式便于将文章与代码一起管理，也减少了自行维护应用服务的工作。

例如，GitHub Pages 配合 Jekyll 和 Minima 就能完成基础建站。文章保存为 Markdown 文件，标题等信息写在文件开头；Jekyll 读取内容，再按照主题模板生成网页。GitHub Free 支持通过公开仓库使用 Pages，并提供默认的 github.io 地址，可以从这条路线开始，无需预先购买服务器和域名。

选择这类方案，也要接受相应的边界：公开仓库中的文章和源码可被他人查看，私人草稿和密钥应另行保存；静态托管本身不提供评论、登录或写作后台，这些功能需要另外配置相应服务。这里的免费指托管和默认域名，AI 工具的使用额度另计。

如果更习惯在网页后台写作，或者需要自行保存评论数据，就应让 AI 根据这些需求选择后端与存储方案，同时说明新增的维护工作。已有模板或正在运行的博客，则先读取项目说明、依赖版本和目录结构，在原有基础上修改，并保留文章地址与数据。

第一版可以围绕首页、文章列表、正文和个人介绍展开。接入一篇真实长度的文章后，再完成一次新增和修改：内容保存在哪里，发布后列表是否更新，正文和图片是否同步变化。把这条流程确认下来，后面的设计和功能扩展才有明确的基础。

用原型确认设计

AI 生成的概念插画。

“简洁”“有质感”可以表达偏好，落到页面上，还需要具体的视觉判断。正文的行宽、字号和行距影响阅读，导航的位置与展开方式影响操作，图片与留白则共同决定页面节奏。让 AI 先提供可运行的原型，便于在这些细节上形成共识。

参考网站也应拆解到具体部分。借鉴导航栏时，可以分别观察按钮样式、当前页面的标识和菜单展开过程；借鉴文章页时，则关注文字层级、正文宽度与图片的安排。明确希望保留的特点，再结合博客自身的内容调整，设计会更有依据。

原型可以是独立的 HTML 文件，也可以直接使用项目已有组件。评估时应放入长标题、多段中文、图片和代码块，并同时查看桌面与手机布局。短标题下整齐的卡片，换成长标题可能出现挤压；桌面上合适的留白，在窄屏上也可能限制正文宽度。使用真实内容，才能发现这些问题。

动画同样需要在实际页面中判断。导航展开应保持操作连续，内容切换应避免明显跳动；音乐和复杂图形可以在使用时加载。文章页尤其应优先呈现正文，在手机或开启“减少动态效果”的设备上，适当简化动画，兼顾阅读与性能。

保留设计与开发约定

原型确认后，可以让 AI 将实际采用的颜色、字号、间距、圆角和组件用法整理进 design.md，并尽量通过共享样式与组件实现。以后新增页面时，沿用这些约定，可以减少视觉差异，也方便统一调整。

项目本身还需要一份简洁的说明，记录目录用途、启动命令、文章位置、发布方式和已经确定的约束。命令应经过实际运行；尚未验证的内容应明确标注，避免后续接手的 AI 将推测当成既定条件。

这些记录的价值在于保存已确认的决定。对话可以帮助讨论方案，项目文件则应提供稳定的操作依据。代码、内容结构或部署方式发生变化时，说明也要一并更新，否则过时的文档反而会增加判断成本。

验证完整的使用过程

AI 完成开发后，应继续执行验证，并留下可以核对的结果。类型检查有助于发现类型和接口使用错误，构建检查能确认项目是否可以生成发布产物，浏览器操作则用于验证实际交互与排版。它们各自覆盖不同问题，需要结合改动范围使用。

对于内容发布，可以新增一篇文章，从列表进入正文，再修改标题与图片，检查相关页面是否同步更新。启用搜索、归档或 RSS 后，也应确认新内容能出现在相应入口。这样才能检验完整的发布过程，避免只凭首页截图判断网站已经完成。

交互功能还要覆盖异常和连续操作。以搜索为例，除了正常返回结果，还应处理空输入、没有匹配内容和请求失败。若采用异步查询，连续修改关键词时，较早请求可能更晚返回；实现时需要避免旧结果覆盖当前查询，再通过实际操作验证。

使用单页导航的网站，还要检查切页、返回和直接刷新后的状态。页面创建的监听器与计时器应在不再使用时清理，全站播放器则需避免重复初始化。对于同时提供音频与可视化的网站，可以保留跨页播放，并在离开相关页面后停止图形渲染，减少无效的资源占用。

验证的投入应与改动相称。调整间距，重点检查实际布局；涉及内容保存、搜索或权限，则需要能验证相应行为的测试。交付记录中写清检查方法、通过的项目和未验证的部分，发现问题后修复并复查，便于后续维护时追溯。

部署与持续维护

AI 生成的概念插画。

部署方式应在方案阶段确认。配置好发布来源后，GitHub Pages 可以在内容提交后触发构建与发布；自建服务则需要明确运行环境、更新流程和失败后的处理方式。新版本宜在独立目录或构建环境中准备，检查通过后再切换，同时保留上一版的可用产物。

部署结束后，应通过公开网址验证实际结果：新内容是否出现，文章能否打开，图片与下载链接是否可用。更新已有站点时，还要检查原有访问入口、文章链接和数据是否正常。服务器上的文件已经更新，并不能单独证明读者访问到的内容也已更新，缓存或发布流程仍可能影响最终结果。

备份则要覆盖内容的实际存储位置。Git 可以保存纳入仓库的代码和文章，上传图片、评论数据库、私有配置却可能存放在其他目录。应记录各类数据的位置与恢复方法，并在隔离环境中验证数据库备份能否恢复。程序版本回退和数据库恢复是两项不同的操作，涉及数据结构变更时，需要分别准备处理方案。

将这些工作纳入日常更新，博客才能在更换工具、继续改版或遇到故障时保持可维护。AI 也可以依据清楚的项目记录接续工作，减少每次从头理解和重复试错的成本。

把建站任务交给 AI

AI 建站任务书 已整理默认方案、起步代码与检查方法。将文件交给能够操作项目的 AI 编程助手，再补充博客的用途与设计偏好，就可以开始执行。例如：

按这份任务书创建个人博客。请先检查现有项目与工具能力，再完成开发、验证和发布。技术方案由你根据需求决定，交付可访问的网址，并留下更新文章和维护项目的方法。

账号登录与发布授权由本人完成。若工具缺少发布能力，应先交付完整文件，并说明尚待完成的操作。也可以使用 三文件起步包，继续配置 GitHub Pages 发布。