给自动化流程留一个人工出口

设计自动化流程时，我会先问：如果它卡住了，或者给出的结果需要判断，人应该从哪里接手？这个入口越明确，流程就越容易逐步投入使用。

下面用一个假设的内容工作流举例：读取产品资料，生成文章草稿，整理配图，最后发布到网站。这只是用来说明设计方法的示例，并非某个已经运行的项目。

先写清输入和输出

“帮我生成一篇文章”很难直接变成稳定的流程。可以先明确输入需要哪些字段：产品名称、已经确认的参数、参考资料和目标读者。缺少必要信息时，任务进入待补充状态，避免让后续步骤自行猜测。

输出也需要边界。草稿除了正文，可以附上引用来源和待核对的问题。生成完成只代表已经得到草稿；通过检查、等待确认和发布完成，应该是不同的状态。

这样即使某一步暂时停住，前面的结果仍然能够保留，也能知道下一次该从哪里继续。

把确认绑定到具体内容

在这个示例里，发布到外部网站前安排一次人工确认。我会把需要判断的信息放在同一处：文章预览、待核对事项、发布渠道，以及这次操作实际会产生的结果。

确认需要对应具体的文稿版本和目标渠道。正文修改以后，先前的确认不能自动沿用；更换发布位置，也应重新检查。否则界面上虽然有一个“已确认”，真正发布的却可能已经是另一份内容。

人工出口还应允许退回修改、暂存或结束任务，而不是只剩下一个继续按钮。

让重试有依据

发布请求超时，不一定代表发布失败。可以先查询下游状态，确认是否已经产生文章，再决定是否重试。临时网络错误可以有限次数重试；资料缺失、权限错误或内容待确认，则应该停在对应环节。

为避免重复发布，可以用任务编号、内容版本和渠道组成唯一键，记录处理状态；下游接口支持幂等键时，也一并传递。相同任务再次进入流程，应先检查已有结果。

日志至少留下任务编号、当前步骤、尝试次数、错误类型和下游结果标识。排查需要的是过程线索，凭据和完整的敏感资料没有必要跟着写进日志。

从一小段流程开始

最初可以只自动整理资料和生成草稿，让人继续完成检查与发布。等输入稳定、异常能够解释，再逐步加入后面的环节。

每增加一步，都检查它怎样完成、怎样失败，以及人能怎样接手。先把这些路径走通，自动化才更容易成为日常工作里靠得住的一部分。