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。
好的工具不會改變你思考方式，它只是把“想法 -> 行動”的摩擦降到最低。
這不是行銷，是我們自己踩過的坑。