OpenBrep v0.8.0 发布：25天154次提交，从命令行到专业 AI 自校正 GDL 开发工作台
5月25日凌晨两点，第一个提交被推送时，没人预料到这条路需要走整整二十五天。6月19日凌晨，v0.8.0 正式诞生。
01 从终端到工作台
OpenBrep 最初的模样是一个命令行工具。你输入一句自然语言，它帮你生成 GDL 脚本，编译成 Archicad 可用的库构件。架构师 Ren 深夜敲下 obr run "做一个参数化书架"，几秒后文件落盘。能用，但远远不够。
哪里不够？终端里看不到三维预览；修改参数必须重新运行命令；编译报错时，错误信息和你的代码散落在不同屏幕。对于 GDL 写手而言，这套流程就像用记事本写代码，每次想看效果都得保存、切窗、刷新。
5月25日，第一个 React 工作台提交出现在分支上。那晚连出九个提交，从概念验证骨架，到加载 HSF 项目、编译，再到 AI 解释。速度极快，因为方向明晰：把终端工具升级为专业 IDE。
二十五天，154个提交，全部由同一人完成。
02 Streamlit 到 React：一次断臂求生
v0.7 时代的 OpenBrep 运行在 Streamlit 上。Streamlit 是个优秀工具，快速搭建原型，几行 Python 就能生成界面。可一旦想要 Monaco 代码编辑器、Three.js 实时 3D 预览、可拖拽的工作区网格以及深色专业工具视觉风格，Streamlit 的服务端渲染模型便开始处处掣肘。
React 工作台分支的思路很直接：前端采用 React 19 + Vite + Zustand + Three.js + Monaco，后端以 FastAPI 做本地 API，全部领域逻辑保持复用，一行代码都不重写。这不只是换肤，而是将 UI 层从“表单堆叠”升维为“代码工作台”。
5月30日到6月2日是最为密集的四天，每天 18 到 27 个提交。暗色工作台视觉基线、Monaco GDL 语法高亮、3D 视口控制、参数面板、编译诊断、版本管理、AI 助手面板，功能一个接一个接入。到6月1日审查时，核心链路已经全线跑通：打开 HSF、编辑脚本、调参、预览、保存、编译、诊断、AI 修改。
然而，合并到 main 的进程被按下了暂停键。
禁令很明确：禁止将 react-workbench 分支并入 main，除非 ① 通过就绪性检查与手动冒烟验证；② 用户明确说“合并到 main”。历史教训：上一次合并后立刻被回滚。
那次合并的确失败了。main 分支上留下了一道疮疤：一个合并提交紧跟着一个回滚提交。这道疮疤在后来正式合并时差点酿成灾难——直接合并会产生三十二个文件冲突，因为那次回滚让 main “删掉”了所有前端文件。
03 验证报告：让 AI 诚实交卷
6月14日撰写了一份审计文档，核心结论是：OpenBrep 已经拥有自校正代理的骨架，但缺少 Verification 这个一等缝合层。用人话说就是——AI 生成代码后，系统会检查编译是否通过，但检查结果散落各处，用户看不到一份统一的“验证报告”。AI 声称“已完成”，但你不清楚它验证过什么。
6月19日，这个问题被彻底解决。新建的 openbrep/verification.py 把散乱的静态检查、Linter、编译验证、规划检查项聚合成一份统一报告。AI 生成之后，你看到的不仅是代码，还有：置信度（高/中/低）、检查结果（通过几项、失败几项、未知几项）、编译状态、已修复项、残余风险。
有一个设计决策值得铭记：检查项里凡是没有自动化覆盖的，一律标记为 UNKNOWN，绝不假装通过。这种诚实比虚报全部通过更可依赖。一个坦诚的代理比一个看起来通绿的代理更值得托付。
04 合并夜：revert the revert
6月19日晚上，合并正式执行。策略是“反转那次回滚”——先撤销 main 上那一次失败的回滚提交，让前端文件恢复存在，然后再合并 react-workbench。冲突类型从 modify/delete 变成正常的 modify/modify，Git 自动完成合并。
实际结果零冲突。865 个测试全部通过。合并后修改了 CLI 入口：obr 默认启动 React 工作台，并自动打开浏览器。Streamlit 代码完整保留在 ui/ 目录，8847 行，一行未删。streamlit run ui/app.py 依然可以运行。那些用无数夜晚熬出来的代码，全都保住了。
合并前做了备份：一个标签指向合并前的 react-workbench，一份 3MB 的打包文件放在桌面。万一出问题，一行命令即可回退。那晚的许多决策都极为谨慎，因为上次回滚的教训还铭刻在心。
“那都是熬夜干出来的啊。”
05 v0.8：新阶段
v0.7 的 OpenBrep 是“GDL 生成工具 + 可追溯的资产生命周期”。v0.8 的 OpenBrep 则进化为“可验证的自校正 GDL 开发工作台”。两次跃迁：UI 从聊天工具蜕变为专业 IDE；能力从“生成过代码”上升为“验证了什么、通过了什么、修复了什么、还剩下什么风险”。
GitHub 上 GDL + AI + 代码工作台 + 编译验证闭环这一交叉领域，目前没有直接竞品。最接近的 CAD-Genesis（SolidWorks/Fusion 360 的 AI 参数化生成插件）也缺乏编译验证。OpenBrep 的差异化在于将自校正代理产品化：生成、检查、编译、自动修复、重新验证、证据报告、版本快照。
界面选择了英文设计，这是有意识的选择。GDL 本身就是英文的，Archicad 的开发者文档是英文的，Monaco 编辑器的快捷键也是英文的。英文界面降低的是国际化门槛，而非使用门槛。对于 GDL 开发者来说，面对一个英文代码工作台，远比看到一个中文聊天框更为自然。
v0.8.0 现已在 GitHub 开放下载。macOS 与 Windows 安装包由 GitHub Actions 自动构建并发布。如果你使用 Archicad，如果你编写 GDL，如果你想尝试 AI 辅助的 GDL 开发工作台，不妨亲自一试。
操作逻辑并不复杂：打开 HSF 目录，编辑脚本，调节参数，查看预览，点击编译，让 AI 帮你生成或修改。验证报告会清晰告知你结果。
二十五天，154次提交，从终端走到工作台。这不是终点，而是 OpenBrep 作为正式产品的新起点。下一个版本要做的事已写入文档：CREATE 路径补全编译验证、Tauri 桌面外壳、真机联调 Archicad。路还很远，但方向已分外清晰。