# G04 定制工单处理

2026-10-13 · 业务基线 0.15 · 图集文字 0.18。主图文字已加入 AI 验收；失败达到 x 次才转人工。x 未定。投影用 SVG 尚未重绘。执行器、Git 服务及实现参数尚未选择。

**一个工单固定一次改动需求，自动或人工执行后直接更新运行版本；人工模式增加金额确认。**

![定制工单主流程](G04-定制工单处理.svg)

```mermaid
sequenceDiagram
    participant customer as 客户
    participant ticket as 平台工单
    participant ai as AI 执行能力
    participant human as 人工团队
    participant publish as 发布与运行核验
    customer->>ticket: 单项目提交文字与附件，选择自动或人工
    ticket->>ticket: 固定需求修订；核对执行基准、权限及费用条件
    alt 自动模式
        ticket->>ai: 执行需求分析与开发；每次真实 AI 调用均计消耗
        ai->>ai: AI 验收；未通过则修改后再验收
        alt 验收通过
            ai-->>ticket: 合格改动成果
        else 验收失败达到 x 次
            ai-->>ticket: 此时才转原工单人工模式，保留需求、成果和消耗
        end
    end
    opt 人工模式，包括由自动模式转入
        ticket->>human: 内部评估并设置本次人工服务金额
        human-->>ticket: 提交报价
        ticket-->>customer: 系统提示金额：同意 / 拒绝
        alt 同意且满足消费条件
            customer->>ticket: 确认报价
            ticket->>human: 执行开发与验证；真实 AI 辅助同样计消耗
            human-->>ticket: 合格改动成果 / 失败原因
        else 拒绝或未满足消费条件
            ticket-->>customer: 拒绝则停止改动；缺少消费条件则等待，不停已有服务
        end
    end
    opt 已产生合格成果且允许发布
        ticket->>publish: 发布涉及的 APP 版本，核验实际运行
        publish-->>ticket: 实际发布 / 健康 / 恢复结果
        ticket-->>customer: 成功摘要、版本和预览地址；或失败原因与下一步
    end
```

2026-10-13 会上补充：自动路径里，转人工之前先做 AI 验收。验收失败未达到 x 次时继续修改并再次验收；达到 x 次才转入原工单人工模式。x 的具体次数未定。这里的 AI 验收不是客户逐次验收后才允许上线。

自动开发失败未产生合格成果时，也必须在工单写入失败回执；详见下面的异常图。验收失败次数用尽后走转人工，不把未达次数的一次失败直接当成已经转人工。

## 失败、恢复与再试

![失败与恢复](G04-失败与恢复.svg)

```mermaid
flowchart LR
    attempt["执行一次工单尝试
固定需求修订与执行基准"]
    conditions{"满足执行条件？"}
    waiting["等待资源 / 用量 / 充值
停止新调用，保留任务；已有年付服务继续"]
    work["开发与内部检查
有限修复；到次数或预算上限停止"]
    checked{"内部检查通过？"}
    unchanged["发布前失败
保留原运行版本"]
    deploy["发布涉及的 APP 组合"]
    healthy{"实际运行健康？"}
    success["成功回执
改动摘要、版本、预览地址"]
    recover["新版无法运行
恢复此前有效版本并核验"]
    restored{"恢复成功？"}
    failure["失败回执
原因、当前有效版本、重试 / 人工入口"]
    intervention["恢复异常：人工接管
如实显示服务故障"]
    retry["同范围：新增需求修订与尝试
旧尝试结束后重试；不覆盖原件"]
    attempt --> conditions
    conditions -->|"否"| waiting
    waiting -->|"条件补足后"| attempt
    conditions -->|"是"| work --> checked
    checked -->|"否"| unchanged --> failure
    checked -->|"是"| deploy --> healthy
    healthy -->|"是"| success
    healthy -->|"否"| recover --> restored
    restored -->|"是"| failure
    restored -->|"否"| intervention
    failure -->|"客户选择再次尝试"| retry --> attempt
```

必须保留的规则：

- 项目创建后可提交工单，实际执行要等必要应用/基准与消费条件满足。还没初始版本时，不能虚构“修改前版本”。
- 一个工单只涉及一个项目，但可修改多个 APP。跨项目分别提交；多个 APP 发布不天然原子完成，部分失败的恢复策略由技术设计落实。
- 客服/TG 负责沟通、协商及反馈。工单保存需求原件、追加修订、尝试、系统回执和工程关联；新增业务范围或方向另开工单。
- 所有实际项目 AI 调用，包括分析、失败、修复、转人工及人工辅助，都先消耗套餐内含 AI 用量，超额扣真实积分。回退不撤销真实消耗；同一调用不得重复计费。见 [G05](G05-收费与权益.md)。
- 平台工单为业务主记录，Git Issue/PR/提交是工程关联。引擎返回成功、Issue 关闭或代码提交不等于线上健康。
- 默认代码回退保留业务数据并检查兼容性。涉及数据库/文件数据恢复时使用保护检查点并提示丢失新增数据风险，不把每次普通改动都画成整库回滚；实现与保留参数待技术评审。

依据：[02 工单流程](../02-业务流程与产品需求.md)、[03 发布与恢复](../03-系统架构与领域模型.md)、[04 工作流草案](../04-模板与AI工作流.md)、[05 消耗规则](../05-商业模式与成本指标.md)。[返回图集](README.md)。