把 blog-publisher 跑稳：多平台上传、测试和触发优化

上一篇写的是扩展规划：单篇知乎草稿跑通之后，下一步要接上批量上传、CSDN、博客园，以及统一的 blog-publisher。

真正开始跑的时候，问题很快变得具体。知乎批量草稿整体比较顺，CSDN 暴露的问题更多：正文换行、编辑器状态、保存确认、限流、父子进程收尾，每一项都在提醒我，发布类 Skill 的稳定性要靠证据支撑。

这一篇就写“跑稳”这件事。

这次实测里，三个平台处在不同阶段：知乎批量草稿相对顺利，CSDN 是主要问题样本，博客园仍然适合先放在单篇验证和权限确认阶段。也正因为状态不同，后面的判断不能只写“多平台已支持”，而要分清楚哪些能力已经稳定，哪些还只是下一步要补齐的边界。

跑通只是第一步

单篇跑通时，最容易兴奋的点是：文章终于进草稿箱了。

但扩展到批量和多平台之后，判断标准要细很多。一次成功只能说明某个时间点、某个账号状态、某篇文章、某个平台页面组合下，脚本完成了一次动作。

跑稳要回答的问题更多：

• 这篇文章真的生成了独立草稿吗。
• 标题、正文、换行和代码块是否保持正常。
• 页面提示能否作为保存证据。
• 批量中的下一篇是否覆盖了上一篇。
• 平台限流时脚本是否能识别并停在可解释状态。
• 父进程汇总的结果是否和单篇执行结果一致。

这些问题都指向同一个结论：发布类 Skill 需要把“动作完成”和“结果确认”分开看。

先定义哪些情况算成功

我后面把成功拆成三层。

层级	成功含义	需要看到的证据
页面写入	标题和正文已经进入编辑器	编辑器内容可见，正文结构正常
草稿保存	平台接受了保存动作	页面出现明确保存状态
草稿确认	平台生成了可追踪草稿	有草稿入口、草稿 ID 或稳定状态记录

这三层看起来很像，但实际差别很大。

页面写入成功，只能说明脚本把内容放进去了。草稿保存成功，说明平台有保存反馈。草稿确认更进一步，它说明这篇文章已经进入平台的草稿系统，后续可以被找回、复核和手动发布。

知乎批量草稿里，这条链路相对顺。CSDN 的问题就集中在第二层和第三层：页面上看到保存文案，草稿箱里未必能找到对应文章；有些成功记录看起来正常，回头看报告才发现缺少文章 ID。

所以后面的报告里，单纯写“已保存”已经不够。它要尽量记录更硬的证据，比如草稿 ID、保存时间、页面状态、重试次数和失败原因。

再定义哪些情况必须停下来

发布类 Skill 更需要警惕带着错误继续跑。停下来反而是清楚的状态。

多平台上传时，我把这些情况归到“停下来并报告”：

1. 登录状态失效：浏览器打开后进入登录页，交给用户完成登录。
2. 编辑器入口异常：页面进入了预期之外的编辑器，保留现场。
3. 草稿按钮不清楚：只保留浏览器，让用户确认。
4. 保存证据不足：报告写成状态未确认。
5. 平台限流：识别提示，等待后重试，超过次数就停。
6. 批量结果不一致：父报告读取子报告，再做汇总。

这里最重要的是“状态未确认”这个词。

它比“失败”更准确。比如页面写入完成了，但平台未返回草稿 ID，这时文章内容可能还在编辑器里，用户也许能手动保存。脚本把它写成状态未确认，比直接写成功或失败都更诚实。

批量上传的测试重点

批量上传的风险，核心在“连续处理”。

单篇上传时，浏览器里只有一篇文章。批量上传时，上一篇的页面状态、保存弹窗、编辑器缓存、平台限流，都可能影响下一篇。

所以测试矩阵要覆盖这些情况：

测试项	观察重点
正常单篇	标题、正文、换行、代码块是否正常进入草稿
正常批量	每篇文章是否生成独立草稿
缺标题文章	是否在进入浏览器前报告问题
正文为空	是否停在检查阶段
保存证据缺失	报告是否写状态未确认
平台限流	是否进入等待、重试和停止流程
子进程收尾	单篇结束后是否能回到父流程
父子报告一致	汇总报告是否读取真实状态

这张表的价值在于，它把测试从“跑一遍命令”变成了“每一步拦一个风险”。

比如缺标题和正文为空，应该在内容层被拦住。保存证据缺失，应该在平台层记录。父子报告一致，属于批量调度层的问题。每个测试都对应一个边界，后面定位时就更快。

多平台上传里真正不稳定的地方

多平台扩展之后，我对“不稳定”的理解变了。

一开始以为不稳定主要来自选择器失效。后来发现，选择器只是其中一部分。真正影响稳定性的，还有平台编辑器的内部模型、页面状态复用、保存反馈和限流策略。

不稳定来源	具体表现	调整方向
编辑器模型	内容看似写入，结构被编辑器改掉	使用平台推荐的写入方式
页面状态复用	下一篇受上一篇编辑器状态影响	逐篇重新进入写作页
保存反馈	页面文案和真实草稿状态不一致	记录更强证据
平台限流	连续保存后提示稍后再试	等待、重试、写入报告
进程收尾	子进程完成后仍挂起	子进程模式明确结束条件

知乎适合走富文本粘贴，因为它接收 HTML 后排版更稳定。CSDN 更适合走 Markdown 编辑器，并且要尽量靠近真实用户粘贴或编辑器源码写入。博客园先保持单篇草稿路线，等保存反馈和权限状态更稳定后再扩展批量。

这一轮测试后的平台状态可以先这样收住：

平台	当前状态	最大问题	后续规则
知乎	批量草稿整体较顺	富文本粘贴后的排版稳定性	继续走 HTML 富文本粘贴，并保留人工复核
CSDN	暴露问题最多	Markdown 写入、草稿证据、限流和进程收尾	逐篇隔离，记录强证据，状态不足时写未确认
博客园	先保持单篇验证	写作权限和保存反馈还要确认	不急着批量，先稳定单篇草稿

CSDN 这次暴露出来的几个坑

CSDN 是这次跑稳过程中最有价值的样本。

第一个坑是正文换行。脚本一开始看起来把 Markdown 放进了编辑器，但草稿里的正文变成一整段大标题。后来回头看，问题出在写入层：内容被写进了错误的可编辑层，编辑器内部模型未按 Markdown 源码理解换行。

这个问题带来的规则很直接：CSDN 正文要走真正的 Markdown 编辑路径，或者使用更接近真实操作的粘贴方式。只改页面 DOM，看起来快，后面验证成本很高。

第二个坑是批量中的单实例状态。单篇能保存，多篇连续跑时却出现覆盖、漏保存或状态混乱。CSDN 写作页更像一个单实例编辑器，批量时需要把每篇都当成独立单篇流程处理：重新进入写作页，确认新草稿状态，再进入下一篇。

第三个坑是保存证据。页面出现“草稿”或“保存”字样时，脚本容易判断成功。但真正可靠的证据应该更具体，比如新草稿 ID 或稳定的草稿状态。只有通用文案时，报告应该写状态未确认。

第四个坑是限流。批量上传到后面，平台可能提示操作频繁。这个阶段脚本应该识别提示，等待后重试，并把重试次数写进报告。重试后仍然受限，就停在可解释状态。

第五个坑是父子进程汇总。单篇子进程可能返回正常退出码，但子报告里的状态是未确认。父进程如果只看退出码，就会误报成功。后面汇总报告要读取子报告的真实状态，再决定最终结果。

Skill 触发描述怎么调

跑稳之后，description 也要跟着调整。

Skill 的触发描述要让 Codex 明白几件事：

• 用户要求上传、粘贴、导入、批量保存 Markdown 博客草稿时触发。
• 目标平台是知乎、CSDN 或博客园时触发。
• 任务重点是保存草稿和保留浏览器复核。
• 最终发布交给用户完成。
• 登录、安全验证、账号信息由用户在浏览器里处理。

这段描述的作用很大。它决定 Skill 会在什么请求里被叫醒，也决定它醒来之后的第一反应。

比如用户说“把这几篇 Markdown 保存到知乎草稿”，这应该触发。用户说“帮我检查文章标题是否缺失”，更适合先走内容检查。用户说“直接发布到平台”，Skill 也应该把流程收回到草稿保存和人工发布确认。

触发边界写清楚后，自动化就更像一个可靠助手，动作范围也会更克制。

优化后留下的执行规则

跑到这一阶段，执行规则可以收成一组更稳定的清单：

1. 先扫描文件范围，再执行真实上传。
2. 单篇和批量都要输出结果报告。
3. 知乎正文走 HTML 富文本粘贴。
4. CSDN 正文走 Markdown 编辑路径。
5. 博客园先保持单篇草稿验证。
6. 保存成功要尽量记录强证据。
7. 限流进入等待和重试，重试结果写进报告。
8. 状态未确认时保留浏览器现场。
9. 最终发布由用户手动完成。

到这里，blog-publisher 才算从“能跑”往“可解释”迈了一步。

本篇小结

这一篇把“跑稳”的标准压实了：

• 成功不能只看动作完成，还要看草稿是否有可追踪证据。
• 批量上传要测试连续状态、限流、子进程收尾和父子报告一致性。
• Skill 触发描述要把目标收在保存草稿和浏览器复核上，避免越界到最终发布。

下一篇就可以做最终复盘了。重点会从具体平台退回到通用问题：发布类 Skill 的边界怎么定，测试怎么覆盖成功和失败，触发描述怎么避免越界。