liangqiang/AllStar2.0
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
AllStar2.0/开发周期with AI.md

16 KiB
Raw Blame History

引入 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 租户定制能力的边界
  • 历史数据模型兼容
  • 跨团队接<EFBFBD><EFBFBD><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 后台系统，而是典型的：

业务后台 + 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. 灰度上线验证

十二、推荐第一阶段目标

如果目标是尽快上线，建议第一阶段控制为：

starlock 创建会话
+ session-orchestrator 状态机
+ BifroMQ signaling
+ APP/设备 MQTT
+ ZLMediaKit 优先兜底
+ WebRTC P2P 作为增强