法国开发者花3天写脚本，把发文效率从2月1篇提到4天1篇

一个技术博主平均花4小时写稿，却花2小时在复制粘贴、调格式、改链接上。结果？更新频率从每周一篇掉到两月一篇。法国开发者Benjamin Caure算过这笔账后，用3个Node.js脚本把全流程压缩成一行命令：node scripts/publish-article.js my-slug，然后就可以去喝咖啡了。

这不是什么大厂中台，是个人博客的自动化流水线。核心思路很产品经理：把重复劳动拆成可版本控制的JSON配置+可复用的API调用。每个平台一条管道，每个管道一个schedule文件，状态机管理（draft/published），Git全程可追溯。

Dev.to：REST API + HTML转Markdown的脏活

Dev.to（开发者内容社区）的接口足够干净：Header里塞API Key，POST到/api/articles，返回文章ID。但Benjamin的原文存在.en.php文件里，是HTML格式。这里用了Turndown库做转换，却踩了两个经典坑。

第一个坑是代码块。他的博客用Prism高亮，class="language-go"这种写法，Turndown默认不认。必须加自定义规则，把

标签翻译成Markdown的三反引号+语言标识。第二个坑更隐蔽：相对链接。/blog/goroutine-leaks-golang这种内部链接，原封不动发到Dev.to会变成404——因为域名变了。规则里硬编码了主站URL前缀，强制转绝对路径。



「Canonical URL（规范链接）必须指向原博客，」Benjamin在代码注释里强调。这是SEO的保命设置，告诉Google「Dev.to这篇是转载，原站才是源头」。没有这个，搜索引擎会把流量分给平台而非个人域名。

发布拆成两步：先POST创建draft（草稿），再PUT /api/articles/:id把published设为true。中间隔4天，由devto-publish-next.js脚本控制——检查最后一篇的发布日期，不到4天就休眠。防骚扰机制，手动操作很难坚持这种纪律。


LinkedIn：没有官方API，只能走"非官方"渠道


LinkedIn（职业社交平台）的官方API对普通开发者近乎封闭。Benjamin的解法是用linkedin-api-client这个社区库，走内部未文档化的端点。风险是接口随时可能变，但"至少比手动复制粘贴稳定"。

LinkedIn的帖子需要图片+钩子文案。他的脚本自动提取文章首图，生成带缩略卡的分享格式。文案不是全文，是excerpt（摘要）+ 链接，引导回流到主站。这和Dev.to的策略形成分工：前者做内容托管，后者做流量入口。



两个平台的schedule文件结构完全一致：slug、scheduledDate、status。JSON格式，Git管理，随时能回滚或批量调整。这种设计让"内容日历"从Notion表格变成了可执行的代码。


为什么不用现成的CMS或自动化工具？


Zapier、Make这些无代码平台能连Dev.to和LinkedIn，但Benjamin没选。原因写在代码注释里：「我的HTML源文件有特殊结构，通用工具处理不了转换规则。」Prism的代码高亮、自定义的内部链接格式、多语言文件的组织方式——这些业务细节只有自建脚本能精准覆盖。

另一个隐性收益是成本控制。无代码平台按任务量收费，高频发布会触达阶梯价。Node.js脚本跑在本地或CI/CD里，边际成本为零。对月更8-10篇的技术博主，这笔账不难算。

但代价也明显：LinkedIn的私有API可能明天就失效，Turndown的规则遇到新HTML结构要手动补丁，整个系统只有Benjamin自己能维护。这是典型的"个人自动化陷阱"——跑得通的时候效率惊人，跑不通的时候调试成本翻倍。

这套系统跑通后，Benjamin的发布频率从"想起来才更"变成了固定4天一篇。不是因为他写得更快了，是心理摩擦降到了接近零：写完文章，运行脚本，看到两个平台的草稿已就绪，点确认即可。剩下的4天间隔，机器会自动遵守。