建立可移交的 AI 软件交付规划文档仓库。
纳入截至 2026-10-13 会议回写后的产品基线与会议图源。
This commit is contained in:
mdszxy committed
commit
638d3541bf
55 files changed
+3484
No files matched your search
@@ -0,0 +1,101 @@
|
||||
# G04 定制工单处理
|
||||
|
||||
2026-10-13 · 业务基线 0.15 · 图集文字 0.18。主图文字已加入 AI 验收；失败达到 x 次才转人工。x 未定。投影用 SVG 尚未重绘。执行器、Git 服务及实现参数尚未选择。
|
||||
|
||||
**一个工单固定一次改动需求，自动或人工执行后直接更新运行版本；人工模式增加金额确认。**
|
||||
|
||||
|
||||
|
||||
```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 验收不是客户逐次验收后才允许上线。
|
||||
|
||||
自动开发失败未产生合格成果时，也必须在工单写入失败回执；详见下面的异常图。验收失败次数用尽后走转人工，不把未达次数的一次失败直接当成已经转人工。
|
||||
|
||||
## 失败、恢复与再试
|
||||
|
||||
|
||||
|
||||
```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)。
|
||||
Reference in new issue
Block a user