为什么 AI 设计工具需要唯一真相源

很多 AI 设计工具最吸引人的瞬间，是你说一句话，它就给你一张图、一个模型、一个看起来已经完成的空间。

但真正进入设计工作流以后，问题很快会出现：

这张图能继续编辑吗？

这个模型里的墙、门、组件和尺寸，分别来自哪里？

设计师指出一个问题以后，AI 是修正了结构，还是只改了一次表面输出？

下一次再打开项目时，agent 怎么知道哪些是设计意图，哪些是临时试验，哪些来自原始图纸，哪些只是一次推测？

这就是为什么我认为：AI 设计工具不能只追求“看起来画出来了”。它需要一个可编辑、可校验、可修复、可回放的唯一真相源。

这里的“唯一真相源”不是说 AI 替设计师决定什么是好设计。它指的是一个结构化的工作事实层：让设计意图、来源证据、空间、尺寸、组件、规则、假设和执行结果有地方可放，有办法被检查，也能在出错时被修复。

只生成结果是不够的

如果 AI 只是生成一张效果图，结果很直观，但它很难成为长期工作基础。

图像能表达风格、氛围和方向，却很难稳定承载：

墙体厚度
门窗开口
空间边界
组件尺寸
清距规则
图纸来源
设计假设
修改历史

如果 AI 只是直接操作 SketchUp 场景，情况也类似。SketchUp scene 是重要的执行结果，但它本身并不天然告诉 agent：这个对象为什么在这里，哪个尺寸来自设计师指令，哪个尺寸来自导入图纸，哪个修改是临时探索。

聊天记录也不能承担这个角色。对话适合表达意图和讨论判断，但不适合成为设计项目的长期结构化状态。

所以，一个可靠的 AI 设计工具不能只有最终画面。它还需要知道：当前项目到底“是什么”。

真相源解决的是可继续工作

以 SketchUp Agent Harness 为例，它把 design_model.json 作为设计项目的结构化工作真相。

这个文件不是最终审美判断，也不是法律或施工图合规报告。它更像 agent 和设计师之间共享的项目状态层。

它应该记录这些内容：

空间如何组织
尺寸和单位是什么
哪些组件已经放入项目
组件的语义、锚点和清距是什么
当前采用了哪些设计规则
哪些结论来自导入图纸、图片或扫描件
哪些地方只是推测
哪些视觉反馈需要变成结构化修改

有了这个层，agent 才能做几件关键的事：

比较版本差异
检查结构是否合理
根据来源证据修复模型
把结构重新执行到 SketchUp
把视觉反馈转成明确的模型修改

这就是 source of truth 的价值：它不是让输出更炫，而是让项目可以继续被理解、被检查、被修复。

SketchUp 场景不是唯一真相源

这句话容易被误解。

SketchUp scene 当然重要。设计师最终要看的、要调整的、要交付的，很大一部分都发生在 SketchUp 里。

但对 agent 来说，SketchUp scene 更像一个 live execution result。它是执行结果，不应该独自承担全部项目真相。

原因有三个。

第一，软件场景里有很多状态是隐性的。agent 很难直接知道每个对象背后的来源、假设和设计意图。

第二，场景里的结果可能混合了多次尝试。没有结构化记录时，很难判断哪些对象应该保留，哪些只是试验残留。

第三，修复很容易变成“在现有画面上补丁式调整”。这会让短期结果看起来变好了，但长期项目状态越来越难追踪。

更稳的方式是：

设计意图
-> 结构化真相
-> SketchUp 执行
-> 视觉审阅
-> 结构化修复

也就是说，SketchUp scene 和截图都应该回到结构化 truth 形成闭环。

视觉反馈必须回到结构

视觉审阅非常重要。

一张俯视图可能马上暴露墙体错位、开口缺失、空间方向反了、外部空洞被误认为房间等问题。渲染图也可能暴露材质、灯光、比例和风格问题。

但视觉反馈不能只停留在“这张图哪里不对”。

如果设计师说：

“这个墙太厚。”

或者：

“这个开口不应该被封起来。”

或者：

“这个区域不是房间，是外部空洞。”

一个好的 agent 不应该只是临时改一下当前画面。它应该把反馈转成更明确的结构化动作：

修改墙体厚度
修正空间边界
更新 opening evidence
增加 validation failure
记录来源不确定性
生成一次可回放的模型 diff

这样下一次再打开项目时，agent 不是只记得“用户不满意某张图”，而是知道项目真相发生了什么变化。

平面图导入尤其需要真相源

平面图导入是一个很好的例子。

如果用户给 AI 一张 DWG、DXF、PDF、图片、扫描件或照片，最差的流程是让 AI 生成一个看起来像的模型，然后把这个结果当成事实。

更稳的流程应该是：

登记来源。
保留 source evidence。
解释比例、方向、边界、房间、墙体和开口。
生成第一版可编辑 working model。
执行或展示到 SketchUp。
通过俯视图、截图或验证器发现问题。
把修复写回结构化 truth。

第一版导入结果不应该被当成 verified survey。它只是 working truth。

这一区分很关键。

AI 不需要一开始就百分之百正确。它需要承认哪些地方来自证据，哪些地方是推断，哪些地方有不确定性，并且允许设计师用自然语言把错误修回来。

这对设计师意味着什么

如果 AI 设计工具有结构化真相源，设计师的角色会更清楚。

设计师不需要把每一步底层建模操作都手动执行一遍，也不需要在聊天记录里反复解释同一个项目背景。

设计师应该把精力放在更高价值的事情上：

判断空间是否合理
确认设计意图
选择风格和材料方向
管理约束和取舍
审阅视觉输出
决定哪些反馈应该进入项目真相

换句话说，AI 不应该把设计师变成“用自然语言操作软件的画图师”。更好的方向是让设计师成为工作流的判断者和导演。

这对 AI 产品意味着什么

对 AI 产品来说，唯一真相源会改变产品架构。

如果产品只追求输出，它可以围绕 prompt、图像生成和一次性结果优化。

但如果产品要进入真实工作流，就必须处理更多结构：

项目目录
结构化模型
来源证据
运行时技能
设计规则
组件元数据
软件 bridge
验证器
版本和回放
视觉审阅闭环

SketchUp Agent Harness 之所以有意思，不是因为它已经是成熟平台，而是因为它把这个问题暴露得很清楚。

Claude 和 Codex 都只是入口。更重要的是 MCP server、SketchUp Ruby bridge、runtime skills、协议文档和 design_model.json 共同构成的中间层。

这个中间层决定了 agent 是在“生成一个结果”，还是在“维护一个项目”。

真相源不是万能答案

也需要明确边界。

design_model.json 不是审美判断。

它不能替设计师决定空间是否漂亮。

它也不是施工图合规报告，不等于法律、规范或工程审查。

它更像一个可编辑工作事实层：负责承载项目当前状态、来源、假设、规则和可修复结构。

真正的设计判断仍然属于设计师。

这也是为什么 source of truth 这个词在这里不应该被理解成“唯一正确答案”，而应该被理解成“唯一可追踪工作状态”。

结论

我判断一个 AI 设计工具是否真正进入工作流，会看它能不能回答几个问题：

当前模型的结构化状态在哪里？
每个重要结论来自什么来源？
视觉输出和结构化模型是否一致？
设计师反馈会变成什么具体修改？
这个项目能不能被检查、修复和回放？

如果这些问题没有答案，AI 只是一个输出引擎。

如果这些问题有答案，AI 才开始接近一个真正的设计工作流工具。

这就是为什么 AI 设计工具需要唯一真相源。