主题
从DeepSeek宕机说起：为什么盘诚越来越笃信"本地优先"
亲爱的小伙伴们，大家好！我是Panson，一名混迹高校二十余年的老IT。
10月15日早上8点11分，DeepSeek网页端、App和API全线提示“服务器暂时不可用”，直到13点04分才恢复，整整断了近5个小时。如果你只是拿来闲聊，顶多骂两句；但如果你把API接进了工作流、自动化脚本或业务系统，那几个小时就是实打实的停工。更扎心的是，这已经不是第一次了——2026年以来，DeepSeek已出现至少18次大面积服务异常。
这让盘诚想起一个词儿：本地优先（Local First）。它不是让你推翻云，而是想清楚一件事——你的数据，到底该放在哪儿。
2019年，Martin Kleppmann等人在Ink & Switch发表了《Local-first software: You own your data, in spite of the cloud》，系统地提出了本地优先的理念。核心就一句：数据首先属于你自己的设备，云只是帮忙同步、备份和协作的，不应该成为软件能用的唯一前提。
很多人容易把概念搞混。先说结论：自托管是把云服务器从别人手里拿回来，本地优先是把数据从云服务器手里拿回来。 这是两码事。
本地优先不反对云。它的主张其实很简单：数据首先完整地落在你自己的设备上，云负责的是同步、备份、协作，而不是软件能不能跑的"命门"。说白了，断网了你还得能干活，服务商哪天关张了数据不能跟着蒸发。
也别把它跟自托管混为一谈。自托管是你把服务器从别人手里拿回来，自己部署、自己维护，追求的是"应用层面的掌控"。本地优先盯的是"数据层面的主权"——不排斥云，只是重新排座次：设备是主人，服务器是帮手。两个不冲突，可以一起用。
为什么这事突然被反复提起？ 因为像DeepSeek这样的大模型，已经从"好用的工具"变成了很多人生产线的一部分。过去一年多家大模型服务商都出现过宕机。用户量暴涨、算力跟不上、版本频繁切换，任一环节出问题都可能引发连锁反应。你接进工作流、接进业务系统，它一崩，崩的不是你一个人的聊天框，是一整条流程。
你花时间在AI工具里写的文档、生成的代码、整理的知识库，如果有一天服务商改规则、涨价甚至关停，这些东西怎么办？本地优先回答的是：如果背后的公司不存在了，你今天创造的数据还剩下什么？
稳定性本身就是一种能力。你把命脉押在一家的服务器上，风险就是别人的。好在CRDT（一种让多台设备各自修改后能自动合并、不用人工处理冲突的技术）等方案逐渐落地，让"离线可用、在线同步"从理想变成了可实现的方案。
落到咱们身上能做什么？三条建议，都实用，不用大动干戈。
说实话，完全本地优先的软件生态还没成熟，但你可以做一些务实的事。NAS玩家可以跑起来——在自己NAS上部署开源大模型（比如用Ollama跑本地模型），断网时能顶用，隐私数据不出内网。给关键流程配备胎——用大模型API至少接两家服务商，一家挂了自动切另一家，先保证不断流比啥都强。重要数据定期在本地留一份——笔记、代码、对话记录都养成定期导出习惯。Obsidian、Logseq这类本地优先笔记工具值得尝试，文件在你硬盘或NAS上，用什么软件打开都行。别问"用得上吗"，真用的时候你会庆幸做了。
另外，还请注意两个小细节：中断重试别狂点，加个间隔——高峰期一窝蜂重试，流量反而被自己放大，恢复更慢。关键任务保留人工复核，别把生死攸关的流程全交给自动化，尤其是依赖外部API的环节。
本地优先不是完美方案，CRDT在性能、权限管理、大规模协作上还有不少坑。但它提出了一个值得想清楚的问题：你的数据，到底算谁的？
如果一个软件背后的公司和服务器有一天都不存在了，你手里还剩不剩得下一份完整、能继续用的数据？如果答案是那份你手里攥着的、还能接着用的数据，那才该是你真正想要的。
你有没有遇到过云服务宕机导致工作停摆的情况？最重要的数据主要存在哪儿？评论区聊聊。
#Homelab #本地优先 #自托管 #CRDT