构建可验证的 AI 工作流

很多 AI 应用把“模型返回了内容”当成任务完成。这样的系统在样例里通常表现不错，进入生产后却很难解释：输入是否完整、工具是否真的执行、引用是否支持结论、失败发生在哪一步？可验证的工作流需要把一次模糊的生成任务拆成一组有输入、有输出、有约束的步骤。

先定义什么叫完成

不要从提示词开始，而要先写验收条件。“生成一份报告”不是可验证目标；“报告包含三个指定指标，每个数字都能追溯到查询结果，缺失数据明确标注”才是。

验收条件应尽量由程序、规则或第二数据源判断，避免让同一个模型既作答又给自己打分。对高影响结论，还需要把证据充分性与表达质量分开检查。

• 结构——输出必须具备哪些字段、格式和必填项。
• 证据——哪些事实必须带来源或原始记录。
• 权限——哪些条件触发人工确认，哪些错误必须中止。

把流程写成状态机

长提示会把检索、判断、生成和执行混在一起，任一环节出错都难以定位。更稳妥的方式是将工作流设计成状态机：接收任务、补全上下文、调用工具、验证结果、生成交付物、等待确认。

每次状态转换都记录输入、输出、理由与时间。模型只能选择允许的下一状态，不能跳过验证直接执行高风险操作；重试也必须复用可识别的输入并留下次数与原因。

• 单一职责——每个步骤只解决一种问题。
• 稳定接口——中间结果用明确的数据结构传递。
• 确认点——外部写入、发送与删除前要求显式授权。

用分层验证降低错误成本

验证不必全部交给更大的模型。格式可以用 Schema 检查，计算可以用代码复算，引用可以检查链接与原文片段，业务约束可以用规则判断。只有语义一致性、证据是否充分等问题，才需要模型评审。

先运行便宜、确定的检查，再运行昂贵、带概率的检查，可以更早暴露问题，也能给线上故障提供明确分类，而不是把所有失败都记为“模型质量不好”。

• 结构层——字段、类型、长度和必填项。
• 事实层——数字、时间、实体与引用的对应关系。
• 逻辑层——结论是否由证据推出。
• 行动层——目标、权限和影响范围是否一致。

让失败可以重放

线上问题最难处理的情况，是只留下最终答案而没有过程。至少应保存模型版本、提示模板版本、工具参数、工具返回、验证结果和最终选择。对于敏感数据，可以保存脱敏后的结构与受控访问引用。

重放不是简单地再次调用模型，而是在固定上下文下逐步执行，比较变化从哪里开始。这样才能区分数据变化、模型波动和代码缺陷，并把真实失败样本沉淀进回归测试集。

• 发布门禁——正常、缺失、冲突和越权样本全部通过。
• 运行记录——足以还原一次工具调用与验证链路。
• 回归闭环——每次线上失败都能转化为新的测试样本。

没有留下证据的正确答案，只是一次暂时没有暴露问题的猜测。