我把自己的公众号写作系统，改成了三台电脑都能无缝切换。表面看，这是在折腾机器、目录、SSH、Dashboard、离线队列这些东西。但做完之后我发现，它真正解决的不是技术问题，而是一个很普通的写作问题。
我的主要目标其实很简单，就是让写作随时可以进行。不管我坐在哪台电脑前，不管当时打开的是哪个 agent，不管主机是不是刚好在线，只要一个想法出现，系统就应该先把这个想法接住。更进一步说，我希望多个 agent 也能接着工作。一个 agent 写到一半，另一个 agent 能继续看同一份文章、同一个台账、同一个 Dashboard，而不是每次都从环境问题开始。
你有没有遇到过这种情况。一件事本来只在一台电脑上能做，坐在那台电脑前就很顺，换到另一台电脑，整个人就卡住了。文件在哪里，版本是不是最新，刚才写了一半有没有保存，面板为什么打不开，另一台机器是不是还在线。每个问题都不大，但它们会一点点消耗人的心力。
尤其是写文章。写文章最怕的不是工具慢一点，也不是步骤多一点，而是你刚有一点想法，手还没碰到正文，脑子先被环境问题打断了。你想想看，一个念头刚冒出来的时候，其实很轻，很脆。你让它先等一下，先处理路径，先处理版本，先处理同步，它很快就散了。agent 也是一样，它最怕的不是多做一步，而是工作上下文断掉，刚建立起来的判断被迫重新来一遍。
我以前的状态就是这样。主力电脑上当然什么都顺，文章库在这里，V4 Dashboard 在这里，skill 也在这里。可是我不可能永远只坐在一台电脑前。有时候我在 apple64 上，有时候在 mac 上，有时候只是顺手想打开面板看一眼，有时候想马上写一篇草稿。说到这里，真正的问题就出现了。
我到底应该把文章写到哪台机器。写完以后别的电脑能不能看到。主机不在线怎么办。副机上改了 skill，会不会把主机的新版本盖掉。打开 Dashboard 是不是要记一串命令。这些问题看起来都小，但长期用下来，你会发现它们才是最烦的地方。
先别急着同步所有东西
一开始很容易想到一个方案。既然有三台电脑，那就把文件都同步起来。谁写都一样，哪里打开都一样，所有机器都保持一致。听起来非常自然，也很诱人。但我跟你说，这个方案最危险的地方，恰恰就在它看起来太自然。
如果三台电脑都能写，都能改，都能互相同步，那看起来是自由了，实际上也把冲突带进来了。哪台电脑才是最终版本。如果两台电脑都改了同一个文件，谁覆盖谁。如果其中一台电脑离线了一阵子，后来又上线，它拿着旧版本回来，会不会把新版本冲掉。
这些事情不是不能解决，但越解决，系统就越复杂。最后你会发现，你本来只是想写文章，结果先给自己造了一个分布式文件系统的管理问题。这个时候就要停一下，问一个更朴素的问题。我们到底需要三台电脑平等地当主库吗。
最后我们没有走那条路。这次改造的核心观点很简单，文章库要有一个主心骨。不管我在哪台电脑上写，真正的正式文章库只有一个。它在主机里，主机上的文章库才是最终位置。
**副机不是第二个正式库，也不是第三个正式库。副机只是入口。**这件事一确定，很多问题就变简单了。主机在线时，副机写文章不是先写到自己本地，再同步过去，而是直接通过 SSH 让主机写。这样文章从一开始就在正式库里。
我在 apple64 上写，落点还是主机。我在 mac 上写，落点还是主机。打开 V4 Dashboard，看的也是主机那一份数据。这听起来少了一点自由，但换来的东西很重要，叫确定性。
有意思的是，很多系统让人安心，不是因为它提供了最多选项，而是因为它在关键地方不给你制造岔路。你不需要判断哪一份才是真的。你不需要猜这台电脑上的文件是不是最新。你只需要知道，正式库只有一个。
主机不在线也不能写失败
当然，问题没有这么简单。如果主机不在线呢。这才是这套系统真正需要处理的地方。因为从写作者的角度看，我不关心主机此刻是不是在线。我只关心一件事，我现在有想法，我要写下来，而且要写成功。
如果系统告诉我，主机不在线，所以你不能写，那这个系统就没有站在写作者这边。换个说法，系统不能只在一切正常的时候好用。它要在不那么正常的时候，也尽量把人的意图接住。
所以我们做了一个副机离线队列。主机在线时，副机直接写主机。主机不在线时，副机允许写成功，但不会假装自己就是正式文章库。说实话，这个边界一旦立住，很多焦虑就下去了。它会把文章放进本机对应的数据盘 outbox 里。
两台副机会先把文章放到各自的数据盘离线队列里。等主机恢复之后，再把 outbox 里的文章同步回主机正式库，并重建台账。
这个设计我很喜欢。它既没有牺牲写作时的连续性，也没有牺牲系统的秩序。你可以把它理解成机场的值机柜台。飞机能正常起飞的时候，你直接登机。如果天气原因暂时不能飞，柜台不会让你回家重来，它会先把你的信息登记好，等航班恢复再继续处理。
写作系统也应该这样。它不应该因为某台机器一时不在线，就让写作中断。它应该先把你的意图接住。等条件恢复，再把临时状态转成正式状态。说回来，这就是离线队列最有价值的地方。
我们加了几道保险
第二个让我觉得重要的改动，是给系统加保险。以前我最担心的是副机改 skill。这件事很容易发生。比如我在 apple64 上发现一个小问题，顺手改了一下。过几天回到主机，主机又改了一版。再过几天同步，谁还记得哪一版才是新的。
人的记忆在这种事情上是不可靠的。不是因为人不认真，而是因为这种细节太多了。今天改了哪个文件，明天同步到哪台机器，后天哪台机器重启过，时间一长，脑子里那张地图一定会糊。
所以这次我们不再靠记忆。我们给副机加了一个上工前的自检。它做的事情很朴素，就是先检查自己有没有和主机不一致的关键文件。如果一致，就告诉你没问题。如果不一致，就告诉你哪些文件变了。需要的时候，它还能把主机和副机的具体差异展示出来。
这就很要紧。因为自动化不是越猛越好。很多自动化系统让人不安，是因为它在背后偷偷做决定。你不知道它什么时候同步了，什么时候覆盖了，什么时候把旧东西当成新东西。
这次我们刻意不这么做。监督可以自动，合并要清楚，覆盖要谨慎。所以我们还加了一个从副机拉回改动的正式流程。如果我真的在副机上改了东西，主机可以把副机的关键文件拉回来，先放进临时目录，显示差异。默认不覆盖。
只有确认采纳时，才真正应用这些改动。应用之前，还会先把主机旧文件备份起来。这就从一个模糊的口头流程，变成了一个明确的正式流程。副机可以实验，主机负责定稿，发布之前先看差异，覆盖之前先备份。
你看，这里面没有什么玄学。都是很笨的办法。但长期系统最需要的，往往就是这种笨办法。它不赌人的记忆，也不赌网络永远顺畅，更不赌每一次操作都刚好正确。
Dashboard 不只是一个页面
这次还改了 V4 Dashboard。以前 Dashboard 更像是一个工作台。打开它，是为了看文章库，看任务，看发布状态。现在我更希望它像一个驾驶舱。不只是展示内容，还要展示系统是否健康。你想啊，如果每天都要靠脑子记系统状态，那工具就没有真的替你分担。
所以我们加了两个状态卡片。一个叫离线队列。它会显示 outbox 里有没有 pending、failed、skipped、synced 的文章，也会显示同步锁有没有被占用。另一个叫技能同步。它会每隔一段时间检查两台副机和主机是不是一致。如果副机上有未发布的改动，它会提醒。
这件事的好处不在于信息更多，而在于你不用记。好的系统，应该减少人的记忆负担。我不应该每天想着 apple64 有没有改过，mac 有没有旧版本，outbox 有没有没同步的东西。这些事情应该被系统放在我能看到的地方，对吧。
一眼看到三机一致，我就安心。看到有离线文章，我就知道该同步。看到有漂移，我就知道先别覆盖。这和开车有点像。你不需要一直记着发动机温度、油量、胎压。仪表盘会把需要注意的东西放到你眼前。
系统也是一样。只要它足够诚实地告诉你当前状态，你就不用一直在脑子里维护一张隐形清单。到这里，我觉得 Dashboard 的角色就变了。它不只是一个页面，而是一个让人知道系统还稳不稳的入口。
最后我们把说明书也瘦身了
还有一个改动，看起来不那么技术，但我觉得很关键。我们把 SKILL.md 瘦身了。它原来有一千多行。这不是坏事，说明这套系统经历过很多问题，也积累了很多经验。故障排除、历史记录、发布细节、Dashboard 注意事项，全都写在里面。
但问题是，每次加载 skill，都像把一本维修手册摊在驾驶座上。你当然能从里面找到答案，但真正重要的规则也会被淹没。比如主机才是正式库。比如副机开工前要先检查自己有没有未同步的改动。比如改完系统规则以后，必须同步到另外两台电脑。比如发布前必须过质量门。
这些规则应该像仪表盘上的灯一样醒目，而不是藏在一千行文档里。所以我们把主文件压到了百来行。它只保留硬规则、关键命令、当前职责和参考入口。详细手册拆到 references 里。
写作流程有写作流程的文件。多机同步有多机同步的文件。Dashboard 有 Dashboard 的文件。故障排除有故障排除的文件。原文也没有删，完整归档。这其实也是一种产品思维。
用户第一次进来，不应该先看百科全书。他应该先看到现在该怎么做。等真的遇到问题，再去翻维修手册。讲真，驾驶舱就应该像驾驶舱，维修手册就应该像维修手册。
真正改的不是电脑
回头看，这次改造表面上是在改三台电脑。主机、副机、SSH、Dashboard、outbox、版本号、同步、备份、漂移检测。这些词听起来都很技术。但我觉得真正被改造的，是写作这件事周围的秩序。
写作最珍贵的不是工具，而是那个刚刚冒出来的念头。一个念头刚出现的时候，很轻，很脆。其实吧，如果你要先想文件在哪，环境有没有配好，版本是不是新的，另一台电脑有没有同步，它很快就散了。
多个 agent 一起工作时，这件事会更明显。它们不是人，不会天然记得我昨天在哪台机器上改过什么，也不会自动知道哪一份文件才是正式版本。如果底层环境是乱的，agent 越努力，越可能把混乱放大。所以我想要的不是让 agent 更忙，而是给它们一个清楚、稳定、可检查的工作现场。
所以我现在越来越在意工作流的意义。好的工作流不是让人显得更专业。好的工作流是让人少被打断。你在哪里，就在哪里开始。主机在线，就直写主机。主机不在线，就先进入队列。副机改了，就提醒你。版本不一致，就展示差异。要覆盖，就先备份。打开 Dashboard，就看到系统状态。
这些东西合在一起，才会让人有一种很朴素的安全感。我不需要每一步都紧张。我也不需要靠记忆维护整个系统。我只要表达意图。比如写一篇文章。比如打开 V4 Dashboard。比如把副机改动拉回主机。剩下的流程，系统应该替我接住。
说到最后
这次我最大的感受是，个人系统做到最后，不是功能越多越好，而是边界要清楚。谁是主库，谁只是入口，什么时候允许离线，什么时候必须提醒，什么时候可以自动，什么时候必须让人确认。这些边界想清楚，系统才会越来越稳。
很多工具之所以越用越累，不是因为它们不强，而是因为它们把边界做糊了。到处都能改，到处都能同步，到处都像主库，最后人反而不知道该相信哪里。我现在更愿意接受一种有节制的自动化。
能自动检查的，就自动检查。能自动提醒的，就自动提醒。但真正会覆盖、合并、发布的动作，要留下清楚的痕迹。这不是保守，这是对长期使用负责。因为一个系统不是只用一天，它要陪你过很多个普通的下午。
你可能在主机前，也可能在副机前。你可能网络很好，也可能主机刚好不在线。你可能记得所有命令，也可能完全忘了。系统要做的，不是考验你有没有记住，而是在你忘了的时候，也尽量不让事情坏掉。
我觉得这就是这次改造真正有价值的地方。不是三台电脑终于连起来了，而是写作这件事，终于少了一点被环境打断的可能。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你看我的文章，我们，下次再见。
作者：剑飞，本文共3442字