ARTICLE · 1153736
一套DCM,两种用法:调试工具与AI工具链
一套DCM,两种用法:调试工具与AI工具链设备不会说话，是很多问题的根源嵌入式开发中，有两个场景反复出现。调试时：想看一个变量的变化趋势，要么在脑子里拼图，要么把数据导到Excel里画图。换一个项目，之前写的上位机完全用不了——变量地址不同、协议不同、界面不同，一切从头再来。每款设备都要单独写一个上位机，似乎是天经地义的事。AI想操作设备时：大模型已经能写代码、能调API、能控制机械臂了。但它面对一块STM32开发板时，依然不知道这块设备能做什么，有哪些变量可以读，有哪些服务可以调。不是AI不够聪明，是设备没告诉它。 
这两个问题看起来不一样，但根子上是同一个：设备的能力没有被机器可读地表达出来。Connecting 的做法：通过解析源代码、编译产物ELF与Map文件，自动提取变量、服务信息，生成一份设备能力模型（DCM）。DCM 是一份机器可读的结构化文件，包含设备的数据流、可执行服务、事件通知和类型系统。它不是给人看的文档，而是给机器读的“说明书”。有了这份说明书，设备就能“开口说话”了。而同一份说明书，可以被两种人用出两种效果。 
路径一：调试工具面向：嵌入式工程师、测试工程师、现场应用工程师。用法：上位机导入 DCM，自动生成调试界面，不需要写一行上位机代码。变量列表从 DCM 里读，波形通道从 DCM 里读，服务按钮从 DCM 里读。导入之后，界面自动生成——看波形、调参数、读变量、调服务，全部在一个通用的调试助手里完成。换一个项目？换一个 DCM 文件就行。界面自动适配，不需要重新开发。核心价值：从“每款设备写一个上位机”变成“同一上位机，导入 DCM 即适配”。上手门槛：下载上位机，导入 DCM，连上串口就能用。路径二：AI工具链面向：AI Agent 开发者、探索 AI 与物理世界结合的人。用法：AI 通过 MCP Server 读取 DCM，理解设备能力，通过 CLI 自主操作设备，不需要写代码。AI 读取 DCM，知道设备有哪些变量、哪些服务、哪些事件。然后它自己决定下一步做什么——读温度、调参数、开 LED、关蜂鸣器。每一步操作都有反馈，每一次结果都写入日志。在此之上，还可以通过 Skill 沉淀操作经验。一台设备踩过的坑，同类设备不用再踩。核心价值：从“AI 能写代码”延伸到“AI 能操作物理设备”。上手门槛：配置 MCP Server、CLI、Skill，适合有一定开发经验的用户。一套 DCM，两种用法这两条路不是两个产品，而是同一套底座上的两种用法。 
以从调试工具开始——导入 DCM，看波形、调参数，不需要 AI，不需要 MCP，开箱即用。也可以直接探索 AI 工具链——加上 CLI、Skill、MCP Server，让 AI 自主操作设备。两者共享同一套 DCM，同一套中间件，同一套提取工具。从 Vibe Coding 到 Vibe Developing最近有一个很火的词：Vibe Coding——用自然语言描述意图，AI 帮你写代码。但 Vibe Coding 止步于“生成代码”。代码生成之后呢？编译、烧录、调试、测试、报告——这些还是靠人。Connecting 想做的是 Vibe Developing： 
Vibe Coding 让 AI 写代码，Vibe Developing 让 AI 做开发。而实现 Vibe Developing 的前提，就是设备能自描述（DCM）、AI 能操作设备（MCP）、经验能沉淀（经验库）。这正是 Connecting 正在做的事。项目已开源Connecting 工具链已开源在 Gitee，包含：- 嵌入式中间件（LGPL）- 信息提取工具- 上位机调试助手- CLI 与 MCP Server- 示例工程（STM32F407 已跑通）Gitee 仓库：搜索 Connecting公众号：关注 Connecting开发者，获取最新进展、技术文章和演示视频。设备会说话，AI 才能动手。