图纸导入很容易被包装成一个过度承诺的问题：给 AI 一张户型图，它自动识别成完整模型。

对开发者来说，这个叙事不够严谨。更可靠的架构问题是：如何把 DWG、DXF、PDF、图片、扫描件或照片变成可编辑 working truth，同时保留足够 evidence，让错误可以被局部修复？

SAH 的导入方向不是“完美识别”，而是“可修复导入”。

Import should be autonomous-first, not evidence-free

设计师不应该在导入时被迫确认每一面墙、每一个门洞和每个中间候选。那会让工作流停在低信号确认上。

所以导入应该尽快生成一个可编辑 first-pass working model。

但 autonomous-first 不等于 evidence-free。系统仍然需要保留 source manifest、格式信息、previews、evidence artifacts、extracted interpretation、scale assumptions、confidence、quality flags 和 generated model references。

这些 evidence 不是最终 truth，但它们是后续 repair 的上下文。

imports/ 不是 project truth 本身

imports/<import_id>/ 应该保存 source、preview、evidence 和 extracted interpretation。它回答的是“这个 working truth 从哪里来、有哪些假设、哪里不确定”。

真正进入 agent 工作流的，是被接受进 design_model.json 的 working truth：

  • import sessions；
  • walls；
  • openings；
  • spaces footprints；
  • source provenance；
  • quality flags。

换句话说，source evidence 负责可追溯，working truth 负责可编辑。两者不能混成一个东西。

First-pass model 不是 verified survey

导入第一版模型应该尽快可编辑，但不能被说成测绘级真相。

它更像是一个带 provenance 的 working model。它可以被验证、版本化、执行、视觉审阅和修复，但它仍然需要承认不确定性：

  • scale 可能来自推断；
  • opening 可能有低置信度；
  • raster source 可能有外部空白区域；
  • room labels 可能和实际边界不一致；
  • negative regions 不应该被误生成房间或墙体。

这类不确定性不应藏起来。它们应该进入 quality summary 或 source interpretation。

Source fidelity 和 SketchUp execution 是两道门

SketchUp 执行成功，不代表导入 truth 与 source 匹配。

这两件事必须分开：

  • bridge execution gate：当前 design_model.json 是否能生成并执行到 SketchUp；
  • source fidelity gate：生成的 working truth 是否仍然尊重 source evidence。

一个模型可能 clean replay 成功，但阳台区域来自外部空白、门洞 host wall 错误，或 room footprint 与 source label 面积冲突。这不是 bridge 问题，而是 source fidelity 问题。

因此导入 pipeline 需要 source-scoped constraints、negative regions、dimension chains、room candidates、opening constraints 和 boundary checks。

Repair 应该局部化

当用户指出“这面墙不对”或“这个导入宽度应该不同”时，系统不应该默认重跑整个导入。

更好的流程是：

  1. 找到受影响的 model entity 和 provenance。
  2. 回到相关 source evidence。
  3. 重新解释局部区域或实体类别。
  4. Patch design_model.json。
  5. 重新生成 bridge trace。
  6. Clean replay 或局部执行。
  7. 报告具体变化。

这就是 working truth 的意义。它允许 agent 把自然语言纠错转成局部结构化修改，而不是每次都从零开始。

Dynamic runtime memory 要留在项目内

某次导入可能会产生 source-specific 记忆，例如这个图纸里的符号含义、设计师纠正过的房间命名、某个尺寸推断方式。

这些信息对当前项目有价值，但不应该直接进入产品 runtime skills，也不应该默认进入中央知识库。

它们可以成为 project/session dynamic runtime skills，保存在当前设计项目的 agent skill 位置。只有当一个模式经过多次验证、能泛化，并且有测试覆盖时，才应该进入产品 baseline 或中央抽象知识。

为什么这适合开发者系列

导入不是一个“识别模型”的单点能力。它是 source management、evidence retention、truth generation、validation、repair、runtime memory 和 host execution 的组合。

如果开发者只追求“一次性看起来像”，产品会很快遇到不可修复的问题。真正有价值的是：即使第一版不完美，系统仍然知道它从哪里来、哪些地方不确定、应该如何局部修复。

这就是从 source evidence 到 working truth 的架构价值。

Source trace