从 SDK 到 AI-native Development Agent：我们在一家 MCU/DSP 原厂跑通了这条路

最近几年，Coding Agent 的发展速度非常快。Claude Code、Codex 已经不再只是代码补全，而开始具备理解代码仓库、修改工程、运行测试、定位问题，甚至完成复杂开发任务的能力。

这也带来了一个新问题：

当通用 Coding Agent 已经越来越强，MCU/DSP 原厂为什么还需要自己的 Coding Agent？

先看几家原厂现在怎么走。

TI：把 Claude Code / Codex 接进 CCStudio

TI 在 2026 年发布的 CCStudio 21 里已经明确支持 Codex，并持续增强 AI Agent / Skill 相关能力。CCStudio 本身覆盖 C2000、DSP、Sitara、SimpleLink 等嵌入式产品，所以这不是单纯「代码聊天」，而是把 AI Agent 接到真实 IDE、工程、Build / Debug 环境里。TI 官方文档甚至专门提供了 CCStudio + AI / Code Assistants 的配置体系。(Texas Instruments)

我们也把 Coding Agent 接到了这套生态里。TI 这边仍以 CCS Studio 为主，原厂的开发者习惯已经在 IDE 里，Agent 必须走进这个现场，而不是另开一个窗口。

Microchip：直接做自己的 MPLAB AI Coding Assistant

Microchip 这条路线更明确：基于开源 Coding 工具做二次开发，持续注入原厂上下文，目标之一就是减少幻觉。

它推出了 MPLAB AI Coding Assistant，基于 Continue 做 Microchip 专用版本，直接面向自家产品开发，支持：

• Autocomplete
• Generate / Edit Code
• Review / Explain Code
• Microchip-specific Chat
• 在编辑器里直接访问 Datasheet

Microchip 自己强调，这套工具持续注入 Microchip-specific information，相比公共 AI 工具要减少幻觉。(Microchip)

更进一步，它已经加入 Agent Mode + MCP Server。MCP 可以让 Agent 直接查询 Datasheet、Evaluation Board User Guide、Compiler Guide、Example Projects、Training Videos 等官方资料。(Microchip Developer Help)

Microchip 还在 2025 年发布了独立的官方 MCP Server，让兼容的 AI / LLM 获取经过验证的产品规格、Datasheet、库存、价格和交期等结构化信息。(Microchip)

所以 Microchip 的路线已经很接近：

Coding Agent + 原厂知识接口。

ST：先解决「资料太多、找不到正确答案」

ST 当前更偏知识入口，路线和 TI 有相似之处：IDE 已经很成熟，用户习惯已经在那边。接下来要决定的是：做一个全新的 AI 入口，让开发者更快用起来；还是站在现有使用路径上，让原来的工作做得更好。

它推出的 STM32 Sidekick 主要基于 STM32 官方资料回答开发者问题，包括产品文档、产品信息和官方内容，给开发者一个自然语言入口去找技术答案。ST 公开说明其底层采用 RAG，把官方资料作为回答依据。(STMicroelectronics)

所以 ST 目前更像：

STM32 官方可信知识助手。

再结合原有 STM32CubeMX、CubeIDE、HAL / LL 等开发工具，实际上也是在逐步降低开发者找资料、配置工程和上手 STM32 的成本。

乐鑫：开始把 Agent 往 Build / Flash 方向推

乐鑫通过 ESP-IDF，让 AI 更好地理解代码和文档，并进一步进入项目配置、Build、Flash 等真实开发动作。

乐鑫已经开始通过 ESP-IDF 的 Agent / MCP 能力，让 AI 不只理解代码和文档，而是进入真实开发执行。

它代表了另一个方向：

从 AI Coding 继续往 AI Development Execution 走。

把四家放在一起看，趋势其实很明显

它们路线不同，但共同点非常清楚：

原厂正在把过去给「人」使用的 SDK、文档、IDE、Example 和工具链，逐渐变成 Agent 也可以理解和调用的基础设施。

这里会分出两条路：一家 AI 公司去做 MCU 场景下的 Coding Agent，还是一家 MCU 公司自己去适配 AI Agent。角度不同，做出来的东西也不一样。

我们认为下一步不是再做一个通用 Coding Agent，而是帮助 MCU/DSP 原厂把自己的 Developer Ecosystem 重新组织成 Agent-native 的 Developer Infrastructure。

上一篇我们也写过：芯片公司对 AI 的认可度，决定了它接下来的产品形态，是围绕 AI 重建，还是只在原有基础设施上加一层 AI。差别很大。

下面按具体场景说清楚：为什么 DSP、MCU 这个场景特别需要 AI。

MCU/DSP 原厂最大的成本之一，是让客户把芯片真正用起来

这不是拷一个 hello_world 就结束。下面是一些真实会卡住项目的环节。

从 Demo / EVM 到客户自研板的 Bring-up

NXP 官方的 Custom Board 流程就要求重新处理 board.c/h、Clock、PinMux、CMake / Kconfig、启动配置、Flash runner、Debug runner；Flash / Debug 又涉及 LinkServer、J-Link、Flash Address。客户第一次从原厂开发板迁到自己的 PCB，本身就是一整条工程链。

外设初始化和系统资源配置

GPIO、Clock Tree、PinMux、ADC、PWM、DMA、Interrupt、Middleware 之间有大量约束。STM32CubeMX 之所以专门提供 Pinout 冲突处理、Clock Tree 校验、Peripheral 配置和初始化代码生成，就是因为这部分本身就是 MCU 开发的主要上手成本。ST 官方甚至直接把「降低开发时间」和「减少配置错误」作为 CubeMX 的核心价值。

复杂外设和实时控制功能的二次开发

TI 的 C2000 CLB 可以做自定义 PWM、修改 ePWM、编码器接口、自定义串行协议，甚至替代部分 FPGA / CPLD 功能。官方支持里就有客户问「外部触发的一次性 PWM 怎么实现」，FAE 会定位到具体 CLB Example，再告诉客户怎么把示例迁到自己的器件和 SysConfig 配置。

DSP / 实时控制并不是「写几个寄存器」

以 C2000 MotorControl SDK 为例，原厂需要支持 FOC、无感 / 有感控制、Resolver / 增量 / 绝对编码器、电流采样、MTPA、Field Weakening、启动失败恢复、失相保护、振动补偿、CAN / FSI / EtherCAT；CLA 又涉及 CPU 与协处理器之间的内存、消息 RAM、触发和实时任务。客户经常要的不是 API 解释，而是一段能进入真实控制系统的应用方案。

SDK 版本、器件迁移和平台迁移

一个 Example 在旧芯片能跑，不代表换一颗料还能直接跑。TI 专门做了 C2000 SysConfig migration；NXP、Infineon 都有 BSP / SDK version、custom BSP 和迁移体系。Infineon 就明确要求自定义硬件时重新处理 clocks、pins、peripherals、BSP 和 library versions。

Build / Flash / Debug / 现场故障定位

这是通用 Coding Agent 最容易低估的一块。代码能编译，不等于板子能跑：Boot Mode、Flash 地址、Debugger、UART、时钟、供电、Pin 配置，都可能导致「烧进去了但是没反应」。NXP 的官方 Bring-up 文档就明确涉及 Flash boot mode、debug probe、terminal 设置；Infineon 的真实支持案例里，遇到客户系统异常，官方会要求进一步查看 schematic + software code，才能由 FAE 协助定位。

培训、Example、FAQ、Debug Tips 本身就是 FAE 的巨大重复劳动

TI 的 CLA 官方学习路径非常典型：Workshop → Examples → FAQ / Debugging Tips → System Use Cases。ST 对自己的 FAE 描述也包括 firmware development、customer support、training。原厂今天本来就在花大量人力，把「芯片怎么用」不断解释、演示、迁移、Debug 给客户。

我们的答案是：

因为 MCU/DSP 行业真正的竞争，并不只是「谁能生成更多代码」，而是谁能够帮助开发者更快、更低成本地把芯片真正用起来。

对于 MCU/DSP 原厂来说，最大的壁垒之一，并不是芯片设计本身，而是围绕芯片建立起来的 Developer Ecosystem。

MCU/DSP 最大的成本：让客户真正把芯片跑起来

一颗 MCU 进入客户项目之后，难点才刚开始。真正难的是一整套开发者生态：选型、开发环境搭建、SDK 和 Example 学习、Clock 与 PinMux 配置、外设初始化、自研板迁移、Build、Flash、Debug，以及后续的性能优化和量产问题。任何一个环节出错，都可能让项目卡上几小时、几天，甚至更久。现在很多场景仍然是原厂 AE 驻场，帮客户调试、帮客户快速上手。

一个工程师从拿到芯片，到最终产品运行，中间通常需要经历：

选型
↓
安装工具链
↓
学习 SDK
↓
理解 Example
↓
配置 Clock
↓
配置 PinMux
↓
初始化外设
↓
迁移到自研板
↓
Build
↓
Flash
↓
Debug
↓
性能优化
↓
量产问题处理

其中任何一个环节出现问题，都可能导致项目延期。

很多时候，客户遇到的问题并不是：

「我不会写这段 C 代码。」

而是：

「这个功能应该从哪个 Example 开始？」

「这个 SDK 版本应该用哪个 API？」

「为什么开发板可以运行，换成自己的 PCB 就不工作？」

「这个问题到底是软件问题，还是 Clock、Pin、硬件配置问题？」

这也是为什么 MCU/DSP 原厂需要大量 FAE 和应用工程师支持。

原厂最宝贵的资产，其实是 Developer Enablement 能力

原厂最宝贵的资产，其实是一颗 MCU 从出生到客户量产的全生命周期经验。同类客户可以复用，持续沉淀，形成团队资产。

一个优秀的 MCU/DSP FAE，价值并不只是熟悉 Datasheet。

更重要的是，他知道：客户提出一个需求以后，应该参考哪个 Example，应该使用哪个外设模块，应该修改哪些配置，当前 SDK 版本有哪些坑，哪个问题优先检查硬件，哪个问题优先检查软件。

例如，一个客户想实现特殊 PWM、编码器接口或者可配置逻辑功能。

对于普通开发者来说，需要搜索 User Guide、Application Note、Example、SDK 文件和 Forum。

但一个经验丰富的 FAE，可能几分钟就能判断：

• 是否适合使用 CLB
• 哪个 C2000 Example 最接近
• SysConfig 如何配置
• 哪些寄存器需要注意
• 如何迁移到客户工程

这类能力非常宝贵。但问题是，它长期存在于 FAE 个人经验、客户邮件、历史工单、培训材料、示例代码和工程师记忆里，很难规模化复制。

所以我们认为：

MCU/DSP 原厂真正需要解决的问题，不只是代码生成，而是如何把 Developer Enablement 能力产品化。

我们正在做的：原厂定制 Coding Agent

我们的思路不是先做一个 Coding Agent，而是先从评测开始。

我们先把 TI、Microchip 这类原厂公开问题，以及真实 MCU/DSP 开发支持场景中的历史问题，整理成 Eval 数据集，先定义什么叫「回答正确」、什么叫「工程上可用」。在这个基础上，再构建自己的 LLM Wiki / Code Wiki，把 Datasheet、Manual、SDK、Example、版本关系和真实问题，逐步组织成一套可持续迭代的知识基座。

这个知识基座同时服务两个入口：

• 问答：FAE、AE 日常大量问题，其实通过高质量 Chatbot 就能解决；问答本身也是持续收集真实问题、发现 Wiki 缺口、推动知识回写的入口。
• Coding Agent：当任务从「告诉我怎么做」进入「帮我改代码、迁移工程、Build、Flash、Debug」时，再进入真正的生产执行。

我们之所以自己搭 Harness，而不是完全依赖 Claude Code 这类现成 Agent，是因为我们需要看到和控制完整的检索、工具调用、执行轨迹、失败原因和中间状态，才能把这些 Trace 持续回流到 Eval、Wiki 和 Agent 策略里做迭代。

简单说，我们真正做的是一条闭环：

Eval
↓
Wiki
↓
问答 / Coding Agent
↓
Trace
↓
回写
↓
再 Eval

Coding Agent 只是其中的执行层。真正长期积累的，是知识基座、评测体系和可观测的 Agent Harness。

这也是我们正在探索的方向：帮助 MCU、DSP 原厂构建属于自己的 AI-native Developer Ecosystem。

相关产品见 Coding Agent 和 MCU / DSP 场景说明。如果原厂希望把 SDK、文档和工具链做成 Agent-native 的开发者基础设施，欢迎 预约沟通。