Product
作为开发者，我们通常都非常清楚自己想改什么。真正的瓶颈往往不是理解，而是沟通。
当我在 Cursor 或 Windsurf 里打磨 UI 时，我能精确看到问题：这个阴影要再糊 2px，那个间距紧了 4px，这个 hover 需要一个轻微上浮动画。CSS 属性我知道，设计理由我也知道。
问题是，把这些完整打出来很费时：要描述是哪个元素、在页面哪里、上下文是什么。时间就耗在这里。
Architect mode 就是为了解决这层摩擦。
问题：上下文靠打字太贵
拿一个常见任务来说：调整按钮视觉权重。
没有 Architect mode 时，我可能要这样写：
“在 hero 区域有个主 CTA，文案是 ‘Get Started’。它现在有个比较轻的阴影。我想把阴影加强一点，比如 0 4px 12px rgba(0,0,0,0.15)。另外加个 hover 上浮效果，类似 translateY(-1px)，配个过渡……”
只是描述一个我 2 秒就能指给你看的对象，却要写 60+ 个词。
方案：指一下，说一句，直接执行
Architect mode 把屏幕选区和语音输入结合起来：
- 双击 Option -> 出现覆盖层
- 框选元素（不再有“到底哪个按钮”的歧义）
- 说出意图：“阴影更明显，hover 微上浮，200ms ease-out”
- 再双击 Option -> 自动生成结构化规格
输出会很具体、可执行：
“Update the primary CTA button in the hero section: > - box-shadow: 0 4px 12px rgba(0,0,0,0.15) > - hover: translateY(-1px), box-shadow: 0 6px 16px rgba(0,0,0,0.18) > - transition: all 200ms ease-out > - Verify WCAG AA contrast ratio maintained”
这段可以直接贴进 Cursor，不用重排，也不用补充解释。
工程实现难点
要做成这件事，得解决几个硬问题：
1. Latency budget：多模态 LLM（GPT-4V、Claude 3.5 Sonnet）本身偏慢。我做了激进图像压缩和流式返回，让交互保持“跟手”。
2. Prompt precision：早期版本容易给泛泛建议。最终系统 prompt（约 300 词）强约束输出格式：精确 CSS 数值、组件识别、可访问性要求。
3. Context preservation：LLM 不能只看你框了什么，还要看设计系统上下文。我会从可见 UI 中提取配色和间距模式，补齐语境。
为什么重要
这不是在替代技术能力，而是在移除视觉到执行之间的翻译层。
当你正在打磨微交互和视觉细节时，最不想做的就是切换到“写 prompt 模式”。Architect mode 让你保持 flow。
好的工具不会改变你思考方式，它只是把“想法 -> 行动”的摩擦降到最低。
这不是营销，是我们自己踩过的坑。