用AI助手CodeBuddy协同开发:初次见面有爽感

关注公众号, 即可获得与Linux相关的电子书籍(含《嵌入式系统设计与应用》)以及常用开发工具，文末有文档清单，本公众号提供的电子书均只可作为个人学习使用，不可用做商业用途。

🌸 初次使用CodeBuddy

开始我弄错了，以为让安装WorkBuddy，安装完立马提问，让它给我提供用WorkBuddy协同开发的基本配置流程，结果它把我的电脑扒了个底朝天，看着就是一安装就获得了最高权限一样，这一点点安全感都没得了哇，后面才知道要装CodeBuddy 。

切换到 CodeBuddy 之后，第一件事就是去寻找减少token消耗的相关配置 ，因为现在我的项目里sdk代码量还是非常大的，查到可以在工作空间目录下配置.codebuddy/settings.json，通过 permissions.deny 配置屏蔽规则，把编译产物、工具链、第三方大目录全部限制读取，同时增加规则禁止 SVN 自动提交代码。

配置完成，效果立竿见影，工具响应速度提升了一个量级。AI协同开发这条路，我们开发者需好好思考如何把控边界。

🌺 亲测能真实地效率提升

经过下午亲测，CodeBuddy确实能为嵌入式开发减负，是实打实的效率提升。

第一： 快速定位代码修改的遗漏点。

今天移植SDK中改一个需求，将默认的文件系统jffs2格式改为squashfs，我漏掉了一个修改，导致启动不了，让AI改，很快找到问题并修复了，很精准。我的提示词：

帮我修改文件系统jffs2格式为squashfs，目前我修改完烧写到系统里报错："错误日志......"只按需读取本次问题相关文件，不要预加载整个项目所有源码不要自动执行命令，先给命令让我确认:所有shell命令先展示给我确认，我同意后再执行

做BSP相关修改还是比较容易遗漏关联配置模块的修改的，比如GPIO 复用、调整 MTD分区参数，驱动层、设备树、板级配置文件都需要同步改动。人工评审的时候，很容易顾此失彼。

CodeBuddy可以顺着代码调用链，快速检索关联文件，直接提示风险：代码改动了，但头文件宏定义未同步更新、多平台编译选项不一致。这类细节，人工排查耗时久，AI 几秒就能识别出来，作为第二双代码审查眼睛非常好用。

第二：代码修改精准可控。

不需要完整描述整套工程背景，只需要贴报错日志，或者描述需求，它可以精准定位代码行做修改，不会输出大量空泛无用的建议。

像Linux内核适配、SPI NAND 调试、UART 资源冲突这类底层问题，省去很多查阅、检索基础代码的重复工作。

第三：快速构建「报错 - 修复 - 编译」闭环。

我固定了工作流：问题分析→代码diff修改→本地编译打包→输出编译日志。

工具可以提取编译报错，定位根因并给出修复方案。以前需要逐行啃报错日志，现在AI先完成基础排查，我只需要在关键技术节点做决策，大幅缩短调试周期。

初次见面，爽感满满。

🌷 爽感之后，真正让我警惕的，是 "掌控力的流失"

效率提升是事实，但很多用过了AI协同开发一段时间之后的友友反馈，潜在风险，感觉自己什么都不会了。

想想也是，以前啃过的问题，都会留下深深的印象。

现在借助AI，几分钟就能拿到修复方案，问题快速解决。但有一个隐患：

原本需要靠深度调试沉淀下来的底层理解，很容易被跳过。

工具越智能，开发者自身的技术肌肉记忆越容易退化。在日常开发里，几个危险信号值得警惕：

1. 习惯AI改，开发者只简单浏览diff，慢慢不再深究改动背后的原理；

2. 遇到报错，第一反应不是自己分析日志，而是直接复制日志丢给AI，把问题分析能力外包；

3. 长期依赖AI辅助，底层原理、驱动时序、内核机制理解变浅。

对于嵌入式开发者，技术掌控力不是虚的概念，它由三部分组成：底层原理理解 + 独立排障经验 + 工程架构判断能力。而这些，恰恰是AI最容易替代，也最难事后补回来的硬实力。

面试官不会关心你会不会用AI工具，只会深挖底层原理、驱动设计思路。如果长期依赖AI代劳，核心能力会慢慢空洞。

🌻 给自己定下的使用底线：AI是助手，不是大脑

为了避免过度依赖，我给自己定下几条硬性使用规则：

✅ AI 定位为第二审查眼睛，不替代核心决策

所有关键代码改动，要求它先给出修改方案和原理说明，由我判断方案合理性，而不是直接落地代码。它负责检查遗漏，最终技术判断权保留在自己手上。

✅ 先读核心代码，再调用AI辅助

接手新模块，先独立通读关键源码，再让AI介入。遇到看不懂的代码片段，可以让AI解释原理，倒逼自己吃透底层逻辑。每一处diff，必须能独立讲清楚：为什么这么改、改动前后差异是什么。

✅ 卡住之后，先独立排查30分钟，再求助AI

遇到Kernel panic、Flash适配这类疑难问题，给自己设置门槛：先独立阅读日志、追溯代码。尽力尝试之后无法突破，再交给AI辅助。保留亲手排错的过程，就是守住底层技术经验。

✅ 定期脱AI自测复盘

每周选取一个负责模块，关闭CodeBuddy，纯人工阅读代码、梳理逻辑、排查问题。相当于定期自测，检验自己是否真正掌握模块原理，避免 “看得懂 AI 给的代码，但自己独立写不出来”。

💐长期规划：用AI提速，不用AI替代思考

[阶段一]:

熟练落地 CodeBuddy 的权限配置，固化「人工审核为主，AI 辅助修改」的工作流。

重复、遍历检索、基础代码修改这类机械工作交给 AI；架构设计、底层原理分析、疑难问题判断，保留给自己。目标：把 AI 变成效率放大器，而不是思考替代品。

[阶段二]:

依托BSP转型主线，利用AI补齐知识短板，而不是回避难点。

借助工具快速查阅陌生驱动、内核相关知识点，但每一个知识点都做到学懂吃透，不能只复制解决方案。持续做技术输出，写技术复盘、调试笔记。能把原理用自己的语言复述出来，才算真正掌握。

[阶段三]:

理想的分工模式：AI承担80%重复性机械工作，开发者牢牢抓住20%核心能力：架构设计、复杂疑难故障定位、整套BSP工程全局把控。

未来AI编程工具会越来越普及。最终拉开开发者差距的，不是谁更熟练使用AI工具，而是在工具加持下，还能保有独立工程判断与底层技术功底。

🌸 写在最后

CodeBuddy可以帮我快速检索代码、找出修改遗漏、精准修改代码，实实在在节省大量开发时间。

但作为有多年嵌入式开发经验、正在探索BSP方向的开发者，我很清楚：工具只是放大器。若我们有扎实的判断力，它会放大我们的能力；如果我们选择偷懒，它会放大我们的短板，掩盖能力漏洞。

守住边界，让CodeBuddy 提速，但是让自己的大脑持续思考。速度交给工具，技术掌控权，留在自己手里。

往期文章（欢迎订阅技术分享栏目全部文章）：

15年+嵌入式软件开发经验兼二胎宝妈

分享读书心得、工作经验，自我成长和生活方式。

希望我的文字能对你有所帮助