把 AI 工具接进终端排障：一套可复用的工程工作流

很多人使用 AI 工具时，习惯把它当成一个更会说话的搜索框：复制报错、等待解释、再去终端里尝试命令。这个方式能解决一部分问题，但在真实工程里经常不够稳定。日志会截断，环境会变化，命令有副作用，Android 和 Linux 的问题还常常夹在权限、进程、文件系统、网络和构建缓存之间。

更高效的做法，是把 AI 放进一套固定的排障工作流里。它不直接替你判断结论，而是帮助整理现场、收敛假设、设计下一步验证。人仍然负责执行命令、确认边界和决定是否修改系统状态。

一、先固定现场，不急着问原因

排障最容易浪费时间的地方，是一开始就让 AI 猜。比如 Android 构建失败，只贴最后一屏错误，它可能会围绕 Gradle、Kotlin、SDK 或缓存给出一串宽泛建议。Linux 服务启动失败也是一样，只给一行 failed，很难知道问题在权限、配置、依赖还是运行用户。

可以先把现场整理成稳定模板：

目标：我本来要完成什么操作
环境：系统、工程目录、运行用户、关键工具链
现象：完整错误、复现步骤、出现频率
限制：哪些命令不能执行，哪些文件不能改
已尝试：已经跑过的命令和结果

这个模板的价值不在于好看，而在于逼迫自己把“我感觉哪里坏了”转换成“哪些事实已经可确认”。AI 在这样的输入上，更容易给出可以验证的假设，而不是直接跳到重装依赖、清缓存或改配置。

二、让 AI 先生成检查清单

一个实用提示词是：

不要先给修复方案。
请根据下面现场，列出 5 个最可能原因。
每个原因给出一个只读检查命令，并说明命令输出如何支持或排除该原因。

这句话里的“只读检查命令”很关键。排障早期不要让工具直接建议删除缓存、重启服务、改权限或覆盖配置。先用 pwd、ls -l、id、env、systemctl status、journalctl、adb devices、adb logcat 这类命令建立事实，风险会低很多。

在 Android 场景里，可以让 AI 把检查项按层次拆开：

请按设备连接、构建环境、依赖解析、安装阶段、运行时崩溃五层排查。
每层只给 1 到 2 个检查动作。

在 Linux 场景里，也可以要求它按权限、路径、服务用户、端口、资源限制拆分。这样做的好处是，排障过程不会在一个方向里钻太深，也不容易忽略那些“看起来不像代码问题”的基础条件。

三、把命令输出变成差异，而不是长日志

AI 能读长日志，但长日志不等于高质量输入。更好的方式，是让终端先把噪声压掉，只保留差异和关键上下文。

例如对比两次环境变量：

env | sort > /tmp/env.current
diff -u /tmp/env.expected /tmp/env.current

查看服务失败原因：

systemctl status app.service --no-pager
journalctl -u app.service -n 80 --no-pager

查看 Android 运行时错误：

adb logcat -d | rg "FATAL EXCEPTION|AndroidRuntime|Permission|Unable to start"

把这些输出交给 AI 时，可以要求它只做三件事：

1. 标出最关键的 3 行。
2. 解释这些行之间的因果关系。
3. 给出下一条验证命令，不要一次性给多个修复动作。

这个节奏会慢一点，但每一步都有反馈闭环。排障不再是“试一堆建议”，而是从一个可验证事实走向下一个可验证事实。

四、修改前让 AI 写回滚方案

真正需要改文件、改权限、清缓存或重启服务时，AI 的角色应该切换成变更审查助手。可以直接要求：

我要执行下面的修改。
请指出它可能影响的范围、失败后如何回滚、以及执行前还缺少哪些确认。

比如准备修改 systemd unit、调整 Android manifest 权限、升级构建插件、删除 Gradle 缓存，都应该先有回滚路径。工程效率不是把动作变快，而是让错误动作的代价变低。

一个简单原则是：凡是会改变系统状态的命令，都先问三件事。

它改了哪里？
如何确认改成功？
如何恢复原状？

如果 AI 不能清楚回答这三点，这个建议就还不能直接执行。

五、沉淀成团队可复用的提示词

个人使用 AI 工具，提升的是单次排障速度；团队使用 AI 工具，更重要的是把经验固化下来。可以在仓库里维护几类提示词模板：

Android 构建失败排查模板
Android 崩溃日志分析模板
Linux 服务启动失败模板
Shell 脚本变更审查模板
线上变更回滚检查模板

模板不需要很长，重点是统一输入结构、限制危险动作、要求给出验证命令。这样新人遇到问题时，不会只把一段日志丢给 AI 等答案，而是按团队认可的路径收集证据。

AI 工具真正适合承担的，不是替工程师“猜中原因”，而是把混乱现场整理成一连串低风险、可验证的小步骤。对于 Android、Linux 和日常工程实践来说，这种能力比一次漂亮的答案更稳定，也更容易被团队长期复用。