Por qué las páginas de aterrizaje hechas por IA se ven todas iguales y la solución
TuBrief 편집팀
2026년 8월 22일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Para un desarrollador solitario que hace de todo, desde la planificación hasta el despliegue, herramientas como Cursor o Claude Code parecen un salvavidas. Escribes un par de líneas de instrucciones y en 10 minutos tienes una página web de aspecto convincente.
El problema viene después. Haces clic en el botón de despliegue y, al ver la pantalla, te invade una sensación de déjà vu. Botones con degradados morados, la fuente Inter, una estructura de tres tarjetas justo en el medio. Huele a plantilla vista mil veces. Por fuera se ve limpia, pero no se traduce en pagos o registros de usuarios. Las personas detectan de inmediato una página hecha en serie y cierran la pestaña.
Los LLM funcionan basándose en promedios estadísticos. Si no les das reglas, regresan a los preajustes predeterminados de Tailwind y Shadcn UI más comunes en la web. En el momento en que lanzas una instrucción como "crea una página de aterrizaje limpia y elegante", la IA vomita valores de píxeles en línea sin identificar, como w-[320px] o top-[117px], arruinando el diseño.
Intentar solucionar este problema modificando las instrucciones de forma manual es agotador. Debes construir una tubería (pipeline) que obligue a seguir las reglas de marca cada vez que se genera código y bloquee físicamente en la fase de confirmación (commit) el código que las infrinja.
Cursor lee .cursor/rules/*.mdc, Claude Code lee CLAUDE.md y las herramientas de código abierto leen AGENTS.md. Al definir los tokens de diseño de tu marca en estos archivos, evitas que la IA utilice estilos arbitrarios desde la fase de generación de código.
Si el archivo de reglas supera las 500 líneas, el coste de contexto que se lee en cada sesión aumenta y la tasa de cumplimiento de las instrucciones por parte del modelo disminuye. Debe redactarse de forma clara, rondando entre las 200 y 300 líneas.
Crea .cursor/rules/design-system.mdc en la raíz del proyecto e introduce el siguiente contenido.
bg-[#123456] or h-[117px].pnpm lint:style to verify token compliance before completing tasks.var(--color-bg-primary) (Tailwind: bg-brand-primary)var(--color-bg-secondary) (Tailwind: bg-brand-secondary)var(--color-text-main) (Tailwind: text-brand-main)var(--color-text-muted) (Tailwind: text-brand-muted)var(--color-accent-default) (Tailwind: bg-brand-accent)var(--space-1): 0.25rem (4px)var(--space-2): 0.5rem (8px)var(--space-4): 1.0rem (16px)var(--space-6): 1.5rem (24px)var(--space-8): 2.0rem (32px)text-brand-h1 -> Font: Inter, Weight: 700, Size: 2.5rem, Tracking: -0.02emtext-brand-body -> Font: Inter, Weight: 400, Size: 1.0rem, Leading: 1.5`
Al incluir esta regla, la frecuencia con la que la IA inyecta valores arbitrarios entre corchetes o códigos hexadecimales se reduce notablemente.
Las instrucciones por sí solas no bastan. Con frecuencia, la IA ignora las reglas y mezcla sigilosamente valores de píxeles en línea. Al combinar Stylelint y los ganchos (hooks) de Git Pre-commit, bloqueamos el acceso de estilos hardcodeados al repositorio.
Instala las herramientas e inicializa Husky.
`bash
pnpm add -D husky lint-staged stylelint stylelint-declaration-strict-value
npx husky init
`
Crea stylelint.config.mjs en la raíz del proyecto. Es una configuración que genera un error de compilación si se introducen códigos de color o valores de píxeles arbitrarios.
`javascript
import type { Config } from "stylelint";
export default {
plugins: ["stylelint-declaration-strict-value"],
rules: {
"scale-unlimited/declaration-strict-value": [
["/color/", "font-size", "/margin/", "/padding/"],
{
ignoreVariables: false,
ignoreFunctions: false,
ignoreKeywords: {
"": ["transparent", "inherit", "currentColor", "auto", "0"]
},
message: "Design System Violation: Hardcoded value for '{property}' is forbidden. Use CSS Design Tokens instead."
}
]
}
} satisfies Config;
`
Añade la configuración de lint-staged en package.json.
json
{
"lint-staged": {
"*.{css,scss,tsx,jsx}": [
"stylelint --fix",
"eslint --max-warnings=0"
]
}
}
`
Registra la siguiente línea en el archivo .husky/pre-commit.
`bash
npx lint-staged
`
Ahora, cada vez que ejecutes git commit, se realizará un análisis estático del código preparado (staged). Si hay código como margin: 17px introducido arbitrariamente por la IA, la confirmación fallará por completo. Puedes ahorrar unas 5 horas semanales que antes gastabas en corregir estilos.
El análisis estático solo comprueba reglas de texto. Los problemas de elementos superpuestos o menús rotos en pantallas móviles requieren abrir directamente el navegador. Como no es viable reducir y ampliar manualmente la ventana gráfica cada vez, automatizamos la comparación de instantáneas con Playwright.
Crea el archivo playwright.config.ts.
`typescript
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
testDir: './tests/visual',
snapshotPixelRatioTemplate: '{snapshotDir}/{testFileDir}/{testFileName}-snapshots/{arg}{ext}',
expect: {
toHaveScreenshot: {
maxDiffPixelRatio: 0.01,
threshold: 0.2,
animations: 'disabled',
},
},
webServer: {
command: 'pnpm dev',
url: 'http://localhost:3000',
reuseExistingServer: !process.env.CI,
timeout: 120 * 1000,
},
projects: [
{ name: 'Desktop Chrome', use: { ...devices['Desktop Chrome'] } },
{ name: 'Mobile Safari', use: { ...devices['iPhone 13'] } },
],
});
`
Escribe el script de prueba (tests/visual/landing-page.spec.ts) que valida 5 ubicaciones clave de la interfaz de usuario.
`typescript
import { test, expect } from '@playwright/test';
test.describe('Visual Regression Guardrails', () => {
test.beforeEach(async ({ page }) => {
await page.goto('http://localhost:3000');
await page.evaluate(() => document.fonts.ready);
});
test('TC1: Renderizado de la sección principal de escritorio', async ({ page }) => {
await page.setViewportSize({ width: 1440, height: 900 });
const heroSection = page.locator('section#hero');
await expect(heroSection).toBeVisible();
await expect(heroSection).toHaveScreenshot('hero-desktop.png', { maxDiffPixelRatio: 0.01 });
});
test('TC2: Renderizado del menú de navegación móvil en la ventana gráfica', async ({ page }) => {
await page.setViewportSize({ width: 375, height: 812 });
const navBar = page.locator('header#main-nav');
await expect(navBar).toHaveScreenshot('nav-mobile.png');
});
test('TC3: Alineación de la cuadrícula de tarjetas de precios', async ({ page }) => {
await page.setViewportSize({ width: 1280, height: 800 });
const pricingGrid = page.locator('div#pricing-cards');
await expect(pricingGrid).toHaveScreenshot('pricing-grid.png', {
mask: [page.locator('.dynamic-price-timestamp')]
});
});
test('TC4: Estado de pasar el cursor sobre el botón principal de CTA', async ({ page }) => {
const ctaButton = page.locator('button#primary-cta');
await ctaButton.hover();
await expect(ctaButton).toHaveScreenshot('cta-button-hover.png');
});
test('TC5: Diseño del modal de inicio de sesión', async ({ page }) => {
await page.click('button#open-login-modal');
const modalDialog = page.locator('div[role="dialog"]');
await expect(modalDialog).toBeVisible();
await expect(modalDialog).toHaveScreenshot('login-modal.png');
});
});
`
Registra los comandos en package.json.
`json
{
"scripts": {
"test:visual": "playwright test",
"test:visual:update": "playwright test --update-snapshots"
}
}
Con solo ejecutar una línea en la terminal (`pnpm test:visual`), podrás detectar diseños rotos en las vistas de escritorio y móviles en menos de un minuto. Te deshaces de la tediosa tarea de ajustar manualmente el tamaño de la pantalla y revisar con la vista cansada.
Al establecer una estructura que controle las entradas de la IA mediante archivos de reglas, impida la introducción de estilos erróneos con ganchos de Git y compruebe los fallos visuales con Playwright, es posible mantener la consistencia del diseño incluso en proyectos desarrollados por una sola persona.