内容系统
为什么有两套内容系统？用生活中的例子帮你理解。
为什么有两套系统？
想象一下你的手机里有两种"发内容"的方式：
- 朋友圈 / 公众号：随时发、经常更新、能收到评论、用手机就能操作
- 飞书文档 / 产品手册：稳定不变、有版本记录、多人协作审批后才发布
这个网站模板也是这样——博客就像你的公众号，文档就像你的飞书知识库。它们各司其职，互不干扰。
对比一览
博客 (/blog) | 文档 (/docs) | |
|---|---|---|
| 像什么 | 公众号 / 朋友圈 | 飞书文档 / 产品手册 |
| 更新频率 | 经常更新 | 相对稳定 |
| 在哪里写 | 管理后台（浏览器里） | Git 仓库里的 Markdown/MDX 文件 |
| 谁来管理 | 作者自己 | 仓库维护者，通过 Git 提交和审核 |
| 有草稿功能吗 | 有，支持定时发布 | 通过 Git 分支管理（类似文档审批流） |
| 支持评论吗 | 支持 | 不支持 |
| 能上传图片吗 | 能，直接在后台上传 | 能，但需要放在项目文件里 |
| RSS 订阅 | 包含 | 不包含 |
博客：你的"公众号"
在管理后台（/admin）里，你可以：
- 写文章、存草稿、设定时发布
- 上传封面图和配图
- 管理评论
- 导入/导出内容备份
- 通过 API 让 AI 帮你发文章
适合放这里的内容：行业观点、产品更新通知、教程文章、个人思考——任何"经常会发、会更新"的内容。
文档：你的"飞书知识库"
文档页面（就是你现在看的这些）放在项目代码里，像一本"产品说明书"，也像 Obsidian 一类本地 Markdown 笔记：
- 内容稳定，不会频繁改动
- 在本地文件和 Git 仓库里维护
- 改动需要提交并随网站重新部署
- 跟网站代码一起发布，保证版本一致
适合放这里的内容：产品手册、使用说明、开发者文档、部署指南——任何"写好后长期不太改"的内容。
简单判断：放哪里？
问自己一个问题：这个内容下周还会改吗？
- "可能会"→ 放博客
- "写完就不怎么动了"→ 放文档
如果你只想用其中一套系统也完全可以。比如只要博客不要文档，或者反过来，删掉不用的那部分就行。