LearnData 进阶：让 AI 和脚本接管博客维护

本文是 LearnData 系列的第三篇。第一篇介绍了把博客变为知识库的理念，第二篇分享了笔记搜索、本地定位等进阶技巧。

在第二篇中我提到，随着笔记量增长，传统的管理方式开始力不从心。当时靠 Algolia 搜索和 Quicker 脚本还能应付。但 LearnData 的文章量继续涨到两百多篇之后，新的麻烦一个接一个冒出来。

有段时间我几乎每周都要发新文章，发完才想起来 description 忘了写，或者写了但超出了搜索引擎推荐的展示长度。翻回去逐个检查，几百篇文章，光是打开文件就够喝一壶的。读书笔记那边也一样，每读完一本书就要去 _sidebar.md 里手动加一行链接，偶尔忘了，过几天才发现侧边栏里少了一本。

这些有一个共同特点：重复、机械、容易遗漏。每一件都不难，但每一件都在消耗注意力。它们不该由人来做——于是让 AI 和脚本来接手。

生成 llms.txt：让 AI 读懂你的站点

一如搜索引擎依赖 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 天生擅长处理结构化数据。我的实际工作流是这样的：

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

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

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

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

4. 改完再跑一次 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 为你的域名，三个脚本就会自动适配，不需要额外配置。

用 Jules 自动巡检

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

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

检查 main 分支最近的提交，如果有新增或修改的 Markdown 文件，检查这些文章是否存在错别字、语句不通顺、逻辑不连贯等内容问题，同时运行 pnpm seo:audit 检查 frontmatter 是否符合规范。如果发现问题，创建一个 PR 修复。

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

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

不止 LearnData

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

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