闭环三：质量与异常

对象与动词：先保护，后追责

前两课的闭环都发生在生产开始之前，这一课看生产开始之后。这个闭环的决定是：检验失败之后，要不要停线？对象是 inspection、defect、workOrder，关系是 workOrderInspections 和 inspectionDefects。为了判断严重度，给 inspection 加两个小属性：sampleSize 和 failedQty，都是整数。

缺陷是单独的对象类型，不是检验的属性：一次检验可以发现好几个缺陷，缺陷有自己的状态和关闭时间。塞进检验里，就只能记一条，也没法单独跟踪关闭。severity 用值类型限定为 minor、major、critical，写入时就会校验。

暂停工单是这个闭环里风险最大的动作，所以条件写得最严：

{
  "kind": "actionType",
  "apiName": "hold-work-order",
  "title": "暂停工单",
  "schema": {
    "parameters": [
      { "name": "workOrder", "type": "object", "objectType": "workOrder", "required": true },
      { "name": "reason", "type": "string", "required": true, "maxLength": 300 }
    ],
    "rules": [
      { "type": "modifyObject", "objectType": "workOrder", "object": "$workOrder", "values": { "status": "paused" } }
    ],
    "submissionCriteria": [
      { "condition": { "type": "comparison", "left": { "param": "workOrder", "property": "status" }, "operator": "isIncludedIn", "right": { "literal": ["released", "running"] } },
        "failureMessage": "只有已下达或生产中的工单可以暂停" }
    ],
    "summary": "{workOrder} 暂停：{reason}",
    "actionLog": true
  }
}

自动到哪一步

自动化只做两类事：记录事实，和先保护起来。停线可以恢复，漏检的产品发出去不能撤回，所以宁可多停一次。判断权仍然留给人：

严重度先由规则给一个底线：不合格率（failedQty 除以 sampleSize）超过 5% 至少记为 major，这个数是示例，按你的工艺定。AI 分析步骤再读检验备注，只许往上调，不许往下调。这样模型判断得再乐观，也不会把规则挡下的停线放掉。

自主程度是「自动」，但只用在可逆的动作上。人的两道关口是关闭缺陷和恢复工单。

运行时发生什么

"trigger": {
  "change": {
    "type": "inspection",
    "when": "=object.result == 'fail'",
    "cooldown": "30m",
    "input": { "inspection_id": "=object.inspectionId" }
  }
}

每次失败的检验是一个独立对象，冷却 30 分钟，只是防止它后来被编辑时再跑一遍。通知步骤不引用写回步骤的输出，两者互不依赖，内容只写事实：哪次检验、失败几件、严重度几级，不写「已经暂停」。暂停是否成功，以工单的状态为准。

智能体读检验与工单、判断严重度、起草通知。工作流以提供方应用的成员角色写入，所以 flag-defect 与 hold-work-order 的 roles 要包含 member。close-defect 收窄到 developer 与 editor，并加提交条件：authorKind 等于 human。角色本身不能区分人和智能体。受限 Key 可执行获授权且列入限制范围的 Action；普通只读 Key 仍不能写入。

复盘与上线前的验证

每周复盘一次，问三个问题：哪个缺陷代码最多？哪条产线最多？哪些缺陷超过 24 小时没关？第一个直接用聚合数：

aidc semantic aggregate defect --select '{"$count":"unordered"}' --group-by '{"code":"exact"}'
aidc semantic aggregate inspection --select '{"$count":"unordered"}' --where '{"result":"fail"}'
aidc semantic apply hold-work-order --param workOrder=WO-2609-031 --param reason="检验失败" --validate-only

第二个问题要沿关系从产线走到缺陷（对象集的 searchAround），再聚合。第三个问的是时间，不是数据变化，所以放进每天早上的提醒（自动化⑤）里一并汇总，不另开工作流。

复盘的结论有两个出口：缺属性、缺同义词这类只做加法的改进，可以走自进化，自动发新的语义版本；改类型、删属性这类破坏性改动，走分支和提案，由人确认。

1. 只校验

   对一张已完成的工单暂停，应当失败并给出提交条件的那句话，退出码是 2。

2. 预演三种严重度

   取三次历史失败检验，分别应得到 minor、major、critical，只有后两种的预演计划里有暂停。

3. 量一量

   数过去 30 天每天失败的检验数，对照每天 20 条通知的缺省上限。