Mejores Prácticas de Claude Rules

Esta página destila todas las listas de reglas de la sección "Claude Rules & Best Practices" en una única lista de verificación independiente: la versión positiva y aplicable de cada regla, agrupada por categoría, diseñada para ser revisada durante una revisión de preparación para producción o una auditoría periódica del equipo.

Cómo Usar Esta Lista de Verificación

• Trabaja a través de ella por categoría, no de arriba a abajo por número: un equipo que adopta estas reglas por primera vez generalmente comienza con A y D antes de abordar el resto.
• Trata cada casilla de verificación como algo para lo que puedes señalar evidencia: un valor de configuración, una regla de linter, un comentario de revisión o un ADR, no solo una creencia.
• Úsala como una puerta de control de preparación para producción antes de que una función impulsada por Claude llegue a usuarios reales o a un presupuesto real.
• Revisa la lista completa en una cadencia fija, e inmediatamente después de cualquier incidente cuya causa raíz se remonte a una regla faltante.

A - Selección de Modelos

• Empareja el nivel del modelo con la complejidad de la tarea por defecto. La clasificación y la extracción comienzan con Haiku, el trabajo general con Sonnet, el razonamiento complejo de varios pasos con Opus, y el trabajo agéntico de horizonte largo más exigente con Fable.
• Requiere evidencia antes de escalar a un nivel superior. Un cambio de nivel está respaldado por una revisión de muestra fallida o una brecha de calidad medida, no por una corazonada.
• Reduce la escala de las rutas probadas en una cadencia regular. Cualquier ruta donde un nivel más económico haya igualado la calidad en una muestra representativa se baja y se monitorea.
• Mantén las rutas síncronas y visibles para el usuario fuera del nivel más pesado a menos que la experiencia del usuario pueda tolerar la latencia. El razonamiento pesado tolerante a la latencia se traslada al procesamiento asíncrono o por lotes.
• Documenta la decisión del nivel para cada ruta de producción. Una entrada de configuración o un comentario que nombre el modelo y la razón evita cambios silenciosos y no revisados más adelante.

B - Higiene de Prompts y Contexto

• Estructura cada prompt en secciones claramente etiquetadas. El rol, la tarea, las restricciones y el formato de salida obtienen su propio bloque en lugar de mezclarse en prosa no estructurada.
• Requiere un propietario y una razón para cada adición de prompt del sistema. Los prompts que crecen por acumulación no revisada se degradan de maneras que nadie puede rastrear hasta un cambio específico.
• Recorta el contexto de forma proactiva, no reactiva. Los resultados de herramientas obsoletos y los turnos reemplazados se descartan antes de que degraden la calidad de la respuesta, no después de que un usuario note que algo está mal.
• Mantén el formato de salida consistente para el mismo tipo de tarea en cada sitio de llamada. Un analizador escrito para una ruta debe funcionar para todas las rutas que producen ese mismo tipo de salida.
• Elimina instrucciones que nadie puede justificar actualmente. Si nadie en el equipo puede explicar por qué una línea está en el prompt del sistema, eso es una señal para probar su eliminación, no para dejarla indefinidamente.

C - Diseño de Herramientas

• Limita cada herramienta a exactamente una acción bien definida. Una herramienta que realiza varias cosas no relacionadas se divide hasta que cada pieza pueda ser razonada y autorizada de forma independiente.
• Nombra las herramientas por lo que hacen, no por cómo están implementadas. La nomenclatura se mantiene consistente en el conjunto de herramientas para que la selección de herramientas del modelo sea predecible.
• Valida las entradas y salidas de las herramientas por separado, tanto antes de que crucen un límite de confianza. Una entrada incorrecta llega a sistemas reales; una salida incorrecta corrompe el siguiente turno del modelo; ambos necesitan su propia verificación.
• Controla las llamadas a herramientas destructivas o irreversibles con confirmación. Las eliminaciones, pagos y escrituras en producción nunca se ejecutan automáticamente sin un paso humano o una excepción revisada.
• Revisa todo el conjunto de herramientas en busca de propósitos superpuestos, no solo cada herramienta individualmente. La ambigüedad entre dos herramientas que pueden realizar una tarea se resuelve antes de que cause un comportamiento inconsistente en producción.

D - Control de Costos

• Almacena en caché prefijos de prompt estables detrás de un punto de interrupción. Los prompts del sistema y las definiciones de herramientas que no varían por solicitud se posicionan para que puedan ser reutilizados.
• Dirige el trabajo masivo no sensible a la latencia a través de la API de Batches. Los precios en tiempo real se reservan para las solicitudes que realmente necesitan una respuesta síncrona.
• Establece un presupuesto de tokens rastreado y con alertas por equipo. Cada equipo que consume la API de Claude tiene un techo de gasto sobre el cual alguien recibe una notificación antes de excederlo, no después de que llega la factura.
• Mide el uso real de tokens frente a las estimaciones previas a la llamada. Las suposiciones de costos se verifican con los campos usage con suficiente regularidad para detectar desviaciones mientras aún son pequeñas.
• Reevalúa las palancas de costos cada vez que cambia la línea de modelos. Una estrategia de caché o de lotes ajustada para una generación de modelos se vuelve a verificar contra la siguiente.

E - Barreras de Seguridad

• Aplica el mínimo privilegio a cada credencial a la que un sistema impulsado por Claude pueda acceder. Ninguna herramienta, servidor MCP o integración tiene un acceso más amplio del que su tarea requiere estrictamente.
• Trata la salida del modelo como entrada no confiable en todas partes donde toca un sistema real. El texto generado y los argumentos de las herramientas se validan y parametrizan, nunca se interpolan directamente en un comando, consulta o ruta.
• Registra cada llamada a herramienta sensible independientemente de la transcripción de la conversación. Las llamadas destructivas o que tocan datos tienen un rastro de auditoría que sobrevive incluso si la transcripción se edita, trunca o se pierde.
• Mantén los secretos fuera de los prompts, mensajes del sistema y archivos de memoria por completo. Las credenciales viven en una bóveda o variable de entorno, nunca en texto que el modelo pueda leer.
• Aísla el contenido externo no confiable de las instrucciones a nivel de operador. Los documentos recuperados y el contenido web se separan estructuralmente de la autoridad a nivel del sistema para que una instrucción incrustada no pueda hacerse pasar por uno.

F - Gobernanza y Práctica de Equipo

• Asigna un propietario explícito para las reglas de Claude del equipo. Las reglas se degradan en inconsistencia en el momento en que nadie es responsable de mantenerlas actualizadas.
• Convierte la causa raíz de cada incidente en una regla, no solo en una solución única. Un error que no se captura como una regla aplicable tiende a repetirse en un sitio de llamada diferente escrito por un ingeniero diferente.
• Revisa los conjuntos de reglas en una cadencia fija, no solo después de que algo se rompa. Una revisión trimestral detecta reglas que se han vuelto obsoletas a medida que cambia la línea de modelos o el producto.
• Haz que las desviaciones de una regla sean una excepción explícita y revisada. Un valor predeterminado que se anula silenciosamente en un lugar es una deriva en la toma de decisiones; un valor predeterminado que se anula deliberadamente con una razón documentada es una decisión juiciosa.
• Mantén el conjunto de reglas lo suficientemente pequeño como para que el equipo pueda tenerlo en mente. Un conjunto de reglas demasiado grande para recordarlo se ignora, lo que es funcionalmente lo mismo que no tener reglas en absoluto.

Preguntas Frecuentes

Relacionados

• Cómo las Reglas de Opinión Previenen Incidentes de Producción de Claude - el modelo mental detrás de por qué cada elemento de esta página está escrito como una regla aplicable.
• Las Reglas Centrales de Claude: Una Lista de Referencia Rápida - el mismo conjunto de reglas organizado por categoría con enlaces a detalles completos.
• Reglas de Barreras de Seguridad que Todo Tech Lead Debería Aplicar - el detalle completo detrás de la categoría E.
• Reglas de Control de Costos: Caché, Lotes y Disciplina de Presupuesto de Tokens - el detalle completo detrás de la categoría D.

Versiones de Stack: Escrito contra la línea de modelos de Claude actual a partir de ~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 de SDK cambian rápidamente: verifique los detalles actuales en platform.claude.com/docs antes de confiar en ellos.