AI-CAD：把施工图深化交给 AI Agent，规则引擎 + 大模型 + 人在回路怎么配

Sun, 04 Oct 2026 06:50:00 +0800

先说一个可能让部分人略感意外的判断：在施工图深化这件事上，“AI 直接画图"大概率是个错误命题。

原因不复杂。施工图深化的绝大部分工作量，既不是创意、也不是判断，而是规则化、重复性的劳动——标注、材料表、规范逐条检查。这些活儿本来就有明确的规范和明确的判据，把它交给一个擅长自由发挥的大模型，反而是用错了工具。

AI-CAD 这个项目有意思的地方，就在于它一开始就把这件事想清楚了：不是让 AI 画图，而是让 AI 做"深化"这件苦力活儿，人守着关键节点做决策。

它到底想解决什么问题
三支柱：准确、灵活、可控
整体架构：一座五层的塔
规则引擎：为什么不用 LLM 判规范
技术栈与关键设计决策
Agent 链路与人在回路
可扩展性：加一个专业要做多少事
不只是检查：碰撞、冲突与出图深化
交付形态：双击一个 exe 就能跑
占位清单：哪些是真的没做完
工程质量：409 个测试和一条红线
给谁用、以及现实一点的话

一、它到底想解决什么问题

AI-CAD 的自我定位写得很直白：这不是"AI 画图"工具，而是 AI 辅助施工图深化 Agent——基于人类方案，由 AI 完成规则化、重复性的深化工作。

维度	描述
仓库	github.com/flowerjunjie/AI-CAD
主语言	Python（核心引擎）+ TypeScript（React 面板）
产品形态	桌面端应用（FastAPI 桥 + React 面板，PyInstaller 打包成双击 exe）
目标用户	建筑设计院施工图设计师
核心价值	把设计师 80% 的重复性工作时间自动化
人机协作	人在回路——关键节点暂停等待确认，AI 不直接出图
第一版范围	建筑专业 · 住宅套型施工图
当前进度	Phase 0-3 全部收口 + M3 出图深化 + M4 碰撞检测 + M5 改动冲突

它的核心原则只有九个字：规则引擎保准确 + LLM 保灵活 + 人在回路保可控。

顶层的产品哲学则是一句话：让 AI 做 AI 擅长的事（规则化、重复性工作），让人做人擅长的事（判断、决策、创新）。

需要先说明的是：这是一个个人/小团队性质的开源项目（作者 flowerjunjie，仓库 2026-09-26 创建，截至 2026-10-04 约 1 star），不是商用产品。它的价值不在"可以直接拿来用”，而在于它展示了一套把 AI 塞进严谨工程流程里的完整范式——尤其是"哪些交给 LLM、哪些绝不能交给 LLM"这条边界怎么划。

二、三支柱：准确、灵活、可控

理解 AI-CAD 的关键，是理解它为什么需要三个看似矛盾的东西同时存在。

flowchart TD
 subgraph P1["规则引擎 · 保准确"]
 R1["规范条文写成 DSL 代码"]
 R2["命中 / 放行 / 参数覆盖，结果确定"]
 end
 subgraph P2["LLM · 保灵活"]
 L1["理解自然语言意图"]
 L2["把'三室一厅100㎡'变成结构化方案"]
 end
 subgraph P3["人在回路 · 保可控"]
 H1["每个关键节点暂停"]
 H2["设计师确认后才继续"]
 end
 R1 --> OUT["成果：DWG + 违规清单 + 户型图"]
 L2 --> OUT
 H2 --> OUT

 style R1 fill:#10b981,stroke:#047857,color:#fff
 style R2 fill:#10b981,stroke:#047857,color:#fff
 style L1 fill:#3b82f6,stroke:#1e40af,color:#fff
 style L2 fill:#3b82f6,stroke:#1e40af,color:#fff
 style H1 fill:#f59e0b,stroke:#b45309,color:#fff
 style H2 fill:#f59e0b,stroke:#b45309,color:#fff
 style OUT fill:#8b5cf6,stroke:#6d28d9,color:#fff

规则引擎保准确 —— 规范条文（门宽 ≥ 0.9m、窗台 ≤ 0.9m 等）写成 DSL 代码，判断结果确定、可复现、可追溯，不依赖模型的"心情"；
LLM 保灵活 —— 人话进来（“帮我出个三室一厅 100 平”），LLM 负责意图理解和方案结构化，这一层本来就是它的强项；
人在回路保可控 —— 每个关键节点暂停等设计师确认，AI 不直接出图，出问题有人兜底。

这三者不是并列的营销词，而是各管一段：LLM 管入口的模糊输入，规则引擎管硬性判据，人管最后的决策。弄混了任何一段，系统就不可信。

三、整体架构：一座五层的塔

从架构图看，系统分五层，自上而下职责分明：

flowchart TD
 subgraph UI["界面层 · React 面板 + FastAPI 桥（PyInstaller 打包）"]
 U1["CAD 编辑器"]
 U2["图元预览"]
 U3["规则面板"]
 U4["成果导出"]
 end
 subgraph ORCH["Agent 编排引擎"]
 O1["任务分解 → 执行 → 验证"]
 end
 subgraph CORE["核心能力模块池"]
 C1["CAD 引擎
ezdxf + COM"]
 C2["规则引擎
规范校验"]
 C3["对话引擎
LLM"]
 end
 subgraph KB["知识层"]
 K1["ChromaDB 本地向量库"]
 K2["SQLite 图元库"]
 K3["规范文档"]
 end

 UI --> ORCH
 ORCH --> CORE
 CORE --> KB

 style O1 fill:#8b5cf6,stroke:#6d28d9,color:#fff
 style C1 fill:#3b82f6,stroke:#1e40af,color:#fff
 style C2 fill:#10b981,stroke:#047857,color:#fff
 style C3 fill:#f59e0b,stroke:#b45309,color:#fff
 style K1 fill:#64748b,stroke:#334155,color:#fff
 style K2 fill:#64748b,stroke:#334155,color:#fff
 style K3 fill:#64748b,stroke:#334155,color:#fff

值得单独拎出来说的是知识层全部本地化：ChromaDB 向量库跑在本机、SQLite 存图元、规范文档存本地文件系统。这对应设计院的硬性安全要求——图纸和规范数据不出境、不上云。LLM 选型也因此偏向国内模型（MiniMax / Kimi / GLM），中文规范理解好、调用合规。

四、规则引擎：为什么不用 LLM 判规范

这是整个项目我认为最值得抄的一个设计决策。

很多"AI + 设计"的项目，第一反应是"把规范喂给大模型，让它判断合规"。AI-CAD 明确反其道而行——规范判断坚决不用 LLM，而是写成 DSL，用受限 eval 执行。

它给出的理由是硬道理：规范条文是确定性判据，而 LLM 是概率模型。用概率模型去判一个本该确定的事情，等于主动引入不确定性。规则引擎把条文写成代码后，命中就是命中，放行就是放行，参数可以覆盖，每一个判断都能追溯到具体规则的哪一条。

规则来源走了双轨制：

来源	内容	特点
硬编码规则类	30 条（住宅/防火/无障碍）	锚点，稳定不动
DSL 规则	14 条（各专业 `-`）	可扩展，改 JSON 即生效

规则 DSL 长这样（示意）：

@rule("住宅户内门宽度")
def door_width(room: Room) -> bool:
 """户内门宽度不应小于 0.9m"""
 return room.door_width >= 0.9

@rule("窗台高度")
def window_sill(room: Room) -> bool:
 """窗台高度不应大于 0.9m"""
 return room.window_sill_height <= 0.9

而 DSL 的安全边界也是明确标注的——predicate 走白名单 eval，__import__ / getattr / open 在 load 时全部 fail-fast 拒绝。因为规则文件来自外部 JSON，这是一条真实的信任边界。

五、技术栈与关键设计决策

决策	选择	理由
CAD 双引擎	ezdxf（读）+ COM（写）	ezdxf 纯 Python 跨平台读取；COM 写 AutoCAD 保证输出格式标准
Agent 框架	LangGraph	支持可中断/可观察的执行流，适合人在回路
LLM 选型	国内优先（Agnes / MiniMax / Kimi / GLM）	中文规范理解强，数据不出境
知识库	ChromaDB（本地）	轻量，符合设计院安全要求
规则引擎	自定义 DSL	条文写成代码，不依赖 LLM 做逻辑判断
界面	FastAPI 桥 + React 面板	同源 `/api/*` 直连，零端口配置

其中 CAD 双引擎和 LLM 工厂两块最实用：

双引擎的好处是兼容性——ezdxf 不需要装 AutoCAD 就能读，COM 在 Windows 上写出的 DWG 是原生格式，Linux/macOS 上则降级为 ezdxf 写入 + 离线验证；
LLM 工厂用统一的 LLMFactory 接口封装四个适配器（默认 Agnes，Anthropic 兼容接口），可以通过环境变量 AI_CAD_LLM_PROVIDER 运行时切换，不被任何一家模型绑架。

六、Agent 链路与人在回路

Agent 的执行链路是一条清晰的生产线：

flowchart LR
 A["意图理解
(LLM)"] --> B["方案结构化
(RAG)"]
 B --> C["CAD 执行
(ezdxf)"]
 C --> D["规则校验
(5 专业)"]
 D --> E["成果输出
(DWG + 报告)"]

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style B fill:#3b82f6,stroke:#1e40af,color:#fff
 style C fill:#f59e0b,stroke:#b45309,color:#fff
 style D fill:#10b981,stroke:#047857,color:#fff
 style E fill:#8b5cf6,stroke:#6d28d9,color:#fff

关键设计在于每个节点都是可中断、可编辑、可追溯的。而且它做了"双路径"——run.py --llm 走 LLM 主导，run.py --no-llm 纯本地快验。LLM 到底有没有参与，肉眼可验（会打印"LLM 实例就绪"），不糊弄。

人在回路这块，项目做的是 session 级真人在回路，而不是演示级的假动作：

sequenceDiagram
 participant U as 设计师
 participant B as FastAPI 桥
 participant G as LangGraph 图
 U->>B: POST /agent/run
 B->>G: start_agent_run_suspended(起图挂起)
 G-->>B: 真实 pending task 列表
 B-->>U: 透出每个待确认 task
(类型/描述/出图结果 + 图面预览)
 U->>B: POST /agent/confirm(逐 task 确认)
 B->>G: resume_agent_run(同一 thread 真续跑)
 G-->>U: 继续执行 / 拒绝则保持挂起

实现上依赖 LangGraph 的 interrupt + checkpointer：外部持有 checkpointer 和 thread，分"起图挂起 / 续跑"两步走。用同一个 thread 真续跑，而不是重新开一轮——这点做过 Agent 的人知道有多关键。

七、可扩展性：加一个专业要做多少事

这是这个项目最硬的卖点，也是它反复自证的地方：加一个新专业 = 改配置 + 少量元素模型，主链路零改动。

它用一个引擎底座，让五个专业照同一套范式接入：

专业	元素模型	DSL 规则	上游 DWG 解析	出图图层
建筑（本尊）	30 条硬编码规则类	—	墙 / 门窗几何	CENTERLINE 双线墙 + OPENING_TAG
给排水	`PlumbingPipe`	3 条 `plumbing-*`	线段	PIPE
电气	`ElectricalOutlet` / `Switch`	3 条 `electrical-*`	INSERT 块	ELEC_OUTLET / ELEC_SWITCH
暖通	`HvacDuct` / `Unit` / `Grille`	3 条 `hvac-*`	INSERT 块	HVAC_*
结构	`StructuralBeam` / `Column`	2 条 `structural-*`	线段 / 块	BEAM / COLUMN

支撑它的四个机制：

开放封闭范式 —— 新专业一律走 default.json 的 DSL 规则（dsl_only: true），不新建硬编码规则类；主链路的 _ELEMENT_CHECKS 分发表只加一项，循环体 0 改动；
一份上游底座 + N 个专业映射 —— 结构/电气/暖通的块类元素共用同一份 get_element_blocks INSERT 读取逻辑，各专业只加"图层/块名 → kind"的映射 dict，消除"每个专业各写一套"的孤儿模块；
受限 eval 信任边界 —— 外部 JSON 是信任边界，实测打穿无注入面；
护栏不崩校验链 —— predicate 缺属性降级 warning、文案缺字段渲染 [缺失:x] 占位、baseline 路径穿越白名单。

一句话说清楚它想证明什么：各专业专家不需要写核心代码，他们做的是"确认数值 + 定 DWG 约定"——工程底座已经消化了"接入一个新专业"的全部技术复杂度。

八、不只是检查：碰撞、冲突与出图深化

除了基本的规范校验，项目往后推了三个里程碑，都是可完全自主推进的：

M3 · 出图深化 —— 22 个图层配 ACI 色号 + 线宽，按制图惯例上色（墙白粗 / 水红 / 风蓝 / 结构绿 / 电黄 / 标注白 / 碰撞品红），出图 PNG 预览按图层上色，肉眼验收不用开 CAD。

M4 · 多专业碰撞检测 —— 核心是一个纯函数几何库 clash_detection.py，覆盖 8 类跨专业碰撞（管线/风管/插座/风口 × 梁/柱）：

flowchart TD
 A["上游各专业 DWG"] --> B["提取几何
(线段 / 点位)"]
 B --> C["seg_intersect
严格相交(T-touch 不算穿)"]
 B --> D["point_to_seg_dist
点线距离"]
 C --> E{"是否越界?"}
 D --> E
 E -->|"是"| F["生成 clash-kind 违规条目"]
 E -->|"否"| G["无碰撞，0 实体"]
 F --> H["出图：品红警示圈(CLASH 层)"]

 style C fill:#3b82f6,stroke:#1e40af,color:#fff
 style D fill:#3b82f6,stroke:#1e40af,color:#fff
 style F fill:#ef4444,stroke:#b91c1c,color:#fff
 style H fill:#ef4444,stroke:#b91c1c,color:#fff
 style G fill:#10b981,stroke:#047857,color:#fff

M5 · 改动冲突检测 —— 两稿 raw JSON 按元素类 + id 对齐比对，覆盖三类冲突：

冲突类型	含义
`value`	同 id 的字段值不同（含嵌套 list 深比较、缺字段）
`added`	稿 B 新增的元素
`removed`	稿 B 删除的元素

这三个（尤其 M4/M5）都遵循同一套纯函数范式接入、主链路零或最小改动——可扩展的底座又被证明了一次。

九、交付形态：双击一个 exe 就能跑

一个很容易被忽略但很见工程功力的点：它真的打包成了能双击运行的东西。

flowchart TD
 subgraph EXE["build/dist/ai_cad_gui/"]
 E1["ai_cad_gui.exe
双击即开"]
 E2["_internal/
引擎 + 桥 + 前端 dist + 样本数据"]
 end
 E1 --> S1["自动起 FastAPI 桥
(端口自动探测)"]
 S1 --> S2["浏览器自动打开面板"]
 S2 --> S3["无需 node / 无需工程源码"]

 style E1 fill:#10b981,stroke:#047857,color:#fff
 style E2 fill:#64748b,stroke:#334155,color:#fff
 style S3 fill:#3b82f6,stroke:#1e40af,color:#fff

三条入口覆盖不同人群：

入口	适用	说明
双击 exe	无 node / 无源码的机器	双击即开，端口自动探测，浏览器弹面板
`start_gui.py`	开发态（有 node/vite）	FastAPI 桥 + Vite 面板（端口 3000）
`start.bat`	全链路验证 / 出图	自动装依赖 + 跑 `run.py` + 弹户型图

打包这里踩的坑也很实在：前端 dist 由 FastAPI StaticFiles 托管在 /、/api/* 同源直连、零端口配置；default.json 是数据文件非模块，必须 --add-data 单独进包，否则 11 条 DSL 规则进不了引擎（dsl=0）。产物约 43 MB exe + 236 MB _internal。

十、占位清单：哪些是真的没做完

我个人认为这是全项目最值得尊敬的一节。它专门列了一张"未实现能力"的清单，并明确写着：已实现的如实展示，未实现的明确留占位符，绝不假装有。

里程碑	剩余占位	需要谁
M1 规范数值终确认	电气插座高度/接地、暖通风口高度/室外机安装、结构部分数值	各专业专家背书
M2 DWG 图层/块名约定	各院"点位画法/块名"映射目前全 TBD	各院制图规范
M5 权限模型	角色·权限矩阵值 + 在线协同协议（机制骨架已通）	业务定协同模型
出图深化	各专业"元素模型 → 精细图元"的画法仍偏简	各专业制图规范

设计上有个很妙的处理：数值与机制分离——阈值全部是占位，专家确认后填 default.json 的 param_defaults 即可，零代码改动。UI 上还做了"填值即点亮"的闭环：某专业任一规则 confirmed=true，前端对应卡片就点亮，四个专业全亮则整卡变实。

这套设计等于把"落地门槛"从"专家要会写代码"降到了"专家只要确认数值"。

十一、工程质量：409 个测试和一条红线

数字上看，这个项目在工程质量上是相当克制的：

409 passed / 5 skipped / 0 failed（47 个测试文件，unit + integration）；
5 个 skip 是诚实的外部依赖用例——4 条 langgraph 框架（设 AI_CAD_RUN_FRAMEWORK=1 启用）+ 1 条 LLM（需 API key），不是漏测；
覆盖率门槛 .coveragerc 设 fail_under=90，纯可测代码实测 95%，三个需真实框架/LLM/向量库的模块明确豁免（是"需外部依赖"而非"漏测热点"）；
冒烟脚本 smoke_test.py 秒级验证 5 大核心不变量（小改动 0.4s 出结果）；
一条硬红线：硬编码规则类 0 改动（用 git diff 校验），配合"全量绿 + 单跑绿"双护栏防假绿。

它甚至专门说明了"本轮外部依赖边界"，逐条标注哪些是外部依赖、哪些是自主子集，故意不虚标。这种自我约束在开源项目里并不多见。

十二、给谁用、以及现实一点的话

这套东西适合谁看：

做 AI + 垂直领域落地的工程师 —— 尤其是"哪些该交给 LLM、哪些绝对不能"这条边界怎么划，这个项目提供了一个完整且自洽的答案；
BIM / CAD 数字化从业者 —— 规则 DSL 化、ezdxf 读写、图层着色、碰撞检测几何库，都是可以直接借鉴的工程做法；
设计院的数字化决策者 —— 可以看清"AI 辅助深化"当前真实的成熟度边界在哪里。

需要现实看待的：

这是个个人开源项目，热度很低（约 1 star），社区基本没有，不要指望它开箱即用；
真正落地强依赖各专业专家背书——M1 数值、M2 图层约定、M5 权限模型三块全是外部依赖，机制通了但值待补；
第一版范围只覆盖建筑专业 · 住宅套型，跨专业、跨项目的通用性还有待验证；
在线协同（真·多机 socket / 消息总线 / CRDT）仍处于骨架占位阶段。

但它的真正价值，恰恰不在"能不能直接用"，而在于它把一件事讲透了：

让 AI 做 AI 擅长的事（规则化、重复性工作），让人做人擅长的事（判断、决策、创新）。

在一个人人都在喊"AI 画图"的领域里，愿意老老实实说"我们不做画图，我们做深化；规范判断坚决不用 LLM；没做完的部分我们列清单"——这份清醒本身就是这个项目最大的参考价值。

本文基于 AI-CAD 官方仓库（github.com/flowerjunjie/AI-CAD，默认分支 master）的 README、DELIVERY.md、capability-map.md、architecture.md 及源码目录结构整理，数据截至 2026-10-01 最后一次提交。项目处于活跃开发阶段，功能与状态可能变化，请以官方仓库为准。

项目信息

项	值
仓库	https://github.com/flowerjunjie/AI-CAD
主语言	Python（+ TypeScript 前端）
核心依赖	ezdxf · LangGraph · FastAPI · React · ChromaDB · PyInstaller
测试状态	409 passed / 5 skipped / 0 failed（47 个测试文件）
默认分支	`master`
更新截至	2026-10-01

AI Agent on 我的博客