周五下午，流水线跳出绿色。研发在群里说：新包已经上传。合作学校的老师按上周那条链接去装，有的还是旧版，有的提示正在处理，有的装上后课堂流程对不上本周讲义。

教育机器人的配套 App 往往带着课程、固件入口和设备连接。学校试用不是「能下到一个文件」就结束。老师要在固定时间带着学生完成指定关卡。版本错一天，整节课都会乱。

上传成功、发布完成、试用放行，是三件事

很多团队把 CI 的绿色方块理解成「学校现在可以装了」。对蒲公英 API 来说，这一步还早。

截至 2026 年 9 月 15 日，快速上传文档把流程写成三步：先取预上传地址，再把文件 POST 上去，最后用 buildInfo 轮询发布结果。第二步成功时，接口返回 HTTP 204 No Content。文档写明：这一步成功不代表发布完成，文件会进入后台队列，通常还要继续检测，直到成功或失败。

所以，CI 日志里的「upload ok」只说明文件到了对象存储。学校入口能不能看到这一版，要看发布是否结束，以及该入口被设置成跟随哪一个版本。

第三件事是试用放行。即便发布完成，也不该默认所有合作学校立刻切换。课堂用的版本需要和讲义、机器人固件、账号环境对过。研发验证通过，不等于教学场景通过。

学校入口最怕「自动跟上每一次构建」

CI 的价值是少搬文件。它的风险是把每一次构建都送到老师手机上。

更稳的拆法：

• • 构建通道：CI 持续上传，给研发和测试看。

• • 学校试用通道：单独渠道，只放本周约定版本。新构建默认不要自动加入；验收后再改渠道里的可用版本。

• • 讲义冻结：本周课使用的 App 版本、机器人固件和课件页码写在同一张说明里。老师反馈问题时，先对这三项，而不是再要一个「最新包」。

蒲公英渠道文档允许为同一 App 建不同短链接，并选择自动加入后续新版本，或只保留手动选择的版本。学校试用通常应选后者。API 上传参数里的 buildChannelShortcut 可以更新已经创建好的某一个渠道，但不能代替「这周学校该用哪一版」的人工确认。

还要看分发模式。应用上传后默认是内测模式，下载次数受限。面向多所学校、多个班级时，额度可能先于课程结束。更大范围试用需要按当前规则申请分发模式，并以后台当时显示的限额为准。把内测入口直接当成公开课堂下载，会在学期中途突然下不下来。

历史版本不会因为你「需要复现那节课」就一直留着

学校试用经常要回到两周前的构建，核对某次课堂故障。这要求版本可追溯，但不等于每一次 CI 产物都会一直留在托管列表里。

当期版本管理文档说明：系统最新版本会长期保留；成为历史版本之后，超额或连续 90 天不活跃的包可能进入自动清理。额度因认证和套餐而异，以账户权益为准。正常发布造成的超额没有额外宽限期，也不会每次上传都单独提醒。文档还写：上传成功不表示所有历史版本继续保留。需要长期归档的课堂包，应在自己的 CI 产物库里另存一份。

下载设置里如果写着「长期有效」，意思是没有设置下载起止时间，不是每一次课堂构建都会一直留在托管列表里。平台已取消旧的自动到期和手动续签，但这只覆盖系统最新版本的托管方式，不能拿来安慰「三个月前那节课的包一定还在」。

发给学校之前，流水线至少要卡住这几步

1. 1. 上传返回 204 之后，继续轮询 buildInfo，直到成功或失败；失败必须让流水线失败。

2. 2. 核对包名、版本号、更新说明是否写入本周课堂说明。

3. 3. 只把通过教学验收的版本放进学校渠道；研发渠道可以跟随构建。

4. 4. 用老师常用的 Android / iOS 真机从学校入口走一遍安装和连接。

5. 5. 确认当前是内测还是分发模式，下载额度够不够覆盖本周班级。

6. 6. 需要复现的课堂版本，在自己的制品库留备份，不要只依赖托管列表。

教育机器人的 CI 可以减少「谁来传包」。它不能减少「谁来决定这周课堂用哪一版」。绿灯是文件到达的信号，不是发给学校的许可。