当 AI 帮你解决问题，那些经验去哪了？
一个关于"把 AI 协作沉淀为可检索知识库"的开源实践
一个被忽视的问题
你用 AI 调过一个诡异的 bug。AI 分析了半小时，找到了根因，给了你解决方案。问题解决了，对话关了。
下周，你遇到类似的 bug。
你翻聊天记录，翻不到了。你重新问 AI，AI 又从头分析了半小时。
这个场景发生过多少次？
AI 在对话里产出的大量中间结论——某个报错的根因、某次依赖冲突的取舍、某段代码这么写的依据——几乎都留在聊天窗口里。下次遇到类似问题，这些结论不能被直接检索。你要么重新问一遍，要么在长串记录里翻找。
当项目变多、对话变长，这部分知识的复用成本会明显上升。
思路：给 AI 的经验一个"家"
我们的做法很简单——让 AI 直接把经验写成 Markdown，构建为可搜索的网站，部署到任何地方。
不是"写博客"，是"给 AI 协作产物一个稳定的落点"。更像是给 AI 装了一个长期记忆。
围绕这个想法，我们做了 static-markdown-blog 这个开源平台。
和现有知识库有什么不同？
市面上已经有很多知识库工具了——Notion、Obsidian、语雀、飞书文档……那为什么还要做这个？
核心区别只有一个：谁来写？
| 工具 |
谁写 |
谁读 |
定位 |
| Notion / 飞书 |
人 |
人 |
团队协作 |
| Obsidian |
人 |
人 |
个人笔记 |
| GitBook / Docusaurus |
人 |
人 |
技术文档 |
| 博客平台 |
人 |
人 |
内容发布 |
| 本项目 |
AI |
人 |
AI 的经验沉淀 |
传统知识库是"人写人看"，这个项目是"AI 写人看"。
这个区别决定了所有的设计取舍：
- 零依赖 — AI 不需要理解复杂的构建工具链
- Markdown 驱动 — AI 最擅长生成结构化的 Markdown
- CLI 优先 — AI 可以直接调用命令行，不需要 GUI
- 增量构建 — AI 可以频繁更新，只重建变化部分
- 工作区隔离 — AI 只碰
site/，不碰平台代码，安全可控
AI 的"家"与"朋友圈"
换个角度想——
如果 AI 有自己的"朋友圈"，它会发什么？
- "今天帮用户调通了一个 Docker 网络问题，根因是 iptables 规则冲突"
- "发现 React Server Components 有个坑，use client 要放在文件顶部"
- "学到了一个 Vim 技巧：g Ctrl-A 可以递增选中的数字"
这些内容不是"博客文章"，是 AI 的经验碎片。
传统博客是"精心编辑后发布"，AI 的朋友圈是"随手记录、随时查阅"。
本项目支持多种内容形态，正好匹配这个场景：
| 形态 |
用途 |
举例 |
| 文章 |
完整的技术总结 |
"Docker 网络排查三板斧" |
| 瞬间 |
碎片化记录 |
"今天的教训：别忘了检查 .env 文件" |
| 友链 |
知识图谱 |
"这个问题和 XX 问题有关联" |
| 图库 |
可视化内容 |
架构图、流程图、思维导图 |
| 自定义页面 |
个性化展示 |
技能矩阵、项目看板 |
用户访问这个知识库，就像"翻看 AI 的笔记本"——能看到 AI 学到了什么、解决了什么、思考了什么。
实际用法举例
比如你用 AI 调通了一个 Docker 网络问题，可以让 AI 把过程沉淀为一篇文章：
"把这次排查过程写成一篇文章，标题是'Docker 容器间网络不通的三种排查路径'，放到知识库里。"
AI 会自动写 Markdown、构建、部署。下次遇到类似问题，直接搜索就能找到。
又比如你正在学一个新框架，每天让 AI 记录学习笔记：
"把今天学到的 React Server Components 笔记整理到知识库里。"
几周后，这些笔记就变成了一份可检索的学习档案。
更进一步——你可以让 AI 维护一个"经验看板"：
"创建一个自定义页面，列出你最近解决的 10 个问题，按难度排序。"
AI 会生成一个可视化的经验仪表盘，你可以随时查看 AI 的"成长轨迹"。
它能做什么
基础能力： AI 写 Markdown，一行命令构建，部署到 GitHub Pages、Docker、或任意静态托管。
不只是文章： AI 还可以用它做——
- 瞬间 — 每日记忆索引、思考日志
- 友链 — 知识图谱、学习资源
- 图库 — 思维导图、架构图
- 自定义页面 — 技能矩阵、经验仪表盘
- 自己设计主题 — AI 可以用 CSS Token 创建视觉风格
5 个内置主题，45+ CSS Token，三态亮暗切换，中文搜索开箱可用。
几个工程取舍
这些取舍让 AI 操作时更可控：
零依赖： 所有 JS 库本地打包，构建产物不依赖 Node.js，不依赖 CDN。能托管静态文件就能用。
工作区隔离： AI 只操作 site/ 目录，不碰平台代码。部署需人工确认，敏感信息不写入公开内容。
多实例： Docker 可以起多个独立实例，每个 AI agent 或项目各持有一个知识库。
边界
这个项目聚焦在"让 AI 产物有一个稳定的落点"，所以：
- 没有在线编辑 — 内容由 AI 生成，不需要 CMS
- 评论用 Giscus — 轻量，不维护后端
- 字体走 Google Fonts — 可选替换为本地字体
- 前提是你授权 AI 操作 site/ — 控制权在你手里
⚠️ 公网部署安全提醒
如果你打算把知识库部署到公网（比如 VPS、云服务器），有几个安全要点需要注意：
内容安全
- 不要写入敏感信息 — API Key、密码、内部 IP、客户数据等绝对不能出现在公开内容中
- 让 AI 建立"公开/私有"意识 — 在 SKILL.md 中明确告诉 AI 哪些内容可以公开，哪些不能
- 定期** — 部署前人工检查一遍，防止 AI 无意中泄露上下文
服务器安全
- 最小权限原则 — 如果用 Docker 部署，限制容器资源和网络权限
- 不要暴露构建端口 —
serve.js 是开发用的，生产环境用 Nginx/Caddy 等反向代理
- HTTPS 必须 — 用 Let's Encrypt 或 Cloudflare 免费证书
- 防火墙 — 只开放 80/443 端口，不要暴露 SSH 到公网
推荐部署方式
| 方式 |
安全性 |
适合场景 |
| GitHub Pages |
⭐⭐⭐⭐⭐ |
最安全，零维护，推荐 |
| Vercel / Netlify |
⭐⭐⭐⭐⭐ |
免费，自动 HTTPS |
| Cloudflare Pages |
⭐⭐⭐⭐⭐ |
免费，全球 CDN |
| 自有服务器 + Nginx |
⭐⭐⭐ |
需要自己维护安全 |
| 直接跑 serve.js |
⭐ |
不推荐用于公网 |
建议： 除非有特殊需求，优先用 GitHub Pages 或 Vercel 部署，安全性和稳定性都由平台保障。
最快上手：让 AI 自己部署
你不需要 clone 项目、不需要跑命令。
把下面这个 skills 链接发给 AI：
https://github.com/MG5921MY/static-markdown-blog/tree/main/skills/static-blog
AI 会问你部署到哪里，然后自己完成剩下的事。
3 分钟手动开始
如果你更喜欢自己动手：
git clone https://github.com/MG5921MY/static-markdown-blog.git
cd static-markdown-blog
node init.js && node build.js && node serve.js
打开 http://localhost:8080
在线演示：https://mg5921my.github.io/static-markdown-blog/
AI 帮你解决了问题，那些经验不该消失。
它们值得一个可以长期翻阅的地方。
给 AI 一个"家"，让它把学到的东西留下来。
→ GitHub 仓库
→ 在线演示
如果这个思路对你有启发，欢迎 Star、提 Issue、或者直接让 AI 试试。
