一次发布操作，可能经历创建草稿、填写正文、提交审核和公开展示。把这些步骤都显示成“成功”，会让用户分不清文章究竟到了哪一步；遇到网络中断再点一次，还可能产生重复文章。
我在开发观引的发布流程时，将这件事拆成了两个问题：如何记住已经做过的操作，以及如何证明平台实际收到了什么。下面介绍实现思路，不把模拟测试当作真实平台发布效果。
一、先保存任务，再发送请求
在调用平台接口前，先在本机保存任务编号、目标账号、稿件版本和当前阶段。稿件版本包含标题、正文和事实快照。相同账号的同一份稿件再次操作时，优先寻找原任务。
这不意味着所有平台都能提供“恰好执行一次”的保证。更保守的做法是：请求发出后如果结果未知，就停止自动写入，只查询原任务。用户因此可能看到“结果待确认”，但不会在没有证据的情况下自动再创建一篇。
二、保存草稿与公开发布分开
以博客园官方 MetaWeblog 接口为例，newPost 可以先用 publish=false 保存草稿。拿到文章编号后，再通过 getPost 比对原编号、标题和完整正文。
随后发布同一篇稿件时，使用原编号调用 editPost，而不是再调用一次 newPost。提交前还要重新检查本地审核版本和远端正文：如果用户已经在平台修改内容，应停下来保留原稿，不能用旧版本覆盖。
三、接口返回成功，仍不等于公开可见
发布接口返回 true，可以证明接口接受了操作，但不能单独证明审核通过或任何访客都能看到文章。
因此，结果展示至少应区分“草稿已保存”“已提交”“公开正文已核对”。对于具有可验证公开地址的平台，可以不携带登录凭据读取该地址，并核对文章标题和完整正文。遇到登录页、摘要页或正文不一致时，保持待确认。
四、中断后的恢复以读取为主
恢复时应先使用已保存的文章编号查原稿。如果没有取得编号，可以在账号自己的草稿列表中寻找唯一候选，但不能只凭标题就认定成功，还要核对账号、正文与稳定编号。
多个同名候选、内容变化或账号变化都应停止自动判断，显示具体原因。恢复按钮也应表达实际行为，例如“查看原稿”或“核对结果”，避免让用户误以为它会重新发送。
五、把复杂性放在程序里
用户看到的流程可以是：登录账号、勾选平台、点击发布、查看各平台结果。程序内部则需要分别处理账号归属、稿件版本、平台适配、任务持久化和回执核对。
简洁的界面与严格的状态判断并不冲突。真正应该减少的是用户反复配对、手动核验和猜测结果的负担，而不是省略失败处理。
参考：博客园官方 MetaWeblog 接口说明，https://rpc.cnblogs.com/metaweblog/example 。不同平台的权限、审核规则和接口行为不同，接入与实机验证需要分别完成。
温舒｜杭州 FDE · GEO 践行者
本文包含 AI 辅助整理；实现思路由作者结合开发过程核对，不代表所有平台已经完成自动发布验收。
本文包含 AI 辅助生成或整理的内容。
