芯耀
与非AI
126
我是老温，一名热爱学习的嵌入式工程师，关注我，一起变得更加优秀！
各位嵌入式老铁，最近 Agent 编程是不是越来越热了？我这几个月一直在折腾一件事：怎么让 AI 真正看懂我们的嵌入式软件工程。
不是"帮我写个冒泡排序"的那种看懂，而是"我改这个函数，会不会顺带影响其他三个模块"的那种看懂。（后者才是我们日常真正需要花精力的地方~）
最近，我试了一个工具，叫 CodeGraph，开源而且本地运行，我觉得，还真有点意思~
上周五下午，我拿手上的 RK3568 网关项目试了一下，从装 CLI 到索引建完，前后大概花了20 分钟。
进项目根目录，一条 codegraph init，图谱存成 SQLite 放在 .codegraph/ 目录里。
然后我试着问了一句：modbus_receive 被谁调用了。
几秒钟的时间，函数的完整调用链就出来了，从 TCP 接收回调一路追到应用层处理函数，每一跳都带行号。
（搁以前这活儿我得 grep 一遍，再人肉顺着几个文件跳进去看，少说也得花费十分钟~）
整个过程给我一种感受就是：我们总在抱怨 AI 不够聪明，但真正卡住的可能不是模型，而是我们喂给它的东西。
你会想， Agent 平时是怎样读代码的吗？grep 一圈，Read 几个文件，发现不对，再 grep 一圈。一轮下来大部分 token 烧在"找"上面，真正用来"想"的没多少。
而"找"这件事有个特点：它是确定的，并且每次都一样。
一个函数被谁调用，这是代码里客观存在的事实，不会因为你今天心情好就改变。那既然如此，它就不该每次对话都重算一遍，应该提前算好、存起来、随查随用。
这，就是 CodeGraph 干的事：用 Tree-sitter 把源码解析成语法树，把调用关系和依赖关系抽出来存成图谱，再通过 MCP 暴露给 AI 编程工具。查询从"翻箱倒柜"变成"查目录"！
更关键的是，它的抽取是确定性的，直接从 AST 推导，不让大模型去总结。
这一点我是特别认同的。因为我们这行代码是要过评审、要过功能安全的。
一个"AI 觉得这里大概是这么调用的"结论，没人敢拿去改驱动！但从 AST 推出来的调用关系，可复现、可审查，出了问题能查到是哪一步推出来的。
（让 AI 去猜代码结构，这事儿本身就离谱，明明就有确定的答案）
但我也要泼一盆冷水。
CodeGraph 的边界，恰好卡在了嵌入式项目最难受的地方。
C、C++、Python 都是完整支持，但汇编、Shell 脚本、设备树，还有 Makefile、CMake、Kconfig 这些构建文件，全都不在支持清单里。我把支持情况整理成了表格：
这意味着什么？
你想追一条"从设备树匹配到驱动 probe 再到 input 事件上报"的链路，图谱里只有 C 代码那一段，compatible 匹配那一段是断的。
你想搞清楚某个 .c 到底有没有被编译进去，Kconfig 和 Makefile 那层判断，图谱帮不了你。
而这些地方，恰恰是嵌入式项目里最容易踩坑、最耗时、最需要上下文的地方！
所以我的结论是：图谱结果不能直接当结论，它是一张地图，不是一份报告。
它能告诉你"这一段路是通的"，但不能告诉你"整段路都是通的"。断点在哪儿，得你自己心里有数。
还有个坑，卡了我一会儿。
我去 Agent 里看 MCP 工具列表，发现只有一个codegraph_explore。
翻了文档才明白：另外 7 个工具都存在、功能完整，但默认不列出来，官方的理由是，它们的返回内容已经内联在 explore 的响应里了。
如果想全开，就需要自己设环境变量：
CODEGRAPH_MCP_TOOLS=explore,node,search,callers,callees,impact,files,status 注意，这个是允许列表，会替换默认集合，不是追加。我第一次只写了一个 impact，然后纳闷半天怎么 explore 不见了~
还有一条：工作区里没有 .codegraph/ 索引时，MCP server 会自己宣布 inactive，一个工具都不列。排查连接问题先确认索引在不在。
那么，CodeGraph 到底值不值得安装？值得的，但要摆对期待。
它比较适合做两件事：改代码之前的影响分析，和接手一个谁都不敢动的祖传 BSP。
前者，改公共函数之前把所有调用者列出来，在几十万行的 SDK 或者 vendor kernel fork 上，性价比极高！
后者，新人不用再花两周读代码，直接问"UART2 从 ISR 到应用层回调这条链怎么走"，几秒钟就可以出结果。
再加上 100% 本地运行，没有云端索引，不要 API key，代码一个字节都出不去。在军工/车规/工控这些代码就是核心资产的团队，这一条直接决定了工具能不能用。
（我们这边代码是明确不能上云的，这条对我来说是硬门槛）
最后说说对CodeGraph的期望管理。
别把它当"token 减半"的神器。官方的基准数据是：工具调用减少 58%、执行时间加快 22%、文件读取降到接近零，我把这些数据也整理成了表格：
至于 token 和成本，官方原话是节省确实存在，但属于规模相关的收益，普通规模代码库上"又小又噪"，代码库和团队变大之后，收益才会变得可观。
翻译成人话：小项目收益有限，大项目才划算！
工具的价值不在于它宣传了多少数字，而在于它帮你省掉的那几次"我改这个会不会炸掉其他模块"的心慌。
好了，今天就先说这么多。各位老铁，你们团队给 AI 喂上下文这件事是怎么搞的，欢迎评论区聊聊~
