La Lista de Reglas Esenciales de Claude: Referencia Rápida
Esta página condensa todas las reglas aplicables que este sitio destila para lanzar Claude en producción —selección de modelos, higiene de prompts y contexto, diseño de herramientas, control de costos y barreras de seguridad— en una sola página que puedes escanear durante una revisión de código o una retrospectiva de incidentes.
Intencionalmente no tiene explicaciones largas.
Cada fila enlaza al artículo que cubre el razonamiento completo, ejemplos y casos límite.
Cómo Usar Esta Lista
- Mantén esta página abierta durante la revisión de pull requests para cualquier código que llame a la API de Claude.
- Trata cada regla como un valor predeterminado, no como una regla absoluta; las desviaciones deben ser una excepción deliberada y revisada, no una silenciosa.
- Vuelve a visitar esta página cada vez que la línea de modelos cambie (nuevo lanzamiento de Opus, Sonnet, Haiku o Fable); varias reglas son específicas del nivel del modelo.
- Usa las tablas de categorías para incorporar a un nuevo ingeniero a las convenciones de Claude del equipo en una sola sesión.
- Empareja esta página con Mejores Prácticas de Reglas de Claude, que reitera cada regla aquí como un elemento de checklist aplicable.
Reglas de Selección de Modelos
| Regla | Predeterminado | Detalle completo |
|---|---|---|
| Empareja el nivel del modelo con la complejidad de la tarea | Haiku para clasificación/extracción, Sonnet para trabajo general, Opus para razonamiento complejo de múltiples pasos, Fable para el trabajo agéntico más exigente de largo alcance | Reglas de Selección de Modelos |
| Nunca uses el modelo más capaz por defecto "para estar seguro" | Comienza con el nivel más barato que cumpla el estándar de calidad, escala solo con evidencia | Reglas de Selección de Modelos |
| Reevalúa la elección del nivel en cada lanzamiento de modelo | Una regla fijada a un perfil de costo/latencia antiguo de un modelo puede quedar obsoleta de la noche a la mañana | Reglas de Selección de Modelos |
| Dirige las rutas sensibles a la latencia lejos del nivel más pesado | Opus y Fable intercambian latencia por profundidad; no los pongas en una ruta síncrona orientada al usuario sin una razón | Reglas de Selección de Modelos |
Reglas de Higiene de Prompts y Contexto
| Regla | Predeterminado | Detalle completo |
|---|---|---|
| Estructura los prompts con secciones explícitas | El rol, la tarea, las restricciones y el formato de salida obtienen su propio bloque claramente etiquetado | Reglas de Higiene de Prompts y Contexto |
| Mantén los prompts del sistema como solo de adición en la revisión, no como solo de adición en la práctica | Cada adición necesita un propietario con nombre y una razón; elimina instrucciones que nadie pueda justificar más | Reglas de Higiene de Prompts y Contexto |
| Recorta el contexto antes de cada solicitud, no después de que se rompa | Descarta resultados de herramientas obsoletos y turnos reemplazados en lugar de permitir que la transcripción crezca sin límites | Reglas de Higiene de Prompts y Contexto |
| Mantén el formato de salida consistente en todos los sitios de llamada | El mismo tipo de tarea debe producir una salida analizable de la misma manera en todas partes donde se solicite | Reglas de Higiene de Prompts y Contexto |
Reglas de Diseño de Herramientas
| Regla | Predeterminado | Detalle completo |
|---|---|---|
| Limita el alcance de las herramientas | Una herramienta, una acción bien definida; no una herramienta de propósito general "haz cualquier cosa" | Reglas de Diseño de Herramientas |
| Nombra las herramientas por lo que hacen, no por cómo se implementan | refund_order, no call_billing_endpoint | Reglas de Diseño de Herramientas |
| Valida cada entrada de herramienta antes de que se ejecute | Nunca confíes en los argumentos del modelo como si estuvieran pre-sanitizados | Reglas de Diseño de Herramientas |
| Valida cada salida de herramienta antes de que vuelva a entrar en el contexto | Un resultado malformado o inesperadamente grande debe ser capturado, no pasado silenciosamente de vuelta al modelo | Reglas de Diseño de Herramientas |
| Bloquea las llamadas a herramientas destructivas o irreversibles detrás de una confirmación | Las eliminaciones, pagos y escrituras en producción nunca son "dispara y olvida" | Reglas de Diseño de Herramientas |
Reglas de Control de Costos
| Regla | Predeterminado | Detalle completo |
|---|---|---|
| Almacena en caché prefijos de prompt estables | Los prompts del sistema y las definiciones de herramientas que no cambian por solicitud pertenecen detrás de un punto de interrupción de caché | Reglas de Control de Costos |
| Agrupa solicitudes no sensibles a la latencia | Usa la API de Batches para trabajo masivo en lugar de pagar precios en tiempo real | Reglas de Control de Costos |
| Establece un presupuesto de tokens por equipo | Cada equipo que consume la API de Claude recibe un techo de gasto rastreable y con alertas | Reglas de Control de Costos |
| Mide el uso real de tokens, no lo estimates | Compara los campos usage con las estimaciones previas a la llamada para detectar desviaciones temprano | Reglas de Control de Costos |
Reglas de Barreras de Seguridad
| Regla | Predeterminado | Detalle completo |
|---|---|---|
| Limita estrictamente los permisos de la API y las herramientas | El mínimo privilegio se aplica a cada credencial a la que un sistema impulsado por Claude pueda acceder | Reglas de Barreras de Seguridad |
| Valida la salida del modelo antes de actuar sobre ella | Trata el texto generado y los argumentos de las herramientas como entrada no confiable, no como una instrucción confiable | Reglas de Barreras de Seguridad |
| Registra cada llamada a herramienta sensible | Las llamadas destructivas o que tocan datos necesitan una pista de auditoría independiente de la transcripción de la conversación | Reglas de Barreras de Seguridad |
| Nunca coloques secretos en un prompt o archivo de memoria | Las credenciales pertenecen a una bóveda o variable de entorno, nunca en texto que el modelo pueda leer | Reglas de Barreras de Seguridad |
Preguntas Frecuentes
¿Es esta página un reemplazo de los artículos completos sobre reglas?
No. Es una ayuda para escanear; cada fila existe para recordarte que una regla existe y dirigirte al artículo con el razonamiento completo, ejemplos y excepciones.
¿Por qué esta página sustituye a una página de conceptos básicos de la sección?
Dado que esta sección es una guía de reglas/listas de verificación en lugar de una sección tutorial, una referencia condensada única cumple el rol que tendría una introducción de "conceptos básicos" en una sección de guías de código; es la página en la que un lector aterriza primero para orientarse.
¿Qué categoría de reglas debería leer primero un nuevo equipo?
Reglas de Selección de Modelos, porque la elección del nivel del modelo afecta el perfil de costo y latencia de cada una de las otras decisiones en esta página. Reglas de Control de Costos es la siguiente parada natural.
¿Con qué frecuencia se debe revisitar esta página?
Como mínimo, cada vez que cambie la línea de modelos, y cada vez que una revisión de incidentes revele una regla que esta página no tiene o tiene incorrecta.
¿Son estas reglas obligatorias o predeterminadas?
Predeterminadas. Cada fila puede ser anulada con una razón deliberada y revisada; el punto es que las desviaciones sean decisiones explícitas, no accidentes.
¿Cuál es la diferencia entre esta página y las Mejores Prácticas de Reglas de Claude?
Esta página agrupa las reglas por categoría con una línea predeterminada y un enlace. Mejores Prácticas de Reglas de Claude reitera cada regla como un elemento de casilla de verificación independiente que puedes marcar durante la revisión, sin necesidad de la agrupación por categoría.
¿Por qué la validación de entrada de herramientas se lista por separado de la validación de salida de herramientas?
Porque fallan de manera diferente. La entrada no validada permite que un argumento malformado o malicioso llegue a tus sistemas; la salida no validada permite que un mal resultado de herramienta corrompa silenciosamente el siguiente turno del modelo. Ambas necesitan una verificación, y confundirlas tiende a significar que solo una se construye.
¿"Limitar el alcance de las herramientas" entra en conflicto con dar a un agente suficiente capacidad para ser útil?
No; un alcance limitado significa que cada herramienta individual hace una cosa bien definida, no que el agente tenga pocas herramientas en general. Un agente con diez herramientas limitadas es más seguro y más fácil de depurar que uno con dos herramientas amplias que hacen varias cosas no relacionadas.
¿Por qué el control de costos incluye una regla sobre la medición del uso real?
Porque un modelo de costos que nunca se compara con los campos usage reales se desvía silenciosamente; el almacenamiento en caché, la agrupación y los presupuestos asumen que puedes saber cuándo dejan de funcionar, y la única forma de saberlo es midiendo.
¿Vale la pena el almacenamiento en caché de prompts para cada solicitud?
No; solo compensa cuando un prefijo estable se reutiliza en suficientes solicitudes para compensar el costo de escritura en caché. Consulta Reglas de Control de Costos para las matemáticas del punto de equilibrio.
¿Qué cuenta como una llamada a herramienta "sensible" que necesita registro?
Cualquier cosa que lea o escriba datos fuera de la propia conversación: escrituras en bases de datos, pagos, correos electrónicos enviados, archivos eliminados, o cualquier llamada a un sistema con sus propios requisitos de auditoría. Consulta Reglas de Barreras de Seguridad para la lista completa.
¿Debería esta página ser el único documento de reglas que mantenga un equipo?
Es un punto de partida, no un techo. Los equipos con riesgos específicos de dominio (datos regulados, transacciones financieras) deberían extender estas categorías con sus propias reglas en lugar de tratar esta lista como exhaustiva.
Relacionado
- Cómo las Reglas Opinadas Previenen Incidentes de Producción de Claude - el razonamiento detrás de por qué esta página existe en forma condensada.
- Reglas de Selección de Modelos: Cuándo Usar Opus, Sonnet o Haiku - el conjunto completo de reglas de selección de modelos.
- Reglas de Control de Costos: Almacenamiento en Caché, Agrupación y Disciplina de Presupuesto de Tokens - el conjunto completo de reglas de control de costos.
- Mejores Prácticas de Reglas de Claude - las mismas reglas reiteradas como una lista de verificación independiente.
Versiones de Stack: Escrito contra la línea de modelos de Claude actual a ~junio de 2026 — Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 — y el SDK oficial de Python
anthropic(última versión 0.x). Los nombres de modelos, precios y versiones del SDK cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs antes de confiar en ellos.