自动化应该在哪一步停下来让人确认
自动化应该在哪一步停下来让人确认
自动化最大的价值，不是把每一步都替人做完，而是把人从重复的劳动里解放出来，同时把“不可逆的、不该由机器单独做决定”的那一步，留给人。
这句话说起来轻巧，做起来很难。因为自动化天然想“一路跑到底”，跑得越顺越像“自动化成功了”。可一旦这条链路的末端是不可逆动作——比如直接群发、直接发布、直接删库——那“一路跑到底”本身就是事故，而不是功劳。
我用一个把 Markdown 安全转为公众号草稿的工具为例，讲清楚“在哪一步停下来让人确认”这个设计。这个工具刻意做成一个“草稿模式”：只生成草稿，不碰任何直接群发。细节以实际项目为准，原则是通用的。
一、自动化最危险的那一步，往往是最后一步
很多流程里，前面的步骤都是可逆的、可重来的：转换格式、上传图片、生成内容，这些失败了重跑一次就好。但“真正发布出去”这一步不同——它一旦发生，影响就收不回来了，尤其是在面向大量读者的公开场景。
所以问题不是“要不要自动化”，而是：自动化要跑到哪一步才停，把自己交还给一个能决策的人。
具体到写作类工具，这条链路的形态大概是这样：写好的 Markdown → 转成公众号可用的 HTML → 上传正文与封面图 → 创建公众号草稿。前面几步怎么自动化都不过分，越省事越好；但“生成一个草稿”和“把这个草稿真的发出去”，是两件性质完全不同的事。
二、草稿模式：把“不可逆”变成“可逆中间态”
这个工具的第一个设计决策：它只创建草稿，不创建任何直接群发。 整个流程可以自动化到“上传 markdown、转成公众号可用的 HTML、上传正文与封面图、用公众号 API 创建一个草稿”，然后停在这里。
最后它返回的是一个 media_id（草稿标识），而不是“已发布”的结论。真正的发布，要登录公众号后台去人工审阅、再手动点发布。
为什么停在草稿而不是停在发布？因为草稿是一个“可逆中间态”：它存在了但还没影响任何人，你随时可以改、可以删、可以废弃重来。而“发布”是一个不可逆终态。把自动化停在可逆处，等于给流程留了一个安全阀。
三、显式确认：让“停下来”成为一个有意识的设计
“停手”不是代码偷懒，而是一个显式、有意识的设计。这里有两个层面：
- 功能边界上明确不做什么。 这个 fork 特意移除了基于浏览器 Cookie 的网页自动化、跨平台同步，以及任何“直接群发”的流程。换句话说，它把“哪些事情绝不由程序替你决定”写进设计里，而不是等出事再后悔。
- 操作结果上留一个人工确认点。 工具做完草稿后，把结果（草稿 id、标题、摘要、封面等）交给用户，让用户去后台确认。这一步是“人机交接”，不是程序随便一停。
这对应主页里写的“最后一步人工确认”——它不是一个可有可无的附加功能，而是这个工具存在的意义之一：自动化负责安全、可靠地把内容送到“随时能发”的状态，人负责做那个“发”的决定。
四、可恢复交接：停下来也要让接手人能安全继续
“停下来”还不够，还得让接手的人安全地继续。否则只是把问题甩给了人。
可恢复交接有几点：
- 结果要明确、可追踪。 拿到的是草稿
media_id，而不是一句模糊的“已完成”。人能拿着这个标识去后台找到它。 - 产物要留下来。 转换好的 HTML、上传后的图片、生成的标题与摘要，都要能复用，这样即便要改，也有基础材料，而不是重新跑一遍。
- 凭据要留在本地且隔离。 公众号凭据放在本地配置文件里，token 缓存文件被 git 忽略，不提交到仓库。这样交接的一方（人）拿到的只是“内容”，而不是一堆不该外泄的密钥。
一句话：让自动化在可逆处停下，并给接手人一份“安全的、下一步能接着干”的交接物。
五、判断“在哪停”的三条准则
不看具体工具，判断“自动化该在哪一步停下来让人确认”，可以用这三条：
- 找不可逆点。 从后往前找第一个“一旦发生就难撤回”的动作，在它之前停。发布、群发、删除、覆盖、扣款、对外承诺——都是典型的不可逆点。
- 看影响范围。 影响越广，越应该留人工确认。给一个人看的内容、只影响自己测试环境的操作，可以自动化；面向大量读者、或影响外部系统的动作，必须留人。
- 能否重来。 可重来的步骤放心自动化；不可重来的步骤留人。所谓可恢复，就是这个动作之后还能安全地撤回或继续。
六、可复用结论
- 自动化的终点是“把内容送到随时能发、且安全可逆的状态”，而不是“替人做出发布决定”。
- 用“草稿模式”把不可逆动作降级成可逆中间态。
- 把“哪些事绝不由程序决定”写成设计，而不是口头约定。
- 停下时要给接手人明确的标识、可复用的产物、隔离好的凭据。
- 判断在哪停：先找不可逆点，再评估影响范围，最后看能否重来。
“能在这一步停下来”不是自动化的缺陷，恰恰是它的成熟之处。真正好的自动化，是这个清楚“自己的边界在哪里”、并且把那个边界以外的重要决定，郑重地交还给人的系统。