Figma Web UI 开发规范（Framelink MCP 版）

Normas de desarrollo de UI Web con Figma (versión Framelink MCP)

Resuelve el problema de baja fidelidad al desarrollar UI frontend Web a partir de un diseño de Figma. La causa raíz es tratar los "datos del canvas" de Figma (coordenadas absolutas, colores inline, capas de píxeles) como "datos de implementación", copiándolos directamente, lo que provoca que el diseño responsivo falle, los colores y fuentes sean incorrectos, y falten recursos.

Este skill está orientado a las dos herramientas de Framelink figma-developer-mcp:

Herramienta	Canal	Función
get_figma_data	Canal de precisión	Obtiene los datos del canvas según fileKey + nodeId: información de diseño, contenido, visual y de componentes
download_figma_images	Canal visual	Exporta nodos como SVG/PNG/GIF a un directorio local según el ID del nodo

Nota: Esta es la versión para Framelink, no el servidor MCP oficial de Figma (cuyas herramientas son get_design_context/get_variable_defs/download_assets). La metodología de este skill es común a ambos, pero los nombres de las herramientas están escritos según Framelink.

Si el objetivo es una aplicación de escritorio (Qt Widget / QML / WinUI / Flutter), usa figma-ui-desktop en lugar de este skill.

Principios fundamentales

1. Canal dual en paralelo, prohibido escribir código con un solo canal. El canal de precisión proporciona valores exactos; el canal visual proporciona la maquetación general y el texto. Usar solo uno inevitablemente distorsiona la fidelidad, especialmente si se usa solo el canal visual (equivale a adivinar viendo una captura) o solo el canal de datos (equivale a escribir a ciegas).
2. Usa valores exactos, no hagas estimaciones visuales. Color, tamaño de fuente, interlineado, peso de fuente, espaciado, radio de borde, borde y sombra: toma siempre los valores exactos del diseño.
3. Primero solicita el diseño, no escribas UI por iniciativa propia.
4. Después de implementar, debes cerrar el ciclo de verificación: comparar capturas de pantalla con el diseño → corregir automáticamente los defectos encontrados → revisión humana para pulir e iterar. No existe la magia de lograr el 100% en un solo intento; alcanzar un 70-80% de fidelidad depende del proceso, y el resto se completa con el ciclo de verificación.

Flujo de trabajo

Fase uno: Lectura superficial (comprender los requisitos y la estructura)

Cuando el diseño es grande, primero haz una lectura superficial para evitar sobrecargar el contexto con una extracción completa:

1. Usa get_figma_data para obtener la estructura de nivel superior (depth controla la profundidad de recorrido; empieza desde niveles superficiales) y averigua qué páginas, secciones y componentes existen.
2. Usa download_figma_images para exportar la imagen general de la página y comprender la maquetación y el texto.

Fase dos: Lectura detallada (obtener datos precisos antes de implementar)

Para el componente o sección específica que se va a implementar, llama simultáneamente a:

• get_figma_data (con nodeId, leyendo coordenadas, valores de color, tamaño de fuente, espaciado, radio de borde y borde nodo por nodo)
• download_figma_images (exporta la imagen de esa sección para confirmar las relaciones posicionales relativas de los componentes)

Una vez obtenidos, realiza un análisis estructural antes de escribir código:

• ¿Qué nodos son patrones repetidos (tarjetas, elementos de lista, botones)? → Refactorízalos como componentes.
• ¿Qué posicionamientos absolutos son en realidad maquetación (disposición horizontal, centrado, justificado)? → Conviértelos a flex/grid.
• ¿Qué elementos tienen un rol semántico (navegación, formulario, lista)? → Mapea a la biblioteca de componentes existente del framework de destino.
• Nodos de imagen/icono → Descarga los archivos originales con download_figma_images y colócalos en assets; no los dibujes manualmente.

Fase tres: Implementación

• Colores/tamaños de fuente/espaciados: usa los valores exactos del diseño, no un "parece similar".
• Prioriza el uso de la biblioteca de componentes existente del proyecto. Primero consulta los props del componente (theme/size/variant) para evitar redefinir estilos.
• Los iconos deben usar la biblioteca de iconos del proyecto, no iconos de terceros.
• Los nombres de archivos de estilo, las convenciones de nombres de clases CSS y la profundidad de anidamiento deben seguir las convenciones del proyecto.

Fase cuatro: Ciclo de verificación

Usa Playwright MCP para abrir la página local, tomar una captura de pantalla y compararla lado a lado con la captura del diseño. Corrige automáticamente los defectos evidentes; luego, revisión humana: una persona identifica problemas más sutiles (espaciado, peso de fuente, variaciones de color) y los envía activamente a la IA para una corrección precisa, entrando en la siguiente iteración.

Reglas estrictas contra la pereza

La IA tiende a usar solo un canal para escribir código. Debes exigir explícitamente:

• «Llama simultáneamente a get_figma_data y download_figma_images para leer el diseño»
• «No está permitido usar solo imágenes/capturas para leer el diseño y escribir código»
• «Lee línea por línea los valores exactos de get_figma_data, compara colores/tamaños de fuente/espaciados, no hagas estimaciones visuales»

Normas de componentes (reemplazar según el proyecto)

Lo siguiente es una plantilla que debe reemplazarse por las convenciones del proyecto específico:

• Prioriza el uso de la biblioteca de componentes del proyecto (por ejemplo, @notta/components). Ante la duda, pregunta activamente al usuario.
• Consulta primero los props de la biblioteca de componentes para evitar redefinir estilos.
• Los iconos deben usar la biblioteca de iconos del proyecto.
• Los nombres de archivos de estilo, las convenciones de nombres de clases CSS y la profundidad de anidamiento deben seguir las convenciones del proyecto.

Lista de verificación de autocomprobación de fidelidad

Revisa cada elemento tras la generación (es más fiable que "parece similar en general"):

• Color (¿se ha usado el valor hex exacto, no un aproximado?)
• Tamaño de fuente / interlineado / peso de fuente
• Espaciado / márgenes / relleno
• Radio de borde / borde / sombra
• Maquetación (¿flex/grid equivale a la disposición del diseño?)
• z-index / jerarquía
• ¿Los iconos/imágenes son los archivos originales, no dibujados manualmente?

Fuentes de referencia

La metodología se basa en el flujo de desarrollo de UI con Figma MCP oficial + Playwright (ver «Mejora de la eficiencia del desarrollo y depuración de UI con Figma MCP y Playwright MCP»). La idea central es «canal dual + ciclo de verificación + exigencias claras contra la pereza». Los nombres de las herramientas se han adaptado a Framelink figma-developer-mcp.