让 Codex 通过 MCP 工具调用直接控制 Rhino 与 Grasshopper，而不是让模型「想象」建模结果。核心命题：从一次性自动建模，转向受控、可迭代、可接管的人机协同工作流。
通过工具调用直接控制 Rhino 与 GH，形成「需求 → 分解 → 建图 → 预览 → 迭代 → 导出」的闭环，而非让模型凭空想象几何。
相比纯 NURBS 单次建模，GH 天然适合规则、约束、批量变体，以及城市 / 景观 / 立面 / 空间单元的生成。
可做脚本化几何、参数化定义、批量变体、简单分析；尚不能稳定完成完整设计判断、规范校核、施工级 BIM、复杂拓扑修复与高可靠曲面连续性控制。
2026 年已有可用的 Rhino MCP / Grasshopper MCP 与官方平台文档，但距「一句话生成高质量建筑方案模型」仍有明显差距。
文本需求 → Codex 分解 → 生成 / 修改 GH 图 → Rhino 预览 → 反馈迭代 → 导出 3DM / 图纸 / 分析数据。
AI 读写 Rhino 文档、创建几何、构建 GH 定义：创建对象、布尔、loft、extrude、sweep、offset、pipe、图层管理、视口截图、执行 RhinoScript Python / RhinoCommon C#。
Codex 按自然语言生成脚本：rhinoscriptsyntax 快速建几何，RhinoCommon 构造 NURBS 曲线、Brep、Mesh，再根据错误日志或视口反馈迭代修正。
Compute 是 McNeel 官方 web server，用 Rhino 几何引擎处理请求；Hops 把外部函数或 GH 文件作为远程 / 本地函数调用。
rhino3dm.py / .js / .NET 跨平台读写 3DM（CPython 3.7–3.11），适合文件层操作与轻量数据交换。
RhinoMCP 的 GH 工具：搜索组件、添加、连线、设参、运行 solution、读取警告、批量 build / mutate graph。适合参数化体块生成器、点吸引、塔楼、立面、遮阳、铺装——输出可被建筑师继续编辑的 GH 定义。
把复杂逻辑压缩进一个脚本组件，slider / panel 输入参数，输出 Curve / Brep / Mesh / DataTree。比大量连线更稳、更符合 Codex 写代码的长项；代价是可视化语义弱、组件过大易成黑盒。
2026 年出现的 GH 专用 AI 插件：内置聊天、上下文感知，Ask 解释调试、Build 生成修改定义与脚本，兼容 Rhino 7/8。更像「Grasshopper 内置副驾驶」，不一定依赖 Codex。
生态最活跃（blender-mcp）。适合 mesh、渲染、动画与资产管线；不适合严肃 NURBS / B-Rep 建筑精度工作。
已有 revit-mcp 等项目。偏 BIM 构件、族、参数与审查；落地价值高但语义复杂，适合查询与批量改参，不适合自由形体。
开源参数化 B-Rep，偏机械 / 产品 CAD。适合研究「文本到可执行参数化 CAD」的底层范式；建筑生态不如 Rhino/GH。
有社区 MCP 尝试。适合快速体块草模；精确参数化与 NURBS 能力有限，AI 研究深度暂不如 Rhino/GH。
# ~/.codex/config.toml
[mcp_servers.rhino]
command = "rhino-mcp-router"
args = ["--default-version", "8"]
# 注册 MCP server
codex mcp add rhino \
--env RHINO_MCP_HOST=127.0.0.1 \
-- uvx rhinomcp
| 维度 | Rhino 8 官方建议 | AI × Rhino 研究推荐 |
|---|---|---|
| CPU | Intel/AMD 64 位（不支持 ARM） | 现代 8 核以上，跑 GH 大量变体更舒服 |
| RAM | 8GB+ | 32GB 起步；复杂 GH / 多软件并行建议 64GB |
| GPU | OpenGL 4.5，4GB+ 显存 | 视口独显；本地视觉模型 / LLM 建议 NVIDIA 12–24GB+ VRAM |
| 磁盘 | 5GB（Mac 10GB） | SSD，项目缓存与依赖较多 |
| 显示 | — | 强烈建议双屏：一屏 Rhino/GH，一屏 Codex/文档 |
| 本地 LLM | — | 7B–14B：8–16GB VRAM；30B+：24GB+ 更现实；复杂任务仍不如云端 frontier 模型 |
建筑任务多为规则驱动：楼层、开间、立面网格、遮阳、退界、指标。GH 把一次生成变成可调参数系统，建筑师可用 slider 接管；方案研究需要的大量变体，也只有 GH 适合批量生成。
快速体块草模、明确几何的批量生成、图层清理与测量、局部对象处理——直接建模更快。GH 定义过大过乱时，AI 维护同样会变困难。
| 维度 | Rhino / NURBS 直接建模 | Grasshopper 参数化 |
|---|---|---|
| 输出 | 直接几何对象 | 可复用参数化定义 + 几何预览 |
| 交互 | 命令 / 脚本 / 对象编辑 | 组件图 / 脚本组件 / slider |
| 可编辑性 | 后期多靠手动修改对象 | 后期通过参数和图逻辑修改 |
| 可复用性 | 中等，脚本可复用 | 高，GH 文件即设计系统 |
| 适合阶段 | 快速概念、局部建模、批处理 | 方案研究、规则生成、变体探索 |
| AI 难点 | 几何 API、曲面 / 布尔稳定性 | 组件搜索、连线正确性、数据树 |
| 失败模式 | 几何失败、对象错位、布尔失败 | 连线错、数据结构错、求解报错 |
| 推荐策略 | RhinoMCP 工具 + Python 脚本 | MCP 建图 + GH Python 混合 |
管「生成逻辑」——规则、约束、参数关系。
管「最终几何」——图层、人工编辑、出图准备。
管「脚本、组件图、参数接口、错误修复、批量任务」。
管「目标、审美、空间逻辑、约束与验收」。
目标：证明 Codex 能稳定驱动 Rhino/GH。验收：能创建几何、能读取文档或截图、出错能迭代修正、GH 定义可人工继续调参。
不让 Codex 每次直调底层 API，而是封装建筑语义工具——显著降低失败率，建立建筑师可控的 AI 建模规范。
重点不是「一次性生成最终模型」，而是生成可继续设计的参数化系统。
真正价值来自「生成 + 评价」闭环，并与 Ladybug/Honeybee、Wallacei、OpenStudio、GIS 数据结合。
RhinoMCP 类工具允许 AI 执行 RhinoScript/C#，只在本机 loopback 使用，不暴露公网。
AI 可能删除、覆盖、移动对象；强制保存副本、启用 undo、分层隔离。
复杂 NURBS 与布尔最易失败，必须小步验证。
AI 生成的模型不等于符合规范、结构、消防、施工与造价要求。
大文件不能无脑塞给模型；用摘要、选择集、图层过滤、局部编辑。
使用云模型时，项目模型、客户资料、图纸数据需注意保密策略。
GH 管生成逻辑，Rhino 管最终几何，Codex 管自动化，建筑师管目标与验收。受控、可迭代、可接管——这才是 AI 进入建筑建模的正确姿势。