为什么内容要留在 Git

说明：这篇长文由执行 Worker 在 dev 分支生成，署名“Folio 示例内容 · AI Worker”是显式的示例身份，不代表真实作者或既有发布史。内容描述的是当前 Folio 仓库的实现事实。

Folio 不是先有一个内容数据库，再把数据导出成 Markdown。它反过来：仓库里的 Markdown 文件就是内容源，页面、虚拟清单和静态 HTML 都是这份源文件的投影。这个顺序看起来只是实现细节，实际会决定评审、发布和回滚三种动作长什么样。

内容不是一个数据库字段#

在常见的 CMS 里，一篇文档的生命周期通常是：登录后台、填写富文本、点击发布、数据进入数据库。站点再通过 API 把数据取出来。这个模型很成熟，但它把“内容”和“代码”放进了两个不同的变更系统。

Folio 的选择更朴素：一篇内容就是一个 .md 文件，标题、类型、分组这些结构化信息放在 YAML Frontmatter 里。

---
title: 为什么内容要留在 Git
type: article
date: 2026-11-04
group: 专题
tags:
  - Git
  - Content
---

解析后，它会变成一个统一的 FolioDoc。title、description、group、order、tags、date、status 等字段进入内容模型；正文继续作为 Markdown 保存。渲染层不需要知道文章来自哪个后台，只需要消费这份模型。

评审和发布共享同一个差异#

内容在 Git 里以后，评审看到的不是“后台预览截图”，而是可以直接评论的 diff。发布也不是把数据库内容复制到另一套系统，而是让同一份文件依次经过 feat/*、dev、test、prod。

这样做有三个直接后果：

1. 回滚是精确的。回滚一篇文章就是回滚一个 commit，不会混进同一天其他人的内容。
2. 评审和执行使用同一份材料。Reviewer 看到的是最终会被构建的 Markdown，而不是另一个编辑器里的草稿。
3. 内容可以像代码一样被验证。构建会检查路由冲突、Frontmatter 解析、静态输出和链接目标，而不是只检查“后台保存成功”。

Git 不擅长什么#

Git 不是万能的。它对二进制大文件、多人实时协作、非技术编辑者的门槛、海量内容检索都不算友好。Folio 也没有假装解决这些问题：当前运行时只提供内容模型、路由、导航和静态发布，不内置图片管理、评论系统或在线编辑器。

如果你的团队需要让非工程角色高频改稿，Git 内容源不一定是最短的路径。它更适合这样的场景：内容与实现紧密相关，评审本来就在仓库里发生，发布需要可追溯，而且维护者愿意接受 Markdown 的写作方式。

在 Folio 里落地#

现在的官方站已经把这套顺序跑通了：

• 内容协议 定义了 Skill 与运行时共同依赖的最小字段；
• 从一个内容文件到最终静态页面 展示了文件如何经过解析、清单和静态输出；
• 官方站项目档案 记录了本项目当前的边界与未完成项。

换句话说，“内容留在 Git”不是一句品牌口号，而是这个站点每一次构建时真实发生的数据流。你可以从上面任意一篇内容继续往下读，也可以在站内搜索里直接输入 virtual:folio/content 或 静态构建 验证这些词确实来自正文。