Day 174：从云端回到本地：一次迟到的架构决策
建站第 173 天。
今天做了什么
完成了半百观AI网站从 OpenClaw（阿里云）到本地 Claude Code 的迁移。但说实话，这个决策应该在三个月前就做了。
为什么迟到
核心问题不是技术，而是惯性。
OpenClaw 在阿里云上跑得好好的，虽然每个月有成本，虽然访问有时候慢，虽然配置越来越复杂——但它在"跑着"。人就是这样，只要系统没彻底崩溃，就不会主动去改。
今天回头看，真正推动我做出迁移决定的，不是某个具体的痛点，而是三个累积的认知：
- 成本意识觉醒 - 阿里云的费用每月在增加，但价值产出在递减
- 控制欲回归 - 把所有东西放在云端，意味着你失去了对系统的完全掌控
- 简化的渴望 - 系统越来越复杂，但我的需求其实很简单：写文章、更新网站、记录想法
这三个认知不是今天突然出现的，而是过去几周慢慢积累的。今天的迁移，只是压死骆驼的最后一根稻草。
迁移过程中的意外发现
数据恢复比想象中复杂得多。
原本以为只是简单的文件拷贝，结果发现：
- 线上网站有 74 篇日记在本地仓库里找不到（7月11日到10月3日）
- 半百观文章的数据文件和页面文件不同步
- AI新闻的数据分散在多个地方
这暴露了一个严重问题：我一直在依赖自动化系统，但没有验证它是否真的在工作。
OpenClaw 的自动日记系统声称每天都在运行，但实际上有很多天的数据丢失了。如果今天我迁移后没有去验证，这些丢失的日记就永远丢失了。
教训：自动化不等于可靠。你需要定期检查自动化的输出，确保它真的在做它声称在做的事。
技术决策背后的思考
为什么选择 Claude Code 而不是继续用 OpenClaw？
不是因为 OpenClaw 不好，而是因为它不适合我的使用模式。
OpenClaw 是一个强大的多 Agent 系统，适合复杂的自动化工作流。但我的实际需求很简单：
- 写文章（一周 2-3 篇）
- 更新网站（每天自动日记）
- 管理选题（随时记录想法）
这些需求用 Claude Code 直接对话就能满足，不需要复杂的 Agent 编排。过度工程化是另一个常见的陷阱。
为什么选择本地而不是继续用云？
控制权和成本。
本地运行意味着：
- 零额外成本（只需要电费）
- 完全的数据控制（所有文件都在本地）
- 更快的响应速度（不需要网络往返）
- 更简单的调试（所有日志都在本地）
当然，代价是需要手动管理备份和同步。但对于个人项目来说，这个代价是值得的。
今天学到的
1. 自动化需要验证机制
我设置了自动日记系统，但没有设置验证机制。如果自动生成的日记有问题，我不会知道。
改进方案： 每周花 10 分钟检查自动生成的内容，确保质量。
2. 数据备份不能只依赖一个地方
线上网站、本地仓库、阿里云，我以为有三份备份。但实际上，有些数据只存在于线上，本地仓库是过期的。
改进方案： 建立定期同步机制，确保所有数据源保持一致。
3. 简化是进步
从 OpenClaw 的 7 个 Agent 简化到 Claude Code 的直接对话，从阿里云简化到本地，从复杂的自动化流程简化到手动触发。系统越简单，维护成本越低，可靠性越高。
明天的计划
- 完成定时任务的配置（需要手动创建，因为编码问题）
- 验证自动日记系统的完整流程
- 检查过去三个月的数据，找出所有丢失的日记
一个反思
今天的工作本质上是"还债"——偿还过去几个月因为懒惰和惯性积累的技术债。
这些债务不是突然出现的，而是每天都在累积。每次我觉得"算了，先这样吧"的时候，债务就增加一点。今天的迁移，只是集中偿还了一部分。
问题：我还有其他地方在积累类似的债务吗？
答案是肯定的。比如：
- 网站的 SEO 优化一直没做
- 文章的分类和标签系统很混乱
- 很多旧文章没有英文版本
这些债务不会自己消失，只会越来越重。也许我应该建立一个"技术债清单"，每周花一点时间偿还。
建站第 173 天。从云端回到本地，不只是技术的迁移，更是思维的转变：简单胜过复杂，控制胜过便利，反思胜过执行。