JetBrains 在 CLion 2026.2.2 版本中加入了一项专门用于分析基于 ARM Cortex-M 的嵌入式系统项目中 Hard Fault 错误的 AI 技能。该技能使用集成在开发环境中的 MCP 工具读取状态寄存器、内存和代码指令，然后将这些信息与导致故障的指令地址关联起来，而不是让开发者面对需要手动分析的原始日志。
该功能针对的是嵌入式软件调试中的常见问题。发生 Hard Fault 时，处理器会停止运行，因为继续执行导致问题的指令已经不再安全，但处理器不会自动解释停止原因。这可能是由于访问无效内存地址或栈溢出造成的，而默认的故障处理程序可能只显示异常确实发生了这一事实。
该技能分析什么？
该技能名为 clion-embedded-hardfault，当调试会话在 HardFault_Handler 或相关处理程序（如 MemManage_Handler、BusFault_Handler 和 UsageFault_Handler）中停止时，它便会开始工作。当出现对 CFSR、HFSR、MMFAR 和 BFAR 等寄存器，或对硬件保存的异常帧的引用时，也可以启用该技能。
该技能不会要求代理读取处理器寄存器的文本转储，而是提供预先解析的数据，包括故障状态寄存器、硬件在可能被覆盖之前保存的异常帧，以及根据 SVD 文件解析出的外设寄存器。此外，这些数据还会附带导致错误的指令周围的内存及其反汇编信息。
实际会发生什么变化？
传统调查需要手动解码 CFSR 和 HFSR，然后将导致故障的程序计数器与反汇编结果进行比较；开发者可能还需要多次重现问题，以缩小搜索范围。而在 CLion 中，调试会话停止后，开发者可以从 AI 聊天窗口或终端启动自己偏好的代理，并使用自然语言描述问题。
代理通过 MCP 使用 IDE 工具，访问与处理器实际状态相关的证据。确定原因后，它会显示故障位置和建议解决方案的说明；开发者可以手动修复，也可以要求代理修改代码并重新启动调试会话，以验证结果。该技能支持多种调试工具，包括 Lauterbach TRACE32、Segger J-Link 和 ST-LINK，因此不会绑定到单一供应商。
可用性和限制
该技能默认在 Settings | Tools | AI Assistant | Skills | Bundled skills 设置中启用，但使用它需要在 Settings | Tools | MCP Server 中启用 MCP 服务器。它可在 Claude Code 和 Codex 的聊天模式与终端模式中使用，而 GitHub Copilot 仅支持终端模式。
该功能已在 CLion 2026.2.2 中提供，并计划加入 2026.3 EAP 系列即将推出的首个测试版本。JetBrains 说明，核心 MCP 工具并不局限于 Hard Fault；它们还允许代理启动和停止调试会话、管理断点、逐步执行，以及读取局部变量、帧值和嵌套字段。
为什么这一进展很重要？
这里的实际价值不在于向开发环境中再添加一个代理，而在于为代理提供来自硬件会话本身、经过解析且相互关联的证据。这可以减少对终端输出解释或根据崩溃日志进行猜测的依赖。不过，该功能并不能取消开发者审查的必要性；原文描述的是一种查明原因、应用修复并验证修复的方法，并未保证代理的建议在每种情况下都正确，也未保证重新测试能够覆盖故障的所有条件。