一个机器人项目里，机械设计师改了进料机构，控制组却还在按旧轴线写程序；仿真画面能动，碰撞形体和实际零件也可能隔着一个版本。CadCove-FRC v0.2.0 想缩短这种交接距离。项目在 2026 年 10 月 18 日发布该版本，把 CadQuery/Python 几何、STEP 导入、Java/WPILib 机器人代码和基于 Rust/Rapier 的本地仿真接到 VS Code 或 WPILib 编辑器里；仓库用 Team 3310 的 Amarillo 机器人提供完整样例。[1][2] 它的工程价值取决于同一工作区能否留下可检查的几何、控制和物理绑定变更，而非画面是否像比赛录像。
发布页列出 Windows x64、macOS Apple Silicon、macOS Intel 和 Linux x64 四个 VSIX 包。使用者仍需单独准备 Bun 1.4.2、Python 3.12 与固定版本的 CadQuery 依赖；运行机器人程序还需 WPILib 2026 及队伍所用厂商桌面依赖。源码构建需要 Rust，下载原生扩展包的普通使用流程则不要求自行编译 Rust。安装文档提供从 GitHub 下载该版本的流程；项目尚未在 Marketplace 上架，也未宣称通过硬件认证。[1][3]
同一个目录究竟连了哪些东西
CadCove 的建模入口是可编辑的 Python/CadQuery 和原生 OCCT 几何，旧零件可由 STEP 导入。编辑器内 WebGPU 画布负责查看、旋转及截图；几何计算在本地 Python/OCCT 侧执行。把浏览器视图、源模型和导出的 STEP 分开看很重要：画面好看并不能说明实体拓扑有效，导出再导入也要另测。项目系统卡明确记录了样例中两段导轨的 STEP 往返限制，以及一处导入场地销件的实体有效性问题。[2][4]
控制一侧连接 Java、WPILib 和 Phoenix 6，仿真一侧由原生 Rust/Rapier 处理运动、接触及机构。团队可以在代码工作区修改电机和传感器绑定，观察本地场景的行为。系统卡区分偏向响应速度、简化接触的 gameplay 模式和保留更多接触细节、可能慢于实时的 detailed 模式；观看演示视频时尤其要记住这一区别。视频是剪辑演示，项目也没有把它当作实时性能基准。[2]
编码智能体的入口比较务实：文件、CLI，以及可选的 MCP 工具，让智能体执行构建、尺寸检查、几何检查、取景和导出，再把失败信息返回到编辑循环。安装后执行 CadCove: Initialize Team Workspace 会生成面向 Codex、Claude、Copilot 的工作区说明。人仍要审查编辑结果。一个改变轴距的提示若只让智能体改 models.py 和截图，而碰撞体、传动比及控制限位还留在旧状态，统一界面反而可能给团队造成“已经同步”的错觉。项目样例说明 CAD 源码变更须审查对应物理绑定，现有碰撞快照只是经过核对的基线。[2][3][4]
工作区合并还有一个容易忽略的版本问题：几何文件、机器人代码和仿真配置即使在一个 Git 仓库里，也可能在语义上互相错开。可为每次仿真运行保存提交哈希、CAD 构建产物哈希、碰撞缓存版本、机器人 JAR 和场地文件摘要；把这些写进测试记录，回头才能解释为什么两位队员看到不同的运行结果。项目样例的 example-setup.json 就记录下载和世界文件的哈希、平台及构建状态。组织自己的项目时，沿用这种“产物能追到输入”的习惯，比给截图打一个醒目的版本号可靠。[4]
让智能体参加这条链条，最好先给它有限而清晰的任务边界：一个零件模块、指定的测量点、可运行的校验命令以及提交前的差异报告。改机器人控制代码时附上受影响的配置键；改几何时列出碰撞形体和约束的检查项。智能体能帮忙取景和比对，但最终签字的人要看到原始参数、检查结果和失败日志。复杂装配里常漏掉长度单位、局部坐标轴和重复实例的身份。若本次修改牵涉供应商 STEP，先锁住原始文件，再保存修订版本与来源说明；对直接从代码生成的模型，也保留生成脚本的依赖版本。这样机械组确认的是可重建的实体，而非只能在某台工作站显示的一次性画面。
Team 3310 样例能证明什么
公开 VSIX 带通用工具和一个小型训练装置；完整的 Team 3310 Amarillo CAD、机器人程序及仿真绑定放在对应发行版源码内。样例安装脚本按说明从 FIRST 官方站下载 2026 REBUILT 赛场 STEP，核对尺寸和 SHA-256，再在本机生成场景；厂商 SDK 也在本地按 Gradle 依赖取得，并未塞进公开 VSIX。[1][3][4] 这种分发边界使团队能够沿着来源追查素材，也意味着第一次搭建要预留网络、版本锁定和本地构建时间。
样例指南披露一条具体可检查的几何路线：109 个原生 CadQuery 设计、178 个实例与保留的厂商及自定义 STEP 部件结合，整体维持 1,958 个实例标识及变换；场地重建涉及 6,186 个实例。数目是该样例的内部资产与构建记录，不能当成其他机器人项目的覆盖能力指标。指南还给出 macOS arm64 上重建、碰撞哈希、载入及短程驱动的局部验证数据，同时明确大样例的 Windows/Linux 执行未被这些结果证明合格。[4]
有意思的细节是它把“看见形状”和“认出零件”拆开了。几何模型可以通过缓存快速再开，原生 OCCT 输出显示网格；实例 ID、装配变换、碰撞哈希及机器人配置另外有校验链。团队如果想让编码智能体承担重复设计修改，应该保留这类可追踪标识，否则每次局部改模都可能让仿真绑定重新靠人工猜测。这里的做法值得借鉴，至于能否适配自家复杂装配，还得用自己的零件库试。[2][4]
样例的场地和机器人结构也说明了迁移难度。FIRST 赛场是有既定规则和公开几何的对象，队伍自己的机器人仍会有未分类 STEP、供应商零件和临时装配。移植前先把资产分成参数化源模型、只读供应商几何、场景道具和碰撞近似四类，为每类列出位置、单位、版本、授权、构建时间和可编辑责任人。把一份庞大的 STEP 直接丢进工作区，虽然能够看到完整外形，却很难指望代理自动猜出哪些面该碰撞、哪根轴由哪个电机驱动。[2][4]
场景规模还影响性能结论。项目展示了部分 Mac 硬件上的验收、Windows 11/Intel 图形环境的单独检查、macOS/Linux 的软件图形 CI，以及 Windows 原生构建和包装检查；这些都是不同层级的证据。评估者要记下自己所用 GPU/驱动、CPU 和是否软件渲染，在冷启动、热缓存重开及复杂接触下分别测量。把截图帧率、仿真物理步进速度和机器人程序响应时间混在一张“FPS”图里，会让性能问题失去定位线索。[1][2]
用一周的小实验核对“设计—控制—仿真”闭环
先做环境记录。选一台支持的 OS/架构，安装与包匹配的 VSIX，记录编辑器版本、Bun、Python、CadQuery、WPILib 和厂商库版本，保存 VSIX 发布附件中的校验信息。安装指南要求 VS Code 1.100 或更新版本，或 WPILib 2026 编辑器；报告中不同平台的测试范围有区别，尤其不能把 Windows CI 的原生构建与打包检查说成所有 GPU 上的交互测试。先在隔离的受信任工作区执行 cadcove capabilities，确认依赖和运行入口，再复制自己的最小机器人项目。[1][3]
接着用样例走通“读—改—验”。从发布标签对应源码搭建 Amarillo 工作区；脚本下载 FIRST 场地、解析构件、编译机器人程序后，打开 CAD 视图和 live simulation。按照样例指南在 WPILib Sim GUI 映射控制器并进入 Teleoperated。先录下一份基线：模型构建时间、每次编辑的重建时间、导出 STEP 后复导的实体检查、机器人程序编译、仿真步进速度及启动/退出状态。首次赛场转换可能要数分钟，这一段也要计入成本。[3][4]
然后只改一个可以尺量的部件，例如把导向板安装孔的间距改为明确的毫米值。由人写下验收值与允许公差，让智能体编辑参数化 Python 文件，调用工具检查尺寸并截取两个视角；机械工程师对照原始 CAD 和 STEP 复导结果签字。控制工程师再核对该改动是否触及限位、坐标系、传感器方向或电机配置；涉及接触面时重建碰撞映射，记录哈希变动。若智能体只改视觉模型而没有提醒检查物理绑定，这次任务应判为未完成。[2][4]
仿真测试分两类跑。第一类是功能回归：零初速、固定操纵输入、固定时长，查看驱动方向、行程、碰撞、退出与日志；换一个故意错误的电机 ID 或装配坐标，观察能否在上线真机前暴露。第二类是参数敏感性：在合理范围内改变质量、摩擦、齿轮比与电池条件，绘制运动结果范围，与实测加速、制动距离和机构到位时间比对。gameplay 模式适合快速检查程序流程；详细模式另做接触、稳定性和运行速度记录。报告原始输入及配置文件版本，比截取一帧“运动成功”更可复核。[2][4]
最后给试验加一条真实机器人回路。使用安全场地与限速程序测量一次同类动作，把电机输出、编码器、视频时间戳和接触情况对齐。模拟的 Limelight 观察是近似量；质量、摩擦、电机 ID、传动比及控制行为也不会从 CAD 自动推得。任何涉及安全距离或机构冲击的结论都要经过团队标定和真机检查。[2] 这套步骤的退出条件可以写清楚：模型往返几何检查通过，控制/仿真绑定有责任人，能从版本库重建，关键动作的实测偏差落在团队自行制定的阈值内。阈值必须由机械与控制负责人根据设备用途决定。
落地时别漏掉权限和素材边界
CadCove 本地运行，项目本身不要求 CadCove 账号或 AI API 密钥；接入外部编码智能体时，代码和截图是否发送到供应商由该智能体自身设置决定。打开受信任项目之前，先看 Python CAD 和机器人程序的来源，因为它们以本机用户权限执行。比赛季资料、驱动站配置和凭据也不宜出现在共享截图或版本库。[2] 对使用外部模型的队伍，这比“项目可本地运行”更接近实际的信息流审计。
试用还需要一个“故意失败”的剧本。把 Python CAD 中一项零件参数改成非法值，确认编辑器保留上次成功画面时是否显著显示构建失败；再让机器人程序缺少桌面厂商依赖，确认控制与仿真错误能够分别定位。最后在关闭外部智能体服务的条件下执行本地建模和仿真，验证离线工作是否满足团队需求。系统卡称构建失败会保留最后的成功场景，这对连续编辑是便利，也要求测试者始终核对当前画布与最新代码是否对应。[2] 若仅凭画布内容签收，恰好会错过这一类失败。
许可证也应按资产分层核对。CadCove 原创代码采用 MIT，依赖、队伍素材与 FIRST 内容各有条款。项目样例从 FIRST 下载赛场文件，二次打包并不自动取得公开再分发权。[1][2][4] 工业机器人团队若把这套结构移到自己的产品，先列出供应商 STEP、驱动库、现场数据和客户装配文件的权利清单，再讨论共享样例。
若把工具带进企业机器人研发，而非赛季队伍项目，先评估哪些工位能运行带 WebGPU 的编辑器，哪些构建节点只接受命令行；把 VSIX 版本、Python 虚拟环境和依赖锁文件封存进内部镜像，再由 IT 确认是否允许在受控网络下载场地与厂商二进制。小组协作可以规定：机械提交附几何校验，电控提交附绑定核查，仿真结果附参数表和版本哈希；合并请求由跨专业负责人复核。对不同厂商的驱动器或传感器，先从适配器支持清单确认接口，不能拿示例里的 Phoenix 路径推定普遍兼容。组织流程看似琐碎，却决定统一工作区究竟减少沟通成本，还是让过期的仿真结果传播得更快。[2][3]
这次 v0.2.0 的可信亮点，是把智能体改模后的反馈链放到了几何、代码与仿真的同一工作环境里，并公开了平台测试的范围和已知限制。它适合受控试点：用可复建的工作区缩短检查路径，让错误更早显形。是否能成为正式验证环境，要看自家装配的几何往返、器件适配、参数标定与真机对照成绩。项目发布说明已经把物理控制器验收和机器人标定留给队伍；工程团队应该照此排工时。[1][2]
资料来源
- CadCove-FRC，《CadCove-FRC 0.2.0》发布页，2026-10-18，https://github.com/gfleming1992/CadCove-FRC/releases/tag/v0.2.0 。支持版本、包平台、构成和测试范围。
- CadCove-FRC，《System card》，v0.2.0，https://github.com/gfleming1992/CadCove-FRC/blob/v0.2.0/docs/SYSTEM-CARD.md 。支持组件、仿真模式、限制、安全和许可。
- CadCove-FRC，《Install CadCove-FRC》，v0.2.0，https://github.com/gfleming1992/CadCove-FRC/blob/v0.2.0/docs/INSTALL.md 。支持版本前提、VSIX 安装、环境与样例命令。
- CadCove-FRC，《Team 3310 Amarillo on REBUILT》，v0.2.0，https://github.com/gfleming1992/CadCove-FRC/blob/v0.2.0/examples/team3310-rebuilt/README.md 。支持资产数、下载与构建路线、仿真绑定及平台验证边界。
工程验证流程为试用建议；配图为概念示意。