如何使用 Stitch 插件做页面设计与预览协作

当一个需求涉及落地页、营销页、活动页，或者某个界面的 UI 变化很多时，只靠文字来回描述，通常很难快速对齐结果。

Stitch 插件适合用在这个阶段。它的作用不是替代开发，而是先把页面预览生成出来，再和代码一起往前推进。这样你能更早看到页面效果，也能更快确认方向是不是对的。

Stitch 是做什么的

Stitch 主要用于页面设计审核和预览协作。

在 OSpec 的工作流里，你可以让 AI 连接 Stitch，然后直接围绕页面做生成、编辑和预览。相比只看代码或者只看文字说明，这种方式更适合处理视觉层、布局层和交互层变化比较明显的需求。

简单说，Stitch 更适合回答这类问题：

• 这个页面现在看起来对不对
• 版式和信息层级是不是清楚
• 视觉方向是否已经接近可交付状态
• 这个 UI 改动值不值得继续往代码里落

什么场景适合用 Stitch

下面这些场景特别适合先开 Stitch：

• 新做一个落地页或营销页
• 某个页面要重做视觉结构
• 功能没变，但 UI 需要大改
• 需要先看效果，再决定具体实现细节
• 想把设计确认和代码推进放在同一个节奏里

如果只是改一两行文案、调一个小按钮，未必需要专门走 Stitch。但只要页面改动开始影响整体观感，Stitch 就会很有价值。

最常见的使用方式

一个比较顺手的方式是：

1. 先明确你要改什么页面

不要一上来就说“帮我优化一下界面”。更有效的做法，是先把目标页面和修改范围说清楚。

比如你可以直接说明：

• 要改的是首页、文档页，还是某个功能页
• 这次是新做页面，还是在已有页面上调整
• 你最想解决的问题是什么
• 有没有需要保留的品牌语气、结构或信息模块

2. 打开 Stitch 插件并连接 provider

你们当前对外推荐的说法，可以直接这样用：

$ospec 帮我打开 Stitch 插件，使用 Codex/Gemini 来连接

这一步的重点不是“连上工具”本身，而是让后面的页面生成、编辑和预览能在同一个上下文里继续推进。

3. 用结果导向的方式描述页面目标

给 Stitch 提需求时，尽量少说抽象判断，多说可感知的结果。

比如不要只说：

“做得高级一点。”

可以改成：

“帮我把首页首屏改得更聚焦，主标题更有压迫感，CTA 更明显，下面的功能分区保持清晰，移动端也要成立。”

这种描述更容易得到可用结果，因为它同时包含了目标、重点和约束。

一个简单示例

如果你想让 AI 帮你做一个更完整的页面方向，可以这样开头：

$ospec 帮我打开 Stitch 插件，使用 Codex/Gemini 来连接。我要调整官网首页首屏和插件介绍区，目标是让页面更像正式产品官网，信息层级更清楚，CTA 更集中，保留当前产品语气，并兼顾移动端展示。

这类提示词的好处是，它不会把 AI 限死在某种具体样式里，但又给了足够清晰的目标。

生成之后，应该怎么看结果

Stitch 生成出页面预览后，不要只看“好不好看”，更应该看下面几件事：

• 第一屏有没有把重点说清楚
• 用户是不是能立刻理解这个页面在讲什么
• 视觉层级是否支持阅读，而不是干扰阅读
• CTA 是否足够明确
• 页面风格是否和产品本身一致
• 如果继续落代码，成本是否合理

这一步其实很关键。Stitch 的价值不只是出图更快，而是帮你更早做判断，避免团队在错误方向上继续投入。

使用 Stitch 时的三个建议

1. 先定结构，再抠细节

先确认大方向，再去改颜色、字重、间距这些细节。结构不对时，越早发现越省时间。

2. 一次只推进一个明确目标

一次只聚焦一个问题，通常比同时改十件事更有效。比如先解决首屏表达，再处理功能区展示，最后再补视觉细节。

3. 预览和代码要一起看

Stitch 最适合和实际实现配合着用。只看预览，可能会忽略落地成本；只看代码，又容易错过页面整体观感。把两者放在一起看，判断会更准。

结语

Stitch 适合那些页面效果本身就是需求一部分的工作。

当你不想再靠反复描述去猜页面结果，而是希望更早看到预览、更快确认方向，再继续推进代码时，Stitch 会是很好用的一步。

如果你的需求是落地页、营销页，或者 UI 变化明显的页面改造，最简单的开始方式就是先把 Stitch 打开，然后从一个清晰的页面目标说起。