react:components

react:components 技能概览

react:components 的作用

react:components 技能会把 Stitch 设计转换成适用于基于 Vite 的前端的模块化 React 代码。它面向的是需要从屏幕截图或 Stitch 元数据走到可维护组件系统的代理，而不是只生成一次性 JSX 的场景。

适合谁使用

如果你正在基于 Stitch 构建或更新前端，并且在意结构、token 一致性和校验，就应该使用这个 react:components 技能。它最适合前端工程师、design-to-code 工作流，以及需要用可重复方式把视觉页面映射成组件的代理。

它有什么不同

和通用提示词相比，react:components 包含检索步骤、本地文件检查、设计回退以及基于 AST 的验证。这一点很重要，因为真正的风险往往不是“模型能不能写 JSX”，而是“输出能否与设计、现有文件和项目约束保持一致”。

如何使用 react:components 技能

安装并激活

按照目录里的标准 skill 命令安装 react:components 技能，然后在 Stitch 支持的设计任务上调用它。实际使用中，react:components 的安装步骤只是入口，真正的价值在于你要提供屏幕名称、项目上下文，以及诸如“React component system”或“Vite component set”之类的输出目标。

给技能正确的输入

效果最好的提示词会写明屏幕名称、Stitch 项目，以及期望的实现形态。比如：“把我的 Podcast Stitch 项目里的 Landing Page screen 转成模块化 React components，适用于 Vite，并保留布局和 design tokens。”这比“把这个做成 React”更符合 react:components 的使用方式，因为它明确了页面边界、来源系统和输出预期。

先阅读这些文件

先看 SKILL.md 了解工作流，然后在生成代码前检查 resources/stitch-api-reference.md、resources/architecture-checklist.md 和 resources/style-guide.json。再用 examples/gold-standard-card.tsx 看看理想的组件风格，用 scripts/validate.js 了解这个技能会拒绝什么。如果你需要手动获取设计资源，scripts/fetch-stitch.sh 展示了受支持的下载路径。

能提升输出质量的工作流

这个技能默认会先做设计检索，再检查本地是否存在 .stitch/designs/{page}.html 和 .stitch/designs/{page}.png，随后进行代码生成和验证。如果本地设计文件已经存在，需要决定是复用它们还是先从 Stitch 刷新后再重新生成。这个选择会影响 react:components 指南使用的是缓存的设计状态，还是最新的 MCP 来源。

react:components 技能常见问题

react:components 只适用于 Stitch 项目吗？

是的，这是它最适合的场景。react:components 技能针对 Stitch MCP 输入做了优化，而不是面向任意截图或自由形式的 mockup。如果你只有一个模糊的产品想法，通用 React 提示词可能就够了；如果你手里有 Stitch 元数据，并且想要稳定的映射结果，这个技能会更合适。

还需要写很详细的提示词吗？

需要。这个技能减少的是搭建成本，但它仍然需要清晰的屏幕名称、项目名称和期望的组件范围。输入越明确，react:components 技能就越不容易猜测你要的是单个组件、组件树，还是一组可复用模块。

这个技能适合新手吗？

新手也能用，但它默认你能理解 props、layout 和 design tokens 这类基础前端概念。如果你是刚入门，这个技能仍然有帮助，因为它已经把工作流固化好了；不过，当你能够准确描述目标 UI，并接受模块化 React 输出时，效果会更好。

什么情况下不该用它？

如果你的任务主要是内容撰写、后端工作，或者是非 Stitch 的 React 功能，就不要用 react:components。它也不适合你只想快速做一个视觉原型、且不需要遵守设计元数据、验证或 token 映射的场景。

如何改进 react:components 技能

提供设计上下文，而不只是一个名称

质量提升最大的做法，是明确要转换的是哪一个屏幕、哪些部分必须保留、哪些部分可以抽成可复用组件。比如，“保留桌面版 Stitch 屏幕的间距和排版，但把重复的卡片拆成可复用组件”，会比模糊的转换请求给 react:components 技能更清晰的结构信号。

说明会影响代码形态的约束

提前说明框架边界、路由假设、资源处理方式以及项目约定。如果你需要 TypeScript、Tailwind，或者适配 Vite 的输出，也要直接说清楚。如果背景图应该作为数据处理，而不是硬编码进 CSS，也要把这个约束写进提示词里，这样技能才能沿着同样的 react:components 安装假设和验证路径执行。

留意常见失败模式

最常见的问题，是只要求 UI 代码，却没有提供足够准确映射所需的源设计细节。另一个问题，是明明这个技能面向模块化输出，却要求它生成一个巨大的单文件。第三个问题，是忽略验证规则，这会导致硬编码颜色、缺失接口，或者出现会让 architecture checklist 失败的模板占位符。

用更紧的第二轮迭代

如果第一次结果已经接近，但还不够可上线，就直接指出具体问题：“把 header 和 card 拆成独立组件”、“把静态文本替换成 mock data”、“让颜色对齐 style-guide.json”。这种 react:components 使用反馈比泛泛地要求“更好的代码”有效得多，因为它直接命中了技能已经知道如何优化的结构。