MCU / DSP 项目里，读手册、配时钟、找例程、排 hard fault 的时间，经常超过写业务代码。通用代码助手能生成看起来正确的初始化函数，却可能用了错误的复用脚、过时的 SDK API，或忽略勘误表。
Coding Agent 要解决的，是让原厂全部技术资料进入 VS Code 里的真实工程，而不是再开一个与项目脱节的聊天窗。
它真正能帮忙的工作
- 外设 bring-up：时钟树、引脚复用、中断和 DMA 初始化
- 按手册改配置：对照寄存器与推荐顺序，而不是只抄例程
- SDK / 工程迁移：版本变化后定位 API 和行为差异
- 编译、链接、启动失败：结合工程和原厂限制缩小范围
- 引用证据：指出手册、头文件或示例里的依据，方便复核
这些都依赖“先识别工程、芯片和 SDK”，再检索资料。顺序反了，代码越流畅越危险。
它不该被当成什么
- 不替代示波器和逻辑分析仪
- 不保证生成代码一次上板成功
- 不在缺少芯片上下文时充当通用 Copilot 的替代品
对 国产 MCU 替代 项目，Coding Agent 的价值是把两套 SDK 的差异变成可检查的修改，而不是宣称“已经兼容”。
和 FAE、P2P 如何配合
选型与手册对比仍由 P2P Agent 和 AI FAE 处理。开发阶段的问题进入 Coding Agent。企业知识仍在 LLM Wiki。三者共用同一底座，口径才不会在“能不能替”和“代码怎么写”之间分裂。
适合谁
MCU / DSP 原厂的应用与生态团队，以及长期维护同一系列芯片工程的开发者。通用团队如果没有芯片资料治理，应先补知识底座。
