DreamJia

上线不是部署命令返回成功的那一刻，而是读者能够打开正确页面、站内链接没有断、下一位维护者知道这次改了什么之后，才算真正结束。 Hexo 是静态站点，回滚看起来比动态服务简单，但它同样需要边界：哪一个提交是已验证的版本，哪一份 public/ 是由它生成，远端同步是否经过 dry-run，以及当前工作树有没有不能被覆盖的修改。 发布前先留下边界开始前先看工作树： git status --short --branch 如果有未提交修改，先确认它们属于当前任务还是之前留下的工作。内容发布时只暂存本次文章和文档，不用 git add . 把未知文件一起加入。 提交前再看暂存区： git diff --cached --name-status 一个清楚的提交边界，就是未来最便宜的回滚点。提交信息也应当说明它包含什么，例如“新增文章”或“更新主题配置”，不要把内容、依赖和服务器脚本混在一个模糊的提交里。 用固定顺序发布当前仓库的发布顺序是： pwsh ./ops/check.ps1 pwsh ./ops/build.ps1 pwsh ./ops/deploy.ps1 -Dry...

Butterfly 的配置项很多，真正容易踩坑的不是“找不到开关”，而是改错文件。主题目录里的默认配置像是一份能力清单，项目根目录的主题配置才是个人站点的定制层。把这两个边界分清楚，主题升级和日常改样式都会轻松很多。 先理解两层配置Hexo 基础行为放在根目录 _config.yml，例如站点 URL、permalink、source_dir、public_dir 和构建选项。Butterfly 的外观和交互放在根目录 _config.butterfly.yml，例如菜单、头像、目录、搜索和页脚。 仓库已经在主题配置文件开头写明了边界：保持项目级覆盖，不直接编辑 themes/butterfly/_config.yml。主题子模块可以更新，个人配置也不会因为上游变化而被覆盖。 修改前先查看工作树： git status --short --branch 这样可以区分“本次准备改的配置”和“之前已经存在的未提交修改”。配置文件尤其不适合用 git add . 一次性加入暂存区。 菜单和公共入口当前配置的 menu 定义了 Home、Archives、Tags、...

SEO 不只是“把关键词塞进标题”。对个人 Hexo 博客来说，最有价值的基础工作通常是让 URL 稳定、标题和描述清楚、文章之间有合理的链接，并且让搜索引擎能够发现站点中的页面。 这些工作不保证某个排名，却能减少抓取和理解页面时的歧义。先把站点结构做好，再考虑更复杂的扩展。 先确认站点的基本 URL当前项目的 _config.yml 设置了站点 URL： url: https://dreamjia.cloud 永久链接使用： permalink: :year/:month/:day/:title/ 这意味着一篇文章的日期和 slug 会参与最终地址。文件名使用稳定的英文 slug，标题使用面向读者的中文，是比较容易长期维护的组合。 例如，文件名 hexo-seo-and-sitemap.md 对应的文章路径是： /2026/08/08/hexo-seo-and-sitemap/ 发布之后不要为了追求更短的 URL 频繁改文件名。链接一旦被收藏、引用或搜索引擎收录，稳定比短几个字符更重要。 标题和描述要各司其职title 是页面最醒目的主题说明，应该让读者在列表或搜索结果中...

说到博客性能，很多人第一反应是换主题、加缓存、装一堆优化插件。但个人 Hexo 站点最常见的瓶颈，往往没有这么复杂：重复做了不必要的构建，文章图片太大，生成后没有检查资源是否真的被引用，或者把本地构建耗时和线上页面加载混成了一个问题。 我更喜欢从不会破坏内容的地方开始优化：减少无效工作，控制资源体积，确认生成结果，再考虑额外工具。 先分清两种性能本地构建性能回答的是“从源文件到 public/ 要多久”。它受文章数量、主题渲染、Node 依赖和运行环境影响。页面加载性能回答的是“读者打开一个 URL 要等多久”。它更多受图片、脚本、样式、字体和网络影响。 两者有关，但不是一回事。把本地构建从 20 秒降到 10 秒，并不自动意味着页面会加载得更快；给页面加一个压缩插件，也不一定能解决 Docker 镜像下载慢的问题。 排查时先记录现象：是 hexo generate 慢，还是浏览器打开页面慢，还是只有某一篇文章慢。问题边界清楚，优化才不会变成凭感觉改配置。 不要每次都从清理开始排查缓存时，hexo clean 很有用；日常每次写一段文字都 clean，却会让生成器丢掉可...

Hexo 的发布问题往往不是“页面突然坏了”，而是流程中的某一步没有被确认：文章没有通过 Front Matter 检查，构建没有生成目标页面，部署同步到了错误目录，或者线上缓存仍然显示旧内容。排障的关键不是马上重跑所有命令，而是先确定问题发生在哪一层。 我把发布过程固定成四个阶段：检查源文件，构建 public/，演练同步范围，最后验证线上页面。 第一层：先检查源文件发布前先运行仓库检查： pwsh ./ops/check.ps1 如果这里失败，先不要构建。常见原因包括文章缺少 title、date、tags、categories 或 description，或者仓库关键目录被误删。Front Matter 错误应回到 Markdown 文件修复，不要用生成后的 HTML 反向补救。 YAML 报错时，先看最近修改的几行，尤其是列表缩进、冒号和 Tab。可以把文章暂时缩小到最小 front matter，再逐步加回字段，快速定位是字段名问题还是值的格式问题。 第二层：确认生成物检查通过后，使用仓库的 Docker 构建入口： pwsh ./ops/build.ps1...

文章一旦不再只有文字，就会遇到三个实际问题：图片放在哪里，代码怎样保持可读，文章之间怎样互相引用而不在改标题后全部失效。Hexo 给了我们多种选择，但个人博客最需要的不是“全部都用上”，而是先定一套容易维护的边界。 共享图片放在哪里当前仓库把可复用的小图片放在 source/images，例如公安备案图标和站点公共图片。文章里可以使用站点根路径引用：  这类资源适合头像、Logo、备案图标和多个页面都可能用到的图片。它们不属于某一篇文章，文件名和路径应该尽量稳定。 文章专属的大图不建议随意塞进 source/images。这样做短期很方便，时间长了却很难判断图片属于哪篇文章，也不容易清理历史资源。对于较大的媒体或跨文章复用的资源，先确认图床地址和生命周期，再决定是否使用外部地址。 文章资源文件夹项目的 _config.yml 打开了 post_asset_folder: true，说明可以为文章准备同名资源目录。新文章需要使用专属图片时，可以把资源放在对应的文章资源目录，并使用 Hexo 的资源标签： &#...

打开一篇 Hexo 文章，最上面的两段横线之间就是 Front Matter。它看起来像一小段 YAML，却决定了文章的标题、时间、归档位置、标签页显示内容，以及文章是否进入正式生成结果。 正文写得再好，如果 Front Matter 缩进错了或漏了必填字段，构建时仍然可能失败。把这些字段理解清楚，写作会轻松很多。 一份完整的示例当前博客的文章可以从下面这个最小但完整的结构开始： --- title: Hexo Front Matter 详解：标题、分类、标签与摘要怎么写 date: 2026-07-31 20:10:00 updated: 2026-07-31 20:10:00 tags: - Hexo - Markdown categories: - 技术折腾 description: 一句话说明文章解决的问题和阅读价值。 cover: draft: false --- 两行 — 必须各自独占一行。字段名使用半角冒号，列表项比 tags 或 categories 多缩进两个空格。仓库检查脚本会寻找必填键，但不会替你修复 YAML 结构，所以缩进仍然要自己保持一致...

Hexo 的好处是写作和发布之间隔得很近：文章是 Markdown，预览是本地网页，发布是一次静态生成。但“很近”不等于“没有步骤”。如果一开始就把文件、命令和预览方式固定下来，后面写十篇、几十篇文章都不会变得混乱。 从命令创建文章在项目根目录打开终端，使用 Hexo CLI 创建新文章： npx hexo new "my-first-post" 命令会把文件放到 source/_posts/，文件名通常会根据标题生成。实际维护时，我更喜欢直接使用稳定的英文 slug，例如： npx hexo new "hexo-local-writing-preview" 创建之后先打开 Markdown 文件，补齐 title、date、tags、categories 和 description。文件名决定 URL 的一部分，越早把 slug 定下来，后面改链接的成本越低。 如果你已经确定文章标题，也可以先用 slug 建文件，再把中文标题写入 front matter。标题负责给读者看，文件名负责给 URL 和仓库维护者看，两...

个人项目刚开始时，最重要的是“先跑起来”。过一段时间以后，真正让人头疼的却变成了另一组问题：当初为什么这样配置？哪条命令才是标准入口？改完以后怎么确认没有影响线上？如果电脑换了、依赖升级了，能不能在半小时内重新得到同样的结果？ 我理解的长期主义，不是把项目做得很重，而是把下一次维护的成本降下来。对一个静态博客来说，几条固定命令、几份清楚的文档和一套不容易误触的边界，已经能解决大部分焦虑。 把“能运行”变成固定入口个人项目最怕依赖记忆。今天在终端里敲了一串临时命令，过几周再回来，往往只记得“应该差不多是这样”。所以我会把常用操作收进仓库脚本，让入口拥有明确的名字： pwsh ./ops/check.ps1 pwsh ./ops/build.ps1 pwsh ./ops/deploy.ps1 -DryRun pwsh ./ops/deploy.ps1 这些命令不一定适合所有项目，但它们表达了一个顺序：先确认结构和内容，再生成静态文件，先演练同步范围，最后才接触线上环境。入口固定下来，维护者就不必从目录里猜“哪一个脚本才是真的”。 检查脚本是最便宜的护栏检查脚本不需要很聪明，能抓住高...

我很喜欢用 AI 帮忙写东西，但我越来越不把它当成“按一下按钮就能交稿”的机器。它更像一位速度很快、点子很多的协作者：可以帮我拆题、列提纲、发现遗漏，也可以把一段杂乱的笔记整理成顺畅的初稿。真正决定文章能不能发布的，仍然是我有没有把目标、上下文和复核标准说清楚。 一套稳定的工作流，重点不在于记住某个神奇提示词，而在于把每次协作拆成几个可重复的阶段。 先说清楚要交付什么“帮我写一篇文章”太宽泛，模型可以给出一篇看起来完整、却不一定适合发布的文字。更好的起点是先定义交付物： 文章写给谁，读者已经知道什么； 文章要解决哪个具体问题； 需要教程、复盘，还是观点整理； 最终要落成什么格式，例如 Hexo Markdown； 哪些内容必须由人确认，哪些内容可以让模型自由发挥。 我通常会先写一段任务说明，再让 AI 复述它理解的目标。如果复述已经偏了，越早纠正，后面返工越少。 把上下文切成可控的小块上下文不是越多越好。把整个仓库、所有历史对话和一堆无关资料一次性塞进去，反而容易让重点消失。我更愿意按“项目背景、当前文件、明确约束、验收标准”四块提供信息。 例如写博客时，背景可以是 Hexo...