老梁AI电商｜把人写进AI系统：真人节点的两条落地路径

---

“人工审核”这四个字，写不完一个真人节点。

假设一个电商上新流程：AI完成选品建议、整理调研资料、生成主图和详情页方案，接下来交给负责人审核。流程图画到这里，看上去已经很完整。

但负责人回复一句“这个方向不合适”，系统该怎么办？

退回选品，还是修改主图？已经完成的调研还能不能用？改完以后由谁再审？如果负责人没有回复，流程停在哪里？如果审核通过了，却在提交时中断，下次恢复会不会重复提交？

这些问题，决定了“有人参与”和“人机协作能够持续运行”之间的距离。

老梁AI电商，专注帮电商企业建立可落地的 AI 能力体系——从 AI 内容生产到私有知识库、岗位 Agent。对于企业流程中的真人参与，我们的判断很明确：人的职责、权限和决定，需要进入流程本身。

Human in the Loop，可以理解为“人在回路中”。放到企业业务里，就是让真人成为可触发、可等待、可记录、可恢复的正式节点。

下面用一个假设的电商上新流程展开说明。它用于解释设计方法，不代表某个客户已经部署了完整系统。

先把“请审核”变成一个能够回答的问题

设想AI交来三套详情页方向，请运营负责人审核。

如果只给出一句“请看看是否合适”，负责人就得自己补齐上下文：这是哪个产品？面向哪类客户？采用哪份产品资料？这次要决定卖点顺序，还是决定能不能上线？

审核人需要重新理解整件事，才能开始判断。即使最后回复“可以”，系统也很难知道这句话批准了什么。

因此，真人节点首先要明确输入。

审核的对象是什么，使用的是哪个版本，前面已经做了哪些工作，当前有哪些需要决定的问题，都应该一起交付。不要让审核人靠翻聊天记录拼出任务背景。

其次，要把问题问具体。

“请判断这三套表达中哪一套符合本次产品定位”，与“请确认这一版是否允许上架”，是两种不同的请求。前者解决方案取舍，后者涉及执行授权。把它们合并成一个模糊的“确认”，后续就容易扩大决定的范围。

再往下，还要规定返回方式。

通过、退回、补充资料、终止，这些决定会把流程带向不同位置。即使让真人用自然语言回复，系统也需要把回复对应到明确动作；无法判断时，应继续澄清。

真人参与的质量，往往从提问质量开始。给到明确对象、必要资料和具体问题，人才能把精力用在判断上。

四个结构，让人的决定真正进入流程

一个真人节点，需要同时具备四个结构。

1.可触发：什么时候必须找人。

以假设的上新流程为例，选品建议完成后，需要负责人决定是否继续；详情页方案完成后，需要审核表达方向；进入上架动作前，需要检查对应授权。

这些节点应提前写入流程，而不是等AI遇到困难时临时决定找谁。

触发条件还应覆盖异常。例如产品资料缺失、不同资料里的规格相互冲突、输出无法满足验收标准。此时触发的是补料或异常处理，不能当作普通审核继续往下走。

2.可等待：人还没有决定时，流程停在哪里。

等待应当是一种清楚的业务状态。实例需要保留当前节点、待审核产物、待处理问题和恢复条件。

如果下一步依赖真人决定，就不能因为等待时间较长而自行推进。负责人还没选定产品，后续围绕某个产品展开的制作，就缺少明确依据。

等待期间是否允许做其他独立工作，也应由流程规定。关键是识别依赖关系，不能让“提高效率”变成越过审核的理由。

3.可记录：谁对什么作了什么决定。

一条可用的审核记录，应能回答：谁审核的，审核了哪个版本，结论是什么，批准范围是什么，有没有附带修改要求。

“文案方向通过”和“允许公开发布”，不能记成同一个结果。

如果负责人只批准了方向，系统就应保留这个范围。后续文件发生实质修改，也不能自动沿用旧版本的审核结论。

记录决定，是为了让后面的执行有依据，也让中断后的恢复有依据。

4.可恢复：收到决定以后，从哪里继续。

通过后进入哪个节点，退回后回到哪里，补料后重新执行哪些检查，都需要明确。

例如详情页主卖点被退回，可能只需修改文案与对应画面，不必把已经确认的产品资料重新整理一遍。但如果负责人改变了目标人群，原先的调研判断和卖点组织就可能需要重审。

恢复规则要识别变化影响了什么，保留仍然有效的工作，重新处理受到影响的部分。

四个结构连起来，真人的回复才会产生明确、可追踪的流程变化。

三类事情，要保留清楚的真人责任

设计真人节点，并不意味着每一步都让人重新检查。否则AI做完一遍，人再从头做一遍，执行负担并没有真正减少。

更合理的方式，是把真人放到需要判断、责任和授权的位置。

第一类是价值判断。

品牌表达是否合适、多个方案如何取舍、业务方向是否符合企业目标，这些问题需要明确的负责人。AI可以整理证据、比较方案、指出冲突，但企业需要有人承担最终选择的责任。

还是以上新为例，同样真实的产品特点，可以形成不同的表达顺序。强调耐用、便利还是使用体验，涉及本次业务目标和品牌取舍。资料准确，不等于方向已经确定。

第二类是授权与对外输出。

公开发布、发送客户消息、提交审批、付款，以及代表企业作出承诺，都需要明确的权限来源。

这里最容易混淆的是“内容已经做好”与“动作已经获准”。文案完成，只能说明产物到达了一个阶段；它不会自动产生发布权限。

授权可以在任务开始时明确，也可以在规定节点取得。重点是写清对象、范围和条件，让执行者知道自己能够做到哪一步。

第三类是异常处理。

当输入缺失、规则冲突、外部系统失败，或者出现流程没有定义的新情况时，AI应说明已完成的工作、当前问题和需要补充的决定。

例如产品资料中出现两个不同规格，系统不能为了赶进度自行选一个。又如提交结果没有明确返回，也不能直接当作失败再提交一次。

异常节点的价值，是让不确定性及时暴露，并把问题交给有权处理的人。

第一条路径：用工单承载真人节点

工单驱动型SOP编排，把一次任务的资料、节点和状态放在显式工单里。飞书多维表格等系统可以承担这一角色，但并非唯一选择。

在假设的上新流程里，一条工单可以关联产品资料、当前阶段、负责人、待审核方案、审核意见和下一步动作。

AI完成选品建议后，把结果回填到对应工单，流程进入待定品状态。负责人查看建议，作出决定，工单再根据预先定义的规则流转。

到了详情页审核，负责人面对的应当是本次实例对应的明确版本。通过以后，系统检查后续条件；退回以后，记录原因与目标节点，再交给执行者修改。

这条路径的优势，是流程容易被业务人员看见。

谁在处理，卡在哪一步，还缺什么材料，管理者可以通过工单和视图了解。多人共同参与时，工单也是一个共享的任务入口，不必让每个人进入同一段Agent对话。

但有了表格，并不意味着流程就已经设计完成。

如果字段里只有“进行中”和“已完成”，就无法区分等待审核、等待补料、执行失败和主动终止。不同问题被挤在同一个状态里，后面仍然需要人靠口头解释接续。

审核按钮也一样。按钮背后需要有明确含义：它批准哪个对象，检查什么权限，触发哪一步。只有界面，没有流转规则，仍然无法保证执行一致。

因此，工单路径的重点，是让字段、状态、负责人和流转条件共同承载业务规则。

第二条路径：由主控Agent推进流程，在规定节点等人

Agent原生SOP编排，把流程定义放进Skill，由主控Agent推进具体任务，并使用文件或其他受控载体记录实例状态。

这里有三个不同职责。

Skill定义这类任务怎样运行，包括输入要求、节点顺序、审核条件、异常规则和交付标准。

主控Agent负责这一次任务怎样推进：读取当前状态，执行或调度节点，接收结果，判断下一步，遇到真人节点时发起交互。

实例状态记录这一次任务已经发生了什么，包括产物、版本、审核结论、阻塞原因和恢复位置。

在T0015讨论的设计路径中，可以由主控Codex Agent承担运行时角色；具体执行能力仍取决于实际环境和授权。本文讨论的是流程架构，不是安装一个Skill即可自动获得的完整系统。

用这条路径设计上新流程，主控在收到详情页方案后，应先检查是否满足提交审核的条件。条件满足，再向负责人提出具体问题，并把实例置于等待真人的状态。

收到回复后，先把决定与对应版本记录下来，再推进、退回或终止。

如果中途会话中断，恢复时应读取实例记录，确认当前节点和最近事件。不能仅凭聊天中出现过“继续”二字，就猜测从哪里开始。

这条路径适合产物主要以文件形式存在、流程需要根据输入动态选择分支、希望减少外围工单依赖的场景。

但减少外围工单，并不会减少状态管理的责任。原先由工单展示的进度、审核与异常，仍然需要可靠的载体。

“SOP-as-a-Skill”是梁老师方法体系中的名称，并非OpenAI官方产品名称。理解它时，应始终把流程定义、运行时推进和状态记录放在一起看。

两条路径怎么选，先看协作条件

如果多个部门共同参与，负责人需要随时查看任务，业务人员也要直接补料、审核和维护状态，工单路径通常更容易建立共同的操作入口。

如果主要任务围绕文件展开，执行以Agent为主，流程分支需要根据当前资料判断，Agent原生路径值得考虑。

两条路径也可以组合使用。

例如，工单承担任务入口、进度展示和真人审核；主控Agent负责内部资料整理与文件生产。完成内部节点后，再把结果交回工单。

组合时，必须讲清谁负责推进哪一段。

同一个流程实例在同一时刻，应有明确的运行时主控。否则工单规则和Agent都认为自己应该推进下一步，就可能出现重复执行，或者一边退回、一边继续。

选择技术路径，可以围绕几个具体条件判断：有多少人参与，谁需要看进度，产物放在哪里，分支是否经常变化，现有系统能承担什么。

这些条件，比工具名称更接近企业真正需要作出的选择。

真正考验流程的，是退回、超时和中断

正常情况下，AI交付、真人通过、系统继续，流程看起来很顺。但可靠性往往要在“不顺”的时候验证。

先看退回。

负责人回复“重做”，只是表达了不满意，还没有给出可执行的恢复条件。系统需要知道退回原因、目标节点、修改要求，以及哪些已完成结果仍然有效。

假设主图中的表达不符合品牌要求，退回可能只涉及视觉与文案。如果退回原因是产品定位改变，就需要回到更上游的判断。两者不能使用同一套重跑方式。

再看超时。

真人长时间未处理，流程可以按事先规定继续等待、提醒、升级给指定负责人，或者暂停终止。不同业务可以选择不同处理方式。

但等待时间本身，不会变成授权。负责人没有回复，不能被解释为同意发布或付款。

超时处理需要同时回答：等到什么时候，谁负责处理，已有产物如何保留，之后怎样恢复。这样，等待才不会变成一个无人解释的黑洞。

再看重复执行。

假设一个提交动作已经到达外部系统，但本地没有收到明确结果。此时如果直接重试，可能产生重复记录或重复发布。

因此，恢复前需要检查节点是否已经完成，核对已有结果，再决定是否执行。技术上常把防止重复执行的能力称为幂等；放到业务里理解，就是同一件事不能因为重开流程而做两遍。

最后看异常说明。

一份有用的异常反馈，应讲清已经完成什么、停在哪里、为什么停、缺少什么、满足什么条件后能够继续。单独说“失败了”，不足以支持后续处理。

这些设计会增加前期工作，但也让流程在出错时有明确去向，减少每次都靠人从头排查。

从一个真人节点开始验证

企业不必一开始就重建整个流程。可以先选一个已经存在的审核环节，把它写清楚。

例如只处理“详情页方案审核”：确定审核对象与版本，明确负责人和批准范围，规定通过、退回、补料、终止四种结果，写出各自返回哪里。

然后用不同情况验证它。

正常通过时，是否进入正确节点？退回时，是否保留有效产物？资料不全时，是否停下补料？真人未回复时，是否遵守等待规则？中断恢复时，是否能够确认当前版本和已经完成的动作？

验证的重点，是每一种结果都有明确去向。跑通一次正常流程，只能证明那一次正常路径成立，不能直接证明异常恢复已经可靠。

对于老板，值得关注的是：谁作判断、谁承担责任、授权范围是否清楚。对于AI负责人，值得关注的是：资料、状态、版本、返回值和恢复规则是否落实。

两者对齐以后，再逐步扩大自动化范围。

保留真人，是为了让人的判断进入明确节点，让AI稳定承担边界清楚的执行工作。

让每一次人工决定都有对象、有范围、有记录，也有能够继续运行的下一步。这是老梁AI电商对企业人机协作的基本判断。

老梁AI电商，专注帮电商企业建立可落地的 AI 能力体系——从 AI 内容生产到私有知识库、岗位 Agent。