SolidCraft 把参数化 3D CAD 变成一张命令菜单，下一个被 AI 重写的软件是什么？-开发者社区

SolidCraft 把参数化 3D CAD 变成一张命令菜单，下一个被 AI 重写的软件是什么？

【免费下载链接】solidcraftSolidCraft: an open-source parametric 3D CAD application built in pure Rust. Desktop, web, and automation through MCP.项目地址: https://gitcode.com/gh_mirrors/so/solidcraft

2026 年 10 月前后，中文技术社区几乎同时刷到两个名字：wordcraft，用 Rust 重写文档排版内核；紧随其后的是SolidCraft，一个纯 Rust 编写的开源参数化 3D CAD，桌面、浏览器、headless CLI 和 MCP 服务器共享同一套代码，AI 代理可以直接驱动建模。两个项目隔着完全不同的行业，走的却是同一套做法。那么，下一个会被"AI 化重写"的品类，会是谁？

先给 SolidCraft 定个坐标

读 Cargo.toml：workspace 版本 0.26.1、Rust edition 2024、MSRV 1.95、许可证 MIT OR Apache-2.0。再读 docs/architecture.md，架构是六层：L0geom（向量、平面、网格与度量）；L1sketch/kernel/render（约束求解器、B-rep 内核边界、视图数学）；L2doc（参数、表达式、特性时间线与增量求值）；L3io（设计文件与 STEP/STL/OBJ/3MF 导入导出）；L4engine（会话与命令注册表）；L5gpu/ui-egui/mcp。

翻译成大白话：几何是灶台，命令引擎是菜单，界面和 MCP 只是不同的点菜方式。

浏览器端不是移植版。apps/solidcraft-web/src/main.rs 顶部注释写得很直白："Runs the samesolidcraft_ui_egui::SolveAppas the desktop app through eframe's web runner (wgpu: WebGPU where available, WebGL2 otherwise)"——同一份SolveApp在 wasm 里跑，WebGPU 可用就 WebGPU，否则 WebGL2。一次编写，四处运行，且没有任何一端为 AI 单独开口子。

命令注册表是怎么实现的

crates/engine/src/lib.rs 开头的文档注释定了整个项目的规矩：

Every user-visible action is a command with a stable, dotted, lower-case id (solid.extrude,sketch.create,solid.fillet,timeline.rollback). Commands take JSON parameters and never open dialogs; the UI, the command palette, scripts, the CLI and the control channel all run the same commands throughSession::execute.

翻译：每个用户可见的操作都有稳定的点分 ID，只收 JSON 参数、绝不弹对话框；工具栏、命令面板、脚本、CLI、控制通道走的是同一个入口Session::execute。docs/features.md 这张表由cargo xtask features从注册表自动生成，当前登记 517 条命令（含 3 条标注 planned）——意味着这五个加 MCP 共六个入口共用同一张"菜单"。MCP 服务器对外暴露约 22 个工具（list_commands、execute、batch、measure、set_parameter、screenshot、export、undo/redo等），但骨架就两件事：查菜单、按菜单做菜，其余是审计手段。

docs/mcp.md 给的第一句话是全文的题眼："An agent models exactly like a person does: every tool runs engine commands, the same ones the toolbar, palette, scripts and control channel use, and never opens a dialog." 代理和人用的是同一份操作清单，AI 不需要单独的后门。启动方式分三种：

# Headless：进程内设计会话，无窗口 solidcraft-cli mcp # Headless，从设计文件或命令脚本起步 solidcraft-cli mcp --in part.sc # 桥接到运行中的应用，看着 AI 建模 solidcraft --control 7878 & solidcraft-cli mcp --connect 127.0.0.1:7878

控制通道还有一条更"拟人"的路径：ui.click、ui.drag、ui.key、ui.text注入的是真实鼠标键盘事件，ui.agent_cursor甚至能让一个可见的指针先"滑"到工具栏按钮再点击（docs/control-protocol.md）。也就是说 AI 既能直接下单，也能像人一样点菜，两条路回到同一张菜单。

批次为什么要么全成要么全无

可靠性设计里最值得看的是batch的原子性。docs/mcp.md 的原文：

The design, the active sketch and the undo history are restored exactly as they were, however long the history is.

batch在执行第一步之前先打一个edit.checkpoint引擎检查点；中途任何一步失败，设计、活动草图、撤销历史全部精确恢复到批次开始之前，不管历史多长。翻译成工程语言：AI 要么整单上齐，要么整单撤回。execute失败则"design unchanged"。对偶尔会写错参数的 LLM 来说，全有或全无是它敢下重手的前提。

内核正确性如何验证：oracle、fuzz 与崩溃恢复

光有回滚还不够，结果本身要能独立对账。仓库里三层验证：

oracle 参考测试：tests/oracle/下 90 个案例，每个由项目自己的recipe.json重放命令序列，与expected.json对比体积、表面积、质心、包围盒、面数，部分案例还对比参考 STL 的 Hausdorff 距离。期望值只有两个来源：69 个手推解析解、21 个用 FreeCAD 公共 Python API 独立建出的值。docs/oracle.md 特别声明 "No expected value comes from a commercial CAD product"，当前 90/90 全过——开源替代不是抄商业软件的输出，而是可以被数学对账的独立实现。
随机鲁棒性：solidcraft-cli fuzz --count 1000 --jobs 8用 1000 个种子、8 进程跑随机布尔/圆角/壳体组合，逐步校验"实体闭合、体积恒正、切割不增体积"，并验证布尔恒等式。docs/robustness.md 的结果表：修复后干净设计占 53.8%，布尔失败从 36.3% 降到 27.1%，布尔恒等式成立率 80.8%（其余为超时或暂未支持的步骤，被单独归类而不是算作崩溃）。
崩溃恢复：ROADMAP 的 M13"Never lose work"标记为已完成——原子保存（临时文件 + flush + rename，任何时刻崩溃只留下旧文件或新文件）、每 5 分钟自动保存、下次启动询问恢复，外加一个 kill-mid-save 测试：保存 0.5 MB 设计时杀进程，重复 25 次。apps/solidcraft/src/main.rs 里还挂着 crash journal，崩溃报告可回放现场命令序列，solidcraft-cli crashes replay <id>能直接重放。

把证据收敛成一个判断框架

把上面的证据抽掉 CAD 细节，剩下三条判据：

操作可命名：每个操作有稳定 ID、JSON 参数、无对话框，任何入口走同一执行路径；
状态可回滚：批次级检查点，失败时整体还原，而不是一堆半成品的撤销栈；
结果可审计：有独立来源的期望值可对账（解析解或另一套内核），或有不变量（体积守恒）可抽查。

三条全中才谈"重写"，缺一条就降级为"只做代理层"。拿仓库自带的演示闭环把框架端到端跑一遍：examples/demo/enclosure_mcp.py 是一个最小 MCP 客户端，按enclosure_steps.json一步步建电子外壳——先定义width/depth/height/wall四个参数，草图尺寸用sketch.dimension绑到参数名上，再拉伸、圆角、开 USB 口、加螺丝柱。docs/mcp.md记录的真实会话长这样：

→ tools/call "batch": 8 条命令（草图 → 矩形 → 完成 → 拉伸 20 → 圆角 r3 → 新草图 → 圆 r5 → 拉伸 20 operation:cut） ← {"ok": true, "completed": 8, "results": [...]} → tools/call "measure" ← "total": {"volume_mm3": 22390.6, ...} → tools/call "screenshot" {"view":"iso"} ← 返回 PNG 图像块

判据一：8 条命令每个都是稳定 ID 加 JSON 参数；判据二：batch有检查点，任一步失败整单还原；判据三：measure报 22390.6 mm³，代理拿这个数和自己的解析预期对账，screenshot提供视觉复核。最后再改一次width，整条时间线重建——这就是"操作可命名、状态可回滚、结果可验证"的最小完整闭环。

用同一个框架评估下一批候选赛道

幻灯片 / PPT：🍽️ 高概率。结构强（大纲→页→版式→内容）、无重型几何内核，页面树天然离散可命名，排版是确定性内核，AI 改完能渲染出预览图自审——三条判据全中，且工程量远小于 CAD。wordcraft 已验证文字内核路线，幻灯片是同族谱里最容易再复制一遍的项目。
图像编辑 / PS：侧翼攻破。选区、调色、滤镜这类感知操作恰是 AI 强项，但完整位图引擎的 Rust 重写量巨大，且"结果可审计"这条最难成立——调色没有解析解可对账。更可能的形态：AI 原生工具做语义编辑，旧应用以 MCP/脚本接口被驱动，而不是被重写。
视频剪辑：先代理化。ffmpeg 生态在编解码与渲染管线上不可替代，重写 ROI 极低；但导入、切割、转场、导出这类命令离散、可回滚、可验证时长，非常符合框架——缺的只是一个开放的"剪辑 MCP"。
EDA：先桥接。KiCad 已是开源主流且脚本接口成熟，布线、仿真、DRC 内核是数十年积累，全面重写不现实。最可能的形态是复制 SolidCraft 的桥接模式：代理直连现有命令接口做 AI 布线与版图校验，内核重写要等更久。
CAD：已发生。内核确定性高、可验证性强，AI 做错一步，体积守恒和 oracle 立刻抓出来——这正是它先落地的原因，SolidCraft 本身就是证据。

回到那个问题：什么样的品类会被 AI 重写

开头问"下一个会被 AI 重写的品类是谁"。走完这个仓库，答案不是某个软件，而是一组条件：操作可命名（稳定命令面）、状态可回滚（批次级检查点）、结果可审计（独立期望值或守恒不变量）。三条全中的品类会迎来完整重写——目前 CAD 已落地，幻灯片/设计协作类条件最齐；只中两到三条的，会先走代理化，被现有内核的 MCP 接口驱动；一条都不中的，短期内只是营销词。命令菜单、灶台、验菜台与传菜窗口这四样配齐的厨房，下一个也许正在某个仓库里，以一周一个 PR 的速度搭起来。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考