一条稿子，自动铺满 8 个平台

写一篇文章要花多久？

如果你是一个人干活，真正的答案不是"写作那几个小时"，而是写完之后——把它搬到公众号、复制到知乎、贴进掘金、翻译发 Dev.to、剪个短句发 X、再挂一条即刻……这一圈"搬运"下来，比写作本身还累。

这周我把这套活干掉了。现在我写完一篇稿子，存进一张飞书表格，敲一条命令，它自己铺到 8 个平台。

我想聊的不是"我做了个自动化工具"这件小事，而是三个更值钱的判断：一人公司真正的瓶颈在哪、这套机器该怎么搭、以及——它差点骗了我。

1. 一、写作不是瓶颈，分发才是

很多人以为一人公司最难的是"内容产能"。不是。

AI 已经把写作的边际成本压到了地板。真正吃掉时间的，是同一份内容在十几个平台之间的重复劳动：登录、粘贴、调格式、传封面、改标签、发布、记录……每个平台五分钟，八个平台就是四十分钟，而且每天都要来一遍。

这种劳动有个最恶心的特点：它不创造任何新价值，纯粹是把已经存在的东西搬来搬去。但你又不能不做——不分发，写得再好也没人看。

所以一个人干活，第一件该工业化的事，不是"写得更快"，而是"把分发这件确定的、重复的、没有判断含量的活，整个交给机器"。

2. 二、中央调度台 + 插件式通道

搭这套东西，我没有写一个巨大的"全自动发布脚本"。那种脚本看起来很爽，但改起来是噩梦——加一个平台就要动整个流程。

我的做法是拆成两层。

一层是中央调度台。 我用一张飞书表格当总控：每一行是一篇待发内容，标题、正文路径、要发哪些平台、发布时间、状态，全在表里。我不碰代码，只填表。到点了，调度器扫这张表，把"该发的"挑出来。

另一层是插件式的分发通道。 每个平台是一个独立的小函数，彼此不知道对方存在。想新增一个平台？只要写一个新函数挂上去，主调度逻辑一行都不用改。这周我加 Dev.to 通道，前后就动了一个函数。

这个结构的好处，是它把"多平台"这个会指数级变复杂的问题，摊平成了"一堆互不干扰的单平台问题"。一人公司维护不起复杂系统，所以从第一天就得把复杂度摁在最低。

3. 三、它差点骗了我

真正想讲的是这一段。

图文矩阵那条通道跑完，命令返回了成功——退出码 0，没有任何报错。我以为知乎、掘金那边草稿都躺好了。

我去草稿箱一看：空的。

机器"告诉"我它干完了，但其实什么都没发。原因是负责同步的工具，在没真正连上浏览器扩展的情况下，依然会以"成功"退出。它对着我笑着说"搞定了"，手里却是空的。

这件事让我把成功的判定逻辑整个重写了一遍：不再看命令返没返错，而是去解析它真实的输出——必须同时出现"扩展已连接""同步完成 N 个、失败 0 个"这些真实信号，而且成功数要等于平台数，才算数。少一个都判失败，回写进飞书。

这里藏着自动化最容易踩的坑：你以为"没报错"等于"成功了"，但机器的沉默和机器的谎言长得一模一样。 越是把活交给机器，越要给每一步装一个"你真的干成了吗"的验真环节，而不是听它自己汇报。

4. 写在最后

搭完这套东西，我对"自动化"的理解变了。

它从来不是"一键搞定一切"的幻觉。真正好用的自动化，是一种纪律：把确定的、重复的、无需判断的事外包给机器，把判断权牢牢收在自己手里。

分发是确定的，交给机器。什么内容值得写、发出去的东西是否真的落地了、机器有没有在骗我——这些是判断，留给自己。

一个人能顶一个团队，靠的不是把自己变成机器，而是想清楚：哪些交给机器，哪些绝不。

腾野 Neo · 一人公司实践者