971 lines
16 KiB
Markdown
971 lines
16 KiB
Markdown
# 引入 AI 辅助后开发周期变化评估
|
||
|
||
## 一、整体说明
|
||
|
||
在原智能锁新实时系统方案基础上，如果引入类似 **AI 辅助开发 / 架构评审 / 代码生成 / 测试用例生成 / 运维脚本生成**，整体开发周期会明显缩短。
|
||
|
||
但需要注意：缩短主要发生在后端、协议设计、文档、测试脚本、运维配置、日志分析和问题排查等环节。
|
||
|
||
---
|
||
|
||
### 1.1 AI 很擅长的工作
|
||
|
||
AI 在以下工作上提速明显：
|
||
|
||
- 写代码
|
||
- 生成协议
|
||
- 生成文档
|
||
- 补充测试
|
||
- 查找 bug
|
||
- 生成配置
|
||
- 辅助重构
|
||
- 分析日志
|
||
|
||
---
|
||
|
||
### 1.2 AI 不擅长替代的工作
|
||
|
||
AI 很难直接替代以下工作：
|
||
|
||
- 真机调试
|
||
- 设备固件烧录
|
||
- 网络环境测试
|
||
- 音视频主观体验评估
|
||
- 硬件性能瓶颈排查
|
||
- 线上灰度观察
|
||
- 跨团队沟通
|
||
- 产品验收
|
||
|
||
---
|
||
|
||
### 1.3 难以大幅压缩的环节
|
||
|
||
因此，以下环节仍然难以大幅压缩：
|
||
|
||
- 设备端 WebRTC 移植
|
||
- APP 与设备真机联调
|
||
- 弱网测试
|
||
- 音视频质量调优
|
||
- BifroMQ / ZLMediaKit / TURN 的真实环境压测
|
||
- 线上灰度验证
|
||
|
||
---
|
||
|
||
## 二、整体结论
|
||
|
||
引入 GPT-5.5 辅助后，项目周期大致变化如下：
|
||
|
||
| 版本目标 | 原周期 | AI 辅助后周期 | 预计缩短 |
|
||
|---|---:|---:|---:|
|
||
| MVP 最小可用版本 | 8 - 12 周 | 5 - 8 周 | 缩短约 30% - 40% |
|
||
| 可灰度上线版本 | 12 - 16 周 | 8 - 12 周 | 缩短约 25% - 35% |
|
||
| 完整版本，含 AI、动态选路、完整可观测 | 16 - 24 周 | 12 - 18 周 | 缩短约 20% - 30% |
|
||
|
||
更现实的判断是：
|
||
|
||
> 有 GPT-5.5 帮助后，项目不是从 4 个月变成 1 个月，而是更可能从 4 个月压缩到 2.5 - 3 个月；从 6 个月压缩到 4 - 4.5 个月。
|
||
|
||
---
|
||
|
||
## 三、各模块开发周期变化
|
||
|
||
### 3.1 架构设计与协议设计
|
||
|
||
#### 原周期
|
||
|
||
**1 - 2 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**3 - 5 天**
|
||
|
||
#### 可提速内容
|
||
|
||
GPT-5.5 可以辅助生成：
|
||
|
||
- MQTT topic 规范
|
||
- signaling 消息协议
|
||
- 会话状态机设计
|
||
- ACK / retry / timeout 机制
|
||
- API 文档
|
||
- 数据表设计
|
||
- Redis key 设计
|
||
- 错误码规范
|
||
- Mermaid 架构图
|
||
- 时序图
|
||
- 测试用例矩阵
|
||
|
||
#### 缩短原因
|
||
|
||
这类工作主要是**脑力整理、文档建模、规范输出**，AI 辅助收益很大。
|
||
|
||
#### 仍需人工确认
|
||
|
||
- 业务边界
|
||
- 历史系统兼容性
|
||
- 设备能力真实性
|
||
- 团队技术栈选择
|
||
|
||
---
|
||
|
||
### 3.2 `session-orchestrator` 会话编排服务
|
||
|
||
#### 原周期
|
||
|
||
**4 - 8 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**3 - 5 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以帮助生成：
|
||
|
||
- Go / Java 服务基础框架
|
||
- 会话状态机代码
|
||
- API controller
|
||
- MQTT client 封装
|
||
- Redis 状态存储
|
||
- MySQL 表结构
|
||
- 幂等处理逻辑
|
||
- ACK / timeout / retry 框架
|
||
- 单元测试
|
||
- 集成测试
|
||
- OpenAPI 文档
|
||
- 日志和 trace 埋点模板
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 30% - 40%**
|
||
|
||
#### 不能完全替代的部分
|
||
|
||
- 状态机边界确认
|
||
- 复杂异常流验证
|
||
- 与 APP / 设备端实际联调
|
||
- 高并发压测
|
||
- 线上问题复盘
|
||
|
||
---
|
||
|
||
### 3.3 `device-bootstrap` 设备接入服务
|
||
|
||
#### 原周期
|
||
|
||
**2 - 4 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1.5 - 3 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以帮助生成：
|
||
|
||
- 设备认证 API
|
||
- HMAC 签名校验
|
||
- MQTT 短期凭证颁发逻辑
|
||
- topic ACL 模型
|
||
- capability schema
|
||
- 配置下发接口
|
||
- 设备接入文档
|
||
- Mock 设备脚本
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 25% - 35%**
|
||
|
||
#### 主要限制
|
||
|
||
- 设备端真实认证能力
|
||
- 设备固件兼容
|
||
- 密钥安全方案
|
||
- BifroMQ 自定义鉴权落地
|
||
|
||
---
|
||
|
||
### 3.4 BifroMQ 接入模块
|
||
|
||
#### 原周期
|
||
|
||
**2 - 4 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1.5 - 3 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- 设计 topic
|
||
- 设计 ACL
|
||
- 生成 MQTT 测试脚本
|
||
- 生成压测脚本
|
||
- 生成 Docker Compose / K8s 部署文件
|
||
- 生成设备模拟器
|
||
- 生成 APP 模拟 MQTT 客户端
|
||
- 编写监控告警配置
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 20% - 30%**
|
||
|
||
#### 主要限制
|
||
|
||
- BifroMQ 集群稳定性验证
|
||
- 长连接压测
|
||
- MQTT 消息顺序和重复投递验证
|
||
- ACL 插件或鉴权服务的真实适配
|
||
|
||
---
|
||
|
||
### 3.5 `starlock` 改造
|
||
|
||
#### 原周期
|
||
|
||
**2 - 4 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1.5 - 3 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- 梳理现有 PHP 代码
|
||
- 生成会话创建 API
|
||
- 生成权限校验逻辑模板
|
||
- 生成内部调用 SDK
|
||
- 生成事件回调接口
|
||
- 生成幂等处理逻辑
|
||
- 生成接口文档和测试用例
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 25% - 35%**
|
||
|
||
#### 主要限制
|
||
|
||
- 现有 `starlock` 代码质量
|
||
- 历史业务规则复杂度
|
||
- 多租户 / 家庭 / 设备归属关系的真实逻辑
|
||
- 旧系统兼容
|
||
|
||
---
|
||
|
||
### 3.6 `starcloud` 对接
|
||
|
||
#### 原周期
|
||
|
||
**1 - 3 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1 - 2 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- 梳理 `starcloud` 能力边界
|
||
- 生成内部 API 对接文档
|
||
- 生成权限校验调用逻辑
|
||
- 生成设备归属查询调用封装
|
||
- 生成套餐 / 风控 / 审计调用模板
|
||
- 生成接口测试用例
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 20% - 30%**
|
||
|
||
#### 主要限制
|
||
|
||
- `starcloud` 现有 API 完整度
|
||
- 共享能力和 `starlock` 租户定制能力的边界
|
||
- 历史数据模型兼容
|
||
- 跨团队接<E9989F><E68EA5><EFBFBD>协调
|
||
|
||
---
|
||
|
||
### 3.7 APP 端 `app-starlock` 改造
|
||
|
||
#### 原周期
|
||
|
||
**4 - 8 周**
|
||
|
||
#### AI 辅助<E8BE85><E58AA9><EFBFBD>
|
||
|
||
**3 - 6 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- Flutter MQTT 接入代码
|
||
- WebRTC 基础调用封装
|
||
- 会话 UI 状态机
|
||
- signaling 消息处理
|
||
- route switch 处理
|
||
- 质量上报逻辑
|
||
- 异常提示文案
|
||
- mock server
|
||
- 自动化测试用例
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 20% - 30%**
|
||
|
||
#### 主要限制
|
||
|
||
APP 端会受到真实环境限制：
|
||
|
||
- Android / iOS WebRTC 行为差异
|
||
- 后台保活
|
||
- 音频权限
|
||
- 蓝牙 / 扬声器 / 麦克风路由
|
||
- 移动网络切换
|
||
- 真机兼容性测试
|
||
|
||
所以 AI 能帮忙写代码，但**真机联调时间很难被大幅压缩**。
|
||
|
||
---
|
||
|
||
### 3.8 WiFi 网关锁 / 设备端改造
|
||
|
||
#### 原周期
|
||
|
||
**6 - 12 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**5 - 10 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- MQTT 协议解析代码
|
||
- signaling 消息结构
|
||
- 状态机代码
|
||
- 设备 capability schema
|
||
- HMAC 签名逻辑
|
||
- 日志模块
|
||
- C / C++ 代码审查
|
||
- 崩溃日志分析
|
||
- 设备模拟器
|
||
- 协议一致性测试
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 10% - 25%**
|
||
|
||
#### 为什么提速有限
|
||
|
||
设备端是最难被 AI 大幅压缩的部分，因为涉及：
|
||
|
||
- 芯片 SDK
|
||
- 编码器
|
||
- 摄像头
|
||
- 麦克风
|
||
- 硬件资源
|
||
- 固件 OTA
|
||
- 内存和 CPU 限制
|
||
- 真实网络环境
|
||
- WebRTC 移植
|
||
|
||
如果设备端已有成熟 WebRTC SDK，提速会明显一些。
|
||
如果设备端 WebRTC 从零移植，AI 帮助有限。
|
||
|
||
---
|
||
|
||
### 3.9 WebRTC / TURN / ZLMediaKit 媒体链路
|
||
|
||
#### 原周期
|
||
|
||
**4 - 8 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**3 - 6 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- WebRTC signaling 流程代码
|
||
- coturn 配置
|
||
- TURN 临时账号生成
|
||
- ZLMediaKit hook 接入
|
||
- ZLM 推流 / 拉流 API 封装
|
||
- ICE 失败重试逻辑
|
||
- 质量指标采集
|
||
- route switch 策略初版
|
||
- 弱网测试脚本
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 20% - 30%**
|
||
|
||
#### 主要限制
|
||
|
||
- 真实 NAT 环境
|
||
- P2P 成功率
|
||
- TURN 带宽
|
||
- ZLM 延迟
|
||
- 双向语音质量
|
||
- 弱网表现
|
||
- APP 与设备 codec 兼容
|
||
|
||
媒体链路不是“代码写完就完成”，更多时间花在**联调和调优**。
|
||
|
||
---
|
||
|
||
### 3.10 `MQTT event worker`
|
||
|
||
#### 原周期
|
||
|
||
**2 - 4 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1 - 2.5 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以生成：
|
||
|
||
- MQTT 消费代码
|
||
- 事件 schema
|
||
- 幂等逻辑
|
||
- 回调 `starlock` 代码
|
||
- 重试机制
|
||
- 死信队列
|
||
- 事件落库表
|
||
- 单测和压测脚本
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 35% - 45%**
|
||
|
||
这个模块比较适合 AI 辅助，因为逻辑清晰，边界明确。
|
||
|
||
---
|
||
|
||
### 3.11 `realtime-store` 与可观测性
|
||
|
||
#### 原周期
|
||
|
||
**1 - 3 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1 - 2 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助生成：
|
||
|
||
- MySQL 表结构
|
||
- Redis key 规范
|
||
- Prometheus 指标设计
|
||
- Grafana dashboard
|
||
- 日志字段规范
|
||
- OpenTelemetry 接入代码
|
||
- sessionId 链路追踪规范
|
||
- 告警规则
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 25% - 40%**
|
||
|
||
#### 注意事项
|
||
|
||
AI 能快速生成配置，但指标是否有用，需要靠真实联调不断修正。
|
||
|
||
---
|
||
|
||
### 3.12 AI 旁路模块 `ai-gateway`
|
||
|
||
#### 原周期
|
||
|
||
**2 - 4 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**1.5 - 3 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助：
|
||
|
||
- `ai-gateway` 服务框架
|
||
- WebSocket / streaming 转发
|
||
- 音频格式转换代码
|
||
- AI 会话状态机
|
||
- 回调 `starlock`
|
||
- 错误隔离机制
|
||
- 文档和测试脚本
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 20% - 35%**
|
||
|
||
#### 主要限制
|
||
|
||
- `xiaozhi_server` 接口稳定性
|
||
- 音频实时性
|
||
- 设备端音频旁路能力
|
||
- 隐私合规
|
||
- 与主通话资源竞争
|
||
|
||
---
|
||
|
||
### 3.13 运维部署模块
|
||
|
||
#### 原周期
|
||
|
||
**3 - 6 周**
|
||
|
||
#### AI 辅助后
|
||
|
||
**2 - 4 周**
|
||
|
||
#### 可提速内容
|
||
|
||
AI 可以辅助生成：
|
||
|
||
- Dockerfile
|
||
- Docker Compose
|
||
- Kubernetes YAML
|
||
- Helm Chart
|
||
- Nginx 配置
|
||
- coturn 配置
|
||
- ZLMediaKit 配置
|
||
- Prometheus 配置
|
||
- Grafana 面板
|
||
- CI/CD 脚本
|
||
- 部署文档
|
||
- 回滚方案
|
||
|
||
#### 缩短幅度
|
||
|
||
**约 25% - 40%**
|
||
|
||
#### 主要限制
|
||
|
||
- 真实公网网络环境
|
||
- 防火墙端口
|
||
- TURN UDP 端口开放
|
||
- 证书配置
|
||
- 带宽压测
|
||
- 生产环境权限和安全审查
|
||
|
||
---
|
||
|
||
## 四、按模块重新估算周期
|
||
|
||
| 模块 | 原周期 | AI 辅助后 | 缩短幅度 |
|
||
|---|---:|---:|---:|
|
||
| 架构细化 / 协议设计 | 1 - 2 周 | 3 - 5 天 | 40% - 60% |
|
||
| `starlock` 改造 | 2 - 4 周 | 1.5 - 3 周 | 25% - 35% |
|
||
| `starcloud` 对接 | 1 - 3 周 | 1 - 2 周 | 20% - 30% |
|
||
| `session-orchestrator` | 4 - 8 周 | 3 - 5 周 | 30% - 40% |
|
||
| `device-bootstrap` | 2 - 4 周 | 1.5 - 3 周 | 25% - 35% |
|
||
| BifroMQ 接入 | 2 - 4 周 | 1.5 - 3 周 | 20% - 30% |
|
||
| APP 改造 | 4 - 8 周 | 3 - 6 周 | 20% - 30% |
|
||
| 设备端改造 | 6 - 12 周 | 5 - 10 周 | 10% - 25% |
|
||
| WebRTC / TURN / ZLM | 4 - 8 周 | 3 - 6 周 | 20% - 30% |
|
||
| MQTT event worker | 2 - 4 周 | 1 - 2.5 周 | 35% - 45% |
|
||
| realtime-store / 可观测 | 1 - 3 周 | 1 - 2 周 | 25% - 40% |
|
||
| AI gateway | 2 - 4 周 | 1.5 - 3 周 | 20% - 35% |
|
||
| 运维部署 | 3 - 6 周 | 2 - 4 周 | 25% - 40% |
|
||
| 测试 / 灰度 / 稳定性 | 2 - 4 周 | 2 - 3 周 | 10% - 25% |
|
||
|
||
---
|
||
|
||
## 五、为什么不是直接缩短一半以上？
|
||
|
||
因为这个项目不是纯 Web 后台系统，而是典型的：
|
||
|
||
```text
|
||
业务后台 + MQTT 长连接 + APP + 嵌入式设备 + WebRTC + TURN + ZLMediaKit + 弱网 + AI
|
||
```
|
||
|
||
AI 很擅长：
|
||
|
||
- 写代码
|
||
- 生成协议
|
||
- 生成文档
|
||
- 补测试
|
||
- 查 bug
|
||
- 生成配置
|
||
- 重构
|
||
- 分析日志
|
||
|
||
但 AI 不擅长替代：
|
||
|
||
- 真机调试
|
||
- 设备固件烧录
|
||
- 网络环境测试
|
||
- 音视频主观体验评估
|
||
- 硬件性能瓶颈排查
|
||
- 线上灰度观察
|
||
- 跨团队沟通
|
||
- 产品验收
|
||
|
||
所以合理预期是：
|
||
|
||
> 整体缩短 20% - 40%，不是缩短 70% - 80%。
|
||
|
||
---
|
||
|
||
## 六、最适合让 GPT-5.5 参与的工作
|
||
|
||
### 6.1 协议设计
|
||
|
||
让 AI 直接输出：
|
||
|
||
- MQTT topic 设计
|
||
- JSON schema
|
||
- 状态机表
|
||
- 错误码表
|
||
- ACK / retry / timeout 规则
|
||
- API 文档
|
||
- 时序图
|
||
|
||
收益非常高。
|
||
|
||
---
|
||
|
||
### 6.2 `session-orchestrator` 代码生成
|
||
|
||
适合 AI 参与：
|
||
|
||
- 服务框架
|
||
- 状态机
|
||
- Redis DAO
|
||
- MySQL DAO
|
||
- MQTT publish / subscribe
|
||
- OpenAPI
|
||
- 单元测试
|
||
- mock 设备
|
||
- mock APP
|
||
|
||
这是最应该 AI 深度介入的模块。
|
||
|
||
---
|
||
|
||
### 6.3 测试用例生成
|
||
|
||
可以让 AI 生成完整测试矩阵：
|
||
|
||
- 正常呼叫
|
||
- 设备离线
|
||
- APP 取消
|
||
- 设备拒接
|
||
- signaling 超时
|
||
- ICE 失败
|
||
- TURN 失败
|
||
- ZLM 失败
|
||
- MQTT 断线重连
|
||
- APP 杀进程
|
||
- 双端同时挂断
|
||
- 重复 invite
|
||
- 重复 accept
|
||
- session token 过期
|
||
- 多 APP 同时呼叫同一设备
|
||
|
||
这能显著减少遗漏。
|
||
|
||
---
|
||
|
||
### 6.4 日志分析与故障定位
|
||
|
||
后期联调时，可以让 AI 基于日志判断：
|
||
|
||
- 是 MQTT 没送达
|
||
- 还是设备没 ACK
|
||
- 还是 WebRTC ICE 失败
|
||
- 还是 TURN 凭证错误
|
||
- 还是 ZLM hook 鉴权失败
|
||
- 还是 APP 状态机没更新
|
||
|
||
这对音视频项目非常有价值。
|
||
|
||
---
|
||
|
||
### 6.5 运维配置生成
|
||
|
||
适合 AI 生成：
|
||
|
||
- Docker Compose
|
||
- coturn 配置
|
||
- ZLMediaKit 配置
|
||
- Prometheus 规则
|
||
- Grafana 面板
|
||
- Nginx 反代
|
||
- CI/CD pipeline
|
||
- 回滚文档
|
||
|
||
---
|
||
|
||
## 七、引入 AI 后的新排期建议
|
||
|
||
### 7.1 第 1 周：协议和骨架快速成型
|
||
|
||
#### AI 参与
|
||
|
||
- 输出完整接口文档
|
||
- 输出 MQTT topic 规范
|
||
- 输出状态机
|
||
- 输出数据库表
|
||
- 输出 mock APP / mock device
|
||
- 生成 `session-orchestrator` 项目骨架
|
||
|
||
#### 人工重点
|
||
|
||
- 审核协议
|
||
- 确认设备能力
|
||
- 确认 APP 交互
|
||
- 确认旧系统兼容方案
|
||
|
||
---
|
||
|
||
### 7.2 第 2 - 4 周：控制面 MVP
|
||
|
||
#### 完成内容
|
||
|
||
- `starlock` 创建会话 API
|
||
- `session-orchestrator` 基础状态机
|
||
- `device-bootstrap`
|
||
- BifroMQ 接入
|
||
- APP MQTT
|
||
- 设备 MQTT
|
||
- invite / accept / reject / hangup
|
||
|
||
#### AI 参与
|
||
|
||
- 生成大部分 CRUD / API / 测试
|
||
- 生成 mock 测试工具
|
||
- 辅助修复联调问题
|
||
|
||
---
|
||
|
||
### 7.3 第 5 - 7 周：媒体链路 MVP
|
||
|
||
#### 完成内容
|
||
|
||
- WebRTC P2P
|
||
- coturn
|
||
- ZLMediaKit
|
||
- ICE 失败后切 ZLM
|
||
- 基础质量上报
|
||
|
||
#### AI 参与
|
||
|
||
- 生成 WebRTC signaling 代码
|
||
- 生成 TURN / ZLM 配置
|
||
- 分析 getStats
|
||
- 分析失败日志
|
||
|
||
---
|
||
|
||
### 7.4 第 8 - 10 周：稳定性与可观测
|
||
|
||
#### 完成内容
|
||
|
||
- ACK / retry / timeout 完整化
|
||
- session trace
|
||
- 事件 worker
|
||
- Grafana dashboard
|
||
- 弱网测试
|
||
- 多异常流测试
|
||
|
||
#### AI 参与
|
||
|
||
- 生成异常测试用例
|
||
- 生成压测脚本
|
||
- 分析日志
|
||
- 辅助修复边界 bug
|
||
|
||
---
|
||
|
||
### 7.5 第 11 - 12 周：灰度上线
|
||
|
||
#### 完成内容
|
||
|
||
- 小批量设备灰度
|
||
- 线上日志分析
|
||
- 性能调优
|
||
- 回滚方案
|
||
- 运维文档
|
||
|
||
#### AI 参与
|
||
|
||
- 自动总结灰度问题
|
||
- 分析失败会话
|
||
- 生成修复建议
|
||
- 维护故障知识库
|
||
|
||
---
|
||
|
||
## 八、AI 加持后的推荐团队配置
|
||
|
||
### 8.1 原建议团队
|
||
|
||
| 角色 | 人数 |
|
||
|---|---:|
|
||
| 后端 | 2 |
|
||
| APP | 1 |
|
||
| 设备端 | 1 |
|
||
| 运维 | 1 |
|
||
| 测试 | 1 |
|
||
| 产品 / 架构 | 1 |
|
||
|
||
---
|
||
|
||
### 8.2 AI 辅助后建议团队
|
||
|
||
| 角色 | 人数 | 说明 |
|
||
|---|---:|---|
|
||
| 架构 / 技术负责人 | 1 | 负责边界、协议、评审 |
|
||
| 后端 | 1 - 2 | AI 可承担大量样板代码 |
|
||
| APP | 1 | 仍需真机调试 |
|
||
| 设备端 | 1 | 仍是关键瓶颈 |
|
||
| 运维 | 0.5 - 1 | AI 可生成配置，但仍需验证 |
|
||
| 测试 | 1 | AI 生成用例，人负责执行和验收 |
|
||
|
||
> 不建议因为有 AI 就取消测试或运维。这个项目涉及真实设备和音视频链路，测试和运维仍然很关键。
|
||
|
||
---
|
||
|
||
## 九、最容易被 AI 缩短的交付物
|
||
|
||
| 交付物 | 原耗时 | AI 辅助后 |
|
||
|---|---:|---:|
|
||
| 架构文档 | 3 - 5 天 | 1 天 |
|
||
| API 文档 | 3 - 5 天 | 1 - 2 天 |
|
||
| MQTT 协议文档 | 2 - 4 天 | 0.5 - 1 天 |
|
||
| 数据库设计 | 2 - 3 天 | 0.5 - 1 天 |
|
||
| 状态机设计 | 2 - 4 天 | 1 天 |
|
||
| 测试用例 | 3 - 5 天 | 1 - 2 天 |
|
||
| Docker Compose | 2 - 3 天 | 0.5 - 1 天 |
|
||
| 监控指标初版 | 2 - 4 天 | 1 天 |
|
||
| Mock 工具 | 3 - 7 天 | 1 - 3 天 |
|
||
|
||
---
|
||
|
||
## 十、需要防范的 AI 风险
|
||
|
||
### 10.1 AI 写出的代码看似完整，但边界不一定可靠
|
||
|
||
尤其是：
|
||
|
||
- 并发状态机
|
||
- 幂等处理
|
||
- 分布式锁
|
||
- MQTT 重连
|
||
- WebRTC 状态处理
|
||
- token 安全
|
||
- 资源清理
|
||
|
||
这些必须人工 code review。
|
||
|
||
---
|
||
|
||
### 10.2 AI 容易低估设备端复杂度
|
||
|
||
设备端不是普通 Linux 服务器，可能有：
|
||
|
||
- 内存限制
|
||
- SDK 限制
|
||
- 编译链限制
|
||
- 硬件编码限制
|
||
- 线程模型限制
|
||
- 网络库限制
|
||
|
||
设备端周期不能按普通后端服务估算。
|
||
|
||
---
|
||
|
||
### 10.3 AI 生成的配置要经过真实验证
|
||
|
||
比如：
|
||
|
||
- coturn 配置
|
||
- ZLMediaKit 配置
|
||
- Nginx 反代
|
||
- K8s 网络
|
||
- UDP 端口范围
|
||
|
||
这些配置 AI 可以生成，但不能直接上线。
|
||
|
||
---
|
||
|
||
### 10.4 AI 不能替代弱网测试
|
||
|
||
弱网测试必须真实做：
|
||
|
||
- 20% 丢包
|
||
- 200ms 延迟
|
||
- 抖动
|
||
- WiFi / 4G 切换
|
||
- NAT 类型变化
|
||
- 设备断电重连
|
||
- APP 后台恢复
|
||
|
||
---
|
||
|
||
## 十一、最终结论
|
||
|
||
在引入 GPT-5.5 级别 AI 辅助后，开发周期建议为：
|
||
|
||
| 目标 | 原周期 | AI 辅助后 |
|
||
|---|---:|---:|
|
||
| MVP 跑通主链路 | 8 - 12 周 | 5 - 8 周 |
|
||
| 可灰度上线 | 12 - 16 周 | 8 - 12 周 |
|
||
| 完整生产级版本 | 16 - 24 周 | 12 - 18 周 |
|
||
|
||
---
|
||
|
||
### 11.1 最能提速的模块
|
||
|
||
最能提速的模块是：
|
||
|
||
1. 协议设计
|
||
2. `session-orchestrator`
|
||
3. `device-bootstrap`
|
||
4. `MQTT event worker`
|
||
5. 测试用例和 Mock 工具
|
||
6. 运维配置和文档
|
||
|
||
---
|
||
|
||
### 11.2 最难被压缩的模块
|
||
|
||
最难被压缩的模块是：
|
||
|
||
1. 设备端 WebRTC
|
||
2. APP 真机适配
|
||
3. WebRTC / TURN / ZLM 三方联调
|
||
4. 弱网测试
|
||
5. 灰度上线验证
|
||
|
||
---
|
||
|
||
## 十二、推荐第一阶段目标
|
||
|
||
如果目标是尽快上线，建议第一阶段控制为：
|
||
|
||
```text
|
||
starlock 创建会话
|
||
+ session-orchestrator 状态机
|
||
+ BifroMQ signaling
|
||
+ APP/设备 MQTT
|
||
+ ZLMediaKit 优先兜底
|
||
+ WebRTC P2P 作为增强
|
||
```
|