我把每天和 AI 的对话，做成了自动发布的个人知识博客

起因：对话即知识，但知识在蒸发

每天和 AI 打交道的时间越来越长——问技术方案、讨论架构设计、聊读书心得。一天下来，和 AI 的对话可能有几万字。

问题来了：这些对话里有大量值得沉淀的知识，但它们散落在各个工具里，聊完就忘。过三个月想找回当时讨论的某个方案细节，翻聊天记录翻到眼瞎。

更可惜的是，这些内容对别人也有价值。你在某个问题上的踩坑和思考，可能正是别人搜索半天找不到的答案。

所以我的需求很明确：

把每天的 AI 对话内容自动总结成结构化文章
经过人工审核后发布到个人博客
博客要能被搜索引擎和 AI 大模型收录——不但人能搜到，最好 AI 回答问题时也会引用我的内容

整体架构：一条内容流水线

方案的核心是把「知识生产」和「对外发布」拆成两个循环：

内容生产（内循环）          发布管道（外循环）
┌─────────────────┐        ┌──────────────────┐
│ 知识库(Obsidian) │        │ AI 总结成文章草稿  │
│ 工作台/阅读器     │  ───→  │ 人工审核修订       │
│ 每日 AI 对话      │        │ 一键构建发布       │
└─────────────────┘        └────────┬─────────┘
                                    ↓
                          静态博客站点(自有服务器)
                                    ↓
                     搜索引擎 / AI 大模型 / 订阅读者

关键设计决策有三个：

半自动而非全自动。 AI 总结完直接发布听起来很爽，但翻车风险高：对话里可能混着不该公开的信息，AI 总结也可能跑偏。所以流程是 AI 产出草稿（frontmatter 里标记 draft: true），我审阅修改后改成 false 才会真正构建发布。质量闸门必须握在自己手里。

发布前强制脱敏。 日常工作对话里全是客户名、报价、密钥这类敏感信息。总结成文章时统一做替换处理（客户名改成”某企业”，密钥直接删掉），这是把私人对话变成公开内容不可省略的一步。

静态站点而非动态网站。 这是最重要的技术选型，下面细说。

为什么选 Astro 静态博客

我对比了四条路线：Astro、VitePress、Hexo、Vue3 + Spring Boot 全栈自建。结论是内容驱动型博客，Astro 是最优解：

维度	Astro	全栈自建
SEO	默认输出零 JS 的纯 HTML，爬虫最爱	要自己做 SSR 优化
写作流	原生吃 Markdown	要自建编辑器和后台
服务器开销	nginx 托管静态文件，几乎零内存	跑 Java 服务 + 数据库
维护成本	极低	高

对于”被 AI 收录”这个目标，Astro 有个杀手级特性：默认输出零 JavaScript 的纯静态 HTML。页面加载快、任何爬虫都能无障碍解析内容，这正是搜索引擎和大模型爬虫最喜欢的形态。

而且 Markdown 原生的工作流和我的知识库天然打通——Obsidian 里写好的笔记，打个 publish 标记就能进发布队列。

重点：怎么让 AI 大模型”收录”你的内容

这是大部分人搭建博客时会忽略的一环。想让内容进入 ChatGPT、Perplexity、Claude 这些 AI 的检索范围，需要主动做四件事：

1. robots.txt 显式欢迎 AI 爬虫

很多 AI 爬虫（GPTBot、ClaudeBot、PerplexityBot）默认是被网站屏蔽的对象。我们要反过来，在 robots.txt 里逐个放行：

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

2. 提供 llms.txt

这是专门给大模型看的新兴标准——一个放在站点根目录的纯文本文件，告诉 AI 这个站有什么内容、按什么结构组织、可以怎么引用。相当于 robots.txt 的 AI 版。我在构建脚本里自动从文章 frontmatter 生成它，每篇文章的标题、摘要、标签都列进去，AI 一看就懂。

3. sitemap + RSS 双通道

sitemap.xml 是搜索引擎的索引入口，RSS 是内容聚合器的订阅源。两个都配上，新文章发布后能被尽快发现。

4. JSON-LD 结构化数据

每篇文章页面嵌入 schema.org 的 Article 结构化数据（作者、发布时间、标签），AI 引擎解析页面时能准确理解内容属性，引用时会带上规范的出处信息。

发布流程实际跑起来什么样

整个流程收敛成一条命令：

npm run deploy

它做三件事：生成 llms.txt → 构建静态站点 → tar 打包通过 SSH 推到服务器的 nginx 目录。全程十几秒，没有密码输入（部署用的专用 SSH 密钥）。

日常使用的心智负担很轻：

平时该和 AI 聊就聊，没有任何额外动作
阶段性让 AI 把值得沉淀的对话总结成 Markdown 文章（草稿态）
有空时打开草稿审阅、修改、脱敏确认，改掉 draft 标记
一条命令发布

写在最后

这个方案跑通后，“每天和 AI 对话”就从消费行为变成了生产行为——同样的时间投入，产出的不只是当下答案，还有持续积累、可被检索、能被别人引用的知识资产。

个人博客在 AI 时代不但没有过时，反而因为 AI 引用机制有了新的价值出口：当 AI 回答问题时引用了你的文章，你就获得了超越搜索排名的曝光。而这一切的起点，只是把每天本来就要进行的对话，认真地沉淀下来。

下一步我打算把 Obsidian 知识库的发布队列也接上，让”知识库笔记”和”对话总结”两条内容流汇进同一个博客。有了第一版的管道，这些都是顺手的事。