diff --git a/开发周期with AI.md b/开发周期with AI.md
new file mode 100644
index 0000000..bbe63f1
--- /dev/null
+++ b/开发周期with AI.md	
@@ -0,0 +1,970 @@
+# 引入 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` 租户定制能力的边界
+- 历史数据模型兼容
+- 跨团队接���协调
+
+---
+
+### 3.7 APP 端 `app-starlock` 改造
+
+#### 原周期
+
+**4 - 8 周**
+
+#### AI 辅助���
+
+**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 作为增强
+```