Skill 地址：https://clawhub.ai/zangzhicong/bili-sunflower-publish
前阵子写了第一个版本，把内容自动发到 B 站这件事是跑通了。
但我自己用了一段时间，发现它更像一个"能跑就行"的脚本，离"能长期用"还有距离。
这次更新之后，差别出来了。
最大的变化就一句话：不再依赖系统剪贴板，改为直接走编辑器的 API。
听起来只是技术实现换了一下，但实际体验完全不一样。
这次到底变了什么
之前的方式是通过系统剪贴板模拟粘贴，把内容塞进 B 站编辑器。这个思路能用，但有个隐患：
环境稍微变一点，就可能失效
粘贴行为可能被页面拦截或改写
逻辑上是在"绕过去"，不是在"接进去"
新版换成了直接调用编辑器 API，把内容送进编辑器。
这意味着：
不用再依赖 macOS 剪贴板能力
流程更统一，不用在系统层和浏览器层之间跳来跳去
排查问题更直接，逻辑更清晰
之前是模拟人复制粘贴，现在是告诉编辑器：这是正文，请你按自己的规则接收。
稳定性的差别，不是一点半点。
发布链路终于变成一条"管线"了
这次我还把整个发布流程重新整理了一遍：
HTML / Markdown → 预处理 → 编辑器 → 发布
之前很多自动化脚本容易变成"打补丁"：这里加个分支兼容一下，那里补个 hack 绕过限制。最后逻辑越来越乱，维护成本越来越高。
新版把主路径理清楚之后，结构就干净多了：
先识别文件类型（HTML、Markdown 都支持）
先做预处理，而不是直接往编辑器里塞
再统一注入编辑器
最后执行发布
这个顺序的价值在于：输入和发布解耦了，预处理可以独立演进，平台差异被收进更少的地方。以后想加新功能，不用推倒重来。
补上了"内容预处理"这一层
之前做自动发布，很多人会默认内容文件已经是"发布态"，其实不然。
你手上的 HTML / Markdown，通常只是"写作态"：
标题藏在 H1 里
标题层级不一定适合编辑器
图片可能还是外链
HTML 里一堆无意义空白
新版 Skill 把预处理正式变成了流程的一部分：
提取 H1 作为标题候选
调整标题层级
处理图片内联
清理多余空白
这意味着工具开始理解"内容从素材到成稿，再到发布稿"的过渡了。它不只是在"把文件塞进网页"，而是在承担一部分发布前整理的职责。
真正折磨人的，往往不是点发布按钮，而是发布前那一堆重复琐碎的整理动作。把这些吸收进 Skill 里，才是真正减少体力劳动。
标题处理终于独立了
标题看似小事，其实是自动化里最容易出问题的环节：
用户可能没给标题
文件里有 H1，但不一定适合直接用
平台对长度有限制
专栏和小站的标题策略可能不同
新版把标题单独做成一个阶段，好处很明显：
有标题就用用户指定的
没有就提取正文结构里的候选
标题和正文注入解耦，互不影响
后面想加更复杂的标题建议逻辑，也有地方挂
不要把"暂时能凑合"的行为，塞进隐式逻辑里。只要某一步足够重要，就该把它提升成显式阶段。
小站支持也更完整了
专栏和小站都支持，但小站更复杂一点：你得告诉工具发到哪个小站。
现实是用户不会每次都把参数说完整：
可能只记得小站名称
可能只有 ID
可能两个都没有，只知道"发到我那个xx小站"
新版把这种情况拆开了处理：
同时给 ID 和名称 → 直接拼 URL
只给 ID → 先去小站主页反查名称
只给名称 → 先搜索，再定位到小站主页拿 ID
这不是简单地说一句"支持小站"，而是在认真处理真实用户输入的不完整性。
登录这件事，还是坚持"该停就停"
有些原则不能变。
新版仍然写着：没登录就停下来，让用户手动登录，再重试。
我见过太多所谓"全自动"工具，非要把登录也吞掉。但真正做过工具就知道：越接近账号安全的环节，越不该盲目追求自动化。
风控策略不稳定，一旦越界问题就不是"流程中断"而是"账号异常"。
好的自动化，不是每一步都代替人，而是知道哪一步必须把人请回来。
值不值得更新
如果你是这几类人，值得跟进：
经常把 Markdown / HTML 发到 B 站
同时用专栏和小站
对稳定性比"炫技"更敏感
希望能继续扩展这个工作流
这次升级不是一个"看起来更厉害"的功能点，而是更扎实的底层路径。
你可能不会每天感知到编辑器 API 这几个字的意义，但你会在每次发文时感知到：它是不是更顺、更稳、更少出莫名其妙的问题。
这就够了。
