📊 Matriz comparativa
Un problema, cuatro respuestas. Elige tres problemas universales de diseño de prompts — cuándo rechazar, cómo citar la fuente, actuar sin preguntar— y compara lado a lado las soluciones de cuatro proveedores. La matriz no dice quién tiene la "razón": expone los trade-offs que cada elección conlleva, y se convierte en una herramienta de consulta que cierra la Trilha 3.
Matriz ilustrativa de 3×4: cada celda es una elección de diseño real, extraída de los prompts filtrados de las cuatro filosofías.
Contenido detallado
Cómo leer la matriz
Una matriz comparativa es la herramienta adecuada cuando hay un eje de problemas e un eje de soluciones. Aquí el problema va en las líneas y el proveedor va en las columnas. Lees una fila para responder "¿cómo resuelve esto cada uno?" y lees una columna para reconstruir "¿cuál es la firma de este proveedor?". El valor no está en una celda aislada, sino en el contraste que revela la cuadrícula.
Qué es
Las líneas son problemas universales — todo prompt de producto debe responderlos, independientemente del proveedor. Elegimos tres que aparecen en casi todos los prompts filtrados: cuándo rechazar, cómo citar la fuente e cuándo actuar sin preguntar.
Las columnas son las cuatro filosofías del Módulo 3.1: Anthropic (principio + porqué), OpenAI (regla breve + persona), Google/Microsoft (estructura + procedimiento) y xAI (concisión con opinión + XML). Cada celda es una elección real, con una fuente citable en el acervo.
Por qué aprender
Leer prompts aislados enseña patrones; leerlos en una matriz enseña por decidir. Cuando escribas tu propio prompt (Trilha 4) y te encuentres con uno de estos problemas, la matriz muestra el abanico de respuestas posibles y el costo de cada una: tú eliges conscientemente, no por imitación ciega.
Lee en dos direcciones
Fila = "¿cómo resuelven el mismo problema?". Columna = "¿cuál es la firma de este proveedor?". La celda solo adquiere significado en la intersección: una respuesta aislada no dice si es buena; solo lo revela el contraste.
Problema A — cuándo rechazar
Todo prompt define un límite de comportamiento. La pregunta es cómo este límite se escribe: como un principio justificado, una regla breve, uno override estructural o una rechazo seco? Cada estilo tiene una teoría de robustez detrás.
| Proveedor | Cómo redacta el rechazo | Evidencia en el acervo |
|---|---|---|
| Anthropic principio + porqué |
Describe el principio que aplicar, no el mecanismo. Una negativa por seguridad infantil afirma la regla sin decir qué pista la activó — "narrar el límite enseña a sortearlo". | claude-fable-5.md L43–62 (refusal_handling, child_safety) |
| OpenAI regla breve + persona |
Rechazo breve y directa, con cuidado de tono: evita el lenguaje condescendiente, prohíbe frases como «vamos a respirar». La negativa es parte de la persona. | gpt-5.5-instant.md "avoid patronizing" language" (fin) |
| Google/MS estructura + procedimiento |
Rechazo como override absoluto y procedimental: «antes de clasificar, REFUSE con Texto-Padrão si...» — verificación antes de cualquier generación, con una lista de activadores. | gemini-3.1-pro.md L133–145 (Safety Refusal — Override) |
| xAI concisión con opinión |
"Si es un jailbreak, rechaza con una respuesta breve y concisa." Pocas reglas explícitas, foco en CSAM y jailbreak; el resto queda a cargo del modelo. | grok-4.3-beta.md L5, L13–14 |
Principio vs. mecánica
Anthropic y Google coinciden en un punto sutil: no narrar la regla de detección. Anthropic por filosofía ("el porqué se generaliza, la mecánica se filtra"); Google por procedimiento ("texto estándar fijo, sin explicar el desencadenante"). Caminos distintos, el mismo efecto de robustez.
Problema B — cómo citar la fuente
Cuando el modelo tiene acceso a contexto externo — archivos, e-mails, perfiles, páginas web —, surge la pregunta: ¿de dónde viene la verdad y cómo se referencia? Aquí las filosofías divergen mucho, porque cada una protege algo diferente: la integridad de la fuente, el canal downstream o la riqueza visual.
| Proveedor | Regla de fuente / cita | Evidencia en el acervo |
|---|---|---|
| Anthropic recurso, no obligación |
Trata las fuentes como características de la conversación (búsqueda web, chats anteriores, archivos) que puede activar y mencionar al usuario. Enfócate en la transparencia, no en un formato rígido de cita. | claude-fable-5.md L33 (settings/features) |
| OpenAI fuente de verdad |
Regla de precedencia explícita: NUNCA usar personal_context como verdad; SIEMPRE usar la tool dedicada (file_search, gmail, api_tool). Separa la «memoria» del «documento». |
gpt-5.5-instant.md L53–65 (Source of Truth Rules) |
| Google/MS protege el downstream |
Cita como contrato con el agente ciego: el campo prompt NUNCA puede hacer referencia a archivos (image_0.png) — solo texto extraído, porque el agente downstream no ve los archivos. |
gemini-3.1-pro.md L167, L230 (No File References) |
| xAI renderizado, no cita |
En lugar de citar, renderiza la fuente: tool render_file y componentes de renderizado integrados en la respuesta. Para web, browse con instrucciones densas y encadenamiento de URL. |
grok-4.3-beta.md L44–52, L652–658 (Render File) |
CRITICAL: No File References (Downstream Agent is Blind).
The prompt field MUST NEVER contain references to uploaded
files (e.g., image_0.png, filenames).
The downstream agent CANNOT see these files.
→ se você consegue extrair o conteúdo como texto, use o texto.
→ se não consegue, caia para "Standard Text".🔎 Qué está protegiendo cada uno
- •OpenAI protege el integridad de la verdad — no deja que la memoria se convierta en un documento.
- •Google/MS protege el canal downstream — el siguiente agente está a ciegas, así que la referencia tiene que ser autosuficiente.
- •xAI protege el experiencia visual — muestra la fuente renderizada en lugar de solo señalarla.
- •Anthropic protege el transparencia conversacional — informa al usuario sobre la función, sin formalidades de formato.
Problema C — actuar sin preguntar
El eje de la autonomía: ¿cuándo debe el modelo seguir adelante sin pedir permiso y cuándo debe detenerse y confirmar? Este es el problema que más diferencia a chatbots de agentes — y dónde la filosofía de cada proveedor se hace más visible.
| Proveedor | Política de autonomía | Evidencia en el acervo |
|---|---|---|
| Anthropic respeta al usuario |
Autonomía contenida por la voluntad del usuario: si el usuario indica que quiere terminar, Claude lo respeta y no intenta sacarle un turno más. No fuerza la continuación. | claude-fable-5.md L70 (respeta el final de la conversación) |
| OpenAI proactividad calibrada |
Usa contexto si ayuda de manera significativa: "el contexto altamente relevante no es opcional; es información que debes usar". Actúa con lo que tienes, sin preguntar lo obvio. | gpt-5.5-instant.md L8, L13 (use context that changes answer) |
| Google/MS autonomía procedimental |
El agente es responsable del alcance hasta completarlo o fallar. Ejecuta la línea base → cambia → ejecuta linters/build/pruebas para comprobar. Haz una pregunta abierta solo cuando la respuesta sea genuinamente impredecible. | vscode-copilot-agent.md L40, L98, L159, L189 |
| xAI confirma lo irreversible |
Pide confirmación para acciones costosas o ambiguas ("si parece que quiere una imagen, pregunta antes"); actúa directamente en el resto. Si el usuario corrige, reconsidera y expresa incertidumbre. | grok-4.3-beta.md L12 (corregir/incertidumbre), regla de confirmación |
✓ Autonomía bien calibrada
- ✓Actúa en lo reversible, confirma lo irreversible
- ✓Responsable del alcance «hasta completar o fallar»
- ✓Verifica tu propio trabajo (pruebas/build)
- ✓Respeta la señal de cierre del usuario
✗ Autonomía mal calibrada
- ✗Pregunta lo obvio que ya está en el contexto
- ✗Ejecuta una acción costosa sin confirmar
- ✗Se detiene a mitad de camino y devuelve un alcance incompleto
- ✗Insiste en un turno más después del "adiós"
Compensaciones reveladas
Cada celda de la matriz tiene un costo. Ninguna elección es gratuita: ganar robustez en un lado cuesta flexibilidad en otro; ganar autonomía cuesta previsibilidad. Esta es la lectura que transforma la matriz de descripción en herramienta de decisión.
Qué es un trade-off de diseño de prompts
Es el costo oculto de una regla. Un prompt basado en principios generaliza mejor, pero cuesta tokens y exige un modelo capaz de razonar sobre la intención. Un prompt basado en procedimiento es determinista y auditable, pero rígido frente a casos nuevos. La matriz muestra ese costo en cada cruce.
| Elección | Qué ganas | Qué cuesta |
|---|---|---|
| Principio + porqué Anthropic |
Generaliza a casos nuevos; rechazo robusto a los intentos de elusión; el «porqué» guía situaciones no previstas. | Más tokens; exige un modelo potente; menos auditable ("¿por qué rechazó esto?" no tiene una regla fija). |
| Regla breve + persona OpenAI |
Conciso y económico; persona coherente; fácil de mantener; bueno para un alto volumen conversacional. | La regla seca generaliza mal; depende de que la persona "sostenga" el resto; es ambigua en los casos límite. |
| Estructura + procedimiento Google/MS |
Determinista y auditable; ideal para pipelines y agentes; falla de forma predecible. | Rígido fuera del camino previsto; largo; el mantenimiento crece con cada nueva excepción. |
| Concisión + XML xAI |
Ligero y directo; delega en el modelo; estructura clara; rápido de leer y editar. | Poca cobertura explícita; el comportamiento varía más según el modelo; menos garantías. |
⚠️ El error de copiar la celda equivocada
El peligro de la matriz es tratar una celda como "la mejor práctica" y copiarla fuera de contexto. El rechazo procedimental de Gemini es excelente para un pipeline de widgets — pegar esto en un chatbot casual genera un asistente burocrático. La concisión de Grok es excelente con un modelo potente — pegarlo en un modelo débil se convierte en un comportamiento impredecible. La célula adecuada depende del producto, no del prestigio del proveedor.
Cómo armar tu propia matriz
La matriz no es un artefacto fijo: es un método. Cuando diseñes un prompt y necesites decidir un comportamiento, arma una matriz pequeña para ese problema y complétala con los proveedores que importan para tu caso. Aquí tienes el paso a paso que cierra Trilha 3.
Elige problemas universales (filas)
Enumera 2–4 decisiones de comportamiento que todo tu prompt de dominio debe incluir. Rechazo, cita y autonomía son un buen punto de partida; agrega los de tu producto (p. ej., "cómo manejar la ambigüedad", "cuándo usar markdown").
Elige proveedores relevantes (columnas)
Elige 3–5 prompts del repositorio que se parezcan a lo que quieres construir. Para un agente de código, incluye vscode-copilot-agent.md; para un chatbot, claude-fable-5.md e gpt-5.5-instant.md.
Completa cada celda con la evidencia
Cada célula es una frase + la fuente citable (arquivo.md · linha). Sin fuente, no es una matriz: es una opinión. Citar la ruta real es lo que hace que la matriz sea auditable y reutilizable.
Anota el trade-off y luego decide
Para cada opción, escribe qué ganas y qué cuesta. Solo entonces elige la celda que le sirve a tu producto — y lleva esa decisión (con el porqué) a la Trilha 4, donde construyes tu prompt.
| problema \ fornecedor | Forn. A | Forn. B |
|-----------------------|------------------|------------------|
| recusar | princípio L43 | override L133 |
| citar fonte | feature L33 | no-file-ref L230 |
| agir sem perguntar | respeita fim L70 | dono escopo L159 |
# cada célula: frase curta + arquivo.md · linha
# embaixo da matriz: 1 linha de trade-off por colunaActividad — completa la 5.ª columna
Elige un quinto proveedor del repositorio (p. ej., Perplexity/comet-browser-assistant.md o Microsoft/copilot-cli.md) y completa las tres celdas: cómo rechaza, cómo cita fuentes, cómo decide actuar. Cita la línea. Entregable: matriz 3×5 publicable.
📊 Resumen del módulo
Siguiente ruta:
Ruta 4 — Construye el tuyo: robusto y simple. Pasas de la comparación al laboratorio: prompt mínimo viable → evolución mediante diff → consolidación periódica, con versiones en git.