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

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

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

目录

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

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

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

它的核心原则只有九个字：规则引擎保准确 + 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 是概率模型。用概率模型去判一个本该确定的事情，等于主动引入不确定性。规则引擎把条文写成代码后，命中就是命中，放行就是放行，参数可以覆盖，每一个判断都能追溯到具体规则的哪一条。

规则来源走了双轨制：

规则 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 双引擎和 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 的人知道有多关键。

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

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

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

支撑它的四个机制：

• 开放封闭范式 —— 新专业一律走 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 对齐比对，覆盖三类冲突：

这三个（尤其 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

三条入口覆盖不同人群：

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

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

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

设计上有个很妙的处理：数值与机制分离——阈值全部是占位，专家确认后填 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 最后一次提交。项目处于活跃开发阶段，功能与状态可能变化，请以官方仓库为准。

项目信息