AI 进入设计工具以后，最容易出现的误解是：设计师终于可以“用一句话画图”。

这当然有吸引力。少画几步、少点几次菜单、少做一些重复操作，本身就是效率提升。

但如果 AI 设计工具只把设计师从“手动操作软件”变成“用自然语言指挥软件”，那还不够。设计师只是从鼠标和快捷键的执行者，变成了提示词和对话的执行者。

真正值得追求的方向，不是让设计师更快地当画图师，而是让设计师把更多精力放回想法、判断、约束和取舍。

画图不是低级工作，但它不是全部设计

先说清楚：画图不是低级工作。

图纸、模型、草图和渲染都是设计语言。没有表达，设计判断无法被沟通，也无法被检查。

问题在于，真实设计工作里有很多时间并不是花在“判断”上，而是花在重复执行上：

  • 把同一类组件放到正确位置
  • 按规则调整尺寸和清距
  • 根据已有空间边界补墙、开口和家具
  • 在几版方案之间来回修改
  • 把口头反馈变成模型修改
  • 反复确认图纸、模型和截图是否一致

这些事情需要耐心和精确，但不一定都需要设计师亲自一笔一笔执行。

设计师真正不可替代的部分，是判断什么值得做、为什么这样做、哪些约束不能破、哪里可以妥协、最终表达是否符合意图。

AI 设计工具应该服务这些判断，而不是只制造更多需要设计师检查和修补的输出。

“一句话画图”容易把问题藏起来

如果一个工具的核心卖点只是“输入一句话，生成一个空间”，它很容易让复杂问题被隐藏。

看起来生成了一个卫生间、客厅或展厅，并不代表设计工作流真的成立。

设计师还需要知道：

  • 这个空间尺寸是否可信
  • 墙体和开口来自哪里
  • 组件是否有语义和尺寸
  • 清距是否被检查过
  • 视觉反馈是否能回到模型
  • 下次修改时，AI 是否还能理解当前状态

如果这些问题没有答案，AI 只是把执行过程压缩成了一个结果。它让“第一次生成”更快，但没有让“持续设计”更稳。

这也是为什么 AI 设计工具不能只优化 prompt 到 image，或者 prompt 到 scene。它需要把设计项目组织成一个可持续工作流。

更好的工作流是什么

在我对 SketchUp Agent Harness 的设计判断里，一个面向设计师的 AI 工具至少应该有这条链路：

设计意图
-> 项目目录
-> 结构化工作模型
-> 设计规则
-> 组件和来源证据
-> SketchUp 执行
-> 视觉审阅
-> 结构化修复

这里最关键的是：设计师不是直接和一个黑箱输出打交道，而是在维护一个项目。

设计师可以用自然语言表达目标，比如：

“创建一个 2 米 x 1.8 米的卫生间，包含马桶、洗手台、门、镜子、基础照明，并检查通行距离。”

但 agent 不应该只把这句话变成一次画面。它应该把这句话转成结构化项目状态：空间尺寸、组件、规则、假设、清距检查、执行计划和后续可修复的模型。

这样设计师下一次不是从头再说一遍，而是在一个已有项目状态上继续判断和迭代。

设计师应该控制判断，而不是沉到所有执行细节里

AI 可以承担越来越多低层执行，但它不应该夺走设计判断。

更合理的分工是：

  • AI 负责整理项目状态
  • AI 负责执行重复建模动作
  • AI 负责把来源证据转成第一版工作模型
  • AI 负责检查结构性问题
  • AI 负责把视觉反馈转成可修复动作
  • 设计师负责决定方向、约束、取舍和最终接受标准

这不是让设计师“少参与”，而是让设计师参与更关键的层级。

如果设计师每次都要确认每条线、每个对象、每个微小位置，那 AI 只是增加了一个新操作界面。

如果设计师可以说“这个开口不应该被封起来”“这个墙太厚”“这个空间不是房间，是外部空洞”，并且 agent 能把这些反馈写回结构化模型，那么 AI 才真正开始支持设计工作。

Runtime skills 应该服务设计任务

这也是为什么我把 runtime skills 看成设计工具的重要部分。

面向设计师的 skill 不应该是维护者的开发笔记，也不应该是产品内部实现细节。

它应该服务真实设计任务，例如：

  • 空间规划
  • 平面图导入
  • 组件搜索
  • 设计规则
  • 语义定位
  • 视觉反馈
  • 结构化修复

这些 skill 的作用不是“告诉 AI 一些提示词技巧”，而是让 agent 在具体设计场景里知道该如何行动，如何尊重项目状态，如何避免把一次项目里的局部判断变成产品全局规则。

换句话说，runtime skills 是设计工作流的一部分，而不是营销包装。

项目局部记忆不能污染产品规则

AI 设计工具还会遇到一个很现实的问题：每个设计项目都有局部事实。

某张平面图的方向、某个客户的偏好、某次导入的比例修正、某个房间的命名方式，这些都可能只属于当前项目。

如果 agent 把这些局部事实写进产品默认规则，产品会很快失控。

更好的做法是分层：

  • 产品 runtime skills 只放通用设计任务能力
  • 项目/session memory 只服务当前项目
  • 维护者 development skills 只服务产品开发和发布
  • 经过泛化和验证的模式，才进入中央知识或产品规则

这套分层保护的不是工程洁癖，而是设计师的工作边界和客户材料的隐私。

AI 应该减少噪音，而不是制造更多草稿

一个坏的 AI 设计工具会不停生成选项，然后把筛选、修复、解释和收尾都丢回给设计师。

一个好的 AI 设计工具应该减少噪音。

它应该让设计师更快地到达可判断状态，而不是更快地产生一堆无法继续工作的结果。

对设计师来说，最有价值的不是“AI 给我生成了很多图”，而是：

  • 我能看懂当前方案为什么这样
  • 我能指出问题
  • AI 能把问题转成结构化修改
  • 我能保留版本
  • 我能继续推进，而不是不断重来

这才是工作流意义上的效率。

结论

我不认为 AI 会让设计师变得不重要。

相反，如果工具设计正确，AI 会把设计师从大量低层执行里释放出来，让设计师更集中地处理意图、判断、约束、审阅和取舍。

但这需要工具本身尊重设计工作流。

它不能只追求“输入一句话，生成一个结果”。它要能维护项目状态，保留来源证据，执行到专业软件，接受视觉反馈，并把反馈写回结构化真相。

设计师不应该只是 AI 时代的画图执行者。

设计师应该成为整个设计工作流的判断者和导演。