敲完最后一行 Commit 信息，我盯着屏幕上的 `git push origin main` 输出，感觉像刚跑完一场全马。项目上线了，这个叫 Flovico 的博客雏形。最后那条 Commit 信息我写的是：“v0.1 上线。底层表结构：posts(id, title, slug, raw_content, html_content, status, tags, created_at, updated_at, deleted_at), tags(id, name, slug, post_count), configs(key, value)”。我把表结构刻在 Commit 里，不是给谁看，是给我自己立碑。十年后如果这堆代码还在，翻到这一行，我得知道自己是从哪块砖头开始砌的。
这结构简单得有点寒酸。就三张表。`posts` 表是核心，`raw_content` 存原始 Markdown，`html_content` 是渲染后的，为了 SEO 和首屏速度，我提前渲染好静态化。`slug` 字段是 URL 友好标识，当年做 SEO 时留下的肌肉记忆，必须得有。`status` 字段就三个值：draft, published, archived。`tags` 表单独拎出来，用 `post_count` 做冗余计数，避免联表查标签云时的性能瓶颈。`configs` 表就是键值对，存点全局配置，比如站点标题、描述、主题开关。没了。没用户系统，没评论，没后台管理界面。所有的内容更新，我打算直接走 Git 提交，用 GitHub Actions 触发自动构建和部署。这路子 2016 年那会儿叫 JAMstack，现在 2025 年了，我管它叫“极简生存模式”。
为什么这么搞？因为被坑怕了。2019年那会儿带团队做项目，数据库设计动不动二三十张表，各种外键关联、事务锁、读写分离。为了一个后台 CMS 的富文本编辑器，能跟产品吵三天。最后项目黄了，那一堆精心设计的 ER 图屁用没有。现在我做自己的 IP，第一原则就是“可丢弃”。这个博客的整个数据层，我必须在十分钟内能用另一个框架重构出来。`posts` 和 `tags` 的关联，我甚至没做中间表，直接用 `posts.tags` 字段存逗号分隔的标签 ID 字符串。我知道这违反数据库第一范式，但查询的时候，我一次 `SELECT * FROM posts WHERE tags LIKE ‘%?%’` 就完事了。我的内容量，撑死了几千篇，根本到不了需要考虑范式冗余的地步。先跑起来，比设计完美重要一万倍。
这种设计背后，是 2025 年我作为一个 AI 实战教练的思维转变。我不再追求技术的“优雅”和“完备”，而是追求“可控”和“可解释”。我的内容生产流程会重度依赖 AI。可能用 GPT 生成草稿，用 Claude 优化逻辑，最后我自己在 raw_content 里定稿。这个简单的表结构，就是为了无缝对接自动化脚本。我可以写个 n8n 工作流，监听我的笔记软件，自动解析内容，调用 AI 处理，然后生成符合这个表结构的 JSON，通过 API 塞进数据库，触发部署。整个链条里，数据库只是一个哑巴存储节点，越简单，越不容易成为瓶颈。
Commit 信息里那个 `deleted_at` 字段，是软删除标记。我没真的打算删任何东西。所有写下的字，都是时间的切片，删了就是否认过去的自己。这个博客会记录我接下来十年的所有变化，技术的、认知的、身体的。`deleted_at` 只会在我彻底重构数据模型、迁移到新系统时，才会被填上日期。那一刻，意味着一个时代的终结，和另一个简单粗暴的新循环的开始。
好了，雏形有了。下一个挑战是，怎么让这个简单的结构，扛住未来十年我各种折腾的流量和内容冲击。以及，更重要的，我怎么持续往里面填东西。
