[连载]AI Agent编程之旅:基于GLM和Qwen 构建智能体(3)7. 小试牛刀:当“代码荒原”被照亮
配置好环境后,我没有急着让它写新代码,而是做了一件更符合“中登”身份的事——让它看我的“旧账”。我打开了一个三年前的嵌入式项目文件夹。那是我的“代码荒原”代表作:充斥着各种为了兼容旧硬件而写的#ifdef地狱,变量命名随心所欲,注释更是少得可怜,连我自己现在看都觉得头大。我把这个文件夹告诉了 opencode ,并发出指令:“帮我分析一下这个项目的架构,顺便看看有没有重构的建议。”原本以为会等个几分钟,结果几秒钟后,屏幕开始滚动。GLM 没有像以前的工具那样只给我堆砌代码片段,而是像一位经验丰富的老架构师,条理清晰地列出了模块依赖关系。它甚至自动生成了流程图,把那些纠缠不清的驱动层和应用层逻辑画得明明白白。更让我惊讶的是它的“迭代思路”。它指出了一个我当年为了赶工期而留下的隐患。那一刻,我仿佛看到了一束光,照进了这片荒芜已久的代码废墟。它不仅仅是在“读”代码,它是在“懂”代码。这种被理解的感觉,对于一个在管理岗上坐了7年、早已远离一线编码的老兵来说,简直是一种久违的慰藉。8. 下一步,请继续执行:硅基副驾的“爽文”节奏
我心动了。我决定拿一个具体的功能模块开刀:给这个老项目加一个全新的 MQTT 通信功能。这在以前,我需要查文档、写驱动、调协议栈,起码得磨叽两天。在 opencode 里,我切换到了 Plan 模式。我在对话框里敲下了我的需求:“基于现有的 UART 驱动,集成一个轻量级 MQTT 客户端,要求支持断线重连,不要占用太多 RAM。”- 修改 CMakeLists.txt 或 Makefile。
计划看起来很完美,逻辑闭环,甚至考虑到了我提到的 RAM 限制。我深吸一口气,切换到了 Build 模式,敲下了那个充满魔力的指令。屏幕上,字符再次飞舞。opencode 开始 autonomously(自主地)创建文件、写入代码。每完成一个步骤,它就会停下来,像个礼貌的实习生一样问我:“下一步计划是修改 XXXX,是否继续执行?”看着屏幕上自动生成的代码,那种“指哪打哪”的快感油然而生。我不再需要敲击键盘去纠结分号放在哪,不需要去查 malloc 会不会失败。我只需要做一个决策者。我像个甩手掌柜,一次次地确认。看着文件列表越来越长,代码行数飞速上涨,我仿佛看到了那个曾经“手敲代码”的少年,正坐着时光机回来,只是这次,他手里拿的不是螺丝刀,而是指挥棒。9. 幻觉,还是幻觉:当“一本正经”遇上“胡说八道”
我看着屏幕上不断刷新的 Success 和生成的代码块,心里乐开了花。这就是我一直想要的“赛博进化”吗?这就是 GLM 承诺的“智能体”吗?太好用,好用到让我有点不安。作为在嵌入式深坑里蹲了 13 年的老兵,我的直觉开始报警。太顺了,这不符合常理。嵌入式开发充满了硬件的“脾气”:寄存器的时序、内存的对齐、中断的优先级、编译器的版本差异……这些细节,AI 真的能完全掌握吗?我停下了点击“继续”的手指,决定像个真正的 Leader 一样,去 Code Review 一下它干出来的活。第一眼看过去,代码格式工整,注释清晰,变量命名规范,简直就是教科书级别的“优秀代码”。它调用了一个 UART 发送函数 HAL_UART_Transmit_IT,参数里传了一个缓冲区指针。乍一看,逻辑严丝合缝。但定睛一看,那个缓冲区居然是个在函数里定义的局部栈数组!
我瞬间后背发凉。_IT 后缀意味着这是异步中断发送,函数调完立刻返回,数据是靠后台中断一点点往外挪的。可局部栈数组的命,只活到这个函数 return 的那一瞬间。函数一旦退出,栈空间马上被后续调用覆盖。等 UART 中断真正触发去读数据时,内存里早就不知道塞了什么乱七八糟的东西。
这不是编程,这是给板子埋雷。典型的“自杀式”写法!
再往下看,它引用了一个头文件#include"mqtt_config.h",但我翻遍了整个工程目录,根本没有这个文件。它是自己“幻想”出来的。刚才那个“全栈极客”瞬间变成了一个“只会背八股文的实习生”。它生成的代码,表面光鲜亮丽,逻辑看似通顺,但一放到真实的硬件环境里,立马就会板子变砖,或者跑飞。我靠在椅背上,看着屏幕上那些还在滚动的字符,突然感到一阵荒谬。前文提到的“Vibe Coding”的阴影又回来了。GLM 确实是个天才的“规划师”,它能画出完美的蓝图;但作为一个“执行者”,它在面对嵌入式这种对细节要求极其苛刻的领域时,依然会“一本正经地胡说八道”。那种“生成的代码与实际的期望之间巨大的落差”,像一盆冷水,浇灭了我刚才的狂热。“看来,”我自言自语道,“这个‘中登’还是得亲自把关。AI 可以帮我写代码,但它还不能替我‘负责’。”这场与 AI 的“捉迷藏”,才刚刚露出它狰狞的一面。