Skopia

Skopia

描述一栋建筑；Skopia 就能绘制它——用一份文档生成平面图、剖面图和立面图。 你只需提供设计概要或实测图纸。它会用 CAD 制图规范，以真实毫米尺寸绘制平面图，然后从同一份文档投影出这栋建筑的剖面图和立面图，确保三张图彼此一致。无论是一层还是整栋住宅，都可以生成。之后，你可以获得一张真实比例的图纸，或导出 DXF，再用 AutoCAD、Revit 或 Vectorworks 进行细化。

每张图纸都会以自身比例完整绘制：平面图、每张剖面图和每张立面图都会以 SVG 格式返回，供你查看和检查。图纸都正确后，再放到图纸页上；而不是一开始就从图纸页着手。

一栋现代住宅的一层平面图：通过 Agent 调用的操作完成建模和布置，每个固定装置都来自库存，并按其指定墙体的方向旋转，两条剖切线均依规则放置。这是引擎对文档的渲染，而非对图纸的绘制。

A–A 剖面图，沿上方平面图中标注的线剖切，并从同一份文档投影而来。这里没有任何内容被重复绘制：窗户就是平面图中的窗户，厨房就是平面图中的厨房。

https://skopia.datatreehaus.com/v1

每次调用都需要密钥。获取密钥免费、即时，无需审批。上方的一键安装不包含密钥：Cursor 会从你的环境中读取 SKOPIA_KEY，VS Code 则会在安装时向你索取。

快速开始

# 1. get a key
curl -X POST https://skopia.datatreehaus.com/v1/keys \
  -H 'content-type: application/json' \
  -d '{"label":"my agent","email":"[email protected]"}'

# 2. add the server
claude mcp add --transport http skopia \
  https://skopia.datatreehaus.com/v1 \
  --header "Authorization: Bearer YOUR_KEY"

Cursor、VS Code、Codex、.mcp.json 和原始 HTTP 的配置方法，请参阅 /setup。

ChatGPT、Claude Desktop 和 claude.ai 完全不需要密钥。 它们的连接器对话框要求 MCP 服务支持 OAuth，而本服务支持：粘贴 https://skopia.datatreehaus.com/v1，授权页面就会为该连接生成密钥，你不会看到这个密钥。系统不会创建账户；密钥就是全部，而且可以像其他密钥一样撤销。在支持显示图片的客户端中（ChatGPT，或任何使用 MCP Apps 扩展的客户端），平面图或图纸会以图片而非 SVG 文本的形式呈现。

协议： 基于 Streamable HTTP 的 MCP。该服务基于修订版 2026-07-28（server/discover，无需 initialize）构建，同时也支持 initialize 时代的修订版——2025-11-25、2025-06-18、2025-03-26、2024-11-05——因此普通客户端只需连接即可：使用 initialize 打开连接，在 MCP-Protocol-Version 中声明你的修订版，无需提供较新修订版要求的镜像标头或 _meta 字段。initialize 和 ping 是仅有的无需密钥的调用。

它能做到模型无法自行做到的事

让模型绘制平面图，它会输出 SVG，而且看起来完全没问题。墙线不会严丝合缝，立面图与平面图对不上，门也会偏离铰链转动。一切都不会报错。这正是我们要解决的问题。

**Agent 在这里不会把门画错，因为它根本不画门。**它只需指定一种门——带面板、部分玻璃、三排——同一个组件便会在平面图、立面图和剖面图中呈现一致。门扇的转动弧线只需推导一次、审核一次，不会在某个周二偏离铰链。

• **立面图不会与平面图对不上。**这不是靠仔细操作来保证的。立面图中的水平位置是对平面图特征的引用（opening:3.jamb.left），因此没有任何字段可以填入错误数值。
• **它会询问，而不是猜测。**给它一份测量记录，missing_dimensions 会告诉你哪些尺寸根本没有实际测量，而不是挑一个看似合理的数字来闭合轮廓。从软件编造出这个数字的那一刻起，它就与实测值无法区分。
• 组件由调用者指定，而非手动画出。{"type": "sash", "panes": [3, 2]} 表示一扇六格窗。用 SVG 路径数据画出同一扇窗，所需令牌数约为 50 倍，而且模型可能会在路径数据中悄悄出错，却没有任何检查机制。
• **拒绝会明确指出问题。**返回带类型、永久有效的错误代码，说明哪个对象有问题，因为 Agent 无法根据“布局无效”采取行动。
• 建议性读取绝不替人做决定。suggest_joins 会报告哪些桌子可以拼在一起，但不会做任何更改。相邻关系可以提供建议，最终由人决定。
• **这里不提供任何法规数值。**通道宽度、疏散距离和轮椅比例由你提供，也由你负责。消防检查员会查看的软件里如果包含错误数值，那是责任风险，不是缺陷。

我们编写了另一种方案，但它错了三次

我们必须通过测试来验证这项方案，而不是只做断言，因此竞品是我们代码库中的一个真实文件：一个手写脚本，用来绘制同一栋房子。编写时打开着引擎的源代码，参考了它的配色方案、墙体约定和房屋数据；脚本根据渲染结果修正过三次，每次都有人审核。它不是一次未经准备的测试，我们也不会把它说成那样。

但这反而让这些错误更加刺眼，而非减轻其严重性。明明具备所有这些优势，它还是错了三次。

1. 门的转动弧线从铰链而非门扇末端开始，因此它飘进房间，终点离另一侧门框很远。
2. 窗户只是光秃秃的白色缺口——没有窗框，也没有玻璃线条。那是墙上的洞，不是窗户。
3. 内墙上根本没有门。三个房间，没有一间能进去。

每个版本都能顺利渲染。在查看图纸时的尺寸下，三个错误中有两个根本看不出来；第三个看起来完全合理，经过两轮审核仍未被发现。无人值守运行的 Agent 会直接交付它。

**令牌数不是关键。**单看原始数量，Agent 一次性编写的脚本仍然比调用这个工具更省令牌——图纸写入文件后，工具结果还要返回上下文——我们自己的基准测试也明确说明了这一点，没有刻意掩盖。真正关键的是，廉价方案的错误不会显现，看起来合情合理，最终只能靠人发现，否则就永远不会被发现。

廉价方案每次都是错误的选择。

我们尚未测量冷启动 Agent 从开始到完成所需的令牌数。这需要针对一个需求说明进行真实测试，期间不能查看该引擎的源代码，并持续记录，直到图纸确实正确为止。我们还没有做过这项测试，以上内容也没有任何一句话假装我们做过。

然后我们亲自运行了一遍，结果也错了

一个 Agent、一份任务说明、这个引擎、2026 年 9 月。它耗费了约 269,000 个 tokens，但图纸仍然不对：剖面朝向错误、B–B 剖面为空、上下两扇窗的窗扇并非一体、1:50 的比例对图纸来说太小，以及八个尺寸标注小得无法辨认。

• 观察是工作的一部分。 这些 tokens 中约有 100,000 个（37%）用于渲染图纸并查看，大约每张图 8,000 个 tokens。自行编写 SVG 的 Agent 也要进行完全相同的循环，成本也完全相同，因此这项工作的最大成本对双方都一样，在比较中完全抵消。我们自己的基准测试从未计算过这一点。
• 读取引擎耗费了约 65,000 个 tokens，而且这还没开始做任何工作。使用 MCP 时，这只是一份工具列表——这是支持 MCP 服务的有力论据，而我们之前的看法恰恰相反。
• 拒绝确实发挥了作用。 架构无法容纳的一个标高点和两个未使用的墙体厚度都被报告出来，而不是被悄悄丢弃。

所以：命名组件能消除一类错误，但不能消除整个类别。Agent 仍可能请求错误的组件、将剖面指向错误的方向，或生成空白图纸。我们这三种情况都遇到过。

然后 ENGINE 在两天内错了四次，而测试套件仍然全绿

这是我们最有用的证据，因为这段代码除此之外别无用途，由 680 个测试覆盖，但以下问题仍然全部发布了，而且都是由某个人在能看清图纸的尺寸下查看后发现的：

• 一个剖面在墙顶处停止，导致房屋显示成顶部空无一物的方盒子，而旁边的立面却正确画出了屋顶。
• 随后，屋顶虽然画对了，却悬浮在山墙上方，因为山墙墙体在檐口处就停止了——只有屋顶下接墙体时，墙体才会在墙顶处停止。
• 一段弧形线段导致所有剖面和所有立面都无法生成，因为保护逻辑放在了两种投影共用的位置。
• 坐标传给调用方时是 -85.66329565734681，因为没有弧线时，所有与坐标轴对齐的角点投影结果都是整数毫米，而直到出现弧线才有人发现这个问题。

如果一份有测试套件、且只有一个用途的代码都会出错，那么一次性编写的 SVG 也不会正确。它能做的只是渲染。

具体计算，附上数字。 这些都不复杂；它们就是立面图本身的含义：

弧形墙上的 1,200 窗户	在立面图中绘制为 1,168；900 的门绘制为 890
屋顶的瓦条间距	绘制为 gauge × sin(pitch)——在 39° 屋顶上，100 的间距是 62.5
如果改为绘制实际间距	瓦条间距会扩大 1.6 倍，数量少三分之一
垂直于屋面的250 厚屋顶	在该坡度下，垂直方向的尺寸为 317
山墙端面	完全不会显示瓦条——那里看到的是檐口边缘

这些情况全都能正常渲染，而且没有一种是读者容易发现的。

我们尚未在未做准备的情况下运行另一方。这里没有 A/B 测试，我们不会暗示有。

房屋由楼层组成

首层是同一基准面上的第二份文档。楼梯从地面层的入口处延伸而上；穿过两层的剖面是一张图纸，由引擎拼接，并在交界处进行检查。

楼层并不是一种新的事物。每层都是一份普通文档，以同一基准面为参照，标注自身的高度；每层都会投影出剖面图或立面图，并拼接成一张图纸：两个楼层描述的同一面墙，会合并为从楼板到檐口的一条连续带状轮廓；立面会贯穿楼层线，不留接缝；交界处则绘制成一个连续轮廓，因为所有楼层的剖切部分都位于同一个区域。对齐依据是你在每张平面图上指定的两个固定点（vertex:0.outer ——外侧角点，墙体在楼上变薄时也不会移动），并且只会检查，不会拟合：旋转过的测绘图、未延伸到上层边缘的楼层，或未与其上方楼层构造相接的天花板，都会被拒绝，并给出误差毫米数。基准关系会以数值报告，也可以按需绘制在每张平面图和拼接图上，因此无需盲目信任拼接结果。draw_sheet 使用 storeys 而不是 document，并会在生成图纸的过程中完成所有这些工作。

会自行绘制剖面的家具

浴缸、底柜、马桶、楼梯：{ "op": "add_fixture", "type": "bath", "at": {x, y} } 会按常见的行业尺寸放置一个实例，并让朝向室内角落的那个角与房间角落对齐。平面图会按实际形状显示它；剖面会将其视为剖切面之外的物体，显示所朝向的那一面，并以自身轮廓线表示被剖切的部分——浴缸、橱柜上的台面、楼梯段的锯齿形轮廓——显示哪一面以及采用哪种轮廓，均根据其旋转方向推导得出。它在剖面中的范围与平面图关联，因此会准确落在平面图指定的位置。共有 22 种类型，涵盖厨房、浴室和卧室，而且没有任何一项带有规范要求：尺寸采用行业标准，净空由你自行指定。

家具知道朝向

库存中的每种类型都包含其放置规则：背面是否应靠墙，以及使用时各边需要预留多少净空。使用 against: {wall} 放置时，引擎会将其转向室内；验证会读取这些规则，并指出朝向墙壁的马桶、悬空的洗手盆、座位朝墙的沙发，以及阻挡使用的物体。这些是检查发现，而非拒绝原因。

屋顶窗

{ "op": "add_rooflight", "x", "y", "w", "d" } 会在屋顶上放置一扇窗。它所在的斜面以及距斜面底部的高度，会根据平面图中已有的屋顶信息推导得出：它会显示在朝向该斜面的立面上，并位于坡度所决定的高度，其他立面上则不会显示。对于平屋顶，剖面会在剖切面穿过天花板的位置开口，并画出窗台和玻璃。

剖面也会剖切坡屋顶，前提是 heights.construction.roof 提供了屋顶厚度——椽木线条会在屋脊处斜切对接；屋顶底面沿斜面的垂直方向偏移，而非竖直偏移；无论剖切角度如何，都能精确绘制。厚度必须明确提供，不会推导；若未提供，则不会绘制。只有屋顶压到墙体的位置，墙体才会在 wall_head 处终止，因此山墙端和单坡屋顶的高侧墙会一直延伸至屋顶底面，不会留下悬空的屋顶。

引擎中的统一样式

所有图纸都会以相同方式输出：剖切部分用实心黑色填充，内外均为白底；家具和配件用细线勾勒，不填充；采用三种线宽；屋顶或窗台在立面中可见时使用一种浅色调，玻璃使用一种色调。这是领先建筑事务所呈现平面图的方式，而且这一样式内置于绘图函数中，无需通过任何参数传入——同一房屋的平面图、剖面图和立面图不会呈现三种不同的风格。

剖面标记，按规则生成

剖切线的端部带有一个来自小型标记系列的符号，默认是气泡标记：一个指向视线方向的实心三角形，上方有一个圆圈，参照编号位于三角形所指的一侧。将其设为一个点和一个方向（使用 add_section 的 through 和 along），引擎便会在两端各越过建筑外表面 1.5 米，均匀延伸剖切线。若剖切线以两个点指定，引擎会按此规则进行测量；若某一端未达到或超出要求，则会同时报告两端的距离，而不是等到在图纸上才发现。

工作顺序

1. 平面图。 edit_layout ——按行走顺序输入角点，使用 close_room，然后添加洞口、隔断、固定装置和屋顶。你只需指定门，不必绘制门。
2. 检查。 每批操作后调用 validate_layout，并根据检查结果采取行动。朝向瓷砖的马桶，或无处落座的沙发，都会被指出。
3. 查看。 render_layout。
4. 剖面和平面立面图。 project_section 和 project_elevation。每个工具都会自行绘制，生成一张完整、按比例绘制的 SVG，所以要逐一查看。使用 scale: 20 查看节点。这一步能发现问题。
5. 然后再出图或导入 CAD。 使用 draw_sheet、export_dxf，或两者都用。

第 5 步特意放在最后。A3 纸上比例为 1:50 的图框中，剖面只有 200mm 宽；这么大的图上，错误的窗台或缺失的门窗侧框都看不出来。图纸是绘图正确后才生成的，不是用来检查绘图是否正确的。

导入 CAD

在此生成的图纸是供他人完善的底图，不是最终发布版——这正是 DXF 的用途。

export_dxf 接受与 draw_sheet 相同的内容，并生成一个 DXF：模型空间、单位为毫米、y 轴向上，平面图使用文档自身坐标，因此在 AutoCAD 中测量的墙体就是文档中存储的墙体。墙体由两侧面和每个洞口处的门窗侧框构成；门带有开启弧线；固定装置和构件与图纸中的相同，都是基础图元；剖面切到的部分则是一个带实心填充的轮廓区域。图层按用途命名，如 WALL、DOOR-SWING、CUT-POCHE、EVIDENCE，并采用引擎的三种线宽，因此从 CAD 打印出来的图纸与绘图输出一致。图层名称固定不变，因此事务所自有的模板可以映射到这些图层。剖面和平面立面图都放在同一文件中，并以同一基准线排布。图纸、标题栏和比例尺仍留在图纸上：DXF 是模型空间。

在 AutoCAD、Revit 或 Vectorworks 中打开文件，继续完善图纸。墙体会以两侧面和门窗侧框的形式呈现，而非填充带，因此可以在另一端继续编辑。

何时不该使用

如果你只想画一次草图，而且没人会据此施工，那就自己生成 SVG。它免费、无需密钥，而且完全够用。

当多张图纸必须彼此一致、有人要测量图纸，或没人会在 Agent 工作时从旁监督，就该使用此工具。

工具

edit_layout	通过应用操作来构建或更改布局
list_operations	57 种操作词汇
validate_layout	提供类型化错误，并指出出错的对象
render_layout	确定性 SVG
draw_sheet	在同一张图纸上按比例绘制平面图及其剖面
export_dxf	将相同图纸导出为一份用于 CAD 的 DXF，比例为 1:1，并按角色分层
project_elevation	从平面图投影出立面图
project_section	对平面图进行剖切，包括内部墙体
suggest_sections	建议剖切位置，并说明每个位置能展示什么
join_drawings	绘制跨越多个楼层的单张剖面图或立面图，并检查和清晰绘制连接处
list_components	门窗库存
list_fixtures	厨房、浴室和家具库存，可绘制平面图和剖面图
suggest_joins	建议哪些对象可以推到一起
suggest_rotation	建议对象的朝向
check_rules	根据你提供的规则进行检查
overhead_report	说明剖面图需要考虑的内容
roof_report	以问题形式指出仍缺少哪些屋顶信息
missing_dimensions	指出测量中遗漏了哪些尺寸

每轮都会带上 18 个工具作为固定上下文，因此也提供了更精简的接口： /v1/core、/v1/elevation、/v1/advisory，它们还可以组合使用 （/v1/core+elevation）。密钥也可以关联一个配置文件。

每个工具都是纯函数，并会通过协议明确说明（readOnlyHint、 idempotentHint）：不会存储任何内容，因此可自动批准只读工具的客户端可以批准所有这些工具。

提示词

提供四种工作流，作为 MCP 提示词提供服务，因此列出这些提示词的客户端会显示操作顺序，而不是一组词汇。在 Claude Code 中，它们会以斜杠命令的形式出现。

build_a_room	从房间描述生成经过验证并渲染的平面图
survey_to_drawings	将实测图转换为平面图、剖面图和立面图，并询问未测量的数据
check_a_layout	先验证，再根据你提供的间距规则进行检查
seat_a_room	摆放并编号桌子；仅将连接处报告为建议，不报告容量

每个提示词都会列出它使用的工具，并且只会在所有这些工具均已挂载的地方列出，因此提示词不会引导模型调用该端点未提供的工具。

状态说明

免费，且只是需求探测，而非产品。它的存在是为了了解是否有人需要它。最终会定价，并会提前通知。不会承诺永远免费，也不适用于无法承受服务变化的生产环境。

引擎的源代码未公开。此端点是接口，而非实现，因此本代码库包含客户端、示例和文档，不包含引擎代码。

示例

参见 examples/。它们通过 HTTP 调用托管端点，只需安装 curl 或 node。