从亲手写每一行代码，到学会指挥AI Agent
这是上一篇《如何使用生成式AI 加速MCX MCU的软件开发》的一个后记。
上一篇文章更多讨论的是：在MCX MCU的软件开发中，如何把生成式AI用到资料阅读、SDK示例理解、驱动代码分析、工程配置、问题定位和文档整理等具体环节里。才不到半年过去，AI编程已经跨越到了下一个维度：它不再只是一个“问答助手”，而是一个能读代码库、能修改文件、能运行命令、能做验证的工程超级智能体。
我自己算是比较早开始使用GPT系列工具的用户。过去几年里，我在日常工作中持续使用OpenAI的Codex(目前主力使用GPT5.4, 5.5)，也较长时间使用Anthropic的Claude Code(目前主力 Opus4.6)，近一段时 间也频繁使用Google Gemini(Gemini 3 PRO)。小编认为,与其写成一篇“谁最强”的排名文章，更重要的是形 成一种直觉：什么问题适合交给谁，什么问题必须人来拆，什么结果只能作为提示词或思路参考。
MCU开发并不是单纯写C代码。它同时涉及芯片手册、SDK、启动文件、链接脚本、外设寄存器、时钟树、Keil/IAR/GCC工程、RTOS、中断、pin mux、DMA、低功耗和真实硬件现象。AI可以极大提升信息处理和初稿生成速度，但不能替代硬件验证，也不能替代工程师对边界条件的判断。
以下只是我个人的使用体验,网上也有海量的类似大模型/Coding Agent之间的对比文章, 以下内容仅代表小编个人使用体会。
Claude Code: 更像一线实现型工程师
如果只谈“把一个明确的软件任务落到代码里”，Claude Code在我的日常体验里非常突出。
它比较适合处理这类任务：阅读一个现有工程，理解已有代码风格和约束，然后完成一组相对完整的修改。例如整理驱动接口、重构上位机模块、补齐错误处理路径，或者根据明确的bug现象追踪根因并给出补丁。我对它最大的感受是“克制”。它不只是会写代码，更重要的是知道什么时候不要乱动。对于嵌入式项目来说，这一点很关键。很多MCU工程的软件并不追求漂亮的抽象，而是追求稳定、可追踪、可调试、能被下一位工程师迅速看懂。尤其是客户项目或量产项目，最怕的是AI为了“显得高级”而引入一堆新的helper、全局状态、复杂封装或公共API。
Claude Code的优势在于，它往往愿意先读工程，再动手；会比较尊重现有目录结构、命名习惯和调用关系； 在修改范围明确时，输出比较贴近真实工程师的写法。
当然，它也不是没有代价。第一是成本较高，第二是响应速度不一定快，第三是任务描述不清楚时，它也可能 把“我以为你想要的东西”做得很完整，但这并不等于它做的是你真正需要的东西。所以在MCU场景里，我一般不会把模糊的大命题直接丢给它，比如“帮我优化整个低功耗框架”。更合适的方式是把任务拆成可验证的小块：
-
阅读这个工程，说明当前时钟初始化路径
-
检查这个UART wakeup流程里第一帧数据是否可能丢失
-
在不改变public API的前提下，补齐错误返回路径
-
对这段flash写入流程做review，只关注掉电和越界风险
任务越具体，它越像能力很强的一线工程师；任务越含糊，它越容易热心但跑偏。
Gemini: 更像视野很宽的架构顾问
Gemini给我的感觉不太一样。它的优势不体现在编程，而更体现在最强的世界知识、资料整合、大上下文理 解和多模态输入上，人称美国豆包。他像一个视野很宽的顾问。它能帮你把地图摊开，但不适合冲杀到一线直接撸代码。
当我需要把一堆材料摊开看时，Gemini很有价值。例如对比手册和应用笔记、梳理技术路线、阅读 PPT/PDF/需求文档。很多时候，它适合在我已经有一个直觉但还没有想清楚时，从更高层次帮我审视问题。
Gemini在“先打开视野”的阶段比较适合。它有时能给出一些全局性的提醒：不要只看驱动API，要看clock、pin mux、DMA request、interrupt priority；不要只看demo能不能跑，要看低功耗唤醒后的状态恢复；不要只看外设功能表，要确认封装引脚、板级连接和调试口复用。
Gemini具体实操写代码的能力相对比较差。它有时会显得不太拘小节，尤其是在底层C代码、寄存器细节、 已有工程风格一致性方面，需要更强的人工把关。它适合做“方案发散”和“资料整理”，不适合在没有审查的情 况下直接作为量产代码来源。
Codex: 六边形战士，综合能力最强
Codex在我的使用体验中，最突出的特点是均衡、稳、综合能力强, 适合做review。心思缜密,考虑周到,滴水不漏,嵌入式代码生成及review能力强。
MCU软件里有很多问题不是语法问题，而是工程边界问题。例如：
-
错误码是否被吞掉
-
中断和主循环之间是否存在竞态
-
buffer长度是否同时被协议层和驱动层正确约束
-
flash擦写失败后是否会破坏已有配置
这类问题不一定能靠编译器发现，也不一定能靠一次简单运行发现。它需要读上下文、读调用链、理解原本的意图，再判断新改动有没有破坏旧行为。Codex在这类任务上比较适合作为兜底工具：让它读diff、读相关调用方、读测试，再让它只输出风险，不急着修改。
工程师的角色正在变化
过去软件工程师的核心能力，很大程度上体现在“我能亲手写出多少代码”。但AI Agent出现后，这个比例会变化。
未来的工程师更像一个乐队指挥者。你不一定要亲自吹奏每一种乐器，但必须知道每种乐器能做什么、什么时候进场、哪里跑调了，最后整体效果如何。
放到AI编程里，就是：
-
你要能把大任务拆成小任务
-
你要能识别AI输出里的伪合理
-
你要能设计验证路径
-
你要能承担最终工程责任
这其实比“会不会写某一行代码”更难，因为它要求工程师同时具备技术判断、系统理解、表达能力和取舍能力。
结 语
小编以为: 现阶段仍然可以算是一个相对平权的阶段。普通工程师也能用超低成本接触到很强的模型能力。
但工具越强，差距也可能越快拉开。真正重要的不是“会不会打开某个AI工具”，而是能不能持续更新自己的工作方式，从一次次使用中总结出更好的提示词、验证方法和任务拆分方式。
如果说过去的MCU软件开发更像一个人拿着螺丝刀、示波器和IDE，在一个具体问题前反复打磨，那么现在的开发方式正在变成另一种形态：工程师站在更高的位置，指挥多个AI Agent帮自己阅读、实现、审查、整 理和验证。但指挥者不是旁观者。指挥者要懂乐谱，也要听得出哪里不对。
Claude Code、Gemini、Codex各有特点。它们都不是万能工具。对于MCU开发来说，真正有价值的不是追逐某一个工具的短期排名，而是建立一套适合自己工程场景的AI使用方法：哪些任务可以交给AI，哪些任务必须人来判断，哪些结论必须上板验证，哪些流程可以沉淀成长期习惯。
评论区
登录后即可参与讨论
立即登录