定义任务边界与成功证据

“AI回答成功”不等于业务任务完成。它可能解释了一项政策、生成了草稿、请求了操作，或者真正改变了后台状态。这些结果承担不同责任。本章确定任务边界、合理终态及每种终态的证据，让设计、评测和运营使用同一把尺。

从用户诉求拆出结果层次

客户说“卡没收到”。如果后台仍在配送，解释查询结果可能完成这次服务；如果需要补卡，创建请求只是业务处理中间结果；数据失败时，带上下文转人工也可能是正确终态。Nubank论文支持这些能力与接续路径，但未公开一套可原样部署的完整状态机。下面契约是教学设计。

“合理转人工”可在服务质量上合格，却不会计为无需人工的自动解决。评测任务标准和业务指标分母必须各自明确，不能为了提高自动化率把所有终态视为自动完成。

把契约写到可检查的粒度

合成商品建档任务的输入包含文件ID、供应商与SKU、类目候选及调用者作用域。结果是待审核草稿，禁止自动发布。字段至少带值、来源位置和状态：supported、missing、conflict。这些状态不是模型自报置信度；审核者可以沿来源验证。

{
  "task_id": "CAT-017",
  "outcome": "draft_created",
  "draft_id": "DR-017",
  "fields": {
    "material": {"value": "PP", "source": "file-A:p2", "status": "supported"},
    "net_weight_g": {"value": null, "source": ["file-A:p2", "file-B:p1"], "status": "conflict"}
  },
  "pending": ["确认净重：两份材料分别为120g与150g"],
  "published": false
}

以上是CAT-017冲突任务的完成结果摘要，省略了部分字段，不是可直接传给运行包的完整proposal Schema。这里草稿可用，不意味着所有字段齐全。若商品系统允许缺项草稿，创建草稿并标冲突就是预期行为；若该类目连草稿都要求净重，任务应停在待补资料。条件来自实际系统和业务约束，不能由模型补全。

写入返回超时尤其重要：请求可能已创建，但调用者未收到确认。此时本轮判定为unknown，这是待调查的暂停结果，不是业务终结；工作状态进入write_unknown，按业务键查询或交接调查。不能直接换键重试并宣告失败，也不能猜测成功。后续工具章节应落实幂等与对账机制，本章先规定什么证据足以改变判定。

工业维护需要另一种完成语义。IBM Condition Insight把证据不足作为有效结果，建议仍由维护人员接续。迁移时可将任务定义为“向维修工程师交付可核对的状态说明和检查建议”，输入包括资产、读数、工单和规则版本；禁止由此直接控制设备。建议已交付不等于诊断正确，更不等于维护完成。安全负责人应先定义不可接受错误与允许动作，评测逐项核对观察依据和缺证据时的克制，而不能套商品草稿保存标准。

从相关候选到具备资格

工业采购又多一层：模型推荐“相似的泵”，不等于这台泵可用于现有管线。IndustryLLM将模型需求解释与具体产品资格分开：缺证书、缺工况或证据冲突不能由参数知识填平；硬要求按satisfied、violated、unknown判定，全部满足后才按价格等软偏好排序。报告v1 §2与表1

合成需求是“至少60 L/min、不要铸铁”。有效工况数据为3.6 m³/h可经过确定换算满足流量；文件显示铸铁则违反排除条件；营销文案只写“大流量”而无工况和材质证据，资格仍未知。不能用相似度高、价格低或模型信心抵消硬条件。显式负约束、单位、证据范围和有效时间都属于任务合同。

资格未知是证据不足；写入未知是动作回执不足，两者需要不同接续。合同应允许“指出缺哪项关键依据并请求补证”作为有效结果，而不是强迫每笔任务都推荐商品。若关键需求本身未明确，先问介质、温度或接口；不能先默认一个工业规格再验证自己设定的要求。详细合成结构和候选判定见规划与证据专题。

用三个输入暴露隐藏假设

正常样本：同一SKU资料一致，输出来源可查且创建草稿。歧义样本：两份文件的净重冲突，结果保留空值和差异。关键失败：写入超时，界面呈待确认，不生成第二份草稿。若团队对这三笔任务仍无法一致判定结果，先修任务定义；不要把争议交给LLM Judge“自动决定”。

评测需要分开检查字段正确、行为正确与最终状态。前两项通过，接口却未创建草稿，不能称为任务成功；后台创建成功，但系统掩盖关键冲突，也不能通过质量验收。最危险失败应单列，避免被平均分淹没。

Nubank公开地址Judge的变化说明为什么适用条件属于标准的一部分：先判断是否需要补卡和实际配送；同地址明确确认可满足要求，只有新地址或变更地址才需对应收集。若量尺要求所有对话都重新收集，就会惩罚正确行为。本章只借鉴这一机制；不把其地址评分用作商品发布标准。

契约怎样驱动后续工作

使用任务契约将上述结果交给流程、交互和工程设计：界面展示哪些状态，工具返回哪些证据，日志保存什么，人工接手还能知道什么。版本修改若改变任务终态或允许动作，也需要更新评测；只修改语气则无需重新定义后台成功。

本章完成时，两位业务与工程人员应能独立给同一正常、歧义和失败任务判定结果，并解释依据。判定不一致要回到条件或证据，不追求一个模糊的“综合分”。下一章明确谁拥有这些定义、谁维护依赖、谁承接例外。

把契约接到同一任务的上游观察与下游蓝图，可看商品任务产物接续。其中区分来源支持、供方确认、人的版本确认与任务终态；这些不是一个字段的同义写法。

参考资料

• Nubank v2，§3.4、§4.3、§5及附录A：任务结果、基础设施及条件性地址评价。
• IndustryLLM v1，§2与表1：需求与资格契约；组件成绩不证明端到端资格。
• 商品JSON与状态为合成教学设计。

继续使用

上一章：判断可行性与价值 · 下一章：组织协作与接续 · 五篇阅读目录。相关工具：任务契约。

对照案例：Nubank客服、IBM维护。