我用 OpenClaw 自动发布掘金文章，并把流程封装成 Skill（完整复盘）
这篇文章的重点不是“我发了一篇文章”，而是：
我把“发布文章”这件事做成了可复用、可观测、可重试的流程。
1. 为什么要做这件事
经常写技术文的人都知道，真正消耗精力的往往不是写作本身，而是重复发布动作：
- 打开平台编辑器
- 粘贴标题、正文、摘要
- 提交发布
- 审核失败后反复修改重提
- 到处找最终可分享链接
所以我给自己定了一个更工程化的目标：
用 OpenClaw 自动完成掘金发布，并把过程沉淀成一个 Skill。
2. 这次实战的验收标准
为了避免“看起来成功，实际没提交”，我定义了四个验收条件：
- 能自动写入标题、正文、摘要
- 能走完掘金提交流程（发布/更新 + 二次确认）
- 能识别审核状态（审核中 / 审核未通过 / 通过）
- 能输出最终链接，并区分
spost与post
3. 环境与前置检查
环境：
- Windows + Chrome
- WSL2（Ubuntu）
- OpenClaw CLI
- OpenClaw Gateway
- Chrome Relay 扩展（已连接）
先做两步健康检查：
openclaw gateway status
openclaw browser tabs --browser-profile chrome-relay --json
只要 tabs 能正常返回，说明 relay 链路可用。
4. 关键流程（可复现）
步骤 A：先收敛到单标签页
这是稳定性的第一要点。
多标签并发时，容易出现页面焦点漂移和目标页切换，导致后续点击失效。
步骤 B：写入三项核心内容
- 标题：
input.title-input - 正文：
CodeMirror.setValue(...) - 摘要：摘要 textarea（一定要满足平台最小字数要求）
步骤 C：处理掘金的二段式提交
这是最容易漏掉的部分：
- 新稿：
发布 -> 确定并发布 - 驳回后重提：
更新 -> 确定并更新
如果只执行第一步，通常不会真正提交成功。
步骤 D：提交后做状态校验
提交后不是“点完就结束”，还要确认：
- 页面是否出现发布成功/审核状态
- 是否生成可访问文章链接
- 当前拿到的是
spost还是post
5. 我实际踩到的坑
坑 1：tab not found
现象：看起来在跑，关键一步经常失败。
原因：页面重渲染后 target 变化，旧引用失效。
处理：
- 每个关键动作前重新读取 tabs
- 每次点击前重新查按钮
- 失败后短退避重试（1~2 秒）
坑 2：明明点了“发布”，却没发出去
原因：掘金提交流程有确认层。
处理：必须继续执行“确定并发布/确定并更新”。
坑 3：审核未通过（摘要不满足 50 字）
这是我这次真实遇到的问题。
修复后重新提交即可：
- 补齐摘要到 50 字以上
- 优化表述为自然实战叙述
- 执行“更新 -> 确定并更新”
6. spost 和 post 的区别（很重要）
spost：后台态/审核态链接（常见仅登录态可见）post：公网文章链接（可对外分享）
如果你拿到的是 spost，在另一个未登录浏览器里看不了是正常现象。
发布链路的最终目标应是拿到 post。
7. 把成功经验固化成 Skill
我最后把整套流程封装成了一个 skill：juejin-publish。
它做了这些事：
- 网关与 relay 预检查
- 单 tab 稳定策略
- 标题/正文/摘要自动填充
- 发布与更新双流程识别
- 审核状态抓取
spost/post链接提取- 长任务分阶段进度播报
这样以后发文不再靠“手工记步骤”，而是执行统一流程。
8. 推荐直接复用的 SOP（精简版）
每次发掘金，按这个顺序走：
- 检查 gateway/tabs
- 清理多余标签页，只留目标编辑页
- 写标题/正文/摘要（摘要 >= 50 字）
- 设置分类与标签
- 执行二段式提交（发布/更新 + 确认）
- 抓取审核状态
- 返回最终链接（优先
post）
9. 结语
这次最有价值的，不是“自动点按钮”，而是把发布动作变成了一个工程流程：
- 可重试
- 可观察
- 可维护
- 可复制
如果你也在做内容自动化，我建议先跑通一个最小闭环：
写入内容 → 成功提交 → 拿到公网链接，再把经验 skill 化。
一旦形成这套能力，后续跨平台迁移会非常快。
