AI 辅助变更前检查：把 Android 与 Linux 风险提前摊开

很多团队已经习惯在排障阶段使用 AI：贴日志、问原因、要命令、整理结论。但更有价值的位置，其实是在变更进入主干之前。代码还没有合并，配置还没有发布，脚本还没有跑到生产环境里，这时 AI 能做的不是替我们拍板，而是把容易被忽略的风险提前摊开。

Android 与 Linux 工程尤其适合这种做法。前者经常受生命周期、权限、线程和设备差异影响；后者则容易被文件权限、环境变量、系统服务、路径和资源限制绊住。人工 review 很容易盯住业务逻辑，漏掉这些“边缘但常见”的运行条件。

一、先让 AI 看变更意图，不要先看补丁

直接把 diff 丢给 AI，常见结果是它按行解释代码，提醒一些泛泛的空指针、异常处理和命名问题。更有效的顺序，是先给它一段变更说明：

目标：
影响模块：
运行环境：
预期行为：
不希望改变的行为：

例如一次 Android 启动链路优化，可以写成：

目标：减少冷启动阶段的主线程等待。
影响模块：启动页、配置读取、本地缓存初始化。
运行环境：低内存设备、首次安装、升级后首次启动。
预期行为：首页更快可交互，配置仍能在进入业务页前就绪。
不希望改变的行为：不改变登录态恢复，不跳过数据库迁移。

这段说明的作用，是让 AI 先建立边界。之后再给 diff，它才更容易判断“这行代码是否破坏了目标之外的约束”，而不是只做语法层面的评论。

二、把检查问题拆成三个层次

变更前检查可以分成三层：代码层、运行层、回滚层。

代码层关注局部正确性。Android 里常见的问题包括主线程阻塞、生命周期泄漏、协程作用域过大、权限结果未处理；Linux 里则包括 shell 参数引用不严谨、临时文件路径固定、命令退出码被吞掉、软硬链接处理不清。

运行层关注环境差异。同一段代码在开发机上没问题，不代表在 CI、容器、低端设备、只读目录或弱网络下也成立。AI 很适合根据变更说明列出这些环境假设：

请按 Android 设备差异、Linux 运行环境、并发时序、资源限制四类，
列出这次变更可能依赖但没有显式声明的前提。

回滚层关注失败后怎么办。很多变更真正危险的地方不在“会不会失败”，而在“失败后是否能停住”。比如配置格式改了但没有兼容旧字段，systemd 服务启动失败后不断重启，Android 本地缓存迁移半途失败却没有版本标记，都会让恢复成本变高。

三、让 AI 产出清单，而不是结论

在 review 里，AI 给出的“这段代码没问题”没有太大意义。更可靠的产物是检查清单，因为清单可以被人逐项确认，也可以沉淀进团队流程。

一个实用的提示词是：

请不要给最终通过/不通过结论。
请基于下面的变更说明和 diff，输出一份变更前检查清单。
每一项包含：风险点、为什么可能发生、如何验证、未验证时的合并风险。
优先关注 Android 生命周期、Linux 权限与路径、并发时序、回滚策略。

这样的输出通常比单纯问“帮我 review 一下”更稳定。它迫使 AI 说明风险来源，也迫使我们补上验证动作。对于不确定的条目，可以直接转成测试用例、手工验证步骤或发布前观察项。

四、给 Android 变更加一组固定追问

Android 代码里，很多问题不是编译器能发现的，而是状态组合触发的。变更前可以固定追问：

这次变更在以下场景是否有不同路径：
1. 首次安装
2. 覆盖安装
3. 进程被系统回收后恢复
4. 横竖屏切换
5. 权限被拒绝或被系统回收
6. 弱网或无网
7. 低内存设备

这些问题并不复杂，但人工 review 时经常被跳过。AI 的价值在于持续提醒，而不是比工程师更懂业务。尤其是启动、登录、支付、缓存和通知链路，只要变更触碰到状态恢复，就应该把这些场景过一遍。

五、给 Linux 变更加一组固定追问

Linux 侧可以围绕“谁来运行、在哪里运行、失败后留下什么”来检查：

请检查这个脚本或服务变更是否依赖：
- 当前工作目录
- 特定用户权限
- 特定 PATH
- 可写目录
- 网络连通性
- 文件锁或单实例约束
- systemd 重启策略
- 日志轮转与磁盘空间

很多脚本在交互式 shell 中能跑，在 cron、systemd、容器或 CI 里就失败。原因往往不是命令本身错误，而是环境前提没有写出来。让 AI 专门找“隐含前提”，比让它解释脚本每一行更有用。

六、把结果落到提交说明里

AI 生成的清单如果只停留在聊天窗口，很快就会丢。更好的做法，是把关键项写进提交说明或合并请求描述：

验证：
- 已覆盖首次安装和升级后首次启动。
- 已验证低内存设备冷启动不阻塞主线程。
- 已验证配置读取失败时使用旧缓存。

风险：
- 首次进入业务页前仍依赖本地配置完成加载。
- 灰度期间需要观察启动耗时和配置失败日志。

回滚：
- 回滚代码即可恢复旧读取路径。
- 新缓存字段保持向后兼容，无需清理本地数据。

这比一句“已自测”更容易交接，也方便后续排障时回看当时的判断依据。

七、不要把 AI review 变成形式

AI 辅助检查最容易走偏的地方，是把它变成合并前的固定仪式：贴 diff、生成一段评论、复制到合并请求，然后继续照常合并。这样做只会增加噪声。

更实际的标准是：AI 至少要帮助发现一个原本没有写明的前提、一个需要补充的验证场景，或者一个失败后的处理动作。如果三者都没有，说明提示词、输入材料或变更本身的风险分类需要调整。

工程效率不是让 AI 更快地说“可以合并”，而是让团队更早看见不确定性。变更前多花几分钟把风险摊开，往往能少掉发布后的几小时追查。AI 在这里最适合扮演的角色，是稳定、耐心、不会因为熟悉代码而跳过基本问题的检查员。