知识库过期文档怎么治理：软归档、补写、重定向，而不是一键删除

我后来不太爱用“清理过期文档”这个说法了，因为它太容易让人误会成一次性的删库动作。真正麻烦的，从来不是把几篇旧文删掉，而是判断它们到底该保留、补写、软归档、重定向，还是彻底退出系统。内容写得越久，这个问题越明显，因为旧文不只是旧文件，它们还是外链入口、搜索结果、系列上下文和历史证据。

处理得太粗暴，读者看到的不是“站点变干净了”，而是以前能打开的链接突然失效，以前能串起来的系列少了一节，以前还能查到的历史背景被直接抹掉了。所以我现在更愿意把这件事理解成内容生命周期治理，而不是卫生清扫。

过期内容不只有一种

我现在会先把所谓“过期文档”拆成四类：

1. 信息已经老，但历史记录仍有价值。
   这类内容更适合补一段“当前情况说明”，而不是直接删掉。

2. 主题还有效，但正文太薄。
   这类内容应该补写，不该归档。

3. 结构不完整或还在整理中的半成品。
   这类内容更适合转草稿或从公开索引里拿掉。

4. 已经明确错误、误导或不再应该被访问。
   这类内容才考虑彻底下线或重定向。

如果不先分类型，治理动作最后很容易滑向一种最省事、但也最伤站点信用的默认操作：一键删除。

为什么我越来越反对把删除当默认动作

在 blogV2 里，一篇文章从来不只服务单页。它还会进入最近文章、归档数据、历史迁移结果，未来还可能承接内链和搜索流量。也就是说，一篇旧文不是孤立存在的，它已经和站内很多位置绑在一起了。

scripts/migrate-blog-posts.js 里有几个细节特别能说明这点。归档项会被标记成 source: 'v2' 或 source: 'legacy'，说明系统本来就在区分“已经进入当前体系的正式内容”和“仍作为历史资产存在的内容”；而迁移时又会尽量保住标题、日期和 href 关系，说明旧文的身份并不是可以随手抹掉的。

这些设计都在提醒我一件事：旧内容不是垃圾文件，而是需要被继续理解、分类和安排位置的历史资产。

我更愿意采用的五种治理动作

1. 保留并补充当前说明

适合历史经验仍然成立、只是局部信息变旧的文章。做法通常是：

• 保留原链接
• 在开头补充“当前版本说明”
• 标出哪些步骤已经变化

2. 补写正文

适合主题没过时、但内容太短的文章。这也是这轮 blogV2 治理里最常做的动作。薄内容继续公开，只会拖低整站可信度。

3. 软归档

适合历史价值存在，但不应该再被当成“当前推荐答案”的内容。软归档的关键不是隐藏文件，而是让它从主入口退后，同时仍然保留可访问性和上下文。

4. 重定向到更新版本

适合已经有明确替代篇目的内容。如果旧链接已有外部引用，我更愿意做重定向，而不是让读者自己猜你后来把答案写到哪去了。

5. 彻底下线

只适合明显错误、风险高或根本不该继续暴露的内容。这个动作应该最谨慎，而不是默认选项。

草稿、半成品和公开内容，最好一开始就分层

plugins/recent-blog-posts.js 里有一段很关键的逻辑：默认不把 draft: true 的内容放进全局数据。tests/recent-blog-posts.test.js 也专门验证了这件事，只在本地预览时才允许把草稿带进列表。

这件事看起来像小细节，其实正是内容治理的一部分：半成品可以存在，但不应该默认进入公开索引。否则你会在“继续写”和“先别让读者看到”之间不断打架。

我很喜欢这种处理方式，因为它承认了长期写作一定会有中间状态，又避免这些中间状态污染读者真正能看到的入口。

引用链和覆盖关系，往往比“这篇旧不旧”更值得先看

我现在决定一篇旧文怎么处理时，不会先问“它是不是老”，而是先问：

• 有没有其他文章或导航还在指向它
• 它有没有承接某个固定搜索词
• 它是不是某个系列里的中间节点
• 站内是否已经有更准确的新版本

如果这些关系不先看，治理动作很容易变成删掉一篇旧文，顺手制造出几处新断链。

本地补写过的内容，也不该被下一轮迁移冲掉

这轮做 blogV2 时，我还有一个感受特别强：很多旧文并不是“删掉或保留”那么简单，它们还处在持续补写阶段。scripts/migrate-blog-posts.js 里用 shouldPreserveExistingTarget 和 mergePreservedTarget 去保护本地已经补得更完整的版本，我非常认同这层逻辑。因为这意味着系统承认了一件现实：内容治理不是一次性的，而是迁移、补写和修订会并行发生很久。

如果脚本每跑一次都把人工补写冲回去，治理动作就永远会停留在“清单式整理”，站点很难真正越修越稳。

我现在更愿意把这件事叫作内容生命周期治理

如果可以，我更愿意把“过期文档清理”叫做“内容生命周期治理”。因为它真正做的不是收拾卫生，而是给每篇内容补一个更成熟的结局：

• 继续服务读者
• 退到历史位置
• 指向更新答案
• 或者正式退出系统

只有这样，技术站点才能越写越厚，而不是越写越乱。对我来说，真正好的治理从来不是删得快，而是让读者在几年后打开旧链接时，仍然知道自己看到的是当前答案、历史记录、还是已经被替代的旧版本。这个状态如果能被系统清楚表达出来，旧内容就不会变成负担，反而会变成站点可信度的一部分。