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

文章归档

Scroll down
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 环境里的零散输出,收敛成可复现、可解释、可交接的排障记录。

AI 工具让写代码的速度变快了,但也更容易把一次变更做散:修 bug 的同时改了格式,补测试时顺手调整了命名,生成文档时又夹带了配置变动。最后 git diff 看起来很长,真正要审查的行为变化反而被淹没。

提交整理的目标不是把历史包装得漂亮,而是让每次变更都能被理解、被验证、被回滚。AI 很适合参与这件事:它可以帮助归类 diff、提炼意图、检查遗漏路径,并把提交说明写得更接近工程事实。

AI 工具已经能很快完成代码生成、文档整理、脚本编写和问题排查,但真正影响交付质量的,往往不是“能不能生成”,而是“生成之后怎么验证”。如果缺少验证闭环,AI 写出的内容看起来完整,实际可能改错边界、漏掉失败路径,或者让构建在最后一步才暴露问题。

更稳的做法,是把 AI 产出当成一次普通工程变更处理:先确认改动范围,再建立验证清单,然后用构建、测试、人工审查和回滚预案把结果闭环。这样 AI 负责提高产出速度,人负责控制风险。

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

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

AI 工具最常见的失效方式,不是不会写,而是一次接到的任务太大,导致它把目标、边界和验证混在一起处理。结果通常是:内容很多,改动很多,但最后很难判断到底完成了什么。

更稳定的做法,是把任务先切片,再交给 AI 执行。切片的核心不是拆得更细,而是让每一段都有明确输入、明确输出和明确验证方式。这样 AI 负责产出,人负责把关,整个过程会更接近工程交付。

123
请输入关键词进行搜索