把抽象设计选项画出来：网站生成 Skill 的临时 Gallery 机制

当一个网站生成 Skill 问你：

• 选择叙事型结构还是模块化结构？
• 使用编辑感排版还是技术感排版？
• 主动效采用滚动叙事还是空间切换？

这些选项看起来很专业，但用户未必能仅凭文字想象最终效果。

如果直接生成完整网站，用户发现方向不对时，结构、样式和动效往往都要返工。更合理的办法是：在正式生成网站前，先创建一个临时 Gallery，把抽象设计选项转化成可以直接比较的网页。

一、临时 Gallery 解决了什么问题

视觉选择与普通配置项不同。

“是否启用深色模式”可以通过文字确认，但“编辑感排版”和“模块化排版”之间的区别，涉及字号、留白、对齐、阅读节奏和内容层级。只给用户一段描述，相当于让用户闭着眼睛挑颜色。

临时 Gallery 在设计选择与正式生成之间增加了一个可视化层：

设计数据库
→ 结构化候选
→ 临时 Gallery
→ 浏览器比较
→ 对话确认
→ 正式网站生成

它不是最终网站，也不是需要持续维护的原型，而是一次设计决策的视觉证据。

可以把它理解为装修前的材料样板：样板帮助用户选择木材、墙漆和灯光，但它本身不会成为最终房间。这个类比的边界也很明确——Gallery 不验证完整网站的业务逻辑，只帮助判断当前视觉选项。

二、哪些设计选项需要被画出来

当前流程把网站设计拆成六类决策：

每次只展示一个类别。

例如，比较配色时，所有候选都应使用相同的内容和基本构图，只改变颜色关系；比较字体时，则保持结构和配色尽量中性，只改变字体、字号、字重和间距。

这样可以避免变量过多。如果每个候选同时采用不同结构、配色和动效，用户最终看到的是几个完整风格，却无法判断自己真正喜欢的是哪一项。

三、候选方案从哪里来

Gallery 本身不负责决定展示哪些候选。

候选首先由设计检索程序根据当前网站的内容特征，从本地设计数据库中查找。检索条件可以包括：

• 网站类型；
• 目标受众；
• 内容密度；
• 是否存在可用媒体；
• 已经确认的设计选择；
• 当前项目的反模板设计基线。

不同类别会检索不同的数据库领域。例如：

结构：landing / style / product / ux
字体：typography / style / ux
配色：color / style / ux
主动效：motion / style / landing / ux

检索完成后，程序输出结构化候选：

{
  "id": "structure-1",
  "label": "Editorial · Storytelling",
  "fit": [
    "适合具有明确项目故事线的内容"
  ],
  "risks": [
    "长页面需要控制阅读节奏"
  ],
  "tradeoffs": [
    "表现力更强，但实现成本更高"
  ],
  "responsive_fallback": "移动端恢复为单列语义顺序",
  "accessibility_notes": [
    "保持标题层级和键盘导航"
  ],
  "source_ids": [
    "style:editorial",
    "landing:storytelling"
  ]
}

其中 source_ids 很重要。它证明候选确实来自设计数据库，而不是 Agent 临时编造的风格名称。

如果一个类别找不到至少两个完整候选，流程应该停止并报告数据库证据不足，而不是假装检索成功。

四、HTML 画布如何变成真实展示

Skill 内部准备了一个基础 HTML 骨架：

<article class="direction" data-candidate-id="structure-1">
  <div class="direction-meta">
    <h2>候选方案名称</h2>
    <p>适用性与取舍</p>
  </div>

  <div class="canvas">
    在这里放入真实内容的视觉样例
  </div>

  <p class="annotation">
    当前方案的风险、移动端和无障碍说明
  </p>
</article>

这个文件只提供：

• 页面容器；
• 候选卡片结构；
• 展示区域；
• 推荐标记位置；
• 工程说明区域；
• 基础响应式规则。

真正的视觉差异需要 Agent 根据候选数据写入 HTML 和 CSS。

例如，结构候选可能被画成：

<section class="editorial-layout">
  <aside class="project-index">01 / 04</aside>

  <div class="story">
    <p class="eyebrow">Selected project</p>
    <h2>让复杂流程变得可以理解</h2>
    <p>项目背景与关键决策说明……</p>
  </div>
</section>

字体候选则可能使用同一段内容，只调整排版变量：

.typography-editorial {
  font-family: Georgia, serif;
  font-size: clamp(1rem, 1.2vw, 1.25rem);
  line-height: 1.75;
  letter-spacing: 0.01em;
}

.typography-technical {
  font-family: Inter, system-ui, sans-serif;
  line-height: 1.55;
  letter-spacing: -0.015em;
}

五、Gallery 是怎样在浏览器中打开的

Gallery 生成后，可以直接打开本地 HTML，也可以通过一个轻量的 Node.js 服务展示：

node scripts/visual_companion/launch.cjs `
  --workspace-root "." `
  --gallery ".resume-site-work/style-preview/drafts/color/demo/gallery.html" `
  --open

启动程序主要完成四件事：

1. 校验 Gallery 是普通 HTML 文件；
2. 将页面和资源复制到隔离会话目录；
3. 启动仅监听本机地址的 HTTP 服务；
4. 调用操作系统命令打开默认浏览器。

不同系统可以使用：

Windows：Start-Process
macOS：open
Linux：xdg-open

因此，这种机制不依赖浏览器自动化框架。它不需要控制浏览器点击，也不要求浏览器安装额外扩展，只需要系统具备 Node.js 和默认浏览器。

如果本地服务无法启动，还可以把 Gallery 的绝对路径作为静态 HTML 回退方案。

六、总结

临时 Gallery 的价值，不是提前做出一个半成品网站，而是把难以理解的设计语言转化成可以直接观察的视觉证据。

完整机制可以概括为：

内容特征进入设计数据库
→ 检索出带来源的候选方案
→ Agent 将候选翻译成 HTML/CSS
→ 本地服务打开只读 Gallery
→ 用户在浏览器中比较
→ 回到对话明确选择
→ 将六项选择一次性生成正式网站

其中最重要的边界有三条：

1. Gallery 负责展示，不负责批准。
2. Gallery 是临时决策证据，不是正式网站源码。
3. 设计数据库提供候选依据，Agent 负责把依据翻译成视觉表达。

先把抽象选择画出来，再生成完整网站，可以降低用户理解设计术语的门槛，也让后续实现建立在明确、可追溯的视觉决策之上。