失败复盘：直接发布、登录状态和浏览器自动化踩坑

第二篇已经跑通了第一条链路：检查、生成、导出、预检，再把文章稳定放进知乎草稿箱。

这篇开始回头看失败路线。那条路线最开始的目标更激进，想直接走到发布按钮。真正做下去之后，问题很快从“怎么让脚本点按钮”变成“哪些动作适合交给脚本，哪些动作需要人来做最后判断”。

这篇文章想记录的，就是这个判断怎么变清楚的。

我一开始想把直接发布也做掉

最初的想法很自然：既然草稿生成和预检都已经有了，那浏览器这一步再往前推一点，直接点发布就好。

看起来这条链路可以写成：

检查通过
-> 生成材料
-> 预检通过
-> 打开知乎编辑器
-> 填内容
-> 点发布

问题出在最后一步。

“点发布”在界面上很简单，在流程里却是最重的一步。草稿保存还能回头看，发布之后就进入公开状态，脚本面对的范围会扩大到账号状态、平台风控、二次确认和结果判断。

这一层的风险，让我很快意识到：直接发布必须有更清楚的边界。

第一类问题：最终发布按钮很重

最先露出来的问题，是最终发布按钮本身。

草稿阶段的目标很简单，脚本把内容稳定放进去就行。到了最终发布阶段，脚本需要同时处理这些事情：

• 当前内容是否真的准备好。
• 页面里是否出现二次确认。
• 平台是否出现临时弹窗。
• 发布动作是否已经进入不可逆阶段。
• 发布后能否确认结果。

这类动作一旦和普通填表混在一起，脚本就容易显得太冒进。

所以我后面把发布类 Skill 的目标拆得更细：

阶段	目标	处理方式
检查	发现内容问题	脚本处理
生成	形成发布材料	脚本处理
预检	判断是否适合进入浏览器	脚本处理
草稿保存	把内容放入平台编辑器	脚本处理
最终发布	进入公开状态	人工确认

这张表背后的结论很直接：最重的动作留给人，最稳定的动作交给脚本。

第二类问题：登录状态需要更稳的处理

直接发布想走下去，第二个卡点就是登录状态。

一开始我尝试过几种方式：想沿用现成的浏览器状态，想给脚本一个固定的发布环境，想让它在已有会话里继续往下走。实际跑下来，路线越分叉，维护成本越高。

后来认证边界一次次收口，最后变成更清楚的一条：脚本只接管已经登录的真实浏览器会话，账号、安全验证和扫码由人处理。

这个变化背后的原因很朴素：

• 账号登录保留在真实浏览器里处理。
• 验证码、扫码、安全验证保留人工处理。
• 浏览器会话越多，状态越难解释。
• 认证模式越多，后面调试和写作都越容易混乱。

最后留下来的那条边界更简单，也更稳：

处理项	归属
账号登录	用户在真实浏览器里完成
验证码 / 扫码 / 安全验证	用户在真实浏览器里完成
浏览器会话接管	脚本通过 CDP 连接已登录浏览器
敏感会话信息	留在浏览器环境里
登录失败	停在登录阶段

这一步把很多“看起来可以自动”的东西收回来了，也让 Skill 的边界更清楚。

第三类问题：浏览器页面会变

第三个问题更现实，来自浏览器页面本身。

知乎编辑器的结构会变化。今天看起来能点的按钮，后面可能换了位置；今天能识别的输入框，后面可能变成另一个面板；今天可用的标签入口，后面可能变成话题区域。

这也是为什么我后面把自动化路线收口到更稳定的动作：先保存草稿，再让页面结构变化尽量少影响核心流程。

页面变化带来的教训有三个：

1. 选择器越多，失败点越多。
2. 入口越花哨，维护成本越高。
3. 和用户真实操作越接近的动作，往往越稳定。

最后我把路线往“可解释”方向收了一步：

• 浏览器动作只接管已登录会话。
• 先进入写作页面，再做可预测的填充。
• 遇到页面结构不清楚的阶段，停下来记录现场。
• 截图和阶段名一起保留下来，方便后面定位。

这比硬猜按钮要稳得多。

收口：先保存草稿，让人来做最后确认

这三类问题叠在一起后，答案其实越来越清楚。

第一版更适合先做稳草稿保存、检查和预检。这条路线能解决更多问题，也更接近真实的工作流。

所以后面的路线慢慢固定成这样：

Markdown 检查
-> 草稿生成
-> 正文导出
-> 发布预检
-> 知乎草稿保存
-> 人工检查
-> 最终发布留给人

这个收口带来的好处很明显：

• 脚本范围变清楚。
• 失败阶段更容易定位。
• 登录和安全验证的压力被压低。
• 页面变化主要影响草稿流程，公开发布继续由人确认。

我后来对发布类 Skill 的理解，也基本定在这里：它先把内容稳定送到草稿态，再把人带到最终发布之前。

这次失败留下的边界清单

这条失败路线最后留下了一组更清楚的边界：

• 内容检查先做。
• 草稿生成先做。
• 浏览器动作放后面。
• 登录和安全验证交给用户。
• 页面结构不清楚时停下来。
• 最终发布保留人工确认。

这些边界看起来保守，但它们让整个 Skill 更容易维护，也更容易写成后续的文章和测试。

本篇小结

这次失败的价值，是把“能自动”改成了“该自动到哪里”：

• 直接发布、登录处理和页面变化会把风险一起推高。
• 草稿保存比最终发布更适合作为自动化边界。
• 失败阶段要能停下来，并留下足够定位问题的现场。

下一篇会开始讲扩展规划：当知乎单篇草稿跑通之后，批量上传、CSDN、博客园和统一 blog-publisher 该怎么接上去。