9 篇博文 含有标签「内容工程」

最开始我也以为，把旧博客迁到 Docusaurus 主要是文件格式问题：把文章导进 blog/，补齐 frontmatter，再让站点 build 起来就差不多了。真开始做才发现，Markdown 导入只是最浅的一层。更难的是后面那几件不太显眼、却直接影响站点可信度的事：旧链接能不能继续访问，归档会不会乱，补写过的文章会不会被迁移脚本覆盖，历史内容和新内容能不能进同一套索引。

我现在做技术站点的 SEO，已经很少从“关键词密度”开始想了。对这种长期积累型博客来说，真正决定搜索质量的，经常是另外几件更基础的事：description 写得像不像人话，结构化数据有没有最小字段，归档和最近文章入口稳不稳定，文章之间有没有形成明确的主题路径。

很多团队一讨论内容系统，第一句就会问“博客、文档、知识库、教程到底要不要拆成四套”。这个问题当然重要，但我现在越来越少把它放在最前面。因为真正会决定后面是不是越来越乱的，通常不是页面长什么样，而是同一份内容进入系统时，到底有没有一个稳定身份。

我现在看 blogV2 这类站点，已经不太会先问“这一版什么时候正式上线”，而是更在意它能不能稳定地持续发布。因为对内容系统来说，最容易拖垮人的从来不是第一次把站点搭起来，而是后面一篇篇补写、迁移、修订和回归时，发现所有流程都还靠记忆撑着。

我现在已经不太把“AI 生成标题”理解成一个文案灵感问题了。对技术博客来说，标题更像一个半结构化字段，它既要服务读者，也要服务站内列表、搜索结果和后续 slug 管理。只要规则没先定好，模型再能写，也很容易稳定地产出一堆“能看但不能发”的标题。

如果技术博客今天还只是一个随手放 Markdown 的目录，它当然很容易被放弃。真正让我还愿意认真维护它的原因，不是“写博客”突然又流行了，而是站点早就不只是写作工具了。一篇文章只要要进首页、归档、标签页、RSS、结构化数据和发布流水线，它就已经不再是孤立文本，而是一个被系统消费的内容对象。

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-08-08 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多人会把长期写作失败理解成“内容问题”：

• 题目不够好
• 时间不够稳定
• 人不够自律

这些当然都有关，但我后来做博客系统和内容迁移时，一个感受越来越明显：长期写作能不能持续，往往先败在系统细节上。

这里我想说的“一个细节”，其实就是：草稿和已发布内容是不是走同一条安全的数据链。

如果一个站点里，草稿写到一半就可能：

• 污染公共归档
• 出现在首页列表
• 影响 sitemap
• 甚至引起构建报错

那么写作者会天然变得保守。因为每多写一篇未完成文章，系统负担就多一点，心智负担也多一点。

很多团队在做 AI 内容流水线时，一开始只盯着“生成”。但只要流程开始进入多人协作、审核和发布，真正麻烦的问题马上会变成：

• 这篇内容现在处在哪一步
• 是谁改过它
• 哪一版被审核通过了
• 哪个模型、哪个模板生成的
• 出错时到底该回滚到哪里

如果这些问题回答不出来，系统虽然能生成内容，但很难被真正信任。

所以我后来越来越把“AI 内容流水线”理解成一条需要被追踪的状态链，而不是一个“生成完就结束”的文本处理脚本。

如果说模型、关联、分页都是准备动作，那么真正让人感受到 ORM 价值的，还是内容列表。博客首页、分类页、归档页、后台管理页，本质上都在围绕“把文章列表稳定地拉出来”这件事打转。