AI 辅助终端排障流程：把 Android 与 Linux 现象变成证据

终端排障最容易卡住的地方，不是缺少命令，而是缺少顺序。看到一个异常现象后，工程师往往会同时打开日志、进程、网络、磁盘和配置，信息量迅速膨胀；AI 也会在上下文混乱时给出看似合理、实际跳步的建议。

更稳妥的做法，是把 AI 放在“整理证据”和“生成下一步检查清单”的位置上。它不替代现场判断，也不直接给最终结论，而是帮助我们把 Android 与 Linux 环境里的零散输出，收敛成可复现、可解释、可交接的排障记录。

一、先固定问题边界

排障开始时不要急着粘贴整段日志。先把问题压缩成四个字段：

现象：
影响范围：
复现方式：
最近变更：

例如 Android 应用启动慢，可以写成：

现象：冷启动从点击图标到首页可交互明显变慢。
影响范围：只在部分低内存设备上稳定出现。
复现方式：清理后台后首次启动，重复三次均可观察到。
最近变更：启动链路新增了配置读取和一次本地数据库迁移。

这一步的价值是让 AI 不再根据单个错误行猜原因。它能先判断问题属于启动、资源、IO、网络、权限还是依赖初始化，再建议该优先收集哪些证据。

可以使用这样的提示词：

你是排障助手。请根据下面的问题描述，先不要给结论，只输出：
1. 可能的排查方向。
2. 每个方向需要的最小证据。
3. 哪些信息不足以判断。
问题描述如下：

二、每次只收集一组证据

终端排障要避免“命令瀑布”。一次只围绕一个假设收集证据，输出也只给 AI 一组，让上下文保持干净。

如果怀疑是 Linux 主机资源问题，可以先收集：

uptime
free -h
df -h
ps aux --sort=-%mem | head
ps aux --sort=-%cpu | head

如果怀疑是 Android 进程状态问题，可以先收集：

adb shell ps -A | grep your.package.name
adb shell dumpsys meminfo your.package.name
adb logcat -d -t 300

然后让 AI 做结构化整理：

请只根据这组输出判断：
1. 是否能支持“资源不足”这个假设。
2. 支持或反驳该假设的具体证据是什么。
3. 下一步最小检查命令是什么。
不要扩展到无关方向。

这里的关键不是让 AI 记住所有命令，而是要求它给出“证据是否支持假设”。排障记录里最有用的内容，往往不是命令本身，而是命令输出和假设之间的关系。

三、把日志切成时间窗口

日志最常见的问题是太长。完整日志看起来信息充分，其实会稀释关键事件。更可靠的方式是先确定时间窗口，再围绕窗口前后观察。

Android 场景可以按操作步骤切日志：

adb logcat -c
# 执行一次复现操作
adb logcat -d > reproduce.log

Linux 服务可以按时间段查看：

journalctl -u service_name --since "10 minutes ago"

交给 AI 时，不要只说“分析日志”。可以这样约束：

下面是一次复现期间的日志。请按时间顺序输出：
1. 第一个异常信号。
2. 异常前最近的关键动作。
3. 异常后的连锁反应。
4. 不能从日志中确认的内容。
如果存在多个错误，只按因果关系排序，不按严重程度排序。

这能减少一个常见误判：把最后出现的错误当成根因。很多终端问题里，最后的崩溃、超时或重启只是结果，真正的触发点在前面几十行。

四、让 AI 维护排障表，而不是聊天记录

聊天式排障会越来越难追踪，因为每一轮都混入新的猜测。更适合工程协作的格式是一张小表：

假设	已有证据	反证	下一步	状态
启动阶段 IO 阻塞	首屏前出现密集文件读取	暂无	采集启动阶段 trace	待验证
内存不足触发回收	低内存设备更明显	高内存设备未复现	对比 meminfo	待验证
网络请求阻塞主线程	日志没有直接证据	离线也可复现	暂停该方向	降级

每做完一轮检查，就让 AI 更新表格：

请基于新增证据更新排障表：
1. 保留仍然成立的假设。
2. 标记已被反证的假设。
3. 新增假设必须说明来源。
4. 下一步只能给一个优先级最高的动作。

这会强迫排障过程不断收敛。对团队来说，这张表也比一长串聊天记录更适合放进 issue、复盘文档或提交说明。

五、结论必须能被人工复核

AI 给出的排障结论，最好都落到三句话：

根因判断：
关键证据：
修复或规避方案：

如果其中任何一句写不出来，就说明结论还不够硬。比如“可能是内存问题”不是结论，“在低内存设备上，启动后进程 RSS 持续升高，同时日志出现频繁回收；移除启动期大对象缓存后现象消失”才接近可复核的工程判断。

最终提交修复前，还可以让 AI 做一次反向检查：

请审查这份排障结论：
1. 哪些证据真正支持根因。
2. 哪些结论仍然只是推测。
3. 是否缺少复现前后对比。
4. 是否可以写成更清晰的回归测试或验证步骤。

六、把流程沉淀成团队模板

AI 辅助排障的收益，来自稳定流程，而不是某一次回答。可以把常用模板放进仓库文档或个人片段库：

问题边界模板
证据整理模板
日志时间线模板
假设表更新模板
结论复核模板

每次遇到 Android 卡顿、Linux 服务异常、构建机资源波动或脚本偶发失败，都用同一套骨架推进。久而久之，AI 的角色会从“给建议的人”变成“帮你保持工程纪律的助手”。

真正有效的 AI 工具流，不是把终端输出一次性倒进去等待答案，而是让每一轮对话都产生更清晰的证据、更少的假设，以及更容易被同事复现的下一步。