小红书 / 抖音发布工作流：差一步，卡在登录态

背景

发一张图文笔记，平台要求：多张图、标题、正文、封面、话题。 真的要发的内容（照片和描述）我早就有了，剩下全是重复劳动。

想做的界面很朴素：选图 → 填标题 → 填描述 → 点发布，剩下的交给程序。

方案

三块拼起来：

1. 本地 HTTP 服务（Node，.mjs 直接跑，不用装环境）
2. 一个工作台窗口（打包成 exe，双击就能用）
3. 浏览器注入：在已登录的浏览器里完成上传和填表

关键判断：不去模拟登录，复用真实浏览器的已登录状态。 理由是账号风控对”新设备登录”很敏感，模拟登录基本必挂。

过程

上传和填表这两步意外地顺：

// 图集：把本地文件塞进页面里的 <input type=file>，再触发 change
await page.setInputFiles('input[type=file]', paths);

标题、正文用输入事件写进去，平台侧看起来跟手动敲的一样。 到”点发布”这一步，问题来了。

踩坑

现象	原因	解法
每次启动都要重新登录	浏览器登录态（Cookie/本地存储）绑在特定用户目录，换进程就丢	应该固定一个专用用户目录，绝不能和”工作身份”混用
清理测试残留时把工作身份也清了	为了干净，清了整个浏览器配置	分离：测试用临时目录，正式用固定目录
自动化误触发了平台的登录保护	动作节奏太快、指纹异常	放慢操作、减少并发、别在敏感接口上刷
于是没能完成一次完整的发布验证	登录态被自己清了	—— 这条就是结局

最该反省的是第三条：为了”清理测试环境”图省事，把唯一能用的登录态一起清掉了。 之后一直没能重新验证通过，工作流停在这里。

结果

没跑完，暂停。

• 工作台能用，上传、填表、封面都通了
• 小红书那条线砍掉（规则变动快、风控严）
• 抖音这条没复验，不敢说”能用”

复盘

• 登录态是这个项目最脆弱的东西，应该在第一天就做好隔离（测试/正式两套用户目录），而不是事后清理
• 自动化发帖的边界是平台规则，不是技术。技术能做到，不代表性价比正
• 真正省时间的还是”内容生产”那一半（写、配图、排版），发布这一步的收益最小、风险最大

以后如果重做，我会把它降级成**“生成草稿 + 一键复制”**：程序准备好所有字段，人点两下粘贴。 不碰登录、不碰发布接口，反而最稳。