英飞凌发布ModusToolbox AI Assistant：先给器件上下文，再让AI写嵌入式代码
10 月 20 日，英飞凌发布面向 Visual Studio Code 的 ModusToolbox AI Assistant 扩展包，首批支持 PSOC Edge 与 PSOC Control 两个 MCU 系列。扩展的作用是给通用 AI 编码代理补上硬件上下文，让生成的结果对齐开发者实际的器件、板卡与外设配置。
通用 AI 编码助手在嵌入式场景里出错的典型形态，英飞凌在公告里列了三种：选错目标器件、调用已废弃的 API、漏掉某个初始化步骤——这几种错误在代码层面上看起来都对，要到板子上跑起来才暴露。扩展的处理方式是在本地分析工作区：读取项目结构、 板级支持包 （BSP）、已安装的中间件、代码示例与可用工具，据此向 AI 代理提供器件特定的指令与开发技能，覆盖 GPIO、I²C、SPI、UART、DMA 等外设，以及连接与 RTOS 相关功能。
工作流中有一道显式的审阅环节。生成代码之前，扩展先产出一份项目计划，列明目标器件、板卡、所需库与项目结构，开发者可以先改计划再让它写代码。同一套流程支持把既有项目迁移到其他英飞凌器件；Device Configurator 与 Library Manager 可以从 AI 对话里直接启动，不必在编辑器与独立工具之间来回切。
「AI 辅助的工作流正在改变开发者构建嵌入式系统的方式。」英飞凌 IoT 计算与无线业务执行副总裁 Sam Geha 表示，「通过 ModusToolbox AI Assistant，开发者可以把生成式 AI 的效率与我们单片机和无线产品所需的器件特定知识结合起来。项目上下文在本地处理，客户在加速从概念到部署的同时，仍然掌握自己的开发数据。」
本地处理这一点，对应的是嵌入式客户的实际约束。芯片选型阶段的项目往往处在保密协议下，代码不能上传到外部服务；部分企业的 IT 安全策略直接禁止把工程文件发给云端。扩展把分析限制在开发者本机，使其在受限环境中也能部署。扩展兼容 GitHub Copilot、Cursor 与 Windsurf，本身不绑定某一家代理。
使用门槛是 VS Code 1.85 与 ModusToolbox 3.7 或更新版本。PSOC 4、PSOC 6 与 TRAVEO T2G 三个系列的支持列入后续版本计划，本期未包含。
这层能力建立在英飞凌已经把 ModusToolbox 工作流搬进 VS Code 的基础上。此前该系列的 ModusToolbox for VS Code 扩展已经上架 Marketplace，把项目创建与配置、构建、烧录、调试、BSP 与中间件管理、工具启动器都放进编辑器，并在 PSoC Edge 上支持多核应用。AI Assistant 是叠加在这条路径之上的扩展包：底层工具链不变，新增的是把工程上下文转成代理可读的指令与技能。对已经在 VS Code 里做 PSOC 开发的团队，接入时不需要换工具链；仍在用 Eclipse 版 IDE 或命令行的团队，则需要先迁到 3.7 以上的 ModusToolbox。
英飞凌称这套上下文能让生成的代码更准确、并减少 token 消耗。这类指标取决于工程本身的信息完整度，落到三个具体环节：工程配置是否齐全——未在 Device Configurator 里配置的外设，扩展无从推断其引脚与时钟；中间件版本与示例工程是否匹配，版本错位会带来能编译但运行异常的组合；生成的代码能否直接进入构建与烧录验证，中途仍需人工补齐的部分有多少。板级 bring-up 阶段最常见的错误是引脚冲突、时钟树配置遗漏与初始化顺序颠倒，这类问题正是把器件上下文喂给代理之后应当减少的部分。