有段时间，我几乎每发完一篇文章，都会在几天后发现新的小问题。
有时是 description 忘了写，有时是写了但长度不合适；有时是标题太长，搜索结果里显示得别别扭扭；读书笔记那边更烦，明明文章已经写完，还得去 _sidebar.md 里补链接。忙起来漏掉一两处，过几天回头看，才会想起“这篇怎么又没配好？”

最开始我还觉得这只是小事。直到 LearnData 的内容涨到 200 多篇，我才意识到，这些小事根本不是小事。它们重复、机械、分散，却会持续打断人，逼着你把本该用来写内容的时间，花在一遍遍检查和返工上。

然后我给自己定了个原则：凡是重复到让我烦的事情，就不该再用手做。于是我写了 3 个脚本，再配合 AI，把博客维护里最琐碎的一部分接管掉：构建时自动生成 llms.txt，批量审计全站 SEO，把问题整理成 JSON 报告交给 AI 修复，读书笔记写完还能一键更新侧边栏。

第一次完整跑通，只花了二十分钟。之后我终于可以把精力放回内容本身，而不是那些没完没了的维护杂活上。

本文是 LearnData 系列的第三篇。第一篇介绍了把博客变为知识库的理念，第二篇分享了笔记搜索、本地定位等进阶技巧。这一篇继续往前走，解决的是另一个更现实的问题：当文章和笔记越来越多，如何把重复、机械、容易遗漏的维护工作自动化。

我先补上了 llms.txt 这块空白

最先让我觉得该补上的，是 llms.txt。

一如搜索引擎依赖 robots.txt，AI 也需要对应的引导文本。llms.txt 用 Markdown 格式列出站点所有页面的标题、描述和链接，让大语言模型能快速理解站点结构。

它的格式非常简单：

# LearnData 开源笔记

> 开源工具、效率方法、心理学探索的自我提升笔记

## Pages

- [Rclone 远端图床本地化管理方案](https://newzone.top/_posts/...) - 利用 Rclone 建立自动化工作流...
- [吃掉那只青蛙](https://newzone.top/reading/#/0_效率与习惯/吃掉那只青蛙) - 核心是每天先完成重要的工作...

但几百篇文章总不能手写吧。于是我写了 llms-txt.js，在每次构建时自动扫描所有 Markdown 文件，从 frontmatter 提取标题和描述（没有 frontmatter 的读书笔记则从 H1 和正文首段提取），生成完整索引。

这个脚本已集成在构建命令中，pnpm docs:build 完成后会自动在 dist/ 目录生成 llms.txt，随站点一起部署。站点信息从 VuePress 配置文件自动读取，零配置。

然后是最烦人的 SEO 检查

真正最烦的，还是 SEO 元数据检查。

手动检查有多痛苦？打开一篇文章，看 title 是不是太长，description 是不是在 120-160 字符之间，有没有用「本文介绍了……」这种搜索引擎不喜欢的模板化开头。一篇看下来只要一分钟，几百篇就是好几个小时，而且下次新增文章后还得再来一遍。

我需要的是一个脚本，跑一次就能告诉我哪些文件有问题、问题是什么、该怎么改。于是有了 seo-audit.js。

运行 pnpm seo:audit，它会扫描全站 Markdown 文件，对每篇文章按规则打分（满分 100）：

字符计数按显示宽度：1 个中文 = 2 字符，1 个英文 = 1 字符。

跑完之后终端会打印概要，同时在项目根目录生成 audit-report.json——结构化的 JSON 报告，包含每个有问题文件的路径、当前值、扣分原因和优化建议。

我把报告直接交给 AI 处理

这才是这个脚本真正好用的地方。报告是 JSON，AI 天生擅长处理结构化数据。我的实际工作流是这样的：

运行审计脚本生成 JSON 报告。

将 audit-report.json 投喂给 AI，附带以下提示词：

请根据 audit-report.json 中每个文件的 issues，逐一修复所有问题：补缺失的 title 和 description，将 description 调整到 120-160 字符且以提问或痛点开头，为超长 title 添加 shortTitle，去除「本文介绍了」等模板化表述。输出每个文件修改后的完整 frontmatter。

AI 直接读懂文件路径和扣分原因，批量输出修改后的 frontmatter

改完再跑一次 pnpm seo:audit 验证

第一次跑完整轮审计 + AI 修复，大概花了二十分钟，之后每次只需要关注新增的几篇文章。

Description 后来我只保留一个原则

不管是手动写还是让 AI 生成，好的 description 都遵循同一个原则——以提问或痛点开头，而不是用「本文介绍了」做前缀：

# 好的写法
description: RSS托管成本高？将RSSHub、Huginn从VPS迁移至NAS，节省千元服务费。

# 需要改进的写法
description: 本文介绍了如何配置Docker服务的详细步骤和注意事项...

读书笔记：写完跑一下就行

LearnData 的读书笔记用 Docsify 独立托管，不走 VuePress 构建。Docsify 的侧边栏靠 _sidebar.md 文件驱动，这意味着每加一本书，就得手动编辑这个文件，写对路径、写对标题、放对位置。

我的读书笔记按分类放在 src/reading/ 下，目录命名规则是 数字_分类名（如 0_效率与习惯），数字决定排序。每个 .md 文件就是一篇笔记。

之前我的工作流是：写完读书笔记 → 打开 _sidebar.md → 找到对应分类 → 加一行链接 → 确认路径没写错。现在的工作流只剩下：写完 → pnpm reading:sidebar → 结束。

脚本自动扫描所有分类目录，提取每个文件的 H1 标题，按中文排序生成侧边栏。空分类自动跳过。如果某本书想置顶（比如《原则》对我来说是思维类最重要的一本），在配置里加一个关键词就行：

// scripts/config.js
reading: {
  pinnedFiles: ["原则"],  // 文件名包含该关键词的自动置顶
}

如果你 fork 了 LearnData，只需改 theme.ts 中的 hostname 为你的域名，三个脚本就会自动适配，不需要额外配置。

最后，我把“记得去跑脚本”这件事也交出去了

上面的脚本解决了「怎么查」和「怎么改」的问题，但还有一个漏洞：你得记得去跑它。忙起来的时候，我也会连续推了好几篇文章，才想起来跑一次审计，问题又堆积了。

Google 的 AI 编程助手 Jules 有一个 Scheduled Tasks 功能，可以设置定时任务，定期检查你的 GitHub 仓库。我给 LearnData 配了一个每天执行的任务，提示词如下：

检查 main 分支最近的提交，如果有新增或修改的 Markdown 文件，运行 pnpm seo:audit 检查这些文件的 frontmatter 是否符合规范。

• 如果发现问题并进行了修改，请提交代码并创建一个 PR 修复。
• 如果没有发现问题（即所有文件均符合规范），请结束任务，不要创建任何空的提交或 PR。

这样每天 Jules 会自动检查一次，不只是 SEO 元数据，还包括文章内容本身的质量。发现错别字直接改，description 缺失直接补，title 过长直接加 shortTitle，全部打包成一个 PR。你只需要 review 和 merge。

设置方式：进入 Jules 的 Scheduled Tasks 页面，关联你的 GitHub 仓库，填入检查指令和执行频率即可。

不只是 LearnData

这些功能是为 LearnData 设计的，但思路适用于任何 Markdown 博客——只要你的文章有 frontmatter，就能审计 SEO；只要站点是静态部署的，就能生成 llms.txt；只要笔记按目录分类，就能自动生成侧边栏。

甚至你不需要自己动手改代码。把这篇文章连同你的项目结构发给 AI，它就能根据你的实际情况生成对应的脚本。你只需要掌握思路：把重复的维护工作交给AI，大模型将自动为你完成剩下的工作。