Files
ai-web-delivery-doc/diagrams/G04-定制工单处理.md
T
mdszxy 638d3541bf 建立可移交的 AI 软件交付规划文档仓库。
纳入截至 2026-10-13 会议回写后的产品基线与会议图源。
2026-10-13 22:27:58 +08:00

5.3 KiB

G04 定制工单处理

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

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

定制工单主流程

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 验收不是客户逐次验收后才允许上线。

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

失败、恢复与再试

失败与恢复

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。
  • 平台工单为业务主记录,Git Issue/PR/提交是工程关联。引擎返回成功、Issue 关闭或代码提交不等于线上健康。
  • 默认代码回退保留业务数据并检查兼容性。涉及数据库/文件数据恢复时使用保护检查点并提示丢失新增数据风险,不把每次普通改动都画成整库回滚;实现与保留参数待技术评审。

依据:02 工单流程、03 发布与恢复、04 工作流草案、05 消耗规则。返回图集。