第一版跑通：Markdown 检查、草稿生成和知乎单篇上传

前两篇把问题拆开了：博客上传脚本需要入口、规则、脚本、模板和人工确认点。

这一篇开始跑第一条链路。目标先控制得很窄：给一篇已经写好的 Markdown，先检查内容，再生成知乎草稿材料，最后把文章放进知乎草稿箱里。这个阶段追求的是“能稳定保存草稿”，最终发布继续留给人工操作。

第一版先把链路跑直

第一版先避开批量和多平台，把注意力放在一条最小链路上：

Markdown 原文
-> 基础检查
-> 生成知乎草稿和检查清单
-> 导出可发布正文
-> 发布前预检
-> 写入知乎草稿
-> 人工检查

这条链路里，每一步都要有清楚的输入和输出。

步骤	解决的问题	输出
Markdown 检查	先发现标题、图片、代码块、标签这些高频问题	检查报告
草稿生成	把原文整理成面向平台的发布材料	草稿、检查清单、结构化报告
正文导出	去掉内部元信息，得到真正要放进编辑器的正文	发布正文
发布预检	判断当前材料是否适合进入浏览器流程	预检结果
知乎草稿上传	把正文放入知乎编辑器并保存为草稿	平台草稿

这张表的意义很实际：如果某一步失败，就停在那一步。这样后面调试时能知道问题来自内容、脚本、平台，还是浏览器状态。

Markdown 检查先拦住低级错误

最先做的是 Markdown 基础检查。

原因很简单：很多发布失败，其实在打开浏览器之前就能发现。标题缺失、图片路径坏掉、代码块未闭合、标签缺失，这些都属于文章自身的问题。它们进入平台编辑器之后再发现，会让排查成本变高。

第一版检查脚本主要看这些内容：

• 标题是否能识别。
• 摘要或导语是否存在。
• 标签是否存在。
• 图片路径是否可用。
• 代码块是否闭合。
• 代码块是否标注语言。

检查结果分成两类：

类型	含义	后续动作
blocking	会影响继续发布的问题	停在检查阶段
warning	需要人工注意的问题	可以继续生成材料

比如代码块未闭合就属于 blocking。继续上传会把后面的正文都卷进代码块里，平台里看起来就会乱。缺少标签更像 warning，它影响发布质量，但不一定阻断草稿生成。

这一层做完后，脚本第一次有了“发布前刹车”的能力。它开始判断内容是否适合进入下一步，而不是只把文件往平台送。

草稿生成让发布材料稳定下来

检查之后，下一步是生成草稿。

草稿生成脚本做的事情很克制：保留原文主体，整理出知乎草稿、发布前检查清单和结构化报告。文章观点和表达仍以原文为准，脚本只负责发布材料整理。

第一版生成三个核心产物：

文件类型	用途
知乎草稿	给后续导出和人工检查使用
发布检查清单	展示标题、摘要、标签、阻断问题、警告和人工确认项
准备报告	给后续脚本读取，串起导出和预检

这里有一个重要判断：生成脚本默认尊重检查结果。

当检查里存在阻断问题时，草稿生成会停下来。这样可以把明显有问题的文章留在检查阶段。需要排查时，可以单独进入调试模式；正式发布流程只接收无阻断问题的输出。

这一步跑通后，发布流程开始有了“中间态”。原文先变成一组可检查、可追踪、可复用的发布材料，再进入后续平台流程。

发布正文和预检补上中间环节

草稿文件里会带一些内部发布元信息，方便检查和脚本衔接。平台正文只需要保留真正面向读者的内容。

所以后面又补了一步正文导出：从草稿里导出真正要放进编辑器的正文，把内部注释和发布元信息剥离掉。

导出之后，再做发布预检。预检关注的是“材料是否已经准备好进入浏览器动作”：

• 平台是否支持。
• 准备报告是否存在。
• 导出报告是否存在。
• 标题和正文是否可用。
• 阻断问题是否已经清零。
• 浏览器发布依赖是否具备。

在一次正常样例里，检查、草稿生成、正文导出和预检都能走通。另一些失败样例也按预期停住：缺标题会停在检查阶段，代码块未闭合也会停在检查阶段。

这几个结果让我确认了一件事：浏览器动作可以放到更靠后的位置，前面的内容准备链路已经能先完成大半验证。

知乎单篇上传先走草稿保存

到了知乎这一步，路线发生过一次调整。

一开始更自然的想法，是模拟知乎编辑器里的“导入文档”流程。这个思路看起来很接近用户操作，但它依赖菜单位置、文件选择器、页面状态和编辑器结构。只要页面稍微变化，自动化就容易卡住。

后面收口成更稳定的方式：把 Markdown 正文转换成 HTML，再通过剪贴板写入富文本和纯文本，在知乎编辑器里执行粘贴。

这条路线更接近人手工复制文章的动作：

读取 Markdown
-> 提取标题
-> 正文转 HTML
-> 写入剪贴板
-> 打开知乎写作页
-> 填标题
-> 粘贴正文
-> 等待草稿保存
-> 保持浏览器打开

最终发布按钮继续交给人处理。脚本完成的是“把文章稳定放进草稿箱”，然后让人检查标题、排版、话题、摘要和发布时机。

这个决定让第一版成果变得更实用。它先把最重复、最容易烦的部分自动化，公开发布继续交给人做最终判断。

这条链路跑通后的第一个结论

第一版跑通后，我对发布类 Skill 的理解变得更具体了。

它的价值主要来自前面几层准备工作：

• 检查先拦住内容问题。
• 草稿生成让发布材料稳定下来。
• 正文导出避免内部信息混进平台。
• 预检把浏览器动作放到更靠后的位置。
• 草稿上传完成重复劳动，最终发布保留人工判断。

这样拆完之后，浏览器自动化的压力变轻了。它成为整条链路里的最后一段，前面的检查、生成、导出和预检先把大部分风险消化掉。

本篇小结

这一篇确认了第一条可用链路：

• Markdown 检查能先拦住缺标题、坏图片和代码块未闭合这类问题。
• 草稿生成、正文导出和预检让浏览器动作不再承担所有风险。
• 知乎单篇上传先走草稿保存，公开发布继续留给人工判断。

下一篇会专门复盘失败路线：为什么直接发布、登录状态和浏览器自动化会把问题复杂度拉高，以及为什么最后选择先把知乎草稿保存做稳。