文章归档

把一段报错直接贴给 AI，往往能得到十几种“可能原因”。这些答案未必错，却很难立刻用于工程现场：它不知道问题发生在哪次构建、设备处于什么状态，也不知道日志前后发生了什么。

高效排障的关键，不是提供更多文字，而是提供一份边界清楚、可以复查的故障证据包。它既让 AI 少猜，也让接手问题的人能沿着同一条路径复现和验证。

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

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

调试最怕的不是问题复杂，而是信息散落在日志、配置、代码分支和环境差异里，最后只能靠猜。AI 工具能帮我们快速阅读日志、追踪调用链、整理假设，但如果一开始就问“这个问题怎么修”，它很容易跳过验证，直接给出看似合理的修改建议。

更稳的做法，是把 AI 放进一个可检查的调试流程里：先描述现象，再收集证据，然后缩小范围，最后产出最小复现和修复方案。这样 AI 不只是回答问题，而是参与工程排障。