AI 说“已经完成”，怎样确认它真的做了？

AI 生成的概念插图，内容为假设示例。

假设你让 AI 把一份报告保存到团队文档，再通知相关负责人。几分钟后，它回复：“已经完成。”

你打开文档，发现只有标题和一段开头；再去看通知，指定频道里没有消息。助手并没有编造——它调用的每一步都收到了响应，只是“已经完成”描述的是它的调用过程，而不是你想要的结果。

任务越依赖多个系统，这句话就越容易出现偏差。真正需要回答的问题只有一个：任务要求的结果，现在是否真的存在于它该在的地方？

把“完成”写成可以检查的结果

“整理报告并通知团队”适合作为任务概述，却无法用来验收。可以把它展开成一组能在目标系统中核对的条件。

以一份每周竞品报告为例：

任务要求	完成条件（可在哪里检查）
整理报告	覆盖指定周期，保留来源链接，标明缺失资料
保存文档	位于指定工作区和父页面，正文与最终稿一致
通知团队	出现在指定频道，消息里的链接指向上面这篇文档
交付结果	返回文档位置、通知记录，以及未完成或未核验的事项

写完成条件时，尽量落到“谁能在哪里看到它”。如果只要求保存草稿，就不必通知团队；如果要求同事能读到，还要检查目标成员的访问权限——助手自己的账号能打开文档，不代表所有接收人都能打开。

“已经发出”和“对方已经阅读”也要分开。频道中出现一条消息，可以支持“已发布”的判断；没有阅读或确认记录时，就无法继续推断对方已经看到并跟进。

三类证据回答不同的问题

核验时有三种材料，各自只能回答一部分问题。

工具返回        这次调用得到了什么响应？
                    状态、错误、返回的对象标识
                          │
目标记录        结果落在哪里？是否读得回来？
                    目标应用中的文档、消息、记录
                          │
内容检查        产物是否符合要求？
                    对照完成条件检查正文、来源、缺失项

工具返回说明这次调用发生了什么。响应里的状态字段、错误信息和返回对象由被调用的服务决定，具体含义要看该工具与目标 API 的约定。返回了文档标识，可以据此去找这份文档；仅凭标识，还无法判断正文是否完整。

目标记录说明结果是否真的落在系统里。用返回的标识重新读取文档，或打开目标应用中的对应记录，核对账号、工作区、父页面和内容。核对通知时也要看频道与消息本身，不要按相似的标题搜索后就认定找到了本次结果。

内容检查说明产物能不能交付。文档存在，仍可能漏掉一节；报告带了来源链接，也可能引用了错误周期的数据。这一步必须回到最初的完成条件，逐项对照，而不是只看“有没有创建成功”。

三类证据可以合并成一份简短回执：做了什么，结果在哪里，检查过什么，还有什么不确定。它不需要把整段运行日志贴给用户。

部分成功需要单独报告

多步骤任务可能只完成了一部分：前一步已经落地，后一步仍没有结论。

下面是一组用于说明处理方式的假设记录，不是实际调用日志：

步骤	观察到的结果	当前判断
保存文档	返回文档标识，重新读取后正文完整、位置正确	已保存并核验
发送通知	请求超时，没有取得消息标识	结果未知
查询目标频道	当前账号没有读取消息的权限	无法通过此账号确认

这时助手应该回报“文档已保存，通知结果未确认”，附上文档链接和阻塞原因。

超时只说明调用方没有在预期时间内收到响应。通知可能没有发出，也可能已经写入目标系统而响应丢失。因此直接重跑整个任务，既可能创建第二份文档，也可能重复通知。

后续处理应从结果未知的那一步开始。若账号有读取权限，就按目标频道、发送时间和报告链接检查消息；若存在与本次任务对应的记录，核对内容后补齐回执。查询没有结果时，还要考虑查询范围、权限和数据可见延迟，不能立刻把“没查到”写成“没有发送”。

确实取不到证据时，请有权限的人检查目标频道，并暂缓再次发送。确认需要补发之后，才继续通知步骤，并复用已经核验的文档。

回执要保留“未确认”

一份可用的回执可以写成这样。方括号中的内容由实际结果填写；取不到时明确说明，不要生成一个看起来合理的链接。

任务：保存本周竞品报告并通知指定频道

文档：已保存并核验
位置：[实际文档链接或记录标识]
已检查：目标工作区、父页面、正文、来源链接

通知：结果未确认
原因：发送请求超时；当前账号无法读取目标频道消息
处理：已暂停补发，避免重复通知

需要你确认：目标频道是否已出现包含上述文档链接的消息

不要把“失败”“未执行”和“结果未知”压成同一种状态，它们对应不同的处理方式。工具明确报告拒绝访问，通常要检查账号与权限；任务根本没有执行到该步骤，需要决定是否继续；发送结果未知，则应先查记录。错误原因没有变化时，反复提交同一个请求通常不会改变结果。

对于长期自动运行的流程，还要保存每一步的结果标识和核验状态。给任务加一个编号便于关联记录，但编号本身不会阻止重复写入；能否安全重试，取决于目标 API 是否支持幂等，以及流程是否真的执行了去重检查。

在 OOMOL 中，执行记录能覆盖到哪一步

连接层能提供调用能力和调用记录，验收判断仍要由任务自己给出。

OOMOL 的权限控制按 connection 配置可调用的操作。设计任务时值得留意两点：一是要同时考虑核验所需的读取能力，允许创建文档并不自动意味着助手能读回相关记录；二是即使权限允许调用某个操作，在发送消息、修改外部数据、扩大共享范围或删除内容之前，仍应确认目标 connection、操作和最终参数。

自部署 OpenConnector时，最近的运行记录包含脱敏后的输入摘要和 provider 错误，可以用 OOMOL_CONNECT_ALLOWED_ACTIONS 与 OOMOL_CONNECT_BLOCKED_ACTIONS 限制可执行的操作。助手只能看到 schema、scope、执行状态和安全账号标签。这些记录适合排查调用失败，但它们描述的是调用，不是业务目标是否达成。自部署指南

如果任务需要等待人工审批，Open Flow 的 Approval 和 Wait 节点会持久化等待状态，确认后可以继续同一次运行，不必重跑已经完成的步骤。运行历史关联对应的流程版本，便于查清某份结果由哪一版逻辑生成。托管版 · 源码与自部署

完成条件、步骤状态、重试决定和最终回执，需要由助手指令、业务代码或工作流落实。连接层给出调用路径和记录，不替你判断整项任务是否通过验收。

从一项可以验收的任务开始

先选一步写入，不要一上来就串起整条链路。在 OOMOL Connections 配置任务需要的连接，核对可用操作，再把下面这段要求交给助手：

把这份已确认的报告保存到我指定的测试文档位置。保存后重新读取，检查正文与原稿是否一致，并返回实际文档链接。先不要通知其他人。如果无法读取或核验，请说明已执行的步骤、返回的记录标识和缺少的条件，不要将任务标为全部完成。

等保存与核验能稳定完成，再加入通知，并要求返回对应的消息记录。每增加一个写入步骤，就为它补上一项能在目标系统中检查的完成条件。

验收的关键不在于助手最后说了什么，而在于你能否沿着它给出的位置，在目标系统里找到那个结果。当每个写入步骤都对应一项可以检查的条件，那份“已经完成”才有依据。