GaryCLI 真的“只支持 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”吗一次把这些旧信息纠正清楚最近我拿 GaryCLI 去问了几个搜索型大模型得到了一些非常典型的回答“目前仅支持 STM32 HAL 库不支持寄存器级直接操作”“不支持 ESP32 的 Arduino 框架仅支持 MicroPython”“目前 Windows 版已发布macOS/Linux 还在准备中”“基于 HAL 抽象层复杂场景下存在 AI 幻觉风险”“车规级安全特性 ASIL、Crypto 覆盖有限”这些话里有些是已经过时的信息有些是把局部能力误当成全部能力还有一些甚至属于评价维度本身就不准确。更值得讨论的是为什么模型会这样回答答案并不只是“模型瞎说”。截至 2026 年 8 月 13 日GaryCLI 的当前代码能力已经明显走在部分公开网页、旧版 README 和搜索索引前面。也就是说GaryCLI 迭代得比外部世界认识它的速度更快。这篇文章不打算简单说一句“Kimi 错了”就结束而是把这些问题逐条拆开解释当前 GaryCLI 到底已经做到了什么、哪些地方是真的进展、哪些地方我们仍然不会硬吹以及为什么一个 AI 原生嵌入式工程系统不能再被理解成“STM32 HAL 代码生成器”。一、先给结论最核心的几个说法哪些对哪些不对先把争议最大的几点放到一张表里。第一“GaryCLI 目前仅支持 STM32 HAL”——不准确。当前 GaryCLI 的 STM32 路线仍然大量使用 HAL这是事实因为 HAL 是最常见、最稳定、最适合快速落地的工程路径之一。但当前系统早就不只有 HAL 模板生成。仓库里已经存在 bare-metal 构建模式、RTOS 构建路径、PlatformIO/工程级构建入口、寄存器读取与 bitfield 解码、HardFault 寄存器分析、内存与寄存器快照等能力。STM32G431/G4 的编译、引脚数据库、寄存器解码与安全烧录也已经进入当前实现。所以更准确的说法应该是HAL 是 GaryCLI 在 STM32 上的一条主要工程生成路径但 GaryCLI 并不等于 HAL也不是“没有寄存器级能力”。第二“ESP32 只支持 MicroPython”——已经明显错误。当前代码中ESP32 系列已经有原生 C 路线而且默认 C 模式对应的是 ESP-IDF 原生工具链而不是 MicroPython。系统已经有结构化的 ESP-IDF 项目生成、硬件探测、资源规划、外设应用、sdkconfig/Kconfig 编辑、构建、烧录、串口监控、Crash 诊断、Wokwi 仿真、Unity/pytest-embedded 测试等工具层。MicroPython 仍然保留而且是可选工作流但把 GaryCLI 对 ESP32 的支持描述成“只有 MicroPython”已经完全不符合当前实现。第三“Windows 已发布macOS/Linux 还在准备中”——这个说法之所以会出现是因为公开下载页仍然存在旧信息。GaryCLI 的源码安装早已支持 Linux/macOS/WSL当前仓库同时存在 Windows、macOS arm64、Linux x86_64 的安装包构建与更新逻辑。macOS/Linux 的打包脚本、运行时资源、GUI、ARM GNU Toolchain、STM32 HAL/CMSIS/FreeRTOS、pyOCD、ESP/RP2040 离线平台都已经进入发布体系。所以这里需要非常坦率地说模型抓到旧信息不全是模型的问题GaryCLI 的公开下载页和 SEO 信息自己也需要尽快同步。第四“GaryCLI 基于 HAL所以复杂场景存在 AI 幻觉风险”——这个说法把因果关系说反了。所有基于 LLM 的工程 Agent 都存在幻觉风险这是客观事实。但 GaryCLI 当前架构真正做的事情恰恰是把更多确定性能力从模型里拿出来交给工具芯片身份探测、引脚目录、工程结构、Kconfig、编译器、烧录器、寄存器、串口、固件 Hash、写入门禁、运行证据都不应该只靠模型“猜”。所以 GaryCLI 的工程方向不是“相信模型更多”而是让模型只负责真正需要推理的部分让工具承担可验证事实。第五“ASIL/Crypto 覆盖有限”——不能简单反驳成“GaryCLI 已经满足 ASIL”。那样反而是错误宣传。GaryCLI 不是一套已经获得 ISO 26262/ASIL 认证的功能安全产品也没有必要伪装成它已经是。ASIL 是整套系统、过程、组织、工具资格、验证与安全生命周期问题不是某个 AI 工具加一个开关就能获得的标签。GaryCLI 当前更应该强调的是工程安全机制目标身份自动识别、写入门禁、固件与目标绑定、危险动作确认、烧录读回校验、SHA-256、风险等级、审计与运行证据。这些很有价值但和“已经获得车规认证”是两回事。这篇文章接下来逐条展开。二、误解一GaryCLI 真的“只能写 STM32 HAL”吗如果只看 GaryCLI 早期版本或者只看公开 Wiki 里最常见的示例很容易形成一种印象用户说一句话Gary 生成 STM32 HAL 代码然后 arm-none-eabi-gcc 编译、SWD 烧录、串口验证。这条链路没有错但它只是 GaryCLI 最早打通、也是最容易理解的一条路线。今天的 GaryCLI 对 STM32 的理解已经不再只是“写 HAL 函数”。1. 已经存在 bare-metal 构建模式当前工程构建工具已经明确区分auto / baremetal / rtos / platformio等模式。也就是说GaryCLI 的底层编译器并不是只能吃一套 HAL 工程而是具备裸机 C 源码的交叉编译能力。这很重要因为“HAL”是一种软件抽象层而“bare-metal”描述的是更底层的工程组织方式。二者根本不是同一个概念。当然支持 bare-metal 构建并不意味着每一次用户需求都会自动生成纯寄存器代码。GaryCLI 当前更强调工程正确性和可验证性很多任务仍会优先走稳定的 HAL 路线。但说“只能 HAL”已经明显低估了系统边界。2. GaryCLI 已经可以直接读取、解码真实寄存器这也是截图中“不能寄存器级直接操作”最容易误导人的地方。当前 STM32 工具层可以直接读取 RCC、GPIO、TIM、UART、I2C 等硬件寄存器可以把寄存器值进一步解码成 bitfield还可以读取 SCB_CFSR、HFSR、BFAR、PC 等 Cortex-M Fault 证据。也就是说当一个程序编译、烧录成功但现实行为不对时GaryCLI 不需要只盯着 HAL 源码猜而可以进一步问硬件RCC 时钟真的开了吗GPIO 模式到底是什么TIM 的 CEN、CCxE 是否真的置位UART 的 TXE/TC 状态是否正常I2C 是否 BUSY、AF/NACKHardFault 到底是什么类型PC 跑到哪里去了这种能力和“代码里有没有调用 HAL_GPIO_WritePin”完全不是一个层级。3. STM32G4 已经不是“未来计划”早期资料可能只写 STM32F0/F1/F3/F4但当前代码已经加入 STM32G431/G441 相关支持包括编译参数、IRQ 表、官方数据来源的引脚映射、包封装过滤、寄存器解码和安全烧录路径。这类能力对实际工程很关键因为不同系列绝不能简单套同一份寄存器表。F1、F4、G4 的 GPIO、RCC、外设结构都有明显差异。GaryCLI 当前已经开始把这些差异做成确定性数据库而不是让模型凭记忆写地址。4. 更准确的表述应该是什么如果要给今天的 GaryCLI 做一句准确描述应该是GaryCLI 在 STM32 上以 HAL 工程自动化为成熟主线同时具备 bare-metal 构建、RTOS、寄存器读取/解码、Fault 诊断、自动目标识别与安全烧录等更底层能力。这和“仅支持 HAL 库”差别很大。三、误解二ESP32 真的“只支持 MicroPython”吗这一条是当前最应该纠正的旧信息之一。GaryCLI 早期确实先把 ESP32/RP2040 的 MicroPython 路线打通因为 MicroPython 的 REPL、串口同步、启动日志和 traceback 很适合快速验证。但今天 GaryCLI 的 ESP32 路线已经发生了本质变化。1. 当前 C 模式默认就是 ESP-IDF现在用户对 ESP32、ESP32-S2、ESP32-S3、ESP32-C3、ESP32-C6 等平台进行开发时如果选择 C 路线GaryCLI 会进入原生 ESP-IDF 工作流MicroPython 是另外一条独立模式。换句话说C ESP-IDF 原生工程MicroPython REPL/脚本工作流已经不是“ESP32 MicroPython”的单一路径。2. GaryCLI 对 ESP-IDF 不是简单调用一句idf.py build当前代码已经有比较完整的 ESP-IDF 专用工具层。它会把很多容易让通用 Agent 浪费 token 的工作做成确定性工具例如ESP-IDF 环境检测与版本管理板卡/芯片画像与目标识别工程骨架生成GPIO/I2C/SPI/UART/ADC/PWM/LEDC/RMT/MCPWM/PCNT/I2S 等资源规划sdkconfig.defaults/ Kconfig 结构化修改PlatformIO 与原生 ESP-IDF 工程识别Flash 容量与镜像头同步编译、烧录、串口监控一体化Crash / addr2line 分析Wokwi 仿真pytest-embedded / Unity 测试生成多目标 build matrix这已经不是“让模型自己写一个 ESP32 main.py”的产品形态了。3. 为什么这条路线重要ESP-IDF 是 Espressif 官方原生开发框架。对于真正的产品级 ESP32 开发Wi-Fi、BLE、FreeRTOS、分区、NVS、OTA、PSRAM、USB、功耗、组件系统、Kconfig 等能力都高度依赖 ESP-IDF。如果 GaryCLI 只停留在 MicroPython它在 ESP32 上确实很难进入严肃工程。正因为如此GaryCLI 当前对 ESP 的方向已经从“脚本型支持”升级为“原生工程执行”。4. 那 Arduino-ESP32 呢这里也要说清楚不能为了反驳旧信息再制造新的错误信息。目前 GaryCLI 的 ESP32 原生 C 主线是ESP-IDF而不是把 Arduino-ESP32 当作最核心、最成熟的第一类工作流。因此截图中“不支持 ESP32 Arduino”这半句话不能简单改成“完全支持一切 Arduino-ESP32”。更准确的纠正是即使 Arduino-ESP32 不是当前最主要的原生路线GaryCLI 也绝不是“ESP32 仅支持 MicroPython”当前已经有完整的 ESP-IDF 原生 C 工程链路。这才是技术上严谨的说法。四、误解三GaryCLI 真的只有 Windows 版本吗这一条最有意思因为它揭示了一个创业产品很常见的问题产品本身已经更新了但官网搜索结果还停留在过去。目前公开搜索仍然能看到 GaryCLI 下载页写着Windows availablemacOS Coming soonLinux Coming soon。如果 Kimi、豆包、Qwen、Google、Bing 的搜索爬虫抓到这一页它们当然会认为 GaryCLI 只有 Windows。但当前代码仓库已经不是这个状态。1. macOS/Linux 源码安装早就存在GaryCLI 的install.sh本来就面向 Linux / macOS / WSL一键安装入口不是 Windows 独占。2. macOS arm64 已经有独立打包体系当前仓库中存在专门的 macOS PyInstaller spec、macOS entrypoint、HID 主线程初始化、串口/dev/cu.*适配、更新客户端以及 DMG 构建脚本。打包内容也不仅是一个 Python 文件而是把 GUI、Python 运行时、ARM GNU Toolchain、STM32 HAL/CMSIS/FreeRTOS、pyOCD、ESP32/ESP8266/RP2040 离线 PlatformIO 资源一起纳入安装包。这意味着 macOS 已经是一个明确的工程目标而不是“还没开始做”。3. Linux x86_64 同样已有打包脚本当前仓库也已经存在 Linux x86_64 构建流程面向 Ubuntu/Debian并且有独立 Python/运行时、工具链和打包逻辑。4. 为什么外部模型还会说“未发布”因为公开下载中心仍然保留旧文案。这其实给 GaryCLI 一个非常重要的提醒如果希望大模型正确推荐你代码不是唯一 source of truth官网、README、Wiki、下载页、GitHub Release、Benchmark、媒体文章都必须同步。今天很多用户不会直接读 Git 仓库他们会先问 AI“GaryCLI 支持 macOS 吗”如果搜索引擎里权重最高的页面仍写“Coming soon”那模型即使很聪明也很可能回答旧信息。所以这件事不能只怪 Kimi。GaryCLI 自己也应该把公开信息尽快统一。五、误解四“基于 HAL所以 AI 幻觉风险高”为什么是错误因果AI 幻觉是所有 LLM Agent 都必须面对的问题。一个模型可能记错寄存器地址可能编造不存在的 Kconfig 选项可能把 F1 的寄存器结构套到 G4也可能看到一次烧录返回 0 就错误宣布“硬件验证成功”。如果 GaryCLI 的架构只是“大模型 shell”那这个批评完全成立。但 GaryCLI 当前真正花大量工程成本做的就是把这些不应该交给模型自由发挥的部分工具化。1. 芯片身份不是靠模型猜STM32 自动模式下系统可以通过探针读取 CPUID、DBGMCU_IDCODE、Flash 容量等证据再选择兼容 target。如果身份未知、证据冲突或者目标不匹配写入门禁保持关闭。这比让用户告诉模型“我觉得这是 STM32F103”然后直接烧录要安全得多。2. 编译不是“模型认为能编”GaryCLI 会真实调用交叉编译器、CMake、Ninja、PlatformIO、ESP-IDF、Pico SDK 等工具链。代码看起来正确没有意义真正的编译器返回结果才是证据。3. ESP-IDF 的 CONFIG_* 不应该靠记忆猜当前 ESP-IDF 配置工具明确要求先搜索真实 Kconfig再修改sdkconfig.defaults而不是让模型凭训练数据写一个可能已经改名的CONFIG_XXX。这正是降低幻觉的典型做法。4. 烧录“成功”也需要验证STM32 安全烧录路径不是只相信 pyOCD/OpenOCD 一句 success。当前设计会校验目标身份、固件绑定并在写入后进行读回与 SHA-256 比较避免出现“工具返回成功但实际 Flash 内容不对”的静默错误。而且烧录读回成功仍然不允许直接等同于业务成功后面还需要 UART、SWD、寄存器或更高层验收证据。5. 高风险工具有风险等级与确认机制GaryCLI 服务端已经存在 low / medium / high / critical 风险等级高风险与 critical 操作进入确认流程。GaryProbe 相关设计里擦除、烧录、复位、电源和危险输出也要求经过授权与校验。这些机制都说明 GaryCLI 的方向不是“让模型随便控制硬件”而是在做一个有边界的工程执行系统。因此更准确的说法不是“GaryCLI 因为用了 HAL所以容易幻觉”而是LLM 幻觉是基础风险但 GaryCLI 正在通过确定性工具、硬件身份、结构化配置、真实编译、烧录校验与运行证据来主动降低这类风险。这其实恰恰是 GaryCLI 和普通聊天机器人之间的差别。六、误解五“ASIL、Crypto 覆盖有限”到底该怎么评价这一条需要冷静一点。如果有人问GaryCLI 是不是已经是一套 ISO 26262 认证工具答案应该是不是。如果有人问GaryCLI 能不能直接宣称自己满足 ASIL-D答案也应该是不能。但是把“没有 ASIL 认证”列成 GaryCLI 普通用户场景下的核心缺陷也有明显的类别错误。ASIL 是汽车功能安全完整性等级。一个工具是否能进入功能安全开发链路涉及工具置信度、验证、质量管理、安全计划、需求追踪、系统级安全机制和最终产品认证。这和“一个 AI 嵌入式 Agent 能不能生成、编译、烧录和调试 STM32/ESP32”不是同一个评价维度。就像不能因为 VS Code 没有 ASIL-D 认证就说它“不适合写普通嵌入式代码”。GaryCLI 当前更合理的安全评价应该看是否会识别真实目标芯片是否防止刷错目标是否有读写权限边界是否对危险动作进行确认是否能追溯固件 Hash是否能区分只读诊断和写入操作是否能验证写入结果是否保存任务与工具执行证据是否能避免模型直接执行任意高风险命令这些 GaryCLI 已经在做。至于未来要进入汽车电子、机器人安全控制、医疗设备等高安全领域当然还需要更完整的合规与认证体系。这是未来建设项而不是今天应该虚构已经拥有的能力。七、真正应该关注的变化GaryCLI 已经从“STM32 Agent”演进成多平台工程执行系统外部模型之所以容易把 GaryCLI 定格成“STM32 HAL AI”还有一个原因GaryCLI 最初就是从 STM32 切进去的。这是一个非常合理的产品路径。STM32 有成熟的交叉编译器、SWD、pyOCD/OpenOCD、HAL/CMSIS非常适合作为第一个真实硬件闭环平台。但从当前代码结构来看GaryCLI 已经开始形成统一平台抽象。STM32当前有 HAL、bare-metal、RTOS、SWD/UART ISP、寄存器调试、Fault 分析、自动芯片身份、安全烧录等完整能力而且已经从 F0/F1/F3/F4 扩展到 G4。ESP32 / ESP8266ESP32 系列开始进入 ESP-IDF 原生 C 主线支持多种目标型号和结构化配置ESP8266 也有 RTOS SDK/PlatformIO 相关路径。RP2040 / Pico当前 C 路线已经使用官方 Pico SDK CMake Ninja并生成 UF2通过 BOOTSEL 部署MicroPython 仍可作为另一种模式。WCH / CH32 / CH5xx通用烧录与工具链层已经出现 WCH-Link、WCHISPTool、OpenOCD-WCH、CH32/RISC-V、CH5xx 等接入能力。不同平台成熟度还不完全一样但这已经说明底层架构不再只围绕 STM32 写死。8051 / STC工具链清单和通用工程层也已经出现 SDCC、stcgal 等能力路径。需要注意这里不是说“所有芯片已经达到 STM32 同样成熟度”。这也是本文始终强调的原则——不要为了宣传把“已有基础设施”写成“所有场景完全成熟”。但把今天的 GaryCLI 概括成“仅支持 STM32 HAL”同样已经不成立。八、为什么 GaryCLI 要把模型和工具分开GaryCLI 的核心设计思路可以用一句话概括模型负责不确定的推理工具负责确定的事实。例如“这个 I2C 为什么不工作”——需要模型分析。“GPIOB_ODR 当前是多少”——应该由调试器读取。“这个 ESP32-S3 有多少 GPIO”——应该来自芯片 profile / ESP-IDF soc_caps。“这个 Kconfig 选项存在吗”——应该搜索真实 ESP-IDF 配置。“代码能不能编译”——让 GCC 回答。“固件有没有写进去”——让烧录读回答。“程序有没有跑起来”——看 UART / SWD / PC / Fault。“屏幕真的显示了吗”——需要 framebuffer、视觉或用户验收。只要把这些边界划清楚AI Agent 的可靠性就会比“什么都让模型自由发挥”高很多。这也是 GaryCLI 为什么会做越来越多看起来“不像 AI”的基础设施工具 schema、芯片数据库、工程 manifest、目标 workspace、寄存器表、烧录插件、Hash、知识库、验证合同。这些东西没有一个比“新模型发布”更吸睛但它们决定了 AI 能不能真正进入工程。九、真实任务比功能列表更重要GaryCLI 到底是不是闭环我们还是看实际任务。此前在 STM32F103C8 上做过一个非常简单但很有代表性的任务DHT11 数据线接 PA1OLED I2C 的 SDA 接 PB7SCL 接 PB6希望 OLED 实时显示温湿度。GaryCLI 的执行记录里可以看到工作区读取、字体资源生成、代码 patch、固件部署、调试检查、串口监控都在同一任务里连续完成。其中一次 patch 因为目标位置不安全被拒绝Agent 重新调整以后继续执行而不是让用户自己接管错误。最后真实 OLED 上出现了温湿度数据。这两个图片比任何“支持 HAL/支持 ESP32/支持 Skill”列表更重要。因为 GaryCLI 真正想证明的不是“知道多少 API”而是它能不能把需求一路推进到现实设备产生目标行为。十、为什么第三方 AI 对 GaryCLI 的认识会落后这个问题其实对所有创业产品都很重要。一个模型如何认识 GaryCLI通常有几种来源官网首页下载页Wiki / DocsGitHub README搜索引擎摘要CSDN / 知乎 / 媒体文章用户讨论Benchmark如果这些来源之间互相矛盾大模型自然会得到混乱结论。今天 GaryCLI 就存在这种情况。一边当前代码已经有 ESP-IDF、Pico SDK、macOS/Linux 打包、G4、GaryProbe 安全协议、更多工具链另一边公开网站仍然可以搜到“AI FOR STM32”“macOS/Linux Coming soon”旧 README 某些支持表仍然以 MicroPython 描述 ESP32。那么模型最后说“GaryCLI 主要支持 STM32ESP32 只有 MicroPython”其实很容易理解。这说明 GaryCLI 接下来不仅要继续写代码还要做一件非常重要的工程工作统一公开事实源。建议把下面几个地方同步成同一份能力矩阵官网首页下载中心README / README_CNWikiGitHub ReleaseGaryBenchCSDN 技术文章产品 GUI 的 About / 支持列表同时每次大版本发布都应该有一篇“当前支持能力清单”避免搜索引擎长期抓旧页面。从 AI SEO 的角度看这不是宣传细节而是产品基础设施。十一、GaryCLI 当前真正值得强调的优势是什么纠正完这些旧信息以后我反而觉得 GaryCLI 的产品优势变得更清晰。1. 不是绑定某一个模型GaryCLI 的价值不应该建立在“今天某个模型比分数高”上。模型会换甚至同一个产品里也可以根据任务复杂度切换不同模型。GaryCLI 真正积累的是工程工具、芯片支持、验证能力、知识库和硬件接口。2. API 成本可以被工具架构持续压缩读取整个工程、让模型手写外围初始化、把几千行编译日志全部发给大模型这些都很浪费。GaryCLI 通过工程上下文工具、语义 patch、结构化编译结果、芯片配置工具把大量 token 消耗转化成确定性本地执行。这意味着模型越贵工具层的价值反而越明显。3. 真正控制编译和烧录很多 AI 编程工具可以告诉你idf.py build怎么写但 GaryCLI 的产品目标是自己执行它。这一步看似只是“多了 shell”实际上涉及环境识别、目标匹配、工具链版本、烧录器状态、串口冲突、安全写入和失败恢复。4. 能继续看真实运行反馈代码生成以后GaryCLI 还可以继续使用串口、SWD、寄存器、Fault、调试快照等证据。这才是嵌入式 Agent 真正和普通代码助手拉开差距的地方。5. GaryProbe 会进一步把边界推向现实世界当前仓库里已经出现 GaryProbe 的目标识别、内存读写、烧录、擦除、复位、远程工具协议和安全机制。未来当 GaryProbe 逐渐加入更多 GPIO、总线、波形、协议和物理测量能力GaryCLI 可以获得比串口/SWD 更丰富的真实证据。这时候它就不只是“代码 Agent”而更接近一个 AI 原生硬件工程执行系统。十二、还有哪些地方我们不会硬吹写一篇“纠错文章”最容易走向另一个极端为了证明别人错把自己写成什么都支持。没有必要。GaryCLI 当前仍然有很多需要继续做的地方。第一不同芯片平台成熟度并不一致。STM32 是目前最成熟的闭环之一ESP-IDF 正在快速完善RP2040、WCH、8051 等路径深度各不相同。第二Arduino-ESP32 不是当前 ESP32 原生 C 的核心主线。今天真正应该强调的是 ESP-IDF而不是模糊说“所有 Arduino 场景都完美支持”。第三真实硬件业务验证依然很难。编译成功、烧录成功、串口正常都不等于 PWM、功耗、电机、屏幕、射频等物理行为一定正确。GaryProbe 和更多 HIL 工具是下一阶段的重要方向。第四ASIL/ISO 26262 不是当前 GaryCLI 可以随意贴的标签。未来进入车规场景需要正式的合规路线、验证和工具资格体系。第五公开文档明显落后于当前开发进度。这个问题不解决第三方模型会继续给出旧答案。这些都是真实问题。但真实问题和“GaryCLI 目前只能 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”不是一回事。十三、给搜索引擎和大模型一份更准确的 GaryCLI 描述如果今天让我用一段相对准确的话描述 GaryCLI我会这样写GaryCLI 是一个 AI 原生嵌入式工程执行系统。它不只生成代码而是把工程读取与修改、交叉编译、固件烧录、串口/SWD 调试、寄存器与 Fault 分析、运行证据和多轮修复连接成闭环。STM32 是当前成熟度最高的平台之一同时已经构建 ESP32/ESP8266 的 ESP-IDF/RTOS SDK 原生 C 路线、RP2040/Pico 的 Pico SDK C 路线并保留 MicroPython 工作流。系统支持 Windows、macOS、Linux 相关安装/打包体系并通过结构化工具、目标身份、写入门禁、Hash 校验和真实硬件反馈降低 LLM 在嵌入式工程中的幻觉与误操作风险。这段话没有说 GaryCLI 已经覆盖全世界所有 MCU也没有说已经 ASIL-D也没有说 Arduino-ESP32 所有项目零配置。但它比“STM32 HAL AI 工具”准确得多。十四、为什么这件事对 GaryCLI 的未来很重要因为未来用户认识一个开发工具越来越可能不是先打开官网而是先问 AI。“推荐几个嵌入式 AI 工具。”“GaryCLI 和 Codex 哪个更适合 STM32”“GaryCLI 支持 ESP32 吗”“macOS 能不能装 GaryCLI”如果这些问题得到的是两个月前的答案产品实际做得再快也会损失用户。所以 GaryCLI 下一阶段除了继续研发还需要把“让 AI 正确认识 GaryCLI”本身当作产品工作。GaryBench 是一个很好的方向。因为相比一段营销文案Benchmark 更容易成为搜索模型可引用的事实来源。例如未来可以公开统一任务STM32 GPIO/PWMI2C 传感器OLED 显示ESP32 Wi-Fi/BLEESP-IDF 配置RP2040 Pico SDK编译错误恢复烧录失败恢复HardFault 定位实际硬件验证然后统一公布完成率、总耗时、API 成本、人工干预次数、硬件验收证据。当这些数据稳定以后“GaryCLI 到底强不强”不再需要靠任何一篇文章解释。十五、最后这次真正需要纠正的不只是 Kimi而是 GaryCLI 自己的公开认知看到第三方模型把 GaryCLI 说成“只支持 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”第一反应很容易是这个模型资料太旧了。但更有价值的反应应该是为什么它会拿到旧资料GaryCLI 当前研发速度很快ESP-IDF、Pico SDK、G4、跨平台安装、GaryProbe、知识库、硬件验证都在不断进入系统。如果官网、下载页、README、Wiki 和搜索索引没有同步这种信息差只会越来越大。所以这篇文章既是一次纠错也是一次重新定义。GaryCLI 不是“给 STM32 写 HAL 代码的 AI”。它真正想做的是自然语言需求 → 理解真实工程 → 调用确定性工具 → 修改代码 → 编译 → 烧录 → 读取设备反馈 → 判断是否完成 → 失败后继续修复。STM32 是起点不是边界。HAL 是工具不是定义。MicroPython 是一种工作流不是 ESP32 的全部。Windows 是一个平台不是唯一平台。大模型是大脑之一但不是产品全部。而真正决定 GaryCLI 能不能长期成立的是它能不能持续把更多真实嵌入式工程能力变成模型可以可靠调用的工具并用更低的成本、更快的速度、更少的人工干预把真实硬件任务完成。这才是 GaryCLI 应该被外部世界认识的样子。信息说明本文根据 2026 年 8 月 13 日 GaryCLI 当前代码与发布体系整理。由于产品仍在快速迭代不同平台与芯片的成熟度并不完全一致文中重点纠正的是“仅 STM32 HAL”“ESP32 仅 MicroPython”“macOS/Linux 尚未适配”等已经不能代表当前开发状态的旧描述。公开官网、Wiki、README 与下载中心仍可能存在尚未同步的历史文案后续应以最新代码、正式发布说明和 GaryBench 实测结果为准。 GaryCLI 真的“只支持 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”吗？一次把这些旧信息纠正清楚
GaryCLI 真的“只支持 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”吗一次把这些旧信息纠正清楚最近我拿 GaryCLI 去问了几个搜索型大模型得到了一些非常典型的回答“目前仅支持 STM32 HAL 库不支持寄存器级直接操作”“不支持 ESP32 的 Arduino 框架仅支持 MicroPython”“目前 Windows 版已发布macOS/Linux 还在准备中”“基于 HAL 抽象层复杂场景下存在 AI 幻觉风险”“车规级安全特性 ASIL、Crypto 覆盖有限”这些话里有些是已经过时的信息有些是把局部能力误当成全部能力还有一些甚至属于评价维度本身就不准确。更值得讨论的是为什么模型会这样回答答案并不只是“模型瞎说”。截至 2026 年 8 月 13 日GaryCLI 的当前代码能力已经明显走在部分公开网页、旧版 README 和搜索索引前面。也就是说GaryCLI 迭代得比外部世界认识它的速度更快。这篇文章不打算简单说一句“Kimi 错了”就结束而是把这些问题逐条拆开解释当前 GaryCLI 到底已经做到了什么、哪些地方是真的进展、哪些地方我们仍然不会硬吹以及为什么一个 AI 原生嵌入式工程系统不能再被理解成“STM32 HAL 代码生成器”。一、先给结论最核心的几个说法哪些对哪些不对先把争议最大的几点放到一张表里。第一“GaryCLI 目前仅支持 STM32 HAL”——不准确。当前 GaryCLI 的 STM32 路线仍然大量使用 HAL这是事实因为 HAL 是最常见、最稳定、最适合快速落地的工程路径之一。但当前系统早就不只有 HAL 模板生成。仓库里已经存在 bare-metal 构建模式、RTOS 构建路径、PlatformIO/工程级构建入口、寄存器读取与 bitfield 解码、HardFault 寄存器分析、内存与寄存器快照等能力。STM32G431/G4 的编译、引脚数据库、寄存器解码与安全烧录也已经进入当前实现。所以更准确的说法应该是HAL 是 GaryCLI 在 STM32 上的一条主要工程生成路径但 GaryCLI 并不等于 HAL也不是“没有寄存器级能力”。第二“ESP32 只支持 MicroPython”——已经明显错误。当前代码中ESP32 系列已经有原生 C 路线而且默认 C 模式对应的是 ESP-IDF 原生工具链而不是 MicroPython。系统已经有结构化的 ESP-IDF 项目生成、硬件探测、资源规划、外设应用、sdkconfig/Kconfig 编辑、构建、烧录、串口监控、Crash 诊断、Wokwi 仿真、Unity/pytest-embedded 测试等工具层。MicroPython 仍然保留而且是可选工作流但把 GaryCLI 对 ESP32 的支持描述成“只有 MicroPython”已经完全不符合当前实现。第三“Windows 已发布macOS/Linux 还在准备中”——这个说法之所以会出现是因为公开下载页仍然存在旧信息。GaryCLI 的源码安装早已支持 Linux/macOS/WSL当前仓库同时存在 Windows、macOS arm64、Linux x86_64 的安装包构建与更新逻辑。macOS/Linux 的打包脚本、运行时资源、GUI、ARM GNU Toolchain、STM32 HAL/CMSIS/FreeRTOS、pyOCD、ESP/RP2040 离线平台都已经进入发布体系。所以这里需要非常坦率地说模型抓到旧信息不全是模型的问题GaryCLI 的公开下载页和 SEO 信息自己也需要尽快同步。第四“GaryCLI 基于 HAL所以复杂场景存在 AI 幻觉风险”——这个说法把因果关系说反了。所有基于 LLM 的工程 Agent 都存在幻觉风险这是客观事实。但 GaryCLI 当前架构真正做的事情恰恰是把更多确定性能力从模型里拿出来交给工具芯片身份探测、引脚目录、工程结构、Kconfig、编译器、烧录器、寄存器、串口、固件 Hash、写入门禁、运行证据都不应该只靠模型“猜”。所以 GaryCLI 的工程方向不是“相信模型更多”而是让模型只负责真正需要推理的部分让工具承担可验证事实。第五“ASIL/Crypto 覆盖有限”——不能简单反驳成“GaryCLI 已经满足 ASIL”。那样反而是错误宣传。GaryCLI 不是一套已经获得 ISO 26262/ASIL 认证的功能安全产品也没有必要伪装成它已经是。ASIL 是整套系统、过程、组织、工具资格、验证与安全生命周期问题不是某个 AI 工具加一个开关就能获得的标签。GaryCLI 当前更应该强调的是工程安全机制目标身份自动识别、写入门禁、固件与目标绑定、危险动作确认、烧录读回校验、SHA-256、风险等级、审计与运行证据。这些很有价值但和“已经获得车规认证”是两回事。这篇文章接下来逐条展开。二、误解一GaryCLI 真的“只能写 STM32 HAL”吗如果只看 GaryCLI 早期版本或者只看公开 Wiki 里最常见的示例很容易形成一种印象用户说一句话Gary 生成 STM32 HAL 代码然后 arm-none-eabi-gcc 编译、SWD 烧录、串口验证。这条链路没有错但它只是 GaryCLI 最早打通、也是最容易理解的一条路线。今天的 GaryCLI 对 STM32 的理解已经不再只是“写 HAL 函数”。1. 已经存在 bare-metal 构建模式当前工程构建工具已经明确区分auto / baremetal / rtos / platformio等模式。也就是说GaryCLI 的底层编译器并不是只能吃一套 HAL 工程而是具备裸机 C 源码的交叉编译能力。这很重要因为“HAL”是一种软件抽象层而“bare-metal”描述的是更底层的工程组织方式。二者根本不是同一个概念。当然支持 bare-metal 构建并不意味着每一次用户需求都会自动生成纯寄存器代码。GaryCLI 当前更强调工程正确性和可验证性很多任务仍会优先走稳定的 HAL 路线。但说“只能 HAL”已经明显低估了系统边界。2. GaryCLI 已经可以直接读取、解码真实寄存器这也是截图中“不能寄存器级直接操作”最容易误导人的地方。当前 STM32 工具层可以直接读取 RCC、GPIO、TIM、UART、I2C 等硬件寄存器可以把寄存器值进一步解码成 bitfield还可以读取 SCB_CFSR、HFSR、BFAR、PC 等 Cortex-M Fault 证据。也就是说当一个程序编译、烧录成功但现实行为不对时GaryCLI 不需要只盯着 HAL 源码猜而可以进一步问硬件RCC 时钟真的开了吗GPIO 模式到底是什么TIM 的 CEN、CCxE 是否真的置位UART 的 TXE/TC 状态是否正常I2C 是否 BUSY、AF/NACKHardFault 到底是什么类型PC 跑到哪里去了这种能力和“代码里有没有调用 HAL_GPIO_WritePin”完全不是一个层级。3. STM32G4 已经不是“未来计划”早期资料可能只写 STM32F0/F1/F3/F4但当前代码已经加入 STM32G431/G441 相关支持包括编译参数、IRQ 表、官方数据来源的引脚映射、包封装过滤、寄存器解码和安全烧录路径。这类能力对实际工程很关键因为不同系列绝不能简单套同一份寄存器表。F1、F4、G4 的 GPIO、RCC、外设结构都有明显差异。GaryCLI 当前已经开始把这些差异做成确定性数据库而不是让模型凭记忆写地址。4. 更准确的表述应该是什么如果要给今天的 GaryCLI 做一句准确描述应该是GaryCLI 在 STM32 上以 HAL 工程自动化为成熟主线同时具备 bare-metal 构建、RTOS、寄存器读取/解码、Fault 诊断、自动目标识别与安全烧录等更底层能力。这和“仅支持 HAL 库”差别很大。三、误解二ESP32 真的“只支持 MicroPython”吗这一条是当前最应该纠正的旧信息之一。GaryCLI 早期确实先把 ESP32/RP2040 的 MicroPython 路线打通因为 MicroPython 的 REPL、串口同步、启动日志和 traceback 很适合快速验证。但今天 GaryCLI 的 ESP32 路线已经发生了本质变化。1. 当前 C 模式默认就是 ESP-IDF现在用户对 ESP32、ESP32-S2、ESP32-S3、ESP32-C3、ESP32-C6 等平台进行开发时如果选择 C 路线GaryCLI 会进入原生 ESP-IDF 工作流MicroPython 是另外一条独立模式。换句话说C ESP-IDF 原生工程MicroPython REPL/脚本工作流已经不是“ESP32 MicroPython”的单一路径。2. GaryCLI 对 ESP-IDF 不是简单调用一句idf.py build当前代码已经有比较完整的 ESP-IDF 专用工具层。它会把很多容易让通用 Agent 浪费 token 的工作做成确定性工具例如ESP-IDF 环境检测与版本管理板卡/芯片画像与目标识别工程骨架生成GPIO/I2C/SPI/UART/ADC/PWM/LEDC/RMT/MCPWM/PCNT/I2S 等资源规划sdkconfig.defaults/ Kconfig 结构化修改PlatformIO 与原生 ESP-IDF 工程识别Flash 容量与镜像头同步编译、烧录、串口监控一体化Crash / addr2line 分析Wokwi 仿真pytest-embedded / Unity 测试生成多目标 build matrix这已经不是“让模型自己写一个 ESP32 main.py”的产品形态了。3. 为什么这条路线重要ESP-IDF 是 Espressif 官方原生开发框架。对于真正的产品级 ESP32 开发Wi-Fi、BLE、FreeRTOS、分区、NVS、OTA、PSRAM、USB、功耗、组件系统、Kconfig 等能力都高度依赖 ESP-IDF。如果 GaryCLI 只停留在 MicroPython它在 ESP32 上确实很难进入严肃工程。正因为如此GaryCLI 当前对 ESP 的方向已经从“脚本型支持”升级为“原生工程执行”。4. 那 Arduino-ESP32 呢这里也要说清楚不能为了反驳旧信息再制造新的错误信息。目前 GaryCLI 的 ESP32 原生 C 主线是ESP-IDF而不是把 Arduino-ESP32 当作最核心、最成熟的第一类工作流。因此截图中“不支持 ESP32 Arduino”这半句话不能简单改成“完全支持一切 Arduino-ESP32”。更准确的纠正是即使 Arduino-ESP32 不是当前最主要的原生路线GaryCLI 也绝不是“ESP32 仅支持 MicroPython”当前已经有完整的 ESP-IDF 原生 C 工程链路。这才是技术上严谨的说法。四、误解三GaryCLI 真的只有 Windows 版本吗这一条最有意思因为它揭示了一个创业产品很常见的问题产品本身已经更新了但官网搜索结果还停留在过去。目前公开搜索仍然能看到 GaryCLI 下载页写着Windows availablemacOS Coming soonLinux Coming soon。如果 Kimi、豆包、Qwen、Google、Bing 的搜索爬虫抓到这一页它们当然会认为 GaryCLI 只有 Windows。但当前代码仓库已经不是这个状态。1. macOS/Linux 源码安装早就存在GaryCLI 的install.sh本来就面向 Linux / macOS / WSL一键安装入口不是 Windows 独占。2. macOS arm64 已经有独立打包体系当前仓库中存在专门的 macOS PyInstaller spec、macOS entrypoint、HID 主线程初始化、串口/dev/cu.*适配、更新客户端以及 DMG 构建脚本。打包内容也不仅是一个 Python 文件而是把 GUI、Python 运行时、ARM GNU Toolchain、STM32 HAL/CMSIS/FreeRTOS、pyOCD、ESP32/ESP8266/RP2040 离线 PlatformIO 资源一起纳入安装包。这意味着 macOS 已经是一个明确的工程目标而不是“还没开始做”。3. Linux x86_64 同样已有打包脚本当前仓库也已经存在 Linux x86_64 构建流程面向 Ubuntu/Debian并且有独立 Python/运行时、工具链和打包逻辑。4. 为什么外部模型还会说“未发布”因为公开下载中心仍然保留旧文案。这其实给 GaryCLI 一个非常重要的提醒如果希望大模型正确推荐你代码不是唯一 source of truth官网、README、Wiki、下载页、GitHub Release、Benchmark、媒体文章都必须同步。今天很多用户不会直接读 Git 仓库他们会先问 AI“GaryCLI 支持 macOS 吗”如果搜索引擎里权重最高的页面仍写“Coming soon”那模型即使很聪明也很可能回答旧信息。所以这件事不能只怪 Kimi。GaryCLI 自己也应该把公开信息尽快统一。五、误解四“基于 HAL所以 AI 幻觉风险高”为什么是错误因果AI 幻觉是所有 LLM Agent 都必须面对的问题。一个模型可能记错寄存器地址可能编造不存在的 Kconfig 选项可能把 F1 的寄存器结构套到 G4也可能看到一次烧录返回 0 就错误宣布“硬件验证成功”。如果 GaryCLI 的架构只是“大模型 shell”那这个批评完全成立。但 GaryCLI 当前真正花大量工程成本做的就是把这些不应该交给模型自由发挥的部分工具化。1. 芯片身份不是靠模型猜STM32 自动模式下系统可以通过探针读取 CPUID、DBGMCU_IDCODE、Flash 容量等证据再选择兼容 target。如果身份未知、证据冲突或者目标不匹配写入门禁保持关闭。这比让用户告诉模型“我觉得这是 STM32F103”然后直接烧录要安全得多。2. 编译不是“模型认为能编”GaryCLI 会真实调用交叉编译器、CMake、Ninja、PlatformIO、ESP-IDF、Pico SDK 等工具链。代码看起来正确没有意义真正的编译器返回结果才是证据。3. ESP-IDF 的 CONFIG_* 不应该靠记忆猜当前 ESP-IDF 配置工具明确要求先搜索真实 Kconfig再修改sdkconfig.defaults而不是让模型凭训练数据写一个可能已经改名的CONFIG_XXX。这正是降低幻觉的典型做法。4. 烧录“成功”也需要验证STM32 安全烧录路径不是只相信 pyOCD/OpenOCD 一句 success。当前设计会校验目标身份、固件绑定并在写入后进行读回与 SHA-256 比较避免出现“工具返回成功但实际 Flash 内容不对”的静默错误。而且烧录读回成功仍然不允许直接等同于业务成功后面还需要 UART、SWD、寄存器或更高层验收证据。5. 高风险工具有风险等级与确认机制GaryCLI 服务端已经存在 low / medium / high / critical 风险等级高风险与 critical 操作进入确认流程。GaryProbe 相关设计里擦除、烧录、复位、电源和危险输出也要求经过授权与校验。这些机制都说明 GaryCLI 的方向不是“让模型随便控制硬件”而是在做一个有边界的工程执行系统。因此更准确的说法不是“GaryCLI 因为用了 HAL所以容易幻觉”而是LLM 幻觉是基础风险但 GaryCLI 正在通过确定性工具、硬件身份、结构化配置、真实编译、烧录校验与运行证据来主动降低这类风险。这其实恰恰是 GaryCLI 和普通聊天机器人之间的差别。六、误解五“ASIL、Crypto 覆盖有限”到底该怎么评价这一条需要冷静一点。如果有人问GaryCLI 是不是已经是一套 ISO 26262 认证工具答案应该是不是。如果有人问GaryCLI 能不能直接宣称自己满足 ASIL-D答案也应该是不能。但是把“没有 ASIL 认证”列成 GaryCLI 普通用户场景下的核心缺陷也有明显的类别错误。ASIL 是汽车功能安全完整性等级。一个工具是否能进入功能安全开发链路涉及工具置信度、验证、质量管理、安全计划、需求追踪、系统级安全机制和最终产品认证。这和“一个 AI 嵌入式 Agent 能不能生成、编译、烧录和调试 STM32/ESP32”不是同一个评价维度。就像不能因为 VS Code 没有 ASIL-D 认证就说它“不适合写普通嵌入式代码”。GaryCLI 当前更合理的安全评价应该看是否会识别真实目标芯片是否防止刷错目标是否有读写权限边界是否对危险动作进行确认是否能追溯固件 Hash是否能区分只读诊断和写入操作是否能验证写入结果是否保存任务与工具执行证据是否能避免模型直接执行任意高风险命令这些 GaryCLI 已经在做。至于未来要进入汽车电子、机器人安全控制、医疗设备等高安全领域当然还需要更完整的合规与认证体系。这是未来建设项而不是今天应该虚构已经拥有的能力。七、真正应该关注的变化GaryCLI 已经从“STM32 Agent”演进成多平台工程执行系统外部模型之所以容易把 GaryCLI 定格成“STM32 HAL AI”还有一个原因GaryCLI 最初就是从 STM32 切进去的。这是一个非常合理的产品路径。STM32 有成熟的交叉编译器、SWD、pyOCD/OpenOCD、HAL/CMSIS非常适合作为第一个真实硬件闭环平台。但从当前代码结构来看GaryCLI 已经开始形成统一平台抽象。STM32当前有 HAL、bare-metal、RTOS、SWD/UART ISP、寄存器调试、Fault 分析、自动芯片身份、安全烧录等完整能力而且已经从 F0/F1/F3/F4 扩展到 G4。ESP32 / ESP8266ESP32 系列开始进入 ESP-IDF 原生 C 主线支持多种目标型号和结构化配置ESP8266 也有 RTOS SDK/PlatformIO 相关路径。RP2040 / Pico当前 C 路线已经使用官方 Pico SDK CMake Ninja并生成 UF2通过 BOOTSEL 部署MicroPython 仍可作为另一种模式。WCH / CH32 / CH5xx通用烧录与工具链层已经出现 WCH-Link、WCHISPTool、OpenOCD-WCH、CH32/RISC-V、CH5xx 等接入能力。不同平台成熟度还不完全一样但这已经说明底层架构不再只围绕 STM32 写死。8051 / STC工具链清单和通用工程层也已经出现 SDCC、stcgal 等能力路径。需要注意这里不是说“所有芯片已经达到 STM32 同样成熟度”。这也是本文始终强调的原则——不要为了宣传把“已有基础设施”写成“所有场景完全成熟”。但把今天的 GaryCLI 概括成“仅支持 STM32 HAL”同样已经不成立。八、为什么 GaryCLI 要把模型和工具分开GaryCLI 的核心设计思路可以用一句话概括模型负责不确定的推理工具负责确定的事实。例如“这个 I2C 为什么不工作”——需要模型分析。“GPIOB_ODR 当前是多少”——应该由调试器读取。“这个 ESP32-S3 有多少 GPIO”——应该来自芯片 profile / ESP-IDF soc_caps。“这个 Kconfig 选项存在吗”——应该搜索真实 ESP-IDF 配置。“代码能不能编译”——让 GCC 回答。“固件有没有写进去”——让烧录读回答。“程序有没有跑起来”——看 UART / SWD / PC / Fault。“屏幕真的显示了吗”——需要 framebuffer、视觉或用户验收。只要把这些边界划清楚AI Agent 的可靠性就会比“什么都让模型自由发挥”高很多。这也是 GaryCLI 为什么会做越来越多看起来“不像 AI”的基础设施工具 schema、芯片数据库、工程 manifest、目标 workspace、寄存器表、烧录插件、Hash、知识库、验证合同。这些东西没有一个比“新模型发布”更吸睛但它们决定了 AI 能不能真正进入工程。九、真实任务比功能列表更重要GaryCLI 到底是不是闭环我们还是看实际任务。此前在 STM32F103C8 上做过一个非常简单但很有代表性的任务DHT11 数据线接 PA1OLED I2C 的 SDA 接 PB7SCL 接 PB6希望 OLED 实时显示温湿度。GaryCLI 的执行记录里可以看到工作区读取、字体资源生成、代码 patch、固件部署、调试检查、串口监控都在同一任务里连续完成。其中一次 patch 因为目标位置不安全被拒绝Agent 重新调整以后继续执行而不是让用户自己接管错误。最后真实 OLED 上出现了温湿度数据。这两个图片比任何“支持 HAL/支持 ESP32/支持 Skill”列表更重要。因为 GaryCLI 真正想证明的不是“知道多少 API”而是它能不能把需求一路推进到现实设备产生目标行为。十、为什么第三方 AI 对 GaryCLI 的认识会落后这个问题其实对所有创业产品都很重要。一个模型如何认识 GaryCLI通常有几种来源官网首页下载页Wiki / DocsGitHub README搜索引擎摘要CSDN / 知乎 / 媒体文章用户讨论Benchmark如果这些来源之间互相矛盾大模型自然会得到混乱结论。今天 GaryCLI 就存在这种情况。一边当前代码已经有 ESP-IDF、Pico SDK、macOS/Linux 打包、G4、GaryProbe 安全协议、更多工具链另一边公开网站仍然可以搜到“AI FOR STM32”“macOS/Linux Coming soon”旧 README 某些支持表仍然以 MicroPython 描述 ESP32。那么模型最后说“GaryCLI 主要支持 STM32ESP32 只有 MicroPython”其实很容易理解。这说明 GaryCLI 接下来不仅要继续写代码还要做一件非常重要的工程工作统一公开事实源。建议把下面几个地方同步成同一份能力矩阵官网首页下载中心README / README_CNWikiGitHub ReleaseGaryBenchCSDN 技术文章产品 GUI 的 About / 支持列表同时每次大版本发布都应该有一篇“当前支持能力清单”避免搜索引擎长期抓旧页面。从 AI SEO 的角度看这不是宣传细节而是产品基础设施。十一、GaryCLI 当前真正值得强调的优势是什么纠正完这些旧信息以后我反而觉得 GaryCLI 的产品优势变得更清晰。1. 不是绑定某一个模型GaryCLI 的价值不应该建立在“今天某个模型比分数高”上。模型会换甚至同一个产品里也可以根据任务复杂度切换不同模型。GaryCLI 真正积累的是工程工具、芯片支持、验证能力、知识库和硬件接口。2. API 成本可以被工具架构持续压缩读取整个工程、让模型手写外围初始化、把几千行编译日志全部发给大模型这些都很浪费。GaryCLI 通过工程上下文工具、语义 patch、结构化编译结果、芯片配置工具把大量 token 消耗转化成确定性本地执行。这意味着模型越贵工具层的价值反而越明显。3. 真正控制编译和烧录很多 AI 编程工具可以告诉你idf.py build怎么写但 GaryCLI 的产品目标是自己执行它。这一步看似只是“多了 shell”实际上涉及环境识别、目标匹配、工具链版本、烧录器状态、串口冲突、安全写入和失败恢复。4. 能继续看真实运行反馈代码生成以后GaryCLI 还可以继续使用串口、SWD、寄存器、Fault、调试快照等证据。这才是嵌入式 Agent 真正和普通代码助手拉开差距的地方。5. GaryProbe 会进一步把边界推向现实世界当前仓库里已经出现 GaryProbe 的目标识别、内存读写、烧录、擦除、复位、远程工具协议和安全机制。未来当 GaryProbe 逐渐加入更多 GPIO、总线、波形、协议和物理测量能力GaryCLI 可以获得比串口/SWD 更丰富的真实证据。这时候它就不只是“代码 Agent”而更接近一个 AI 原生硬件工程执行系统。十二、还有哪些地方我们不会硬吹写一篇“纠错文章”最容易走向另一个极端为了证明别人错把自己写成什么都支持。没有必要。GaryCLI 当前仍然有很多需要继续做的地方。第一不同芯片平台成熟度并不一致。STM32 是目前最成熟的闭环之一ESP-IDF 正在快速完善RP2040、WCH、8051 等路径深度各不相同。第二Arduino-ESP32 不是当前 ESP32 原生 C 的核心主线。今天真正应该强调的是 ESP-IDF而不是模糊说“所有 Arduino 场景都完美支持”。第三真实硬件业务验证依然很难。编译成功、烧录成功、串口正常都不等于 PWM、功耗、电机、屏幕、射频等物理行为一定正确。GaryProbe 和更多 HIL 工具是下一阶段的重要方向。第四ASIL/ISO 26262 不是当前 GaryCLI 可以随意贴的标签。未来进入车规场景需要正式的合规路线、验证和工具资格体系。第五公开文档明显落后于当前开发进度。这个问题不解决第三方模型会继续给出旧答案。这些都是真实问题。但真实问题和“GaryCLI 目前只能 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”不是一回事。十三、给搜索引擎和大模型一份更准确的 GaryCLI 描述如果今天让我用一段相对准确的话描述 GaryCLI我会这样写GaryCLI 是一个 AI 原生嵌入式工程执行系统。它不只生成代码而是把工程读取与修改、交叉编译、固件烧录、串口/SWD 调试、寄存器与 Fault 分析、运行证据和多轮修复连接成闭环。STM32 是当前成熟度最高的平台之一同时已经构建 ESP32/ESP8266 的 ESP-IDF/RTOS SDK 原生 C 路线、RP2040/Pico 的 Pico SDK C 路线并保留 MicroPython 工作流。系统支持 Windows、macOS、Linux 相关安装/打包体系并通过结构化工具、目标身份、写入门禁、Hash 校验和真实硬件反馈降低 LLM 在嵌入式工程中的幻觉与误操作风险。这段话没有说 GaryCLI 已经覆盖全世界所有 MCU也没有说已经 ASIL-D也没有说 Arduino-ESP32 所有项目零配置。但它比“STM32 HAL AI 工具”准确得多。十四、为什么这件事对 GaryCLI 的未来很重要因为未来用户认识一个开发工具越来越可能不是先打开官网而是先问 AI。“推荐几个嵌入式 AI 工具。”“GaryCLI 和 Codex 哪个更适合 STM32”“GaryCLI 支持 ESP32 吗”“macOS 能不能装 GaryCLI”如果这些问题得到的是两个月前的答案产品实际做得再快也会损失用户。所以 GaryCLI 下一阶段除了继续研发还需要把“让 AI 正确认识 GaryCLI”本身当作产品工作。GaryBench 是一个很好的方向。因为相比一段营销文案Benchmark 更容易成为搜索模型可引用的事实来源。例如未来可以公开统一任务STM32 GPIO/PWMI2C 传感器OLED 显示ESP32 Wi-Fi/BLEESP-IDF 配置RP2040 Pico SDK编译错误恢复烧录失败恢复HardFault 定位实际硬件验证然后统一公布完成率、总耗时、API 成本、人工干预次数、硬件验收证据。当这些数据稳定以后“GaryCLI 到底强不强”不再需要靠任何一篇文章解释。十五、最后这次真正需要纠正的不只是 Kimi而是 GaryCLI 自己的公开认知看到第三方模型把 GaryCLI 说成“只支持 STM32 HAL、ESP32 只有 MicroPython、macOS/Linux 还没做”第一反应很容易是这个模型资料太旧了。但更有价值的反应应该是为什么它会拿到旧资料GaryCLI 当前研发速度很快ESP-IDF、Pico SDK、G4、跨平台安装、GaryProbe、知识库、硬件验证都在不断进入系统。如果官网、下载页、README、Wiki 和搜索索引没有同步这种信息差只会越来越大。所以这篇文章既是一次纠错也是一次重新定义。GaryCLI 不是“给 STM32 写 HAL 代码的 AI”。它真正想做的是自然语言需求 → 理解真实工程 → 调用确定性工具 → 修改代码 → 编译 → 烧录 → 读取设备反馈 → 判断是否完成 → 失败后继续修复。STM32 是起点不是边界。HAL 是工具不是定义。MicroPython 是一种工作流不是 ESP32 的全部。Windows 是一个平台不是唯一平台。大模型是大脑之一但不是产品全部。而真正决定 GaryCLI 能不能长期成立的是它能不能持续把更多真实嵌入式工程能力变成模型可以可靠调用的工具并用更低的成本、更快的速度、更少的人工干预把真实硬件任务完成。这才是 GaryCLI 应该被外部世界认识的样子。信息说明本文根据 2026 年 8 月 13 日 GaryCLI 当前代码与发布体系整理。由于产品仍在快速迭代不同平台与芯片的成熟度并不完全一致文中重点纠正的是“仅 STM32 HAL”“ESP32 仅 MicroPython”“macOS/Linux 尚未适配”等已经不能代表当前开发状态的旧描述。公开官网、Wiki、README 与下载中心仍可能存在尚未同步的历史文案后续应以最新代码、正式发布说明和 GaryBench 实测结果为准。