Pascal Editor：用 React 组件描述 3D 建筑，把场景状态交给 Zustand

它解决什么问题，给谁用

Pascal Editor 解决的是在浏览器里创建和分享 3D 建筑项目的问题。它不是一个通用的 3D 建模软件，而是一套可嵌入、可扩展的编辑器框架。目标用户是那些想在 React 应用里加入建筑编辑能力的开发者，比如做室内设计工具、施工规划平台或者建筑可视化展示的团队。它把 Three.js 的底层操作封装成节点和渲染器，让开发者不用直接写复杂的 Three.js 代码就能组织场景。从 README 看，它同时提供了一个 Next.js 应用和一个 CLI，后者可以让你在本地快速启动一个持久化的编辑器实例。如果你只是想要一个开箱即用的建筑编辑器，Pascal Editor 提供了完整应用；如果你想把它嵌进自己的产品，它拆成了多个 npm 包供你选择。

节点、渲染器与注册表：场景如何组织

Pascal Editor 的核心概念是节点。所有场景元素，包括 Site、Building、Level、Wall、Slab、Zone 等，都继承自 BaseNode，包含 id、type、parentId、visible 等字段。节点不是嵌套存储的，而是放在一个扁平字典里，用 parentId 和 children 数组表达层级关系。这种设计让查找和更新节点变得直接，不需要递归遍历树。渲染器是 React 组件，每种节点类型对应一个渲染器，比如 WallRenderer、SlabRenderer。渲染器创建 Three.js 对象，然后通过 useRegistry 钩子把对象注册到 sceneRegistry 中。sceneRegistry 维护了 id 到 Object3D 的映射，以及按类型分类的 id 集合，这样系统可以直接根据 id 获取 3D 对象，避免遍历场景图。这种节点与渲染器分离的模式，让数据层和表现层解耦，你可以在不改动渲染逻辑的情况下修改节点数据。

状态管理：Zustand 存储与撤销重做

场景状态由 @pascal-app/core 中的 Zustand store 管理。useScene 存储 nodes 字典、rootNodeIds 和 dirtyNodes，提供 createNode、updateNode、deleteNode 等操作。它使用 Persist 中间件把场景保存到 IndexedDB，但会排除 transient 节点，这些节点可能用于临时预览。撤销重做通过 Zundo 实现，保留 50 步历史。另外还有 useViewer 存储视图状态，比如当前选中的 building、level、zone 的 id，以及层级显示模式（stacked、exploded、solo）。useEditor 则管理编辑工具的激活状态和面板可见性。状态访问有统一模式：在 React 组件里用 hook 订阅，在回调或系统里用 getState 直接读取。这种设计让状态管理集中且可预测，但你需要理解每个 store 的职责边界，避免把场景数据和 UI 状态混在一起。

本地运行：CLI 与 npm 包两种方式

运行 Pascal Editor 有两种途径。第一种是用 CLI 命令 npx @pascal-app/cli editor，要求 Node.js 22.13 或更新版本。这个命令会创建持久化的本地安装，启动编辑器和一个经过认证的 MCP 服务，自动选择无冲突的 loopback 端口，项目数据存放在 ~/.pascal/data/pascal.db。文档说可以让代理运行 pascal mcp connect 来连接 MCP。第二种方式是把各个包集成到自己的应用里，需要安装 @pascal-app/core、@pascal-app/viewer、@pascal-app/editor、@pascal-app/nodes，然后在挂载 Viewer 之前加载内置插件。代码示例是 import { loadPlugin } from '@pascal-app/core' 和 import { builtinPlugin } from '@pascal-app/nodes'，然后 await loadPlugin(builtinPlugin)。这两种方式面向不同场景：CLI 适合快速体验，包集成适合定制开发。

MCP 与 AI 代理：编辑器之外的连接

Pascal Editor 的 CLI 会启动一个 MCP 服务，这是它区别于多数 3D 编辑器的地方。MCP 包暴露场景工具、资源、提示词和本地存储给兼容 MCP 的 AI 主机。这意味着你可以让 AI 代理通过 MCP 协议直接操作场景，比如创建节点或修改属性。从架构看，MCP 服务与编辑器共享本地数据存储，所以代理的修改会同步到场景中。这是一个很有意思的设计，但它的实用性取决于你使用的 AI 主机是否支持 MCP。如果你没有 AI 代理的需求，这个功能可能只是额外开销。另外，MCP 服务需要认证，CLI 在后台启动它，你还需要配置代理去连接，这增加了一些使用复杂度。

限制与失败模式：WebGPU 依赖和功能边界

Pascal Editor 基于 WebGPU，这是一个明显的限制。WebGPU 虽然在 Chrome 和 Edge 中支持较好，但在 Safari 和部分旧浏览器中不可用。如果你的用户群体使用这些浏览器，编辑器可能无法运行。文档没有提到 WebGL 回退方案，所以这可能是硬性要求。另一个限制是节点类型的覆盖范围。内置节点包括 Wall、Slab、Ceiling、Roof、Zone、Scan、Guide，但高级 BIM 功能，比如复杂的构件族、参数化幕墙或结构分析，可能不在内置范围内。你需要检查 @pascal-app/nodes 的源码确认具体支持哪些节点。还有一点，编辑器的状态持久化依赖 IndexedDB，如果用户清理浏览器数据，项目可能会丢失，除非你实现了额外的导出功能。最后，MCP 服务在后台运行，如果端口冲突或认证失败，编辑器可能无法正常启动，文档提到 CLI 会选择无冲突端口，但具体行为仍需在实际环境中验证。

替代方案：对比 Three.js 编辑器与 Ifc.js

与 Pascal Editor 思路不同的替代方案是直接使用 Three.js 或 react-three-fiber 自己搭建编辑器。这种方式没有预设的节点类型和渲染器，你需要自己设计场景数据结构、渲染逻辑和编辑工具。它的优势是完全自由，不受 Pascal Editor 的节点层级限制，但代价是需要大量开发工作。另一个更接近建筑领域的替代是 Ifc.js，它专注于 IFC 格式的解析和渲染，适合处理 BIM 数据。Pascal Editor 的节点模型是自定义的，虽然它提供了 IFC 导入器（v0.9.0 版本加入了 IFC Importer），但并不是以 IFC 为核心。如果你需要严格的 IFC 兼容性和成熟的 BIM 工作流，Ifc.js 可能更合适。Pascal Editor 则更适合那些想在 React 生态里快速构建轻量级建筑工具的场景，它牺牲了部分 BIM 深度，换来了开发效率。

维护与升级成本，许可证注意事项

项目采用 MIT 许可证，这意味着你可以自由使用、修改和分发，包括商业用途，只要保留版权声明。从发布历史看，项目处于活跃开发阶段，v1.0.0-beta.1 在 2026 年 7 月发布，之前有 v0.9.1 和 v0.9.0。版本号尚未到 1.0 稳定版，这意味着 API 可能变动。升级成本取决于你使用的是 CLI 还是集成包。CLI 方式下，你可以通过更新 @pascal-app/cli 来获得新版本，文档提到有更新机制，但具体命令未在 README 中列出。集成包方式下，你需要跟踪每个包的版本变化，因为节点定义和渲染器可能不兼容。另外，MCP 服务的认证和端口管理是运行时依赖，升级时可能需要重新配置。总体而言，这个项目适合愿意紧跟版本迭代的开发者，不适合需要长期稳定 API 的生产项目。

编辑结论

Pascal Editor 适合已经熟悉 React 和 TypeScript、想在浏览器里构建或定制建筑编辑工具的开发者。它把场景建模成节点字典加渲染器，状态管理清晰，CLI 能一键启动本地编辑器和 MCP 服务，方便接入 AI 代理。但如果你需要成熟的 BIM 能力、稳定的 IFC 导入导出，或者必须运行在 WebGL 环境，它目前不是合适的选择。采用前先确认你的目标浏览器支持 WebGPU，并检查 @pascal-app/nodes 内置插件是否覆盖你需要的节点类型，比如 Scan 和 Guide 是否满足点云与二维参考的需求。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes