一、最后一公里才是自动化真正的瓶颈
大部分人的内容流水线止步于草稿箱：文章写好了、封面做好了，但要手动登录后台、复制粘贴、选栏目、填摘要、点发布。一天两篇还能忍，批量十篇就必然出错，而错的地方永远是重复劳动那一步。
解决办法很朴素：给站点留一个只做一件事的 HTTP 接口——收下标题、正文、栏目和摘要，返回文章地址。其余环节照旧，不推倒重来。
二、接口该怎么设计才不会埋坑
第一，鉴权只用一个请求头，例如 X-API-Key，密钥放服务端环境变量或后台配置，绝不写进前端页面。第二，正文同时接受 HTML 与纯文本，纯文本进站时自动分段，避免不同编辑器产出格式漂移。第三，栏目用稳定的 slug 而不是中文名，中文名改一次，历史脚本全废。第四，接口必须返回新建文章的 slug，方便流水线回写日志。
另外记得把字数统计放在服务端统一算。前台展示、后台筛选、采集门槛如果各算各的，很快就会出现同一篇文章三处字数不一致。
三、把它接进现有流程
写稿脚本产出 JSON，最后加一次 POST；失败时把响应体写进日志，重试只针对 5xx 与网络超时，4xx 一律人工看。这样即使某篇文章格式有问题，也不会把整个批次堵死。
本站的发文接口、后台管理和采集器就是按这套思路搭的：前台只读，后台管内容，API 负责写入，定时任务负责喂料。四者共用一份数据文件，任何一方更新，其它方立刻可见。