为什么我坚持要求架构级设计师手写 HTML 原型？

在 Figma 插件可以“一键生成代码”的今天，很多设计师问我：为什么在你的进阶课程中，依然把手写 HTML/CSS 原型作为核心考核指标？我的回答很简单：因为视觉画板无法模拟真实的组件状态与数据流转。

生成式 UI（Generative UI）带来的范式转移

在传统的 GUI 时代，我们设计的界面是高度确定性的（Deterministic）。一个表单、一个按钮，它的状态无非是 Default、Hover、Active 和 Disabled。画板足以应对这些场景。

但在大模型驱动的 AI 时代，产品正在向 生成式 UI (Generative UI) 演进。页面的内容不再是静态组装的，而是根据用户的即时意图，由 AI 从底层调用 API，实时动态拼装出一个卡片或控制台。这意味着界面充满了极端变量：

如果 AI 返回的数据延迟了 3 秒，流式渲染（Streaming）的过程中骨架屏该如何优雅过渡？
如果生成的内容超出了预设的容器宽度，Flexbox 该如何响应？
如果 API 返回了异常格式（Hallucination），你的容错机制（Fallback UI）是什么？

“真正的体验架构不仅关乎像素的美感，更关乎在极限数据和网络条件下的系统韧性。”

代码是唯一不撒谎的设计语言

当设计师开始使用 HTML 和 Tailwind CSS 构建原型时，他们被迫从“画板视角”切换到了“DOM 视角”。

比如，在画板里实现一个气泡弹窗，你只需要拖拽图层；但在代码里，你需要考虑 `position: relative` 和 `z-index`，你需要处理由于内容动态撑开而导致的布局塌陷。这种思维训练是无价的，它让设计师在提出需求时，天然就具备了工程化的同理心。

// 传统设计思维：
// “这里放一个加载动画”

// 工程化体验思维：
<div class="flex items-center space-x-2 opacity-50 transition-opacity">
  <div class="w-2 h-2 bg-blue-500 rounded-full animate-pulse"></div>
  <span class="text-sm text-gray-500">Generating context...</span>
</div>

降本增效的终极解法

对于企业而言，一份包含完整 DOM 结构、CSS 类名（尤其是 Tailwind 这种原子化工具）和轻量级 JS 逻辑的 HTML 原型，是最高效的交付物。前端工程师可以直接拷贝结构，绑定 Vue/React 的状态，这比盯着 Figma 标注去推测响应式逻辑要高效数倍。

因此，在这个被 AI 重新定义的时代，掌握前端基础不再是前端工程师的专利，而是架构级体验设计师跨越职场瓶颈的必杀技。