AI 设计师工作台：设计师应该如何和 AI 协作
解释面向设计师的 AI 工具为什么应该成为可持续工作台：管理目标、项目状态、反馈和版本，而不是停留在聊天、生成图或自动绘图。
ai-design-tools
17 篇公开内容使用了「ai-design-tools」这个标签。
Bridge Trace：为什么先计划执行轨迹，再调用 SketchUp
解释为什么 live SketchUp 执行前需要可检查、可测试、可回放的 bridge trace。
Codex 如何驱动 SketchUp 建模：从指令到可验证模型
解释 Codex 或其他 agent CLI 如何通过 runtime skills、MCP server、SketchUp Ruby bridge 和结构化设计模型，把自然语言意图转成可验证的 SketchUp 项目状态。
`design_model.json` 为什么必须站在 SketchUp scene 前面
解释为什么 SketchUp scene 是执行视图，而结构化 design model 才适合 agent 推理、验证、修复和回放。
设计师的核心价值不是画得更快，而是判断和取舍
讨论 AI 时代设计师的核心价值如何从低层画图执行，转向目标判断、约束取舍、反馈解释、版本决策和可持续协作。
设计师应该专注于想法，而不是成为画图执行者
以 AI 设计工具和 SketchUp Agent Harness 为例，讨论为什么 AI 应该减少低层绘图执行，让设计师把精力放在意图、判断、约束和取舍上。
从聊天建议到可持续设计项目
解释为什么 AI 设计协作需要项目目录、结构化真相、可恢复状态和版本记录，而不是只依赖一段聊天建议。
Headless Smoke、Live Bridge 和 Installed Package：agent harness 怎么验证
解释为什么 agent harness 需要 headless smoke、live bridge、release smoke 和 installed package 验证。
MCP Server 到 Ruby Bridge：把自然语言变成可执行 SketchUp 操作
解释 MCP server、execution trace、JSON-RPC、Ruby bridge 和 execution feedback 如何把自然语言变成可执行操作。
让导入可修复：从 source evidence 到 working truth
解释为什么图纸导入应保留来源证据、生成可修复 working truth，并把识别不确定性纳入后续人工修正流程。
Runtime Skills 的产品边界：设计师 skill、动态 skill、开发 skill 不应混在一起
解释 product runtime skills、project dynamic skills 和 maintainer development skills 的产品边界。
Semantic Component Registry：让 agent 放置对象，而不是搜索模型素材
解释为什么 SketchUp agent 需要语义组件 registry，暴露对象用途、放置约束和复用规则，而不只是搜索 3D 模型素材。
SketchUp Agent Harness 技术架构：为什么 agent CLI 只是入口
解释为什么 Codex 和 Claude 只是入口，SAH 的核心在 MCP server、project workspace、bridge trace 和 SketchUp bridge。
视觉反馈如何变成结构化修改
说明截图、渲染和顶视图如何变成结构化修改请求，进入可追踪的设计迭代，而不是堆积成新的意见垃圾，并形成可复用证据。
为什么 AI 设计工具需要唯一真相源
以 SketchUp Agent Harness 为例，解释为什么 AI 设计工具不能只追求看起来画出来了，而需要可编辑、可校验、可修复、可回放的结构化真相源。
设计规则、个人偏好和项目约束应该谁优先
给出 AI 设计工作台中产品默认、设计师 profile、项目规则和当前会话指令的优先级模型，避免 AI 按错规则执行。
SketchUp Agent Harness
一个开源早期项目：用自然语言、MCP server、SketchUp Ruby bridge、结构化设计模型和运行时技能，把设计师意图转成可验证、可执行、可修复的 SketchUp 项目状态。