扩展规划：批量上传、CSDN、博客园和统一 blog-publisher

上一篇把失败路线收住了：发布按钮交给人，脚本先把文章稳定放进草稿。

到这里，问题就从“知乎单篇怎么跑通”变成了“这个能力怎么继续扩展”。如果每个平台都重新写一套脚本，短期看能解决问题，长期看会变成三个互相分叉的小工具。后面维护时，Markdown 解析、浏览器启动、登录状态、结果记录都要重复处理。

新的 blog-draft-publisher 给了一个更清楚的方向：把目标统一成“保存草稿”，再把平台差异放到各自的适配器里。这样一来，知乎、CSDN、博客园虽然编辑器不同，但它们可以共享同一套外层流程。

这篇先写扩展规划。它还没进入最终复盘，重点是把后续要补齐的能力拆清楚。

先把目标从发布改成草稿保存

前面几篇反复出现的一个结论是：最终发布太重，适合留给人工确认。

扩展到多个平台时，这个边界更重要。因为每个平台的发布页都有自己的弹窗、风控、确认流程和平台规则。如果脚本同时负责填写内容和最终发布，后面每接一个平台，都要重新解释“什么时候算发布成功”“什么时候要停下来”“误点之后怎么处理”。

草稿保存的目标更清楚：

读取 Markdown
-> 解析标题和正文
-> 打开对应平台写作页
-> 写入标题和正文
-> 保存为草稿
-> 保留浏览器给用户复核

这条链路把自动化放在稳定动作上，把最终判断留在浏览器里。用户看到草稿后，可以检查排版、补充平台设置，再手动完成发布。

哪些能力可以抽成通用层

一旦目标统一成草稿保存，很多事情就可以从平台脚本里抽出来。

通用能力	解决的问题	规划里的位置
Markdown 解析	从文件里拿到标题、正文、HTML、字数和文件信息	输入层
文件扫描	支持单篇、目录、包含规则、排除规则	批量层
浏览器会话	按平台打开真实 Chrome，并复用登录状态	浏览器层
结果记录	记录每篇文章成功、失败、跳过和错误原因	报告层
草稿边界	只做草稿保存，最终发布由用户完成	安全边界

这几层是统一 blog-publisher 的骨架。

比如 Markdown 解析这件事，本身和知乎、CSDN、博客园都无关。它只负责回答几个基础问题：标题是什么，正文是什么，是否需要转换成 HTML，文件信息怎么记录。平台适配器拿到这些结果后，再决定怎么写进编辑器。

浏览器会话也是同理。每个平台都需要真实浏览器和登录状态，但“怎么启动浏览器、怎么保留会话、登录时怎么等待用户操作”可以统一处理。平台适配器只关心写作页本身。

平台差异放进适配器

真正麻烦的地方，应该集中在平台适配器里。

平台	写入方式	当前规划重点
知乎	Markdown 转 HTML 后，用富文本方式粘贴	保持排版稳定，默认跳过话题自动化
CSDN	进入 Markdown 编辑器，写入 Markdown 正文	固定编辑器入口，识别草稿保存状态
博客园	打开写作页，填写标题和 Markdown 正文	先支持单文件草稿，确认账号写作权限

知乎这边已经证明了一个关键点：原始 Markdown 直接粘贴进编辑器，效果容易变成纯文本。更稳的方式是先把正文转成 HTML，再用富文本粘贴，让编辑器接收已经排好的内容。

CSDN 的重点在编辑器入口。它有 Markdown 编辑器，也有富文本编辑器。对自动化来说，路线越固定越容易维护，所以规划里优先使用 Markdown 编辑器，把内容按 Markdown 正文写入，再等待草稿状态出现。

博客园的接入更适合先做窄一点。它可以先从单篇草稿开始，确认账号具备写作权限，确认草稿按钮和保存反馈稳定之后，再考虑目录批量。

批量上传先解决状态记录

单篇上传只需要回答一个问题：这篇文章是否保存进草稿。

批量上传要回答的问题更多：

1. 这次准备处理哪些文件。
2. 哪些文件被包含规则选中。
3. 哪些文件被排除规则跳过。
4. 哪篇文章保存成功。
5. 哪篇文章停在登录、权限或页面选择器阶段。
6. 哪个错误可以重试，哪个错误需要人工处理。

所以批量上传的第一步应该放在扫描预演上。预演只列出即将处理的文件，让用户确认范围。确认之后再执行真实上传。

真实上传时，每篇文章都要有自己的结果记录。这样一篇失败时，其他文章的状态还能保留下来，后面复盘也能知道问题出在哪里。

可以把批量流程想成这样：

扫描文件
-> 输出待处理清单
-> 用户确认范围
-> 逐篇写入草稿
-> 逐篇记录结果
-> 汇总报告
-> 用户进入浏览器复核

这里的报告很重要。它让批量上传从“跑完了就算结束”变成“跑完后能解释结果”。后面做测试和优化时，也能用这些记录判断到底是哪一层出了问题。

统一 blog-publisher 应该长什么样

前面设计 blog-publisher 时，我更关注内容检查、草稿生成、发布预检和知乎单篇上传。现在加入 blog-draft-publisher 后，统一 Skill 的形态可以再清楚一点。

它可以拆成六层：

层级	负责内容
输入层	接收单篇文件或目录，处理包含和排除规则
内容层	解析 Markdown，生成标题、正文、HTML 和基础统计
检查层	做标题、正文、结构、图片、链接等发布前检查
平台层	按知乎、CSDN、博客园分别写入编辑器
报告层	输出每篇文章的处理状态和错误信息
人工确认层	保留浏览器窗口，用户复核后手动发布

这套分层的好处是每一层都有明确职责。

内容检查可以持续增强，它只关注文章本身。CSDN 的按钮在哪里，交给平台适配器处理。平台适配器可以持续修选择器，Markdown 扫描留在内容层。报告层可以统一记录结果，也能帮助后续测试边界问题。

如果后面把它们合成一个 Skill，我会倾向于保留两个名字上的分工：

• blog-publisher 更像完整工作流，覆盖检查、生成、预检、上传前准备。
• blog-draft-publisher 更像浏览器执行层，专门负责把 Markdown 写进平台草稿。

最后合并时，外层可以叫 blog-publisher，内部保留 draft publisher 这条执行链。这样名字更贴近用户目标，内部边界也能保持清楚。

后续扩展顺序

接下来的扩展更适合分步推进。更稳的顺序应该是：

1. 先把知乎单篇草稿继续打磨稳定。
2. 再加入知乎批量上传，补齐扫描预演和结果报告。
3. 接入 CSDN Markdown 编辑器，先跑通单篇，再跑批量。
4. 接入博客园单篇草稿，确认权限和保存反馈。
5. 把三个平台的结果汇总成统一报告。
6. 再回头补边界测试，比如登录失效、标题缺失、正文为空、保存按钮变化。

这个顺序的核心是：先把共同流程跑稳，再把平台差异一点点收进适配器。

本篇小结

写到这里，扩展规划已经比较清楚了。

统一 blog-publisher 一开始可以保持很小。它先围绕一个简单目标推进：把本地 Markdown 稳定保存到目标平台草稿里，并把结果解释清楚。

后续真正要重点打磨的，其实是三件事：

• 批量时的文件范围要可预演。
• 平台差异要收进适配器。
• 草稿保存后要留下可复核的浏览器现场和结果报告。

下一篇就可以进入“将其跑通，并测试优化整个 Skill”。到那一步，文章重点会从规划转到实测：哪些平台已经能批量，哪些平台更适合单篇，哪些边界会触发失败，以及报告怎么帮助定位问题。