很多人讨论 AI 设计工具时，默认的问题是：AI 能不能帮我画图？能不能帮我出效果图？能不能把一句话变成一个模型？

这些问题都重要，但它们不是设计师真正长期需要的工作方式。

设计师不是只缺一个更快的绘图按钮。设计师缺的是一个能持续承载项目判断的工作台：意图放在哪里，素材放在哪里，规则谁来维护，模型状态如何更新，视觉反馈如何回到设计本身，以及每一次修改为什么发生。

所以我更愿意把面向设计师的 AI 工具理解成 AI 设计师工作台，而不是聊天机器人、图片生成器或自动绘图插件。

工作台和聊天工具的区别

聊天工具擅长回答问题。你可以问它配色、风格、空间感、动线建议和材料选择。它能给出灵感，也能帮你组织语言。

但真实设计项目不会停在一次回答里。

一个项目会持续变化。客户会改需求，现场条件会变化，材料预算会收紧，设计师会推翻前一天的判断，模型里会出现不一致，截图里会暴露新的问题。

如果 AI 只是聊天，它很难稳定回答这些问题：

  • 这个设计当前采用了哪些规则？
  • 哪些尺寸来自原始图纸，哪些只是推断？
  • 上一次客户反馈到底改了哪个空间？
  • 这个效果图的问题应该修改模型、材料、灯光，还是只修改表达？
  • 当前版本和上一版的差异是什么？

工作台的价值在于，它不把对话当成唯一容器。它会把对话转成可保存、可检查、可修复的项目状态。

设计师仍然是判断者

AI 进入设计流程以后，最危险的误解是：设计师会被降级成给 AI 下命令的人。

更合理的分工正好相反。

AI 可以帮助设计师完成低层执行：整理素材、生成初版模型、批量尝试方案、检查规则、准备截图、记录版本、把反馈翻译成修改动作。

但设计师必须继续拥有这些判断：

  • 目标是什么；
  • 哪些约束不能被破坏；
  • 什么是好方案，什么只是看起来热闹；
  • 哪些反馈应该接受，哪些反馈只是临时意见；
  • 哪些规则可以被更新，哪些规则只是当前项目例外。

一个好的 AI 设计工作台，不应该让设计师变成“提示词操作员”。它应该把设计师从重复绘制、重复查找、重复整理和重复修复里释放出来，让设计师把注意力放回意图、取舍和验收。

一个工作台至少需要六层

如果只从产品体验看，AI 设计工作台可能表现为一句自然语言指令，例如“帮我把这个空间做成更适合阅读的客厅”。

但背后应该有六层东西在工作。

第一层是设计意图。AI 必须知道你想解决什么问题，而不是只知道你说了什么词。

第二层是项目素材。户型图、参考图、组件、材料、约束、客户反馈和现场信息，都应该有来源记录。

第三层是结构化模型。设计不能只存在于截图和聊天记录里。空间、尺寸、组件、规则、假设和版本需要进入一个可编辑的事实层。

第四层是设计规则。个人偏好、项目要求、当前会话指令和产品默认规则会同时存在，必须有优先级。

第五层是专业软件执行。AI 不只是给建议，还要能把结构化设计状态执行到 SketchUp 这类设计软件中。

第六层是视觉审阅和修复。截图、渲染和顶视图可以帮助发现问题，但它们不应成为最终真相。被接受的反馈应该回到结构化模型、规则或来源证据里。

这六层连起来，设计项目才不会变成一堆散落的聊天建议和图片。

SketchUp Agent Harness 只是一个案例

我做 SketchUp Agent Harness 时，核心判断就是：自然语言控制 SketchUp 只是入口，真正重要的是把设计项目变成可持续工作流。

在这个方向里，Codex 或 Claude 不是最终产品本身。它们是设计师进入工作台的入口。更重要的是项目目录、结构化设计模型、运行时技能、SketchUp bridge、组件信息、导入证据、截图记录和修复闭环。

这并不意味着这个产品已经成熟到可以覆盖所有设计场景。相反，很多能力仍然需要迭代：更好的图纸导入、更稳定的组件库、更完整的设计规则、更可靠的视觉反馈闭环。

但方向是清楚的：AI 设计工具不应该只追求“一句话生成结果”，而应该帮助设计师维护一个长期可编辑、可追溯、可修复的设计项目。

这个系列会讨论什么

这个系列不讲底层协议，也不把它写成面向开发者的架构文档。它关注设计师如何和 AI 协作。

接下来几篇会分别讨论：

  • 为什么设计师的核心价值不是画得更快，而是判断和取舍；
  • 为什么聊天建议应该沉淀成可持续设计项目；
  • 视觉反馈如何从一句“这里不对”变成结构化修改；
  • 个人偏好、项目规则和当前指令发生冲突时，谁应该优先。

我的基本观点是：AI 不应该接管设计师的判断。AI 应该成为设计师的工作台，把意图、素材、规则、模型、反馈和修复组织起来，让设计师更稳地推进真实项目。