嵌入式工程师用 Coding Agent 到底卡在哪：编译烧录调试闭环尚未接通

文章从嵌入式软件工程师的实际使用现状切入：CubeMX、Keil、ESP-IDF 等工具都能打开，ChatGPT、通义等网页对话也在用，但 Coding Agent 在日常开发中多半仍停在代码补全或聊天框里，没有进入工程闭环。作者明确划定讨论边界，不谈板上 NPU、Cube.AI / eIQ 这类端侧 AI 推理方向，只讨论 Coding Agent 如何进入需求澄清、写代码、本地编译、烧录上板、调试回读、补文档到轻量 CI 的日常流程，且尽量不绑定具体工具。 作者认为当前缺的不是证明 AI 有用，而是一套跨工具、能落地的接法：厂商自带助手往往锁在自家生态内，社区 MCP 和 IDE 侧协议又偏新，教程与治理滞后。谁先把“需求 → 代码 → 编译烧录 → 调试 → 文档 → 轻量 CI”接清楚，谁就先少跑几趟来回。文中还提到一种常见卡点：不是不会问大模型，而是问完的结果接不回本机工程，两边复制粘贴看似高效，闭环始终断着。 在可放手尝试的部分，作者列出本地构建、读编译日志、按报错改语法和头文件路径，认为这类动作上手成本低、翻车代价可控；不放心时可先只让 Agent 读工程、解释报错，凡涉及硬件的动作全部留给工程师。必须人工把关的部分包括目标芯片选错、下载算法配错、量产板或客户板误刷以及 mass erase，还有板上偶发死机、时序毛刺、示波器与 bring-up 等场景，这些代价 Agent 不会替工程师承担。 因此工程师需要自己设计决策闸门：写清工具链入口，破坏性动作要确认，失败后如何回滚，并把这些想明白后喂进项目上下文。作者强调编译通过不等于板上正确，Agent 说测过了也不等于独立门禁通过。行动建议是不一开始就给 Agent 全开烧录权限，先挑一块非关键板块接入“编译 → 读日志”这一小段，烧录权限往后放，先证明 Agent 能顺利接上工程再谈闭环。