演示 AI 工作流很容易，但真正完成它却很难。快乐路径看起来令人信服，而重试却可能重复产生副作用、跳过审批，或在没有证据的情况下报告完成。

本教程将一个工作流想法转化为一个小合同和六项验收测试。这些示例刻意与模型无关：它们既适用于 OCR 审核流程、支持工单代理，也适用于 API 自动化或研究助手。

从可观测的合同开始

在选择工具之前，请先写下五个字段：

  1. 工作流名称 — 一个有边界的流程，而不是整个部门。
  2. 期望结果 — 运行成功时必须能观察到的状态。
  3. 人工审批点 — 由人控制的、确切的不可逆或外部操作。
  4. 副作用 — 工作流可能创建的记录、消息、支付或系统变更。
  5. 证据引用 — 证明发生了什么的工件。

一个有用的完成规则是：

complete = outcome observed
        AND evidence reference exists
        AND required approval is granted
        AND duplicate side effects = 0

Enter fullscreen mode Exit fullscreen mode

这比“模型返回了答案”更严格。它让周边的自动化变得可测试。

测试 1：快乐路径

提供一个代表性输入，并断言预期的结果、证据引用、审批状态和副作用数量。自然语言的质量声明是不够的；结果需要机器可读的证据。

测试 2：格式错误输入

移除一个必填字段或提供无效类型。工作流应在调用模型或创建副作用前拒绝该输入。失败必须对操作员可见。

测试 3：重复事件

交付同一事件两次。第二次交付应返回已有结果或执行安全的空操作。如果可以创建两条通知、工单或支付，则该工作流不具备重试安全性。

测试 4：依赖失败

模拟超时或下游 5xx 响应。运行应记录依赖失败、保留其证据，并按固定策略停止或重试。静默回退不算通过。

测试 5：缺失审批

移除必要的人工决策。工作流必须在执行外部或不可逆操作前停止。“建议审批”弱于强制门控。

测试 6：证据缺失

在没有工件或证据引用的情况下返回成功状态。验证器应拒绝完成。这可防止仅靠绿色仪表板作为工作已完成的唯一证明。

本地浏览器实现

Acceptance Workbench 提供可编辑的合同、确定性的四文件 ZIP 导出，以及 JSON/NDJSON 运行日志验证器。它无需登录、上传、跟踪脚本、客户数据或模型调用。源代码与已验证的 Starter 均为公开。

该浏览器工具刻意保持轻量。它并不声称验证模型准确性、安全性或合规性。它的作用是在实施成本变得高昂之前，将模糊的工作流语言转化为可观测的通过/失败条件。

运行日志示例结构 

{
  "runId": "run_001",
  "status": "success",
  "outcomeEvidence": "ticket_1842 routed to escalation_queue",
  "validations": {
    "malformedInputRejected": true,
    "dependencyFailureRecorded": true
  },
  "metrics": { "duplicateSideEffects": 0 },
  "approval": { "required": true, "granted": true },
  "artifacts": ["audit_ticket_1842.json"],
  "evidenceRef": "evidence/run_001.json"
}

Enter fullscreen mode Exit fullscreen mode

重要的不是精确的字段名，而是每项验收测试都能指向可观测的证据，而非乐观的完成消息。

免责声明：本文草稿借助 AI 协助完成。它为未发布状态，需账户所有者审核后方可对外发布。