博客仓库近期整理记录
博客仓库近期整理记录
这篇文章主要记录什么
前一篇《博客仓库整理与部署全过程》更偏向一次完整的大清理，这篇文章记录的是后续几次连续的小迭代。
这些改动看起来都不大，但实际上把后续维护成本又压低了一截，主要集中在四件事：
- 统一文章文件命名
- 给写作前分类复用补一个可执行命令
- 给 agent 补一套最小可用的写作 skill
- 修掉 about 页面失效的访客计数
文章文件命名再次统一
之前仓库里的文章文件名有几种风格混在一起：
2025-1-18归并排序.mdBFS-Flood-Fill-ShortestRoute.md博客网站导出为md.md
这种状态有两个问题：
- 目录层面看起来不统一，后面越积越乱
- AI 或脚本写新文章时，很难判断应该遵循哪套规则
后来把正式文章文件名统一成：
1 | |
例如：
2025-01-18-归并排序.md2025-03-21-BFS-Flood-Fill-ShortestRoute.md
这里有一个细节必须处理清楚：
- 文件名要带日期，方便仓库管理
- 但文章
title不应该强行把日期带进去
所以最后的处理是：
- 文件名统一带日期
- front matter 里的
title只保留真正的文章标题 - 对已经发布过的文章，额外补
slug和permalink，尽量保住旧链接
这样做的结果是：
- 仓库目录统一了
- 已有文章展示标题更自然
- 已发布链接也不至于因为批量改名直接失效
写作前先扫 taxonomy
另一个很实际的问题是，后面不管是我自己写文章，还是让 agent 写文章，都很容易重复造分类和标签。
比如同样是最短路、BFS、图论，如果每次都临时起一套新分类，仓库很快会长出一堆近义分类。
为了解决这个问题，仓库里补了一个命令：
1 | |
它会扫描：
source/_posts/source/_drafts/
然后把这些信息集中输出：
- 分类路径
- 分类节点
- 标签频次
- 现有文章列表
如果主题已经明确，还可以再加关键词过滤：
1 | |
这样在真正写文章之前，就能先回答几个很关键的问题：
- 这个主题是不是已经写过
- 现有最接近的分类路径是什么
- 标签到底应该复用哪几个
这个命令的价值不在于“输出很好看”，而在于把原来靠肉眼翻文章的动作，变成了一个固定步骤。
给 agent 补最小写作 skill
taxonomy 只是解决“写之前先看一眼”的问题，还不够。
后面又补了一套最小化的 blog-writing skill，目标非常明确：
- 不让 AI 直接自由发挥
- 让 AI 先读仓库规则，再写草稿
- 把写文流程稳定下来
这套 skill 最终没有做成一大堆层层嵌套的说明，而是压成了最小结构：
1 | |
这里最关键的设计有三点。
规则只维护一份
文章规则统一以根目录的 AI_README.md 为准。
也就是说：
- skill 不再重复定义标题规范
- skill 不再重复定义分类规范
- skill 不再重复定义图片规范
这样后面真要改规则，只改 AI_README.md 一处就行，不会出现多个地方互相打架。
配置单独放出来
仓库根目录、命令入口这些信息放到：
skills/blog-writing/CONFIG.json
这样调用 skill 时，用户不需要每次都重复传一长串参数，AI 先读配置就行。
统一写草稿，不直接写正式文章
这一点是整个流程里最重要的保护：
- AI 新写文章统一先写进
source/_drafts/ - 人工确认后，再决定是否迁移到
source/_posts/
这能避免两个常见问题：
- 草稿质量一般时直接污染正式文章目录
- AI 在没有确认图片、分类、标题的情况下直接发布
about 页访客计数顺手修掉
最后一个看起来小，但确实是线上可见问题。
about 页原来放了一条第三方访客计数徽章：
1 | |
这条统计不是主题内置功能，而是手写在 about 页面里的外部图片服务。它一旦不稳定，页面上就会直接失效。
后面的处理方式很简单：
- 去掉失效的
profile-counter.glitch.me - 换成相对更稳定的
komarev计数徽章 - 顺便删掉页面底部那条重复的计数显示
这个改动本身不复杂，但它提醒我一个很现实的问题：
- 主题能正常渲染，不代表页面资源是稳定的
- 只要是外部依赖，就迟早要面对可用性问题
这几次小改动真正带来的变化
如果只看提交记录，会觉得这几次改动都挺碎。
但把它们放在一起看，实际是在继续收紧博客仓库的几个关键环节：
- 文章命名更统一
- 分类和标签复用更容易
- AI 写作流程更可控
- 页面上的外部依赖又少了一项隐患
这些都不是特别“炫”的改动，但非常适合长期维护。
因为博客仓库最怕的不是某个地方一开始不完美，而是规则一直模糊，导致每加一点内容都会继续变乱。
当前我比较认可的工作流
到现在为止，这个仓库里写博客的大致流程已经比较清楚了：
- 明确要写的主题
- 先跑
npm run taxonomy - 必要时按关键词过滤，确认分类和标签复用方案
- 用
hexo new draft "文章标题"或 agent 流程创建草稿 - 按
AI_README.md写正文、封面和 front matter - 本地执行
hexo generate检查 - 人工确认后，再迁移到
source/_posts/
这套流程的优点不是“最自动化”，而是够简单，也够稳。
总结
这几次提交虽然规模不大，但方向是统一的：
- 继续把仓库规则显式化
- 继续把重复判断前移成固定步骤
- 继续把 AI 写作限制在可控边界里
对个人博客来说，这种小步整理比一次性大改更容易持续。
因为真正有用的，不是写出一套看起来很完整的规范，而是让这些规范真的能在下一篇文章里继续被执行。