AI时代,普通打工人该何去何从

嗨，你好呀！我是从Ring0到AI作者，码农经验5年，从工程师角度专注分享从代码到AI最前沿的科技，欢迎关注～

白天上班，晚上还有自己的生活。面对不断冒出来的新工具，很难每一个都去学。比起追着消息跑，我想聊聊自己工作里已经发生的变化。

我是一名安卓系统底层驱动开发工程师，曾在小米、荣耀等大厂做驱动开发。AI对我的影响，就落在每天处理的Bug单上。

以前，一个Bug要沿着日志和代码慢慢找

按以往的流程，接到一个JARE单或者DTS BUG单，我们通常要经历这些步骤：

复现问题现象 → 抓取日志 → 结合代码分析日志 → 梳理代码流程 → 找到根因 → 尝试修改 → 编译版本验证。

其中费精力的，是把零散信息串起来：这条异常日志对应哪里？代码为什么走到这一步？哪次修改可能引入了问题？

这些工作需要经验，也占用了大量时间。AI进入工作流后，我开始尝试把其中更多的分析环节交给它

拿一个相机内存泄漏问题来说

我遇到过这样一个问题：通过可视化APK，让执法记录仪持续录像，时间长了以后，应用会卡死、闪退。排查时发现，杀掉相机HAL服务后，使用又能恢复正常

我把日志、问题现象和代码交给CodeBuddy，当时的提问是：

分析日志，我现在遇到一个问题，我通过可视化apk执法记录仪进行视频录制，录制时间长了以后，apk会卡死闪退，目前是排查这个相机hal服务meminfo.txt 占用内存，kill 掉这个服务 android.hardware.camera.provider@2.4-service_64 (pid 621)，就恢复正常。请帮我分析代码，解决这个问题

有了问题描述、复现过程、日志和项目代码，Agent就能沿着这些线索展开排查。在这个案例里，它可以把日志对应到内存泄漏的可疑代码块，再结合代码提交记录追查原因，并给出多种解决方案。

很快，codebuddy就分析道日志中关于相机hal的进程占用过高

最后给我下的结论是因为一个关于人为改动导致的相机buffer创建后未释放的问题导致的内存泄漏，而这个问题也困扰了我们另外一个没有用AI分析问题的资深工程师一个月

顺便，AI还给出了问题详细的描述证据和泄漏代码的代码块，是因为一个调试工好问题导致的去掉了一个ASYNC_TYPE丢弃导致的。

然后AI还给出了详细原因和为什么kill之后会解决BUG的解释

最后是修改代码和编译验证，AI给出了最迅速的单编camera 库文件通过push的方式解决问题的方案，这个方向相比于日常编译整个源码要快很多。

以前需要我反复翻日志、查代码、追提交的过程，现在可以让Agent先做一轮完整分析，再尝试修改代码

我的精力随之更多地放在：看分析是否说得通、审阅修改，再编译版本，验证原来的问题是否解决。验证PASS后，我还会回头看它的定位路径和修复思路，把这次排查变成自己的经验

省下来的时间，对普通人很实在

就我日常接触的这类问题而言，按个人使用体感，大约90%能在AI帮助下解决。具体到每一个问题，仍然要靠实际验证来判断

这个变化最直接的价值，是让我从一部分耗时的排查里腾出手来

省下的时间，可以处理其他任务、学习新的东西，也可以给自己的生活多留一点余地。对一个普通打工人来说，这已经很有意义

同时，我过去积累的经验也有了新的用处：把问题描述清楚，判断分析是否合理，理解修改会影响什么，决定怎样验证。这些都需要我继续参与

如果还没开始，可以先试这30天

你不必照搬我的驱动开发场景。整理周报、分析表格、梳理资料，都可以成为起点。选一件自己熟悉的，你觉得能够交给AI开发的工作，让他去尝试一下，说不定有意想不到的收获。

第1周，记录。把这件事原来怎么做、耗时多久记下来，留一个比较的基准单位

第2周，尝试。像提Bug一样交代背景、输入和预期结果（这一步你要知道，你给AI描述的越精细，它解决问题的效率越高），让AI先参与其中一小段

第3周，比较。把准备材料、检查修改的时间都算进去，看总用时、错误和返工有没有改善

第4周，整理。留下有效的做法和核查步骤。好用就继续，不合适就缩小范围或换个任务。最后如果是经常性的内容，你还可以尝试把它做成一个skills。

AI会怎样改变整个行业，还需要持续观察。但在自己的工作里，我们已经可以动手试一试

我先从一个Bug开始。你也可以从手边的一件小事开始，亲自看看它能帮你做到哪一步

如果能让AI帮你分担一项工作，你最想先交给它什么呢？评论区聊聊吧！

如果有任何关于AI的问题求助，可以点赞关注我私信，我看到了都会解答的！点个关注！解锁更多AI前沿知识～

往期精选文章回顾：