我做了一款更「轻」的内容管理工具，不管理账号、不代发布

从散落在文件夹里的 Markdown，到跨平台内容日历、浏览器侧栏和发布记录，聊聊 PublishKit 的设计思路。

写这篇文章的时候，我想先提出一个问题：

如果你经常在多个内容平台发布文章，真正让你感到疲惫的，是写内容，还是管理内容？

对于只经营一个账号、偶尔发布几篇文章的人来说，这可能不是什么问题。但如果你同时管理小红书、知乎、微信公众号、Pinterest、Instagram，甚至还要兼顾中英文内容，情况就完全不同了。

文章可能是用 Markdown 写的，图片保存在不同的文件夹里，排期记录在 Excel 中，发布链接又散落在浏览器收藏夹或者聊天记录里。

有时候，一篇内容已经发布到了 Pinterest，却忘记同步到 Instagram；有时候，准备发帖时找不到最终版图片；还有时候，明明记得某篇文章已经发布，却怎么也找不到对应的链接。

这些事情单独看都很小，累积起来却会不断打断创作。或者是因过多的杂糅内容而让每每想起要发文这件事情就头疼。

市面上已经有不少内容管理工具。Notion、飞书多维表格可以整理内容，Buffer、Hootsuite 等工具则提供社交媒体发布管理能力。

但我发现，我自己需要的其实是另一种工具。

它不一定需要替我自动发布，也不需要管理我的社交平台账号（毕竟当前各个内容平台管理还是挺严格的，账号统一管理和自动发布感觉好像已经是上个世纪的命题了）。我只是希望有一个地方，能把文案、图片、排期、待发任务和最终发布链接串联起来。

于是，我做了 PublishKit 发稿匣。

它是一款面向独立创作者与小型内容团队的本地优先桌面工具，支持 Windows 和 macOS。

它最特别的地方，或许是一个看起来不太符合当下自动化趋势的决定：

PublishKit 不替用户发帖。

一、为什么有了 Notion 和 Excel，我还想做一个内容管理工具？

很多人第一次管理多个内容平台时，都会自然地想到用表格。

这是一个合理的选择。

在 Excel 或飞书多维表格中，创建几列字段：

通过调整状态来进行发布管理，看起来已经解决了大部分问题。

但真正开始高频发布后，我发现表格主要解决的是记录问题，并没有完全解决执行问题。

比如，当我准备发布文章 A 的 Pinterest 版本时，需要进行一连串操作：

从表格中找到今天要发布的内容。

打开保存文章的 Markdown 文件。

找到 Pinterest 对应的英文标题和描述。

打开图片文件夹，确认使用哪几张图。

进入 Pinterest 的发布页面。

分别复制标题、描述，上传图片。

发布成功后复制实际链接。

回到表格，把状态改为已发布，并填写链接。

表格能保存这些信息，却不能天然地把操作衔接起来。

Notion 和飞书多维表格当然可以通过数据库、模板、关联字段和自动化能力构建更完整的流程。但这也意味着，需要自己设计数据结构、维护页面和视图，并处理内容与本地素材之间的关系。

对于喜欢搭建个人工作系统的人，这可能本身就是乐趣。

但我更希望打开工具之后，不需要再考虑如何搭建系统，而是直接看到：

今天该发什么？稿件在哪里？配图在哪里？发完之后记录在哪里？

这就是 PublishKit 最初的产品方向：不再做一个可以自行搭建的通用工作空间，而是针对内容发布这件具体的事，提供一套已经组织好的工作流程。

二、内容和发布任务，应该是两件不同的事

这是 PublishKit 中我认为很重要的一个设计决定。

在很多人的日常理解中，一篇文章就是一条发布记录。

但如果同时运营多个内容平台，这个关系并不成立。

比如，我写了一篇关于宠物服装制作的文章。

它可能有几个不同的版本：

小红书需要适合移动端阅读的中文内容。

知乎可能需要更完整的解释和论证。

Pinterest 需要英文标题、描述和配图。

Instagram 则更适合简短文案与图片组合。

即使这些内容源自同一个主题，它们的发布时间、发布状态和实际链接也不相同。

如果简单地给整篇文章设置一个「已发布」状态，信息就会丢失。

因此，在 PublishKit 中，内容是内容，发布任务是发布任务。

一份内容可以关联不同平台的任务，而每项任务都有独立的状态、排期、备注和发布链接。

例如，同一篇文章可以呈现为：

这样，即使 Pinterest 的版本已经发布，也不会错误地影响其他平台的进度。

对于同时经营国内、海外账号，或者需要分别处理中文和英文内容的创作者来说，这种区分尤其重要。

另一个细节是：如果再次记录已经发布过的任务，软件会提示已有发布记录，帮助减少重复操作。

这个功能看似不起眼，却对应了内容管理中一个经常发生的问题：我们进行复杂的发布内容管理时，很多时候不是忘记发布，而是忘记自己是否已经发布，而且难以追溯源头。

三、打开软件时，我希望它告诉我下一步该做什么

很多内容日历会把注意力集中在未来。

一个月的选题、两周后的排期、下季度的营销计划，都能放进日历。

但对日常执行来说，最重要的问题其实很简单：

今天需要完成哪些发布任务？

所以 PublishKit 除了任务列表和周、月日历之外，还设计了「今天」视图。

它将今天到期的任务和逾期未发布的内容集中呈现。

明天、下周的任务仍然保留在日历和任务列表中，但不会全部挤到当前工作区里。

任务本身也可以通过列表或看板等方式查看。草稿、待发、阻塞、已发布等不同阶段能够分别管理。

这里的设计目标不是让用户看到尽可能多的信息，而是让用户知道现在应该处理什么。

如果今天计划发布三篇内容，那么打开软件之后，最好只需要关注这三篇，而不是在几十条甚至上百条记录里寻找它们。

对于逾期任务，还可以重新安排日期、补记实际发布时间，或者归档不再准备发布的内容。

我很喜欢这种思路：

计划应该帮助我们完成事情，而不是成为另一份需要不断维护的工作。

四、浏览器侧栏，可能比自动发布更适合某些创作者

既然已经有了内容管理和排期，为什么不继续做成自动发布工具？

这可能是 PublishKit 最容易引起疑问的地方。

Buffer、Hootsuite 等社交媒体管理工具的优势之一，就是可以通过平台授权，在支持的渠道上安排自动发布，减少人工操作。

这当然有价值，尤其适合需要集中管理大量账号、统一排程的用户。

但自动发布不是所有人的需求。

有些人希望在发布之前，再检查一遍文案和配图；有些平台的内容格式、发布流程和功能选项存在差异；还有些创作者，不希望为了管理内容而将账号授权给额外的第三方服务（毕竟除了平台会考虑风险之外，创作者随便将账号授权出去也同样会带来风险）。

PublishKit 选择了另一种方式：

既然用户仍然要亲手发布，那么就尽可能减少亲手发布之前和之后的琐事。

为此，它提供了 PublishKit Companion 浏览器侧栏。

安装浏览器插件并与桌面端配对后，可以在平台发布页面旁边查看待发任务，使用相应的文案和图片。

例如，在 Pinterest 的发布页面：

左边是 Pinterest 自己的编辑器，右边是 PublishKit 侧栏。

侧栏中可以查看待发内容，复制正文或图片，取用需要的素材。

用户仍然在 Pinterest 网站上进行最终检查、上传和发布。

完成后，可以直接在侧栏里填写发布链接，并将对应任务标记为已发布。

这里并没有试图绕过平台自身的编辑器，也没有替用户点击发布按钮。

它把自动化的重点放在内容准备和记录上，而把最终发布的决定权留给用户。

我认为，这是自动化之外值得考虑的另一条产品路线。

五、为什么要把标题、正文、关键词分开复制？

这一点来自一个非常具体的使用场景。

不同内容平台的输入结构并不统一。

有的平台单独填写标题、描述和关键词；有的平台主要使用一个正文输入框；还有的平台会把话题、标签与正文放在不同位置。

如果每次都从原始文章中选中一部分、复制、删除多余内容、重新调整格式，会产生大量重复操作。

PublishKit 因此提供标题、正文、关键词、全文等不同复制方式，并针对部分平台做适配。

例如：

Pinterest 可以分别准备标题、描述和关键词；小红书、公众号和 YouTube 的文案与话题信息，可以按照相应场景处理；对于部分单输入框平台，也可以将话题合并进复制的正文中。

另外，Markdown 正文支持复制为富文本，从而减少粘贴之后重新整理格式的工作。

这些功能不算复杂，甚至单独拿出来都不太值得专门开发一款软件。

但它们有一个共同特点：

每次只节省一点时间，却会在高频发布中反复发挥作用。

这也是我对生产力工具的一个理解：不一定要有令人惊叹的功能，能持续减少重复劳动，同样有价值。

六、图片可以被管理，但不应该被迫搬家

文案管理之外，另一个让我觉得麻烦的是图片。

尤其是同时处理图文内容时，一篇文章可能对应封面图、正文配图、英文版图片，以及为不同平台单独制作的素材。

我已经习惯使用本地文件夹整理这些资源，并不希望为了使用内容管理工具，再把所有图片上传到一个新的素材库。

PublishKit 因此采用了本地素材索引的方式。

它可以扫描指定图片目录，生成预览，并根据文件名、目录或内容标题等信息推荐素材关联。

需要单张图片时，可以复制到剪贴板，再粘贴到发布页面。

如果需要多张图片，则可以打开包含相应图片的临时文件夹，再根据平台要求上传。

视频也可以指定独立的素材目录。

整个过程中，原始图片仍然保存在自己的文件夹里，软件不会因为建立素材索引就搬走或者改写原文件。

这意味着，我仍然可以使用自己熟悉的文件管理方式。

PublishKit 只是让这些本地资源能够在内容发布时更容易被找到和调用。

对于已经有一套素材目录结构的人而言，这种不改变原有文件习惯的方式，可能比迁移全部素材更加自然。

七、本地优先，实际上是一种产品边界

PublishKit 还有一个比较明确的选择：本地优先。

它把文案、素材记录和发布状态保存在用户自己的电脑里。

浏览器侧栏通过本机地址 127.0.0.1 与桌面程序通信，不需要用户把社交平台密码交给 PublishKit。

这里想解决的，不只是一个抽象的隐私问题。

对于个人创作者来说，文案可能是一段时间积累的选题和研究；素材可能是自己拍摄、制作或者购买的资源；发布记录则是长期经营内容账号的重要历史资料。

我希望这些数据不必全部依赖某个在线服务才能管理。

软件也提供数据库和设置的打包备份、恢复与合并，以及发布记录导出能力。

当然，本地优先并不只有优点。

云端协作工具通常更适合多设备实时同步、多人共同编辑和远程访问。

而本地软件意味着用户需要更加重视自己的文件备份和设备管理。

因此，我并不认为本地优先天然优于云端。

它只是更适合一类希望保留数据控制权、能够接受自行管理本地资料的用户。

对 PublishKit 来说，这是一项明确的产品取舍。

八、它和 Notion、飞书、Buffer，到底有什么不同？

如果把这几类工具放在一起，会发现它们实际上解决的是不同层次的问题。

这张表并不是要证明谁更先进，而是说明工具的设计重心不同。

Notion 和飞书多维表格的优势是灵活。

它们能够承载的工作类型远远超过内容发布，而且具有成熟的协作、视图和自动化生态。

如果你已经在这些工具中搭建了稳定的发布系统，继续使用完全合理。

Buffer、Hootsuite 等社交媒体发布工具的价值，则在于平台集成和自动化能力。

对于管理大量社交账号、希望定时自动发布，或需要社交媒体分析与团队审批的用户，这类产品通常更匹配。

PublishKit 的重点则是另一个方向：

不搭建复杂数据库，不托管账号，不要求改变本地文件管理习惯，让准备发布、亲手发布、回填记录这套流程尽量连贯。

它不是这些产品的全功能替代品，而是针对特定工作方式做出的选择。

这也是我认为它最值得被讨论的差异性。

九、从现有文档开始，而不是要求用户重新录入

对于一款内容管理工具来说，还有一个容易被忽视的门槛：

用户不是从零开始使用的。

他们可能已经写了几十篇文章，保存在 Markdown、Word 或其他文档中。

如果一款新工具要求把旧内容逐篇复制进去，再手动添加日期和发布平台，那么迁移成本本身就可能让人放弃。

因此，PublishKit 支持导入 Markdown、Word、PDF、网页、Excel、CSV 等不同来源。

用户可以设置起始日期、发布间隔和目标平台，批量创建发布任务。

对于原文件中已经存在的日期和平台字段，也可以依据对应字段安排任务。

如果同时管理多个项目，还可以为不同项目设置独立的文案和图片目录。

例如，一个项目专门管理中文自媒体文章，另一个项目管理英文 Pinterest 内容。

两边使用不同的素材文件夹和排期，但可以通过同一套任务管理方式查看发布进度。

从已有文件开始使用，而不强迫用户重新组织全部工作资料，是我希望降低的一项使用成本。

十、一次买断，而不是每个月增加一项订阅

价格也是这个产品定位的一部分。

目前产品介绍中的方案是：

• Free： 免费管理 50 条内容，可以体验完整核心工作流，支持多个项目与浏览器侧栏。
• Pro： 国内首发价 ¥139、海外 $38，一次买断，解除内容数量限制，无需按月订阅。实际售价以购买页面为准。

这里需要特别解释：50 条限制针对的是内容数量，而不是发布任务数量。

例如，一篇文章分别安排到 Pinterest 和 Instagram，会形成两项发布任务，但仍然只计算一条内容。

我不希望把基础的内容准备、素材关联、浏览器侧栏等功能拆成多个付费档位。

免费版应该足以让用户完整体验一遍工作流程，再决定是否值得购买。

当然，一次买断不意味着产品可以不考虑长期维护成本。桌面应用和浏览器插件都需要持续适配操作系统、浏览器与平台变化。

但至少对于当前以本地存储、手动发布为核心的产品形态来说，买断制是一种相对直接的收费方式。

如果软件确实能够长期使用，用户也不必为了继续管理已有的内容，每个月支付一笔订阅费用。

十一、哪些人可能适合 PublishKit？哪些人不适合？

介绍到这里，我觉得也有必要把边界说清楚。

如果你是独立创作者，同时经营多个内容平台；如果你经常批量准备 Markdown 文章和配图；如果你希望中文、英文内容分别安排发布时间；如果你习惯在平台官网手动发布，不想授权第三方接管账号，那么 PublishKit 所解决的问题与你的工作方式比较接近。

尤其是对已经有大量本地文档和图片素材的人，它可以减少从整理稿件到最终发布之间的重复操作。

但如果你主要需要以下能力，PublishKit 可能不是优先选择：

• 希望提前设置时间，由工具自动完成平台发布。
• 需要多人同时在线编辑、审批和实时协作。
• 主要关注账号增长数据、互动分析或社交媒体监听。
• 希望在手机和多台电脑之间随时同步完整工作区。

这些场景有其他更成熟或者更适合的解决方案。

一款工具不需要覆盖所有人的需求。

对我而言，更重要的是把某一类用户每天都会遇到的问题解决好。

十二、写在最后：不是所有值得自动化的工作，都需要自动完成

这些年，生产力软件不断强调自动化。

自动生成内容、自动分发、自动管理账号、自动分析数据。

这些技术确实在改变创作方式。

但在实际使用过程中，我越来越觉得，有些步骤不一定需要被自动完成。

例如最终发布一篇文章。

我可能希望在点击发布之前，再看一遍标题、检查图片顺序、确认格式是否适合当前平台。

这些动作并不是毫无价值的重复劳动。

真正需要减少的，是寻找文件、反复复制、核对状态、查找链接，以及维护分散记录的时间。

这也是 PublishKit 想做的事。

它并不试图让人彻底退出发布流程，而是希望让创作者把更多精力留给值得亲自完成的部分。

打开软件，知道今天该发什么。

进入平台，拿得到对应的文字和图片。

发布完成，留得下准确的记录。

下一次打开电脑，不用再问自己：

「我记得这篇发过，到底发在哪儿了？」

如果一个工具能够让这些琐事变得简单、确定，而且长期可靠，我认为它就已经具有价值。

PublishKit 的目标不是替你创作，也不是替你发布，而是让每一篇认真准备的内容，都拥有一个更清楚、更从容的发布过程。

产品信息

产品名称： PublishKit 发稿匣

产品类型： 本地优先的跨平台内容管理与手动发布助手

支持系统： Windows / macOS

浏览器插件： PublishKit Companion，支持 Chrome、Edge、Brave

收费方式： 免费 50 条内容；Pro 一次买断

适合人群： 独立创作者、多平台内容运营者、跨语言内容创作者、小型内容团队

• 中文官网：https://get.pongrabbit.cn/zh/
• 英文官网：https://get.pongrabbit.com/en/
• GitHub Releases：https://github.com/aiyahetun/pongrabbit-PublishKit/releases/latest
• 浏览器插件：https://chromewebstore.google.com/detail/publishkit-companion/dijkbipanbpkgndbhonecpfnladaiipj

注：本文主要介绍产品设计思路与功能定位。具体功能及价格请以发布时的正式版本和官网说明为准。