这个项目博客的雏形，本质上就是个 CMS，但我不想用 WordPress。用别人的东西，总感觉数据不在自己手里，哪天插件一更新，或者主题作者跑路了，整个站就废了。2016年那会儿我可能会选 Django，但现在，2021年，我只想用最快、最轻、最可控的东西。所以选了 Flask，加上 SQLite。数据库文件就在项目根目录，备份就是复制一个文件，踏实。
表结构我画了三天。不是技术难点，是业务逻辑的取舍。你得想清楚，十年后，这些数据怎么用。比如，我到底要不要“分类”？早期博客肯定要，SEO 友好嘛。但写着写着你就发现，分类是给读者看的，不是给自己用的。你自己复盘的时候，只会用标签和日期。所以最后的设计，极度简化。
核心就三张表。`articles` 表是主体，除了标题、内容、摘要这些基础字段，我加了几个关键列。一个是 `stage`，整数型，对应我那五个阶段：1是野蛮生长，2是扩张陷阱，3是超级个体回归，4是AI核爆，5是终局形态。写的时候手动选，未来检索，一眼就能看出我在哪个时期犯了什么傻。另一个是 `energy_level`，也是整数，1到5。记录写这篇时的精力状态。5是通宵后亢奋，1是身心俱疲硬撑。这个数据未来做统计，看看产出质量和身心消耗的关系，比任何时间管理课都有说服力。
`tags` 表就是标签，多对多关联。我刻意没做分类表。
第三张是 `statistics`。不记录简单的 PV/UV，那没意义。我记录的是“深度行为”：文章的平均阅读完成百分比（通过滚动事件计算）、在哪个段落停留时间最长（可能是代码块或者某个痛点描述）、甚至是从哪个外部链接跳转过来的。这些数据需要前端埋点配合，但值得。我要知道哪些“技术细节”是读者真正啃下去的，哪些“情绪吐槽”是被快速划过的。流量可以骗人，但眼动数据般的阅读痕迹，骗不了人。
设计这套东西的时候，我正卡在“超级个体回归”的节点上。2021年，团队散了，项目交付的尾款有些还没收回来，人一下子从每天十个会议跌到面对一个空荡荡的日程表。恐慌是真实的，就像胃里有个洞。以前用管理填满它，现在只能用代码和清晰的数据库字段。
给3000个客户写代码是夸张，但那种“持续交付”的心智状态是真的。你就像一个 API，接收需求，返回代码。没有情绪，只有输入和输出。做这个博客系统，是把自己重新变成产品经理，去定义“Flovico”这个唯一用户的需求。用户故事很简单：作为一个想记录十年轨迹的人，我需要一个能承载时间、阶段、能量和真实反馈的系统，以便在未来的某个节点，能精准地回溯到每一个决策的上下文。
这比给客户写任何 ERP 或 CRM 都难。因为客户的需求是模糊的，你可以糊弄。但对自己的需求，你没法糊弄。每一个字段的设置，都在逼问自己：十年后，你看重的是什么？是流量数字，还是认知的演进路径？是日更的虚荣，还是那几十篇真正改变你轨迹的深度复盘？
SQLite 文件现在只有几KB。但我知道，它里面埋着一条时间线。这张网现在只有一个起点，但我会把它织下去。用代码，用思考，用这逃不掉的、必须面对的每一天。
