最终复盘：发布类 Skill 的边界、测试和触发问题

这个系列一开始想解决的是博客上传里的重复劳动。Markdown 写完后，复制正文、调整格式、保存草稿，这些动作做一两次还能接受，文章一多就会变成稳定摩擦。

做到最后，最值得复盘的地方其实很集中：单篇上传能跑通，批量上传就开始暴露问题。

单篇任务里，页面状态简单，浏览器里只有一篇文章，失败也容易看出来。批量任务完全不同。上一篇的编辑器状态可能影响下一篇，平台保存反馈可能延迟，限流提示可能出现在中途，子进程可能结束不了，父报告也可能误判成功。

所以这篇最终复盘会把问题收回到三件事：边界要硬，重试要有出口，日志要完整。它们分别对应发布类 Skill 的边界、测试和触发问题，也是后面继续扩展平台时最不能省的底线。

单篇跑通之后，批量才是真考验

单篇上传看起来顺利时，很容易误以为整个 Skill 已经稳定。

实际批量跑起来后，问题会换一种形式出现：

单篇里看起来正常的事	批量里暴露的问题
正文能写进编辑器	下一篇可能继承上一篇的编辑器状态
页面出现保存提示	草稿箱里未必生成独立草稿
进程还开着方便复核	父进程可能一直等不到子进程退出
一次上传未触发限制	连续上传可能触发平台限流
脚本报告成功	报告可能只看了退出码，跳过了真实草稿状态

这也是我对发布类 Skill 改观最大的一点：单篇能跑，只说明最小链路成立；批量能解释成功和失败，才说明系统开始可靠。

批量远比“把单篇循环几次”复杂。它需要调度、隔离、记录、重试、停止条件和结果汇总。少一层，后面都可能变成“看起来跑了，实际说不清发生了什么”。

第一条规矩：边界要写硬

发布类 Skill 最容易出问题的地方，是边界模糊。

比如它的任务是保存草稿，就应该停在草稿。它的任务是写入 Markdown，就应该围绕编辑器写入和保存状态做判断。分类、话题、最终发布、账号验证、平台风控，这些动作一旦超出当前能力范围，就应该交回给用户。

这条边界需要落到脚本逻辑里。提示词会被上下文影响，脚本才是最后真正执行动作的地方。关键边界要写成可执行规则：

1. 只识别明确的草稿保存控件。
2. 遇到发布相关控件时直接避开。
3. 页面进入非预期编辑器时停下来。
4. 登录和安全验证交给真实浏览器里的用户。
5. 平台返回权限、限流、选择器异常时记录状态并停止当前篇。

这里的重点是“边界内执行，边界外交还用户”。一个保存草稿的 Skill，只负责保存草稿；一个批量上传脚本，只负责调度和记录；一个平台适配器，只负责对应平台的编辑器写入和草稿保存。

边界越硬，失败越清楚。边界一软，失败就会变成混合问题：可能是文章内容，可能是平台编辑器，可能是登录状态，也可能是脚本多点了一步。

第二条规矩：重试要有出口

批量上传一定会遇到临时问题。

页面加载慢、保存反馈延迟、平台提示操作频繁、选择器短时间不可见，这些都适合重试。重试能提高成功率，但重试本身也有风险：一旦缺少上限，脚本就可能一直卡在同一个页面，用户也说不清它到底在等什么。

所以重试要写成硬规则：

场景	处理方式
页面加载慢	等待固定时间后重试，记录次数
保存状态未出现	刷新状态或重新检查，达到上限后标记未确认
平台限流	等待一段时间后重试，超过次数后停止当前篇
选择器找不到	保留浏览器现场，记录选择器阶段
子进程未退出	到达超时时间后结束当前任务并写入报告

这类兜底措施最好写进脚本，提示词只负责说明方向。

提示词适合描述意图，比如“只保存草稿”“遇到登录等待用户”。脚本适合承载硬约束，比如最多重试几次、每次等多久、哪些页面文案算限流、缺少草稿 ID 时写什么状态、子进程超时后怎么收尾。

这次批量过程里，CSDN 的问题就很典型。单篇可以跑，多篇连续跑会出现保存状态不稳定、限流提示、子进程挂住、父报告误判。解决这些问题要靠明确规则：

• 最多重试几次。
• 每次重试间隔多久。
• 哪些提示进入限流分支。
• 缺少强证据时写状态未确认。
• 子进程到时必须返回。
• 父进程必须读取子报告，退出码只作为辅助信号。

更可靠的自动化，应该知道什么时候继续、什么时候等待、什么时候停下来。

第三条规矩：日志和报告要全量记录

批量上传里，最怕的是“跑完了，但说不清”。

如果只在成功时记录，失败就会消失。如果只记录最后一条状态，中间的重试、限流、页面异常也会消失。后面想统计成功率、定位问题、修脚本，就只能靠记忆。

所以日志和报告要覆盖成功和失败。

每篇文章至少要记录这些信息：

字段	用途
文件名	知道是哪篇文章
平台	区分知乎、CSDN、博客园
标题	方便和草稿箱对应
执行状态	成功、失败、状态未确认、跳过
保存证据	草稿 ID、保存提示、页面状态
重试次数	判断是否接近平台限制
错误阶段	知道卡在扫描、写入、保存还是收尾
错误原因	后续统计和修复

日志偏向调试，报告偏向复盘。两者都要有，但用途不同。

日志记录过程，比如第几次等待、找到哪个控件、页面出现什么提示。报告记录结果，比如这篇是否生成草稿、是否缺少强证据、是否触发限流、下一步是否需要人工检查。

批量上传结束后，用户更需要一份能回答问题的报告：

• 哪几篇成功。
• 哪几篇状态未确认。
• 哪几篇触发限流。
• 哪几篇需要人工打开浏览器检查。
• 哪个平台问题最多。
• 哪个阶段最容易失败。

这份报告后面还能用于统计。比如 CSDN 连续多篇都缺少草稿 ID，就说明保存确认逻辑要调整；如果只有长文失败，就要看正文写入和保存时间；如果总是在第几篇触发限流，就要调整批量节奏。

提示词负责方向，脚本负责底线

这次最大的教训，是底线要落进脚本。

提示词能告诉模型“保守一点”“只保存草稿”“遇到问题停下来”。但真正执行时，脚本必须自己知道底线在哪里。

更合理的分工是：

位置	适合放什么
Skill 描述	触发场景、总体目标、平台范围
操作规范	人工确认、草稿边界、账号处理原则
脚本逻辑	重试次数、超时、停止条件、危险按钮过滤
报告结构	状态字段、错误阶段、保存证据

提示词负责让 Skill 朝正确方向走，脚本负责在关键位置踩刹车。

比如“最终发布由用户完成”可以写在 Skill 说明里，但脚本里也要过滤发布按钮。比如“遇到限流要重试”可以写在规范里，但脚本里也要识别限流文案、设置等待时间和重试上限。比如“状态要记录清楚”可以写在流程里，但报告结构里必须真的有状态字段。

只有这样，批量上传才不会变成一串脆弱的浏览器动作。

以后写这类 Skill，我会先问三件事

这一轮做完之后，我对发布类 Skill 的检查顺序变简单了。

第一，边界是否写硬。

这个 Skill 到底负责什么，停在哪里，哪些动作交给用户。只要超出边界，脚本就应该停止、记录、交回浏览器现场。

第二，失败是否有出口。

每一个等待、重试、保存确认、子进程调用，都要有上限。遇到解决不了的问题，进入可解释状态，并结束本轮尝试。

第三，记录是否足够复盘。

成功要记录，失败也要记录。单篇要记录，批量汇总也要记录。报告要能支撑后续统计、纠错和脚本优化。

这三件事，比“多支持一个平台”更重要。平台可以慢慢接，能力可以慢慢补，边界、退出和记录如果一开始没立住，后面越批量越容易乱。

本篇小结

这个系列表面上是在写博客自动上传脚本，最后留下的其实是一套发布类 Skill 的工程规矩。

单篇跑通值得高兴，但批量才会暴露真实问题。批量上传里，最重要的是让脚本知道自己的边界、知道什么时候重试、知道什么时候停止、知道怎么把结果完整记录下来。

以后继续扩展 CSDN、博客园或新的平台，我会先把这三条规矩放在前面：

1. 功能边界写进规范，也写进脚本。
2. 重试和停止条件写成硬编码兜底。
3. 成功和失败都进入日志与报告。

做到这三点，发布类自动化才有资格从“能跑一次”走向“批量可维护”。