本文看点
- 为什么"AI 生成效果图"解决不了装修问题
text-to-cad：让 Agent 学会做 CAD，甚至一路走到制造Pascal Editor：让 Agent 操作一个结构化的 3D 建筑空间- 两者组合 = 一个完整的"装修 Agent"工作流
过去，程序员和 AI 的关系，大多数时候都发生在屏幕里。
我们让 AI 写 Python、Java、TypeScript，帮我们改 Bug、生成 SQL、部署服务。
但最近我看到两个很有意思的开源项目，让我开始觉得：
AI Agent 正在尝试走出代码编辑器。
一个叫 text-to-cad，它试图让 Agent 学会做 CAD；另一个叫 Pascal Editor，则试图让 Agent 直接操作一个 3D 建筑空间。
把两个项目放在一起看，会出现一个非常有意思的场景：
程序员以后装修房子，可能真的可以像开发软件一样做。
房间是项目，家具是组件，尺寸是参数，布局是状态，修改是 Commit——AI Agent 则是那个真正执行设计的人。
这也是我认为这两个项目值得程序员收藏的原因。
一、当程序员要装修，第一反应是什么？
假设你准备装修一间书房。
房间尺寸：
长：4.2m
宽：3.6m
层高：2.8m
你的需求也很简单：
北墙放一张 1600 × 700mm 的书桌
桌子旁边放一个 800mm 宽的收纳柜
桌面需要：
- 一个显示器支架孔
- 两个走线孔
桌子下面要留出腿部空间
靠窗位置最好不要挡住开窗
普通人的第一反应可能是：打开淘宝，找家具，量尺寸，下载几个装修 App，然后开始拖家具。
而程序员可能会产生另一种想法：
"为什么不能把需求直接告诉 AI？"
例如：
创建一个 1600×700×750mm 的书桌。
桌面厚度 18mm。
桌面右后方增加一个直径 60mm 的走线孔。
桌面左后方增加一个显示器支架安装孔。
桌腿采用四腿结构。
桌下净空至少 650mm。
输出可以进一步编辑和制造的 CAD 文件。
如果 AI 最终只给你一张图片，其实意义并没有那么大。
因为图片只是"看起来像"，而装修和 DIY 真正需要的是：
尺寸
几何
参数
结构
碰撞关系
可编辑性
制造文件
这就是第一个项目真正有意思的地方。
二、AI 生成效果图，为什么还不够？
这其实是理解 text-to-cad 的关键。
现在让 AI 生成一张桌子，非常容易。你甚至可以直接说：
"设计一张极简风格的胡桃木电脑桌。"
AI 可以给你生成一张非常漂亮的图片。
但是你接下来问它：
"这张桌子的桌腿具体多长？"
"桌面厚度是多少？"
"这个孔距离桌边多少毫米？"
"我要把它交给 CNC 加工，可以吗？"
问题马上就出现了。
因为视觉生成和工程建模，本质上是两回事。
可以把它们简单理解成：
AI 绘图
文字
↓
视觉模型
↓
图片
而 CAD 更接近：
需求
↓
参数
↓
几何约束
↓
实体模型
↓
验证
↓
制造 / 加工
| 维度 | AI 绘图 | CAD / 工程建模 |
|---|---|---|
| 输入 | 一段文字描述 | 需求 + 参数 + 约束 |
| 输出 | 图片 | 带尺寸、可验证的实体模型 |
| 回答的问题 | "它看起来是什么样？" | "它到底是什么？" |
| 能否直接加工 | 不能 | 可以进入制造 / 加工流程 |
对于装修和家具 DIY，这个区别非常重要。
因为你最终不是要"看一张桌子"，你是真的可能要：
- 买木板
- 打孔
- 切割
- CNC
- 3D 打印
- 激光切割
- 装配
所以：
AI 生成一张漂亮的桌子，只完成了设计的"视觉阶段"；真正可落地的设计，需要进入 CAD。
而 text-to-cad 恰好是在解决后面的事情。
三、text-to-cad：让 Agent 学会做 CAD
先说结论：
text-to-cad 并不是简单的"文字转 3D 模型"。
它更准确的定位，是一个面向 Agent 的 CAD / CAE / CAM Skills 库。
项目当前包含 CAD、CAD Viewer、STEP、DXF、URDF、SRDF、SDF、DfAM Check、G-code、Bambu Labs、SendCutSend 等相关能力。
这件事情真正有意思的地方，并不是"AI 会画一个 3D 模型了"，而是：
Agent 开始拥有了一套"工程操作能力"。
它和普通 AI 生成 3D 模型有什么区别？
最重要的区别之一，是 STEP-first。
text-to-cad 的 CAD Skill 明确采用 STEP-first 工作流：它可以从自然语言、参考图片、2D 工程图等输入生成或修改参数化 CAD，并以 STEP 作为主要 CAD 产物，同时支持 STL、3MF、GLB 等次级输出。默认的建模源代码路线使用 build123d（Python）。
这里的关键词是：参数化。
例如我们做一个桌子，不是简单地生成 桌子.step，而更接近：
desk_width = 1600
desk_depth = 700
desk_height = 750
top_thickness = 18
leg_size = 50
cable_hole_diameter = 60
然后通过这些参数构造实体。
于是你突然拥有了一种程序员非常熟悉的能力：
1600mm
↓
1800mm
只需要修改参数，而不是"重新生成一张桌子"。
这才是程序员真正应该关注的地方
如果你是一名程序员，我反而不建议把 text-to-cad 理解成"一个可以用 AI 画 CAD 的工具"，这个理解太浅了。
更值得关注的是它的设计方式：
Agent
↓
Skill
↓
工程工作流
↓
源代码
↓
CAD
↓
验证
↓
制造
这和今天 AI 编程 Agent 的工作方式非常像。
例如一个 Coding Agent：
需求
↓
代码
↓
测试
↓
运行
↓
修复
而 CAD Agent 变成：
需求
↓
CAD Source
↓
STEP
↓
Geometry Inspection
↓
Validation
↓
Snapshot
↓
Export
也就是说：
AI 不再只是生成一个结果，而是开始执行一套工程流程。
举个例子：让 AI 帮你做一张桌子
我们继续刚才的例子，你告诉 Agent：
我要制作一张电脑桌。
尺寸：
1600 × 700 × 750mm
桌板：
18mm 厚
四条桌腿：
50 × 50mm
桌下净空：
至少 650mm
右后方增加：
60mm 走线孔
桌板背部：
增加理线槽
所有尺寸都需要参数化。
输出 STEP。
理想情况下，Agent 不应该直接"猜一个模型"，它应该首先形成设计意图：
Desk
├── Top
│ ├── Width = 1600
│ ├── Depth = 700
│ └── Thickness = 18
│
├── Legs
│ ├── FrontLeft
│ ├── FrontRight
│ ├── RearLeft
│ └── RearRight
│
├── CableHole
│ └── Diameter = 60
│
└── CableTray
然后生成参数化几何，最后进行：
尺寸检查
↓
几何检查
↓
结构检查
↓
可视化检查
↓
STEP
这时候 AI 做的事情就已经不是"帮我画一张桌子"，而是：
"帮我完成一次工程设计流程。"
这是两种完全不同的能力。
甚至可以继续往制造方向走
text-to-cad 的 Skills 已经不只停留在 CAD，例如可以进一步形成：
CAD
↓
STEP
↓
DXF
↓
DfAM Check
↓
G-code
↓
3D 打印
项目目前还提供与 SendCutSend、Bambu Labs 等制造流程相关的 Skills。
这意味着未来一个完整 Agent Workflow 可以变成：
"帮我设计一个桌面收纳盒"
↓
CAD Agent
↓
参数化 CAD
↓
几何验证
↓
DfAM 检查
↓
切片
↓
G-code
↓
3D 打印
这才是我认为这个项目值得程序员关注的核心：它正在把"AI 生成内容"变成"Agent 操作现实世界的工具链"。
四、Pascal Editor：让 Agent 操作建筑世界
一个家具解决不了装修问题
做到这里，我们其实遇到了第二个问题。
假设 AI 已经会设计桌子，那又怎么样？因为你的桌子不是孤立存在的，它要放进房间，而房间里还有：
墙
门
窗
地板
灯
柜子
沙发
床
插座
过道
于是问题从"怎么设计一个物体？"变成：
"怎么设计一个空间？"
这时候，第二个项目就出现了。
Pascal 是什么？
Pascal Editor 官方定位是一个开源、本地优先的 3D 建筑编辑器，可以在浏览器或 CLI 中运行，并通过 MCP 连接 AI Agent。
它的技术栈也非常"程序员"：
React
React Three Fiber
Three.js / WebGPU
Zustand
Zod
Zundo
Turborepo
MCP
仓库本身采用 Turborepo monorepo，拆分为 core、viewer、editor、nodes、cli、mcp、ui 等多个包。
但真正值得看的，并不是它用了什么前端框架，而是：
它把建筑空间变成了 Agent 可以操作的数据结构。
Pascal 最重要的东西，其实不是 3D
如果只看 UI，很容易把 Pascal 理解成"又一个 3D 房屋编辑器"。
但从程序员视角看，它最重要的部分其实是 Scene Graph。
Pascal 并不是简单地保存一堆 Mesh，而是把建筑拆成了具有语义的 Node，例如：
Site
└── Building
└── Level
├── Wall
│ ├── Door
│ └── Window
├── Slab
├── Ceiling
│ └── Light
├── Roof
├── Zone
├── Scan
└── Guide
这件事情对 Agent 非常重要。
因为 AI 很难可靠地理解 Mesh_1234、Mesh_3821、Mesh_8271，但它很容易理解 Wall、Door、Window、Desk、Cabinet、Zone。
这就是：
从"图形对象"变成"语义对象"。
这和程序员理解的 DOM 很像
如果你是前端开发者，会发现这个概念其实并不陌生。
浏览器不是简单地把网页理解成一堆像素，它有：
html
└── body
├── header
├── main
│ ├── section
│ └── button
└── footer
因此 JavaScript 可以直接 document.querySelector(...)，然后修改属性、结构、位置、内容、事件。
Pascal 的建筑 Scene Graph，本质上也在做类似的事情：
它让 Agent 不必操作"某个三角形的顶点"，而可以操作：
"北墙上的窗户。"
这就是 AI 操作 3D 世界非常重要的一层抽象。
于是 Agent 可以开始"装修"
假设你已经把房间建立起来：
房间
4.2m × 3.6m
现在你可以告诉 Agent：
在北墙增加一个 1.8m 宽的窗户。
在窗户右侧放置一个 1600mm 宽的书桌。
书桌距离墙至少 50mm。
桌子前方预留办公椅空间。
房间中央保持至少 900mm 的通行空间。
如果空间不足，自动调整桌子位置。
这时候 AI 面对的已经不是一张图片，而是一个真正的空间结构：
Site
↓
Building
↓
Level
↓
Wall
↓
Window
↓
Desk
↓
Chair
Pascal 的系统层还包含针对墙体、楼板、天花、屋顶和物品定位的系统，以及用于放置验证的空间网格能力。
这就开始有意思了。
MCP 才是 Pascal 真正的"灵魂"
为什么 Pascal 对 AI Agent 有意义？
核心答案其实不是 WebGPU，而是 MCP。
Pascal 提供专门的 MCP 包，用来向兼容 MCP 的 AI Host 暴露：
Scene Tools
Resources
Prompts
Local Storage
于是整个关系变成：
AI Agent
│
│ MCP
▼
┌──────────────────┐
│ Pascal Editor │
├──────────────────┤
│ Scene │
│ Wall │
│ Door │
│ Window │
│ Furniture │
│ Zone │
└──────────────────┘
│
▼
3D Space
这就不再是"AI 给你一张装修效果图"，而是：
AI 真正拥有了一个可以操作的空间。
五、把两个项目组合起来，会发生什么？
到这里，其实已经可以看到两个项目之间非常漂亮的互补关系，我会把它总结成一句话：
Pascal 负责"怎么摆"，text-to-cad 负责"怎么做"。
或者更简单：一个负责空间，一个负责物体。
| 维度 | Pascal Editor | text-to-cad |
|---|---|---|
| 解决 | 房子、房间、墙、门、窗、区域、家具位置、空间关系、碰撞、布局 | 零件、家具、结构、尺寸、孔、槽、装配、STEP、DXF、制造、3D 打印 |
| 回答的问题 | 这个东西应该放在哪里？ | 这个东西到底应该怎么做？ |
| 类比 | 空间 / 场景 | 几何 / CAD |
一个完整的"装修 Agent"工作流
我们重新回到最开始的需求，你告诉 Agent：
我有一个 4.2 × 3.6 米的书房。 北墙有一个 1.8 米宽的窗户。 我想要一张 1600 × 700mm 的电脑桌。 桌子旁边需要一个 800mm 宽的收纳柜。 桌子最好靠窗，但不能挡住窗户。 书桌需要两个走线孔。 桌下要能放办公椅。 房间中间需要保留至少 900mm 通道。
理想的 Agent Workflow 可以变成：
用户需求
│
▼
AI 装修 Agent
│
┌────────┴────────┐
│ │
▼ ▼
Pascal Editor text-to-cad
│ │
│ │
房间空间模型 家具 CAD 模型
│ │
墙 / 门 / 窗 桌子 / 柜子
│ │
└────────┬────────┘
▼
空间验证
│
┌────────┴────────┐
│ │
能不能放？ 怎么制造？
│ │
▼ ▼
布局调整 STEP / DXF
这时候，AI 才真正开始像一个 "装修 Agent"，而不是"装修聊天机器人"。
为什么特别适合程序员？
因为程序员天然接受一种思维方式：
把现实问题抽象成数据结构。
装修其实也可以这么做，例如：
{
"room": {
"width": 4200,
"depth": 3600,
"height": 2800
},
"window": {
"wall": "north",
"width": 1800
},
"desk": {
"width": 1600,
"depth": 700,
"height": 750
},
"cabinet": {
"width": 800
},
"walkway": {
"minimum": 900
}
}
然后：
Agent
↓
修改参数
↓
重新生成
↓
验证
↓
查看结果
是不是突然非常像软件开发？
甚至可以把装修理解成 Infrastructure as Code
程序员非常熟悉 Infrastructure as Code，比如 Terraform、Ansible、Kubernetes、Docker Compose。
你不需要手动点击几十个按钮，你写：
database:
cpu: 4
memory: 8GB
系统根据声明创建基础设施。
那么未来装修是不是也可以这样？例如：
room:
width: 4200
depth: 3600
desk:
width: 1600
depth: 700
cabinet:
width: 800
constraints:
walkway: 900
然后：
Agent
↓
Scene
↓
CAD
↓
Validation
这就是一种非常有意思的 Design as Code。
当然，Pascal 和 text-to-cad 并不意味着今天就已经拥有完整的"装修 Terraform"。这里更重要的是：
它们正在提供这种工作方式所需要的底层积木。
甚至可以进一步 Git 化
如果未来这套工作流成熟，我们完全可以想象这样的项目：
my-house/
│
├── README.md
│
├── floorplan/
│ ├── scene.json
│ └── layout.json
│
├── furniture/
│ ├── desk/
│ │ ├── desk.step.py
│ │ └── desk.step
│ │
│ └── cabinet/
│ ├── cabinet.step.py
│ └── cabinet.step
│
├── materials/
│ └── materials.yaml
│
└── constraints/
└── room.yaml
然后你突然发现，装修也可以 git diff，例如：
- desk.width = 1600
+ desk.width = 1800
再让 Agent：
重新计算房间布局。
检查：
1. 是否挡住窗户
2. 是否影响开门
3. 是否满足900mm通道
4. 是否影响办公椅空间
这就是程序员非常熟悉的修改配置 → 重新计算 → 验证 → 产生新版本。
六、真正值得收藏的不是"AI 装修"，而是这种范式
如果只是"AI 可以帮我装修房子"，其实并不新鲜。现在大量 AI 产品都可以生成装修效果图、家具效果图、风格方案、3D 场景。
真正让我觉得这两个项目值得程序员关注的是：
Agent 开始操作结构化的现实世界。
以前：
AI
↓
Text
↓
Image
现在开始出现：
AI
↓
Semantic Scene
↓
Geometry
↓
Constraints
↓
Validation
↓
Physical Artifact
这条链路的意义远远不只是装修。
装修只是一个非常容易理解的入口
想象一下：如果 AI 可以操作建筑 Scene Graph，那么它未来可以做的不只是装修。
比如：
家具设计
"帮我设计一个适合这个房间的电视柜。"
↓
CAD
↓
STEP
机械 DIY
"给我的自行车设计一个手机支架。"
↓
CAD
↓
3D 打印
工作室规划
"我需要 3 台打印机、一个工作台和材料柜。"
↓
空间布局
↓
碰撞检查
机器人
设计机械结构
↓
CAD
↓
URDF
↓
仿真
而 text-to-cad 本身就已经包含 URDF、SRDF、SDF 等机器人描述相关 Skills。
于是：
装修只是 Agent 操作物理世界的一个非常直观的 Demo。
但不要把它们吹成"万能 AI 设计师"
这里需要特别提醒：如果准备把这两个项目推荐给程序员，反而应该主动讲清楚它们目前不是什么。
text-to-cad 不是：
- AutoCAD 的完全替代品
- SolidWorks 的完全替代品
- 工程认证系统
- FEA 分析系统
- 专业建筑 BIM 软件
它更适合被理解为 Agent-native CAD workflow。
Pascal 也不是：
- Revit
- AutoCAD Architecture
- 完整 BIM 平台
- 专业建筑施工设计软件
它现在更值得关注的是一个可以被人和 AI Agent 共同操作的结构化 3D 建筑编辑环境，尤其是它的：
Scene Graph
+
Spatial Systems
+
Plugin Architecture
+
MCP
这套设计。
七、如果你是程序员，现在应该怎么玩？
其实不用一上来研究完整架构，我更推荐一个非常简单的路线。
第一步：先玩 text-to-cad
官方推荐通过 Skills CLI 安装：
npx skills add earthtojake/text-to-cad
然后给 Agent 一个非常简单的任务：
设计一个 1200 × 600 × 750mm 的桌子。
要求：
- 桌板18mm
- 四条桌腿
- 桌面两个走线孔
- 所有主要尺寸参数化
- 输出STEP
你不要一开始追求复杂，先观察：
Agent 如何理解需求？
↓
如何形成 CAD brief？
↓
如何写 build123d？
↓
如何生成 STEP？
↓
如何验证？
这比单纯看一个 3D 模型更有价值。
第二步：再玩 Pascal
Pascal 当前可以通过：
npx @pascal-app/cli editor
启动本地编辑器。
然后你可以进一步研究：
Scene
Node
System
Spatial Query
MCP
Plugin
如果你是 AI 编程开发者，建议尤其关注：
packages/core
packages/mcp
packages/nodes
因为这些东西才是 Pascal 和传统 3D 编辑器真正不同的地方。
第三步：把两个项目连起来思考
这时候不要再把它们看成两个独立 GitHub Repo，可以把它们看成：
AI Agent
│
┌────────┴────────┐
│ │
▼ ▼
Pascal Editor text-to-cad
│ │
▼ ▼
空间 / 场景 几何 / CAD
│ │
└────────┬────────┘
▼
Physical World
这时候你会发现一个非常重要的分层：
L1：Intent
"我想装修一个书房"
L2：Spatial Planning
"桌子应该放在哪里？"
L3：Object Design
"桌子应该怎么设计？"
L4：Geometry
"具体尺寸是多少？"
L5：Validation
"有没有碰撞？"
L6：Manufacturing
"怎么加工出来？"
L7：Physical World
"真正把它做出来"
而今天很多 AI 产品其实只解决 L1，甚至只是 L1 → 图片。
真正值得关注的 Agent-native 工具，则开始向 L1 → L2 → L3 → L4 → L5 → L6 推进。
八、最后：Design as Code，Agent as Designer
如果让我用最简单的一句话总结：
text-to-cad：让 Agent 学会做一个东西。
例如桌子、柜子、支架、零件、机械结构、机器人模型。
Pascal Editor：让 Agent 学会把东西放进一个空间。
例如房间、墙、门、窗、家具、灯、区域、建筑。
把它们组合起来：
Agent 不只是会画一张装修效果图，而是开始理解"空间里有什么东西，以及这些东西应该如何被制造出来"。
过去我们使用 AI："帮我写一个 React 页面"，AI 生成代码，然后 npm run build。
现在我们开始看到另一种模式："帮我设计一张适合这个房间的桌子"，Agent 理解空间 → 设计家具 → 生成 CAD → 检查尺寸 → 调整布局 → 输出制造文件。
最终：
代码
↓
数字世界
CAD / Scene
↓
物理世界
这可能是 AI Agent 下一阶段非常值得关注的方向。
所以，回到最开始的问题：如果你是程序员，这两个项目值得收藏吗？
我的答案是：值得。
但不是因为"以后程序员可以不用学装修了"，也不是因为"AI 已经可以完全替代 CAD 工程师和建筑设计师"，而是因为这两个项目分别展示了一个非常重要的方向：
- text-to-cad：
Agent → Engineering Artifact，让 Agent 从自然语言进入参数化 CAD、几何验证和制造工作流。 - Pascal Editor：
Agent → Structured 3D World，让 Agent 通过 MCP 操作一个具有语义 Node、空间系统和编辑能力的建筑场景。
两者组合起来，就是：
自然语言
↓
AI Agent
↓
┌───────────────┐
│ 空间理解 │
│ Pascal Editor │
└───────┬───────┘
│
↓
┌───────────────┐
│ 对象设计 │
│ text-to-cad │
└───────┬───────┘
│
↓
几何验证
↓
制造文件
↓
现实世界
以前，程序员写代码，是为了改变数字世界。现在 AI Agent 正在获得越来越多的能力：
写代码
↓
调用工具
↓
操作浏览器
↓
操作数据库
↓
操作 CAD
↓
操作 3D 场景
↓
操作制造流程
↓
影响物理世界
所以，当我们看到一个叫 text-to-cad 的项目时，不应该只把它理解成"AI 生成 CAD"；看到 Pascal Editor 时，也不应该只理解成"一个 3D 装修软件"。
把它们放在一起看，你会看到一个更有意思的未来：
AI Agent 正在从"会写东西"走向"会设计东西"；从操作代码，走向操作现实世界的数字模型。
而对于程序员来说，最值得收藏的可能并不是某一个具体工具，而是这种正在形成的新范式：
Design as Code，Agent as Designer。
一个未来的装修 Agent，也许不再只是告诉你"这面墙刷成奶油色会很好看"，而是可以真正回答：
"如果把桌子从 1600mm 改成 1800mm，窗户不会被挡住，通道仍然有 920mm；我已经重新生成了桌子的 CAD，并完成了空间验证。"
到了那一步，AI 才真正开始从**"给你建议"走向"帮你完成设计"**。
如果你也觉得这个方向有意思，欢迎点赞、收藏，评论区聊聊你更看好哪个项目，或者你已经用 Agent 做过什么"现实世界"的事情？
项目地址
- earthtojake/text-to-cad（Agent Skills 库：CAD / 制造 / 机器人描述文件）
- pascalorg/editor（Pascal Editor：开源 3D 建筑编辑器 + MCP）
附录：稀土掘金发布建议（发布前请删除本附录）
推荐标题（主标题）
《当程序员遇到装修：用 AI 画 CAD、搭房子，甚至自己做家具》
备选标题
《程序员装修指南：把房子当代码写——text-to-cad × Pascal Editor 实测》
《从"AI 生成效果图"到"AI 操作现实世界"：两个让程序员尖叫的开源项目》
《Design as Code：装修变成写代码之后，AI Agent 开始改变物理世界》
摘要建议
AI Agent 正在从"写代码"走向"设计现实世界"。这篇文章把 text-to-cad 与 Pascal Editor 组合起来，就是一个完整的"装修 Agent"工作流。
标签建议
AI Agent、开源、CAD、3D、MCP、前端、装修、Design as Code
封面 / 配图建议
- 封面：两个项目 GitHub 首页拼图 + "装修效果图 vs CAD 图纸"对比，或"程序员 + 装修"主题插画
- 正文配图：
text-to-cad的 STEP-first 工作流截图、Pascal Editor 的浏览器界面 / Scene Graph 截图、npx skills add与npx @pascal-app/cli editor运行效果截图 - 注意：掘金对图片有版权要求，截图建议使用项目官方 README 中的资源或自行运行截图 #（注：内容由AI生成）
