参加电赛时，最耗时间的往往不是敲下一段代码，而是来回切换：查芯片资料、改工程、打开 Keil、编译、接串口、看波形，再把错误复制给 AI。一个环节的结果，还得靠人手搬到下一个环节。
我正在做的 EDC Workbench，就是想把这些分散的动作接到同一张工作台上。它不是一个“输入题目就自动拿奖”的工具，而是一个面向电子设计竞赛的本地工程助手：让 AI 能读懂当前工程，让编译与测试留下可核对的证据，让人始终掌握实际硬件操作的决定权。
这篇记录依据项目截至 2026 年 9 月 11 日的代码、使用流程和实现审计整理。下面会明确区分已经接通的功能、模拟演示，以及仍然需要补上的实机环节。
一、先用一句话理解：给硬件开发搭一个有记录的操作台
可以把它理解为“会调用工具的工程聊天窗口，加上串口、编译和测试面板”。聊天负责理解目标、提出修改；工具负责真正读取文件、运行编译或执行测试；报告负责说明结果从哪里来。
理想工作顺序是：选工程 → 告诉助手有哪些硬件 → 准备 SDK → 提出修改建议 → 人确认应用 → 编译或测试 → 根据证据继续调整。关键不是让 AI 多说几句，而是让“我已经修好了”后面跟着可检查的文件、日志或测量结果。
桌面程序使用 Wails v2，将 Go 后端与 React、TypeScript 前端放在一起。前端呈现工作区、工程助手和模块面板，后端负责本地文件、进程和设备相关操作。界面采用 Fluent UI 风格，尽量让硬件任务也能像操作普通桌面软件一样清楚。
二、现在能做什么？先把真实能力和演示分开
- 工程助手：读取选定工程及相关声明，调用工具，给出代码修改建议；用户确认后应用，支持回退。
- 串口：真实扫描、连接、发送和接收数据，可以导出日志；接线、电平和通信协议仍由使用者确认。
- Keil 编译：调用本机的 Keil 可执行程序，收集本次编译日志，而不是只生成一段示意输出。
- 图片视觉测试：对 PNG、JPEG 执行桌面端图形检测，管理测试用例并保存结果。
- MCP 工具连接：通过标准输入输出连接工具服务，发现工具、查看参数并在确认后调用。
- 测试步骤串联：把工具调用按顺序执行，对返回值设置断言，失败时停止，保留运行记录。
- 电赛积木演示：支持拖拽、参数设置、流程导入导出和模拟报告；原有竞赛积木执行仍以确定性模拟为主。
尤其要分清：真实调用了一个工具，不等于这个工具连接了真实板卡。例如 MCP 通信与参数校验可以是真实的，但被调用的设备适配器仍然可能是虚拟板卡。这是理解目前版本最重要的一条边界。
三、第一次打开，先选工程，不要急着让 AI 改代码
已有构建产物时，可运行 build/bin/edc-workbench.exe。从源码开发则使用项目的 scripts/dev.ps1；生成桌面程序使用 scripts/build.ps1。需要先准备好项目要求的 Go、Node、Wails 和 Windows 桌面构建依赖。
项目脚本目前针对 Wails 的分析工具兼容性固定了 Go 1.23.6。这是该项目的构建约束，并不是建议所有 Go 项目都退回这个版本。遇到新版本 Go 相关分析错误，应先核对项目脚本与环境，而不是随意修改业务代码。
- 选择工作区。指向实际工程根目录，让后续文件读取、测试报告和代码修改有明确范围。
- 准备硬件说明。补充芯片或开发板型号、连接方式、现有 SDK 和希望测试的能力。只写“STM32”不足以确定具体工程配置。
- 核对工程现状。先确认它原本能否编译，记录当前串口参数和依赖位置。已有问题要与 AI 修改引入的问题分开。
- 再配置助手。在“工程助手 → API”中填入支持工具调用的兼容 Chat Completions 服务、模型和密钥。
当前实现不会把模型 API 密钥写入普通持久化配置，重启后需要重新提供。不要因此误以为所有数据都不会离开电脑：启用远程模型时，发送给模型的聊天内容和相关工程片段仍可能传到所选服务。包含比赛保密资料或商业代码时，要先确认服务的数据政策。
基础本地测试并不都依赖在线模型；如果希望助手本身也离线运行，需要另行准备兼容且能执行工具调用的本地模型服务。
四、让助手改代码：先提建议，再看差异，最后应用
比较有效的提问不是“帮我完成电赛”，而是给出一个可验证的小任务。例如：“检查这个串口解析函数，解释它遇到半包时的行为，提出最小修改，并说明我该发送什么数据验证。”
- 让助手先读取相关文件、硬件声明和已有日志，确认它理解的是当前工程。
- 要求它说明修改位置、原因和验证方法，而不是直接接受一整段替换代码。
- 查看建议的文件差异，再由自己确认应用。
- 运行对应编译或测试，把本次结果作为下一轮讨论依据。
应用已有文件修改时，程序会核对原始内容，避免建议生成后文件又被人修改，却仍被旧建议覆盖。创建文件也有范围限制，例如父目录需要已经存在。这里追求的是可控的小步修改，不是让模型在磁盘里任意新建、删除和重写工程。
即使支持回退，也建议把工程纳入 Git。一次修改对应一次测试，验证通过再提交，会比积累几十处改动后一起排错轻松得多。
五、先编译，再谈上板：Keil 接入需要填哪些东西
Keil 面板不是替代编译器，而是把现有 Keil 编译过程接进工作台。因此电脑上仍需有可用的 Keil，以及对应芯片的软件包和工程依赖。
- 选择本机
UV4.exe的实际路径。 - 填写工作区内的
.uvprojx或.uvproj工程路径。 - 选择与工程一致的 Target，检查不是误用了另一个板卡配置。
- 确认信任该工程后启动编译。工程构建可能执行其配置的命令，因此不要直接运行来源不明的工程。
- 阅读本次生成的独立编译日志，核对错误、警告和输出文件。
实现中每次编译都有带唯一标识的日志，避免把上次成功当作这次成功；编译调用也有超时限制。但是，编译成功只说明构建环节通过，并不表示程序已经烧录，更不表示实体板卡运行正常。
烧录器选择、固件地址、写入校验、复位和运行握手仍需要专门的实机流程。当前不能把面板里的“成功”直接理解为完整的硬件验收结果。
六、串口和视觉测试：先把能复现的小实验跑通
串口：先确定收到的是当前设备的新数据
先确认设备连接和供电，再扫描端口，选择正确端口及通信参数，连接后发送约定的命令，观察新到达的数据。测试完可以导出日志，供后续排查。
这里有两个容易忽略的问题：一是 TTL 电平与 RS-232 等接口不能混接；二是历史日志只是已经收到的数据，不会因为点了读取就自动变成一次新测量。如果要评价某次代码修改，需要重新触发设备采样，并能把数据与这次固件或测试对应起来。
视觉：从简单图片开始，而不是直接上摄像头闭环
当前图形检测适合从相互分离、较清晰的实心圆、三角形和矩形开始。导入 PNG 或 JPEG，调整阈值和感兴趣区域，也就是只检查图片中指定的一块区域，再设置预期数量，保存成测试用例。
之后每次调整参数都用同一套图片复测，观察哪些用例通过、哪些退步。跨次比较会核对相关内容哈希，避免拿不同内容冒充同一版本的比较结果。
项目还可以导出 Go 版本的基础视觉运行代码，并实际运行导出代码的测试，保存日志与哈希。但导出后的代码如果被手动修改，不会自动替换桌面程序里的内置算法；它也不是能够直接烧进 OpenMV 或 K230 的固件。摄像头采集、目标设备 SDK 和部署适配仍需继续实现。
七、MCP 是什么？把外部工具接成助手能调用的按钮
把 MCP 理解成工具之间约定好的“插头”就够了。一个工具服务可以告诉工作台：“我有哪些功能、每个功能要填什么参数、运行后返回什么结果。”助手因此不用只给出建议，也能在允许的范围内调用工具。
当前实现接的是本地标准输入输出方式：工作台启动配置好的工具进程，与它握手，读取工具清单和参数格式。接入不熟悉的工具前，要检查实际执行的程序及参数；工具进程拥有它自身的系统权限，不能把所有第三方工具当成天然安全的插件。
单次调用跑通后，可以组成 1 到 20 步的线性测试。例如先连接设备，再读取状态，然后执行测量，最后判断数值是否在范围内。返回结果通过 JSON Pointer 指定字段，支持相等、小于等于、大于等于等断言；失败会停止，也可以取消。
目前单次工具调用与整段序列分别有 30 秒和 90 秒的超时边界。它适合短测试，不应直接拿来等待长时间烧录或跑一小时的实验。复杂分支、步骤间通用变量传递，以及 HTTP/OAuth 工具连接，也不能假设已经具备。
八、模拟自检的 40 分到 100 分，到底证明了什么
项目提供 contest_local_self_test 自检工具，可使用空参数对象 {} 执行，并检查返回结果中的 /structuredContent/passed 是否为 true。
它会覆盖虚拟板卡连接、模拟基线部署、采样和评分，并检查一些故意制造的错误：设备离线、型号不符、旧版本证据、缺失测量、单位不对或必要断言不通过等。
其中从 40 分到 100 分的过程使用预设候选，不是 AI 临场写出更优算法，也不是官方电赛评分。这套自检验证的是“错误应该被拒绝、证据应该对应版本、流程能够串起来”。它非常有用，但证明的是软件流程，而不是实体硬件的性能。
同样，原有竞赛积木包含工业采样、光点跟踪、单目测量、送药机器人和电路扫描等预设；能拖动步骤、改参数、导出 CSV 或 JSON，不代表这些场景已在真实设备上全部完成。
九、东西保存在哪里？换电脑前要带走什么
工作区里会出现几类文件：edc.hardware.json 保存硬件声明，edc.mcp.json 保存工具连接配置；视觉测试、视觉运行、库测试与 MCP 运行分别有对应目录，编译则保留本次独立日志。
建议备份整个工程及这些测试记录，而不是只复制可执行程序。分享工作区前要检查配置和日志，避免把令牌、设备身份或私有路径一起公开。硬件声明和工具配置也不要写入明文密钥。
部分聊天或模拟流程草稿保存在桌面 WebView 的本地存储里，它与普通浏览器预览不是同一份数据。需要迁移时先使用相应导出功能，不要默认重装或更换电脑后还能自动找回。
十、下一步：让“编译通过”真正走到“实测通过”
接下来最值得做的不是继续增加演示按钮，而是先挑一块明确的板卡，完成一条小而真实的链路：固定工程版本，编译固件，烧录并读回校验，确认设备启动，获取带版本标识的测量数据，按明确阈值判断结果。
这需要具体适配：STM32、GD32、OpenMV、K230 并不是换一个型号字段就能互通；烧录器、固件格式、SDK、接口和运行环境各不相同。仪器控制还需要处理 SCPI、Modbus 等协议，以及电压、电流和动作范围的安全限制。
所谓自动优化，也应该在这些证据可靠之后再加入。先限定允许修改的参数、试验次数、时间预算和停止条件，再考虑自动搜索。否则只是让程序更快地重复一个未经确认的实验。
对我来说，这个项目的价值不是承诺 AI 取代硬件调试，而是让每一步更清楚：改了什么、运行了什么、结果属于哪个版本、哪些结论还需要人拿起仪器确认。先把这些基础打实，自动化才有值得信任的落点。
整理依据：项目 README、docs/current-workflow.md、docs/implementation-audit.md，以及工程助手、Keil、串口、视觉测试和 MCP 序列相关实现。本篇为项目现状说明，不代表所有实体硬件已完成独立实测；文中没有附带尚未确认公开的源码下载地址。