文渡 ContentFerry 开源了：一个"自用"写作工具背后的选择

文渡 ContentFerry 在 GitHub 开源了，一个本地优先的桌面写作工具。

图注：文渡工作台界面，展示文章列表管理与批量操作（来源：项目 README 截图）

写这个工具的原因，得从自己身上说起。

1. 写公众号的痛点

写公众号的流程：选题、找资料、写初稿、改稿、排版、找封面、发布，再分发到几个平台。前面几件事既要靠脑子也要靠工具，后面几件事基本靠工具。

我用过不少 AI 写作工具，最后都没留下。原因集中在几个：

一是AI与工具不贴合。需要在不同的工具中跳转、拷贝、粘贴。

二是一稿多发操作麻烦。同一篇文章，每多一个平台就多一份体力活。

2. 解法：把写文章拆成一条 AI 能插手的流程

文渡的核心想法不复杂：把一篇文章从想法到发布的全过程拆成清晰的步骤，每个步骤尽量让 AI 帮上忙，但决定权始终在人手里。

工具以本地 VitePress 文章库为正式内容源，所有文章都是 Markdown 文件，存在自己机器上。这个设计解决的是资产问题：文章库就是唯一的事实来源，版本、历史、复用都围绕它展开。

为什么用本地 Markdown。 文渡把电脑上的 VitePress Markdown 文章库作为正式内容源，而不是把内容锁在应用私有的数据库里。这样设计的好处是：

• 工具自由：文章就是普通的 .md 文件，可以用 Obsidian、VS Code、Typora 等任意编辑器打开，也可以让其它 AI 智能体、脚本直接在文章库里写稿、改稿——文渡不独占你的内容。

• 多工具协同：资料整理、写作、AI 辅助还可以由外部工具分工完成，文渡负责把终稿统一转换成各平台可发布的形态。

• 可迁移、可备份：内容以纯文本落在自己的硬盘上，不受单一应用约束，随时可用 Git 或网盘备份，也可以用其它工具打开。

• 创作与发布解耦：无论文章在哪写成，最后都由文渡处理微信公众号、CSDN、博客园等渠道的改写、封面、AIGC 检测与发布。

简言之：文章可以在你自己的文件里写，文渡可以只做"最后一公里"的发布，不绑死。

重点说说 AI 在各个环节的实际用法。

素材搜索。 写一篇有判断的文章，光靠记忆不够。文渡内置联网补研能力：给定主题后，它会去检索官方来源和可信的公开资料，把每条能核实的事实整理成独立的资料卡，附上来源 URL。检索不到，或者遇到需要登录的页面，它会明确告诉你，而不是编一个结果出来。这一步把"找资料"从凭感觉变成了可追溯。

文章顾问"阿文"。 写作过程中有一个内置顾问角色，围绕当前这篇文章给具体建议：选题角度、结构安排、论证缺口、标题和摘要。哪一段空泛、哪一段说教，它会直接指出来。它记得当前这篇文章的上下文，能连续协作，而不是每次从零开始。

改写与去 AI 味。 初稿写出来总带着机器味，这是生成式模型的通病。文渡用两个环节处理：平台改写针对目标平台的用户和分发特点调整表达；去 AI 味针对选中的文字片段，只改"怎么说"不改"说什么"，保留事实、Markdown 和你的立场。它不是换个同义词，而是把模板感、表演感和机械结构压下去。

图注：文渡文章编辑界面，右侧为 AI 去味处理功能面板（来源：项目 README 截图）

封面。 封面拆成两步：先生成封面提示词，再按提示词生成 16:9 的封面图。提示词提炼文章真正的主题，而不是机械复述标题，也不会给画面加原文里没有的人物或产品。生成结果先给你确认，不会自动发布。

图注：文章设置面板中的 AI 自动封面生成功能（来源：项目 README 截图）

摘要与 AIGC 检测。 摘要根据完整原文生成，按平台调整口味：公众号摘要自然、有吸引力但不夸张，技术平台摘要突出方法和适用对象。发布前还能调用第三方检测服务，看看文字里有没有明显的 AIGC 特征。

图注：朱雀 AI 检测助手，展示对输入文本的 AI 生成特征分析结果与检测报告（来源：项目 README 截图）

模型连接这块，文渡做了简化：支持模型统一走 OpenAI 兼容 API，配置化处理。OpenRouter、NVIDIA Build、火山引擎等这些不同来源，在文渡里都是同一个可配置的端点，换模型只改配置，不涉及代码。联网检索则用 Tavily 作为独立服务配置。

图注：技能与模型管理界面，展示可供勾选配置的各类文本类 AI 技能卡片（来源：项目 README 截图）

3. 顺便说说：这工具是 vibe coding 写出来的

写完这个工具，最想聊的反而不是功能，而是它怎么来的。文渡是纯 vibe coding 写出来的——不是一句句代码按传统节奏敲出来的，更多的时候，是我描述想要的界面和交互，AI 给出实现，我再改再调，像是和它一起把东西"聊"出来。

对我个人来说，最明显的变化是：一个后端开发，靠AI就变成了全栈。以前写东西，数据库、接口、前端页面是三个世界，每跨一个边界都要重新熟悉一套工具。这次不一样，从桌面端的界面和状态管理，到调用模型、读写本地文件，整条链路都在同一个会话里被反复讨论、反复迭代。能力边界被 AI 撑开了，以前够不着的东西，现在能伸手够到了。

当然，vibe coding 不是没有代价。它更像是"把想法翻译成代码"，所以对想法的清晰度要求更高——你自己都不知道要什么，AI 再强也帮不上忙。另一层感受是，它放大了"判断"的价值：代码可以交给 AI 写，但哪些功能值得做、做到什么程度、哪里该收手，这些还是得自己拿主意。

一句话总结的话：vibe coding 没有取代写代码的人，它把写代码的人往前推了一步，推到更靠近"想清楚再动手"的位置。

4. 为什么开源

说到底这是个自用工具，做的时候没想太多商业的事。开源是顺手的选择：代码放在 GitHub 上，MIT 协议，谁想拿去用、拿去改都行。如果你也有类似的写作流程困扰，可以看看代码，或者直接拿来用。

5. 现在和下一步

现在文渡已经能跑通一条完整链路：从选题、补研、写稿，到改写、检测、封面、发布。工具在这条链路里更像一个"帮着把事情做得更像人"的角色：AI 负责补资料、改措辞、生成配图，人负责判断和决定。

下一步的方向也顺着这个思路走。让素材搜索更聪明，让改写更懂平台，不同平台的读者画像和表达习惯差异，靠配置就能体现出来；让封面生成更贴合文章气质，在提示词层面多下功夫，而不是靠撞运气。

一句话：文渡想让 AI 干的是"打下手"的活，不是"替你写"。这也决定了它今后的演进重点，始终落在素材、改写、封面这些智能环节上。

项目地址：https://github.com/weiluliaokeji/content-ferry（MIT 协议，欢迎 Star、Fork、提 Issue）