把上下文交接做好：AI 辅助 Android 与 Linux 工程的效率边界

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

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

一、不要把聊天记录当成工程记录

聊天记录适合探索，不适合沉淀。一次 Android 构建失败的排查，可能夹杂着 Gradle 日志、环境变量、缓存目录、SDK 路径、临时猜测和几次失败尝试。如果只是继续往对话里追加内容，后面的判断会越来越依赖记忆和运气。

更可靠的方式，是在关键节点主动生成一份短交接：

目标：当前要解决的问题是什么
现象：稳定复现的错误或行为
事实：已经用命令确认过的结论
变更：已经改过哪些文件或配置
限制：不能执行、不能删除、不能重启的内容
下一步：建议先验证的最小动作

这个结构看起来简单，但它能把“AI 觉得可能是”压回到“现场已经证明了什么”。尤其是在 Linux 环境里，权限、用户、systemd 单元、工作目录和环境变量经常互相影响。没有事实列表，排障很容易变成随机试命令。

二、把“已验证”和“待验证”分开

AI 在工程协作里最常见的问题，是把推测写得像结论。比如看到 Android 编译失败，就推断是缓存损坏；看到服务启动失败，就推断是端口占用。这些方向可能正确，但在执行前都只是待验证假设。

交接文档里应该刻意分出两栏：

已验证：
- `./gradlew tasks` 可以运行，说明 Gradle Wrapper 本身可用
- 当前用户能读取项目目录，但不能写入某个构建输出目录
- 服务配置文件语法检查通过

待验证：
- 是否存在旧进程占用端口
- CI 与本机是否使用了不同的 JDK
- systemd 启动时是否缺少必要环境变量

这样做的好处是，下一轮 AI 不会把前一轮的猜测当作事实继续放大。工程效率的关键不是让 AI 一次猜中，而是让每次验证都能缩小问题范围。

三、让命令输出保持可复用

命令输出不要只截图，也不要只摘最后一行。对于 Android 和 Linux 问题，最有价值的信息通常在上下文附近：执行目录、用户身份、完整命令、退出码、关键日志前后几行。

可以用一种固定格式贴给 AI：

命令：
pwd
whoami
./gradlew assembleDebug --stacktrace

结果摘要：
- 工作目录是项目根目录
- 执行用户是普通用户
- 构建在资源合并阶段失败

关键输出：
粘贴必要日志片段

固定格式能减少解释成本，也方便下一次交接时直接复用。更重要的是，它让 AI 更容易区分“命令没有执行”“命令执行了但失败”“命令执行成功但结果不符合预期”。

四、给 AI 明确修改边界

AI 很擅长提出修改建议，但工程现场并不总允许随便改。Android 项目里，改 build.gradle、升级插件、清理缓存、删除锁文件，影响范围完全不同。Linux 服务器上，重启服务、改权限、删目录、修改 systemd 单元，也都有不同风险。

在交接里可以提前写清楚边界：

允许：
- 读取日志和配置
- 修改当前分支内的源码
- 新增小范围脚本或文档

需要确认：
- 升级依赖版本
- 删除缓存目录
- 修改系统服务配置
- 重启线上进程

禁止：
- 覆盖用户未提交改动
- 删除未知来源文件
- 执行不可逆迁移

这不是为了限制 AI，而是为了让建议更贴近真实工作流。边界越清楚，AI 越容易给出可执行的下一步，而不是生成一串“也许可以试试”的通用方案。

五、交接要包含下一步最小动作

一份好的上下文交接，不应该停在“目前怀疑是某某原因”。它应该给出下一步最小验证动作。所谓最小动作，是指成本低、影响小、能明显改变判断的信息。

例如：

下一步建议：
1. 先运行 `systemctl cat xxx.service`，确认服务实际加载的 unit 内容
2. 再运行 `systemctl show xxx.service -p User -p WorkingDirectory -p Environment`
3. 如果运行用户和手工测试用户不同，再比较两个用户下的关键环境变量

这个顺序比直接“重启服务看看”更稳。它先确认 systemd 实际使用的配置，再确认运行身份和环境，最后才考虑改动。Android 构建也是同样的思路：先确认 wrapper、JDK、模块、任务和错误阶段，再决定是否清缓存或改依赖。

六、把复盘写成可复制模板

问题解决后，最容易被忽略的是复盘。很多人会把最终命令贴进文档，却没有记录为什么是这条命令。下一次遇到相似问题，又会重新问一遍。

复盘可以保持很短：

问题：一句话描述故障
根因：最终确认的原因
证据：哪条命令或日志证明了根因
修复：实际改了什么
防复发：是否需要检查脚本、CI 规则或文档
误区：排查中哪些猜测被证明是错的

其中“误区”尤其有价值。它能避免下一次继续沿着错误方向消耗时间，也能帮助 AI 在后续对话里少走弯路。

七、结语

AI 工具的工程价值，不在于把每个问题都变成自动驾驶，而在于让人的判断过程更清晰、更可复用。对于 Android 与 Linux 这类现场因素很重的工作，真正拉开效率差距的不是提示词写得多漂亮，而是上下文是否能稳定交接。

把目标、事实、限制、变更和下一步动作写清楚，AI 才能从“回答问题的工具”变成“参与工程推进的助手”。这套习惯一旦建立起来，不只 AI 对话更顺，团队协作、值班排障和个人复盘也都会变得更轻。