为什么做这个系列：从手动发博客到自动上传脚本

我开始做这个系列，起点其实很小：写完一篇 Markdown 博客后，希望少走一遍打开平台、复制标题、粘贴正文、检查格式、保存草稿的流程。

这些动作单独看都很简单。复制标题、粘贴正文、打开知乎编辑器，本身门槛很低。可它们每次都要重复，而且每一步都带着一点小摩擦：格式可能变乱，代码块可能丢样式，图片可能显示异常，草稿状态也需要确认。

当这些摩擦连在一起，手动发博客就从“顺手操作一下”变成写作之后的第二件事：文章写完了，还要再把它搬到平台上。

起点：我只是想少复制粘贴几次

我最开始想做的东西很朴素：给一篇本地 Markdown，脚本帮我放进博客平台的编辑器里。

理想流程大概是这样：

本地 Markdown
-> 读取标题和正文
-> 打开平台编辑器
-> 填标题
-> 填正文
-> 保存草稿

只看这条线，它像一个普通浏览器自动化脚本。用 Playwright 打开页面，定位输入框，粘贴内容，等页面提示保存成功，好像就结束了。

真正动手后，我发现问题变厚了。博客发布牵扯到内容质量、平台规则、登录状态、浏览器会话和发布边界。

比如：

• Markdown 缺标题时，脚本需要给出明确提醒。
• 图片使用本地路径时，平台可能识别失败。
• 代码块未闭合时，继续上传会把排版问题带到平台里。
• 平台要求登录时，脚本需要复用已有会话，账号密码仍由人处理。
• 页面选择器变化时，脚本要停下来报告阶段和原因。
• 草稿保存和正式发布之间，需要保留人工确认。

这些问题让我把“上传脚本”重新理解成一个更完整的发布流程。

真正麻烦的是发布边界

自动化最容易让人兴奋的地方，是它能替人做重复动作。发布类自动化最需要谨慎的地方，也正是它能替人做动作。

保存草稿和点击发布，表面上都是按钮操作，风险完全不同。草稿还能回头检查，发布可能直接把内容公开出去。脚本一旦把这两件事混在一起，工具就会变得很难让人放心。

所以这个系列的关注点会放在发布流程本身：脚本怎样检查内容，怎样处理平台差异，怎样复用登录状态，怎样留下人工确认的位置，怎样在失败时停下来。

问题	为什么重要
内容检查	上传前先拦住缺标题、坏图片、代码块未闭合这类低级错误
平台差异	知乎、CSDN、博客园的编辑器和发布流程各有一套习惯
登录状态	脚本复用已登录的浏览器会话，账号和安全验证交给人处理
草稿边界	先把内容稳定放进草稿箱，再由人做最终检查
人工确认	真实发布前保留最后判断
失败记录	页面变了、选择器失效了、内容贴入失败，都要能定位原因

这也是我后来把它放进 Skill 思路里设计的原因。Skill 作为入口，需要写清楚什么时候触发、需要什么输入、哪些动作可以做、哪些动作要停下来确认。

换句话说，我想做的是一个尽量稳的发布助手。

当前做到哪一步

现在已经跑通的是知乎单篇草稿上传。

当前这条链路的重点是保守和可检查：

1. 读取本地 Markdown。
2. 识别第一行标题。
3. 把正文转换成知乎编辑器更容易接受的富文本。
4. 复用已登录的浏览器会话。
5. 打开知乎写作页面。
6. 填入标题和正文。
7. 等待页面出现草稿保存状态。
8. 保持浏览器打开，让人自己检查。

这个阶段先把“上传到草稿”做稳。只要草稿可靠生成，人就可以在平台里继续检查标题、排版、话题、摘要和最终发布时机。脚本负责重复劳动，人保留最后判断。

这条线目前处在知乎单篇草稿上传阶段。批量上传、CSDN、博客园、统一 blog-publisher 入口、更多边界测试和触发规则优化，都会放到后面的文章里继续做。

这个系列会怎么写

这个系列按真实推进顺序写：先设计，再实现，再踩坑，再收口，最后复盘。它的重点是记录一个工具怎么一步步长出来，保留过程里的判断变化和修正痕迹。

目前规划是 7 篇：

编号	标题	主要问题
00	为什么做这个系列：从手动发博客到自动上传脚本	交代动机、当前进度和后续路线
01	初版设计：一个博客上传 Skill 应该怎么拆	拆 SKILL.md、references/、scripts/、assets/ 的分工
02	第一版跑通：Markdown 检查、草稿生成和知乎单篇上传	跑通从本地 Markdown 到知乎草稿的第一条链路
03	失败复盘：直接发布、登录状态和浏览器自动化踩坑	复盘为什么直接发布路线需要收口
04	扩展规划：批量上传、CSDN、博客园和统一 blog-publisher	规划从单平台到多平台的结构
05	把 blog-publisher 跑稳：多平台上传、测试和触发优化	设计测试矩阵，优化触发和失败处理
06	最终复盘：发布类 Skill 的边界、测试和触发问题	总结发布类 Skill 的通用经验

每篇文章会围绕一个具体问题写。工作记录、脚本和验证输出会作为材料出现，正文会尽量保留当时的判断变化。

本篇小结

这一篇先把系列的入口放稳：

• 问题不是简单复制粘贴，而是发布边界、登录状态和平台差异叠在一起。
• 当前已经跑通的是知乎单篇草稿上传，批量和多平台还要继续验证。
• 后面的文章会按设计、实现、失败、扩展和复盘的顺序展开。

下一篇要拆的问题

下一篇开始进入初版设计。

当“发博客”从一个手工动作变成一个 Skill，问题就会从“怎么打开网页并粘贴正文”变成：

• SKILL.md 里应该写什么。
• 平台规则应该放在哪里。
• 哪些检查适合写成脚本。
• 哪些动作必须人工确认。
• 第一版怎样控制平台范围。

这一步看起来有点工程化，但它决定了后面的结构能不能稳住。博客上传脚本真正难的地方，往往在一开始有没有把边界摆清楚。