这数据库表结构得从根上设计成能活过我的寿命。第一张表叫 `articles`，主键是 UUID，不是自增 ID，因为我要的是分布式思维，哪怕以后数据迁移到火星上也不能乱。字段除了标题正文，我硬塞进去三个时间戳：`created_at`（草稿时间）、`scheduled_at`（计划发布时间）、`published_at`（实际发布时间）。我得知道从想法到落地到底卡了多久。
第二张表 `article_meta` 是专门用来焦虑的。`word_count`（字数）、`read_time_estimate`（预估阅读时长）、`seo_score`（SEO 分数），还有个 `status` 字段，状态从 ‘draft’ 到 ‘scheduled’ 再到 ‘published’，最后必须有个 ‘archived’。我得看着这些状态流转，才知道自己是不是在空转。
自动发布逻辑是用 Python 脚本配 Systemd Timer 跑的，没用什么花哨的框架，就纯 `requests` 库加 `sqlite3`。脚本每五分钟扫一次 `articles` 表，找 `scheduled_at` 小于等于当前时间且 `status` 是 ‘scheduled’ 的记录。找到就调 WordPress 的 REST API 发布，成功后把 `status` 改成 ‘published’，填上 `published_at`。这里有个坑，WordPress 的 API 有频率限制，我得在脚本里加随机休眠和重试机制，不然半夜并发发布失败，整个流程就断了。
这整套东西部署在阿里云最便宜的共享虚拟主机上，用 SFTP 传文件，在 crontab 里写定时任务。为什么不用更酷的 Docker 或 Kubernetes？因为这套东西的核心不是技术炫技，而是“绝对可靠地在我睡着、喝酒、崩溃的时候，还能替我把话说了”。它得像个老伙计，不说话，但该干的活一点不落。
团队里那帮小孩理解不了这个。他们总想用最新最潮的框架重构，说我这套是“屎山”。我懒得解释。他们没在凌晨三点接过甲方的电话，没经历过服务器宕机后手动一篇篇补发的绝望。这种“数字化遗产”工程，优雅是次要的，活下去是首要的。它现在每五分钟一次的心跳，是我给自己买的保险——确保哪怕我明天就消失，这些想法还能按我设定的时间，从数字世界里长出来。
商业是什么？商业就是把你最值钱的东西，从对一个人时间的依赖，变成对一个系统稳定性的依赖。我今年 35 岁，才刚读懂这一点。冷空气从窗户缝钻进来，屏幕上的日志一行行滚动：“2020-10-11 03:15:02 – 文章 [ID: xxxx] 发布成功。” 这一刻没有感慨，只有确认。确认这个系统，比我更可靠，也更无情。这就对了。
