文章归档

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

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

让 AI 写一条命令很容易：清理构建缓存、批量替换配置、抓取 Android 日志，或者找出占用磁盘最多的目录。真正危险的部分，是我们常常把“看起来合理”误当成“可以直接执行”。

命令行会放大效率，也会放大错误。一个路径变量为空、一个通配符范围过宽，或者一段只适用于另一种 Shell 的语法，都可能让几秒钟的操作变成半天的恢复工作。

因此，我更愿意把 AI 当成命令的起草者，而不是终端的驾驶员。它负责压缩探索时间，人负责建立执行护栏。

AI 工具最容易带来的错觉，是“写得更快”就等于“做得更快”。在真实工程里，速度只是表面，真正决定效率的是你能不能把一次对话变成一次可复现、可验证、可回滚的改动。

对 Android、Linux、脚本和日常工程来说，AI 最合适的位置不是“替你思考全部问题”，而是“帮你缩短搜索、整理和试错的路径”。前提是你给它一个稳定的工作流，而不是一段模糊的描述。

AI 工具进入日常工程之后，最容易被高估的是“生成答案”的速度，最容易被低估的是“把答案接入本地工作台”的成本。一个建议如果不能被复现、验证、回滚，它在 Android 项目、Linux 环境或后端服务里都只能算灵感，不能算工程动作。

真正稳定的效率提升，不是让 AI 替人多写几段代码，而是让它进入一条可控的本地流程：先理解目标，再读取有限上下文，提出可执行改动，最后通过命令、日志和测试闭环。这样做看起来慢一点，却能减少大量“回答正确但落地失败”的消耗。

AI 工具真正提升效率的地方，往往不是第一次回答，而是它能否接住一段正在推进的工程上下文。Android 构建、Linux 服务排障、脚本迁移、依赖升级这些工作，都不是孤立的一问一答。它们会经历观察、假设、验证、修改、回滚和复盘。如果上下文交接混乱，AI 很容易给出看似合理但实际脱离现场的建议。

很多团队把 AI 用得不稳定，并不是模型不会写代码，而是人没有把工程现场组织成可交接的状态。一次高质量交接，应该让后来者知道当前目标、已经确认的事实、不能碰的边界，以及下一步最小验证动作。这个后来者可以是同事，也可以是下一轮 AI 对话。

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

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