固件改完必须等真机才能验证？用 Simantic 把 MCU 测试接进开发循环
AI 编码助手可以很快生成一段嵌入式代码，但代码能编译，不代表它在目标微控制器上真的按预期运行。过去，开发者往往要烧录开发板、连接外围设备，再手动观察 UART、GPIO 或总线行为；当 Agent 连续改动代码时，硬件验证很容易成为反馈瓶颈。Simantic 提供云端固件模拟服务，目标是让工程师和 AI Agent 在不占用实体开发板的情况下运行固件、观察结果并验证行为。
需要先划清边界：模拟通过并不等于真实芯片上的一切都正确。时序、外设模型覆盖度和实际电气行为仍需在目标硬件上复核。Simantic 自己也把真实硅片作为模拟验证的参照，并强调记录差异和覆盖边界。因此，它更适合作为快速反馈层，而不是取代硬件测试的证明器。
两种使用方式：云端运行与本地 CLI
官网把 Cloud Sim 描述为可通过 HTTP API、TypeScript 和 Python 客户端调用的云端模拟服务，并展示了在 CI/CD 中测试每次提交、从终端运行，以及让 AI Agent 测试其生成代码等用途。网站同时标明 CLI 和 MCP 仍为 Coming soon；不要把这些路线图功能误认为现阶段已公开可用。
另一方面，当前 CLI 文档已经提供名为 sim 的单文件程序，用于在本机运行固件模拟。文档列出的平台是 Apple Silicon macOS 与 x86-64 Linux；Windows 用户需在 WSL2 中运行 Linux 版本。它要求 Python 3.12 或更新版本及可加载的共享库，并需要 Simantic 账户。这里的“本机运行”指模拟执行在本地，不代表工具完全离线：文档说明每次运行都会向后端核验保存的凭据。
安装脚本会下载对应平台的二进制、校验 checksum，并放到 ~/.local/bin。安装前应阅读官方文档和组织的安全政策；不要把访问令牌写入仓库或 CI 日志。交互环境可用浏览器登录，headless 环境可使用 SIMANTIC_TOKEN。下例展示安装与版本检查的基本形态：
curl -fsSL https://simantic.com/install | sh export PATH="$HOME/.local/bin:$PATH" sim --version
CLI 文档也列出 Homebrew 安装方式。若在 WSL2 使用，官方建议把程序、固件及缓存放在 Linux 文件系统，而非 /mnt/c，以避免权限、重命名和性能方面的问题。
从 ELF 开始做可重复的冒烟测试
最直接的 CLI 流程是选择 MCU，再用 run --elf 指定固件映像。比如：
sim models sim STM32F072RB run --elf build/firmware.elf --ascii --timeout 3
sim models 列出该二进制支持的 MCU 及模型状态；文档区分已建模、模型不完整和尚未建模的目标。运行时，UART 输出可显示为 ASCII，--timeout 限制模拟的虚拟秒数。对冒烟测试而言，重点不是“命令返回成功”这么简单，而是把可观察行为变成断言：CLI 支持 --expect，要求 UART 输出包含指定文本；也支持 --expect-absent，若出现指定内容则失败。这样可以把启动横幅、初始化完成标记或错误提示纳入自动化检查。
例如，已有固件会在启动时输出 READY，可将断言加入测试命令：
sim STM32F072RB run \ --elf build/firmware.elf \ --timeout 3 \ --expect READY \ --expect-absent "panic"
这只是基于文档选项拼出的示例命令；实际字符串、目标型号和 ELF 路径必须替换为项目中的真实值。还要注意，串口出现 READY 只能证明该输出路径发生了，不足以证明控制器外围行为正确。若测试 LED、传感器或通信总线，应增加对应的场景、信号观测和真机回归。
把模拟放进 CI，也把证据留下来
Simantic CLI 文档列有 --record ，可将运行证据写入目录中的 JSONL 文件；此外，命令行还提供场景运行入口 sim run --scenario ，适用于描述一台或多台 MCU 及其连线的场景。组合起来，团队可以把固件构建、模拟运行、UART 断言和证据归档放入 CI，让每次改动至少经过一致的快速检查。
但流水线应明确区分三种结果：构建失败、模拟断言失败、模拟通过但仍需硬件验证。模拟器不能覆盖的外设或行为不应默认为通过。建议将目标 MCU、模拟器版本、固件构建标识和测试场景一并保存；失败时先复现模拟输入，再在硬件上定位差异。对于影响安全或时序的固件，还应保留实体板测试与测量记录。
Simantic 的产品页还展示了 PR 审查机器人：它会构建固件、在模拟器中运行场景，并把测试内容、发现和建议写回 PR。页面将其描述为产品能力，但具体可用范围、接入条件及套餐限制应以当前账户与官方文档为准。产品定价页列出 Community 计划每月含 10 美元额度及 3 个并发模拟，Developer 计划每月 100 美元并含 200 美元额度、10 个并发运行；价格和配额可能调整，采用前应再次确认。
适合快速反馈，不适合跳过真机
当团队频繁等待共享开发板、Agent 生成代码需要快速回归，或希望在 CI 里稳定重放 MCU 行为时，Simantic 的模拟工作流值得评估。开始时先挑选已建模目标和一项可观察行为，把“固件能启动”改写成清晰断言，再逐步加入场景与记录文件。对不完整模型要显式标注，不要让它混入绿色构建的含义中。
更稳妥的闭环是：模拟负责便宜、快速、可重复的反馈；真机负责确认模型无法保证的外设、电气和时序特性。AI Agent 可以负责提出代码改动，但测试条件和验收标准仍由工程团队定义。这样，模拟器不会成为“看起来通过”的新盲点，而是成为验证链条中可追踪的一层。