从0到1规划一个技术博客的内容结构

很多博客停更不是因为没东西写，而是结构太自由：分类越加越细，标签随手就打，半年后自己都找不到旧文章。开站时花半小时定规则，比事后迁移划算得多。

分类和标签分工

一条简单的规则：分类回答”这是什么领域”，标签回答”涉及什么具体技术”。

• 分类保持5到8个，是稳定的骨架，例如前端工程、后端工程、AI工程、工程实践、写作；
• 标签可以多一些，但不做同义词（JS和JavaScript只留一个）；
• 一篇文章只属于一个分类，标签2到4个足够。

分类一旦定下就尽量不改，因为URL会跟着变。标签反而可以随时整理，成本很低。

摘要不是正文开头

摘要会出现在列表页、搜索结果、meta description和分享卡片里，它承担的是”要不要点进去”的判断，不是内容摘录。写一句能独立成立的结论，控制在60字以内，比复制第一段有用。

URL用语义化短名

用文件名当slug，例如/posts/agent-tool-layer/，不用日期也不用中文拼音。好处是：

• 文章改标题、改发布日期时链接不变；
• 归档由日期元数据生成，不需要体现在URL里；
• 分享出去的链接短且可读。

文件名一旦发布就不要再改，真要改必须同时留重定向，否则外链全断。

元数据在构建时校验

标题、摘要、日期、分类、标签全部放进frontmatter，用schema做必填校验。draft: true用于本地预览，构建时自动排除。这样”写了一半”和”已发布”之间没有模糊状态，也不会误把草稿推上线。

先写能复用的一类文章

起步阶段最稳的是清单型与复盘型：一份检查清单、一次踩坑复盘、一个选型对比。它们不太依赖时效，写起来有抓手，也容易在后续项目里反复引用。

博客的结构本质上是给未来的自己做的索引。宁可少几个维度，也别做一套需要不断维护的分类学。

这些规则不复杂，难的是第一年忍住不加例外。