《7Tan 一键发布工具》：360 次草稿，0 次失败，3075 条警告

昨天上午九点零一分，一篇稿子进了公众号后台的草稿箱。135 个内容块，25 张图。九点零九分同样的内容进了百家号，九点十分搜狐号，九点二十微博，九点五十五头条号，十点零七小红书。六个平台，一小时零六分钟，中间我没动手。【本人实测】




写完这个工具到现在，台账里一共 360 条记录。



一个 Chrome 扩展，加一个跑在本机的服务。




为什么不直接做个网页，在浏览器里打开就往各平台发？我一开始也是这么想的，被三件事挡住了：同源策略——网页发请求能出去，读不回结果；SameSite=Lax——跨站请求不带你的登录 cookie；CSRF token——每个编辑器一次性的，只能从它自己的页面里读。

这三条没有一条能绕。绕不过去就不绕了：让代码跑到平台页面里面去。扩展的内容脚本在页面里就是同源的，而且用的是你浏览器里已经登录的状态。我这边一个平台密码都没存过，全靠浏览器自己已登录。【本人实测】

服务只监听 127.0.0.1，主端口 8899，另开一个 18899 当别名，记哪个都行。






360 条，动作全部是 draft，状态全部 ok。




分到七个平台上：小红书 74 次，公众号 71 次，微博 70 次，百家号 49 次，头条号 47 次，搜狐号 45 次，知乎 4 次。

69 篇不同的稿子。最早一条 10 月 2 日 00:49，最晚 10 月 20 日 12:53，中间 19 天有记录。发得最多的一篇去了 21 次，单篇平均块数从 122 到 146 不等，看平台。

知乎那个 4 次，是我最后接的，也是最不熟的。这点后面单说。



台账里 ok 字段全是 true，没有一次整篇崩掉。可 360 条记录里有 357 条带着警告，单条最多带 38 条，加起来 3075 条。

所以要是有人问我这工具行不行，我只能说：整篇没错过，细节错了很多。

"错了很多"具体是什么，得拆开。不然 3075 这个数听着比实际重。



3075 条里，2293 条是同一句话：图片数量不符。

第一次看到这个数字我心里一沉，以为图丢了。后来把其中 1405 条能解析出具体数字的挑出来对了一遍：





九条。不是两千多条。

为什么多？拿昨天那篇公众号举例。稿子 25 张图，编辑器里数出来 50 个图片节点，正好两倍。它给每张图包了一层自己的容器，我按 img 标签数，它按节点数。搜狐号和百家号那边，那一篇里从头到尾都多两个，应该是编辑器自带的占位。

计数口径不一致，不是内容不一致。我记成警告，是因为我确实对不上，不代表图没进去。

【个人看法】这条我留着不动，理由很简单：宁可每天看两千条假警报，也不想漏掉真丢的那九张。



九条少图里，七条在知乎，两条在微博。

知乎我只跑了 4 次，两次是测试稿，一次 8 块，一次 112 块。112 块那次只进去 102 块，6 块、8 块那几次各少 2 块。原因写在另一条警告里：图片路由探测失败，页面上没有任何一条路能让图进正文。

这种情况工具的选择是不插图、文字继续灌，不换路重试。重试会重复，会错位。

当时是这么想的：内容进去了、图缺着，比整篇乱掉强。事后看，缺的图还是得人来补，省不掉。



有一条警告比丢图更让我难受：顺序错位。

第 18 项没落在该在的位置。第 2 项、第 20 项、第 11 项也都有，总共 154 次。

内容没丢，位置错了。编辑器有时候把一段吞进自己的结构里，后面的块就往前挤一格。我能检测到——每个块的预期位置和实际位置我都记了——但没能让它自己爬回去。现在的做法是报出来，让人看两眼。

154 次里有多少是真错、有多少是我判断标准太严，我没逐条统计【本人未实测】。



这个毛病别的平台没有，294 次。

处理方式是就地清理：把多出来的那张删掉，再按相邻结构去重，262 次。五百多次清理都在同一次灌稿里跑完，人不用管，这部分是真正省事的地方。

有 5 次相邻去重没生效，算出来图片节点总数是 0，那就没得删。这 5 次得手看。



第一个，消息被早退吃掉。background.js 里原来有一句 if (!msg.type) return;，写在路由分支前面。控制台的握手消息只有 __onepub，没有 type 字段，于是每一次请求都干等到超时。症状是控制台永远显示"没检测到扩展插件"，可扩展明明装着。

第二个，握手只喊一次。修完上一条灯还是红的，查出来是内容脚本在 document_start 只发一次 hello，那时候页面自己的监听器还没注册，必然漏掉。改成重试 5 次、成功一次就点灯、之后每 5 秒心跳，扩展后装也能自己连上，不用刷页面。

第三个，列表压根没被解析。article.md 里的列表行以前根本没进列表分支，两个症状：无序列表变成一串以横杠开头的普通段落，金色圆点没了；有序列表被并成一大段，7 条清单变成一坨。补上解析器以后，同一篇稿子的块数从 165 降到 153，少掉的 12 块正是被拆散、被合并的那部分。

三个都是踩出来的，不是想出来的。【本人实测】



代码现在的规模：桥接服务三个文件 1,739 行，background.js 918 行，内容脚本十个文件 11,623 行，manifest 190 行。合计 14,470 行，558 KB。

测试那边是 26 个 e2e 脚本，6 个复刻出来的编辑器 HTML(没有登录态，先照结构搭个假编辑器往里灌)，8 个真实页面快照。

【个人看法】这些测试不是给用户看的，是给我自己看的。改一个选择器，26 个脚本跑一遍，比手动点六遍快。



扩展代码里没有点"发布"的分支，只点"存为草稿"。

这一条是我自己定死的。发布不可逆，一次错发到几万人手机上收不回来；草稿可逆，错了改，改完自己点。代价是它只解决了七遍粘贴，没解决七遍点击。七遍点击大概还要两三分钟。

这活儿我暂时不想交给它。



监听地址强制 127.0.0.1。config.json 里 host 现在是 127.0.0.1，端口 8899，token 是 32 位随机串，这个不发出来。

防 DNS 重绑定靠校验 Host 头，不是本机就 403。CORS 不再返回星号，只对扩展来源和本机页面回显。所有接口要 token，比对用 secrets.compare_digest。图片接口只取文件名，校验扩展名和目录，防穿越。桥接对工作区只读，唯一的写操作是台账。

上面这些除 host 和端口外，这次我没有逐条复测【本人未实测】。写在这里是因为它们写在代码里，可以对着看。



README 第一段写"当前支持：搜狐号、微信公众号"，往下第六节写"目前只适配搜狐号"。同一个文件里两句话对不上。

版本号更明显：README 让按 0.8.0 确认重载成功，manifest.json 里现在是 0.38.1。

实际适配器 8 个：搜狐、公众号、微博、百家号、头条号、知乎、小红书，加一个跑在 MAIN world 的 pm_main.js。

【个人看法】README 是给人看的，代码是给自己看的。代码跑在前面，文档落在后面，中间差了 29 个小版本。这话不好听，但是实情。



要手动装。Chrome 154 已经忽略 --load-extension 命令行开关，我试了 4 组开关组合，加一次 CDP 的 Extensions.loadUnpacked，全部无效。所以自动化测试里装不进扩展，只能人去 chrome://extensions 点"加载已解压的扩展程序"。日常用不受影响，受影响的是没法打个包给不懂的人。

只在这台 Windows 上跑过。macOS、Linux 没试【本人未实测】。工作区只认 config 里写的一个目录，换机器要改配置。知乎最不成熟，4 次里 7 条少图全在它身上。也没有一键安装：给别人用要装 Python、装依赖、跑 bat、装扩展、填 token，五步。



把账算成时间：一篇稿子七个平台手动粘贴，按我的手速大概 25 分钟。360 次灌稿全都手动的话，接近 150 小时。实际投入是写这个工具用了 19 天，小时数没算。

所以它现在是不划算的。要划算，得继续用，用到一百篇文章以后才追平。

【个人看法】这话可能不该我来说。但工具的价值是"用出来的"，不是"写出来的"。

我现在的用法很简单：稿子写完，六七个平台各点一次，标题看一眼，图检查一遍，然后自己去点发布。

它不是让我不用管，是让我不用重复。

---

台账最后一页是 2026-10-20 12:53，一篇叫 crab-price-truth 的稿子进了公众号，90 块全进，5 条警告。

就这样。