文章归档

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

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

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

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

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

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

很多团队已经习惯在排障阶段使用 AI：贴日志、问原因、要命令、整理结论。但更有价值的位置，其实是在变更进入主干之前。代码还没有合并，配置还没有发布，脚本还没有跑到生产环境里，这时 AI 能做的不是替我们拍板，而是把容易被忽略的风险提前摊开。

Android 与 Linux 工程尤其适合这种做法。前者经常受生命周期、权限、线程和设备差异影响；后者则容易被文件权限、环境变量、系统服务、路径和资源限制绊住。人工 review 很容易盯住业务逻辑，漏掉这些“边缘但常见”的运行条件。

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

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

联网设备必须有清晰的设备身份。设备 ID、SN、MAC、证书和私钥如果管理混乱，会影响 MQTT 连接、云端认证、售后追踪和安全性。身份信息要从生产阶段就设计好。

嵌入式 Linux 不等于只能写 C。驱动和底层库仍以 C 为主，但业务服务、网络通信、配置管理、升级程序可以根据资源和团队能力选择 C++、Go 或 Rust。语言选型要看约束，不要只看偏好。

嵌入式项目很容易变成一堆 SDK 压缩包、临时补丁、手工改动和不可复现镜像。项目目录和协作方式如果不规范，团队越多人，问题越难追。

嵌入式设备的存储介质差异很大。NOR、NAND、eMMC、SD 卡的特性不同，适合的文件系统和升级方式也不同。选错存储方案，后面会在断电、坏块、寿命和性能上不断补坑。

嵌入式 Linux 上的 C 服务代码，不只是能编译运行就可以。它要长期运行，要处理异常输入，要能记录日志，要能重载配置，要能在资源紧张和网络异常时保持可控。