建立一个由 AI 管理的个人知识库

一个耐用的个人知识库，不应依赖某个聊天产品的记忆。内容应该以可读的 Markdown 保存，用 Git 记录变化，再由确定性的构建流程决定什么可以公开。

结论

最稳妥的结构是把“内容理解”和“发布控制”分开：AI 负责提取、清洗和组织，Schema、脚本与 CI 负责校验、隔离和发布。即使以后更换 AI 工具，Markdown、Git 历史和静态网站仍然可用。

关键要点

• Markdown 是长期可读的源文件，不被数据库或 CMS 锁定。
• 公开文章、草稿、私密笔记和原始材料必须使用不同目录与发布规则。
• 只有显式满足发布条件的文章才进入页面、搜索、RSS 和 Sitemap。
• 每次修改都经过格式、Schema、链接、隐私和生产构建检查。

内容与发布分层

公开站点不是仓库内容的镜像。仓库可以保存不同阶段的材料，但构建系统只应读取受 Schema 管理的文章集合，并按状态与可见性生成页面。

本项目使用三层白名单：

1. status: published 表示内容已经完成发布准备。
2. visibility: public 或 unlisted 决定是否允许生成直接访问页面。
3. noindex: false 决定是否进入公开列表、搜索、RSS 和 Sitemap。

私密目录完全位于 Astro 内容集合之外。即使路由过滤出现回归，构建工具也无法读取这些原始文件。

AI 与脚本的职责

AI 擅长识别主题、比较来源、重排结构和改善语言，但不应该自行决定构建是否成功。脚本适合执行重复且确定的规则，例如检查唯一 ID、文件名、H1、日期顺序和私密泄漏。

这种分工让错误可复现：失败时能够看到具体文件和规则，而不是依赖一次不可追溯的对话判断。

实际应用

日常收录一条想法时，先保存 inbox 记录，再生成默认草稿。收到网页时，记录 canonical URL、作者、发布日期和访问时间，只保留必要摘记与摘要。完成核验后，再使用发布脚本写入发布时间。

如果需要继续了解文件结构，可以阅读为什么采用 Markdown-first。

风险与边界

• AI 生成的事实仍需来源与人工判断，尤其是金融、医疗、法律和安全内容。
• GitHub 私有仓库不等于公开构建安全，必须扫描最终 dist/。
• 自动化不能替代账户权限管理；部署 Token 仍需存放在平台 Secret。