banner
按时间整理的学习笔记。

文章归档

Scroll down
Android

让 AI 修改代码时,真正危险的往往不是它不会写,而是它一次写得太多:顺手整理目录、统一命名、升级依赖,再补上一层“更合理”的抽象。最终 diff 看起来很完整,验证成本却超过了人工重写。

解决办法不是把提示词写得更长,而是给每轮修改设定一个明确的“变更预算”。预算限制本轮可以触碰的文件、行为和验证范围,使 AI 的产出保持在人工能够快速审查、机器能够及时验证的尺度内。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android 性能优化不是上线前临时跑一次 Profiler,也不是看到卡顿后盲目改几行代码。真正稳定的做法,是把性能问题拆成可观测、可复现、可验证的工程流程:先知道慢在哪里,再判断为什么慢,最后用指标证明优化确实有效。

1239
请输入关键词进行搜索