30 técnicas prácticas de formulación de prompts para Claude basadas en su uso diario real
Un análisis probado en el terreno de 30 técnicas de inducción para Claude, organizadas según lo que realmente logran, desde instrucciones claras hasta sistemas completos de prompts.
Innumerables guías de “ingeniería de prompts” se marcan como favoritas y nunca se vuelven a consultar. Demasiadas parecen haber sido escritas por alguien que envió dos prompts, tomó una captura de pantalla y la declaró como metodología.
Lo que sigue es diferente principalmente por su origen: meses de interacciones diarias, a veces tediosas, con Claude, utilizadas en proyectos paralelos y trabajos de escritura independiente, con una buena cantidad de pruebas y errores para determinar qué “mejores prácticas” comúnmente repetidas realmente resisten el contacto con el trabajo real.
Algunas de las técnicas que se describen a continuación transforman realmente la forma en que los desarrolladores abordan la creación de prompts. Unas pocas fueron probadas, rechazadas, pero se mantuvieron porque siguen resolviendo bien problemas específicos. Y un par que parecen trucos resultan ser algunas de las entradas más valiosas de toda esta lista. Cada sección indica en qué categoría se encuentra.
Estos se organizan en cuatro grupos según lo que realmente logra cada técnica, y no según cuán sofisticada suene en teoría:
Part 1 — Say What You Mean (clarity & structure)
Part 2 — Put Up Guardrails (constraints & format control)
Part 3 — Make It Reason Out Loud (thinking & iteration)
Part 4 — Build a System, Not a Prompt (workflows & long context)
Parte 1: Expresa con claridad lo que quieres
1. Sé explícito, no vago
Este sigue siendo uno de los errores más comunes que cometen las personas al redactar instrucciones. Pedir “mejora esto” te da algo genérico e insignificante. Pedir “reescribe este párrafo para que un fundador no técnico pueda comprender las ventajas y desventajas en dos oraciones” te da algo útil.
Una regla práctica: si tardaste menos de 10 segundos en escribir la instrucción, probablemente no fue lo suficientemente específica.
2. Utiliza etiquetas estructurales para separar las partes de tu instrucción
Las etiquetas de estilo XML merecen usarse constantemente, no porque se afirme que es el “idioma nativo” de Claude (una afirmación difícil de verificar y que debe tratarse con escepticismo cuando se hace con total confianza), sino porque las etiquetas resuelven un problema real y práctico: cuando las instrucciones, el contexto de fondo y los ejemplos se mezclan en un mismo bloque de texto, el modelo debe adivinar dónde comienza y termina cada sección. Las etiquetas eliminan por completo esa necesidad de adivinar.
<instructions>
Summarize the risks section only. Ignore financial projections.
</instructions>
<context>
[pasted document]
</context>
<output_format>
3 bullet points, no more than 15 words each
</output_format>
3. Primero el contexto, luego la pregunta
Este orden es más importante de lo que parece a primera vista. Pegar un documento extenso y luego hacer una pregunta tiende a generar respuestas notablemente peores que hacer la pregunta después de que todo el material haya sido presentado. Una explicación plausible, aunque no verificada científicamente, es que este orden impide que el modelo intente formular una respuesta antes de haber terminado realmente de leer todo.
[long document]
---
Based on everything above, what's the single biggest
risk to the Q3 timeline?
4. Muestre, no solo describa (ejemplos de pocos casos)
Los adjetivos descriptivos son económicos pero a menudo vagos. Un solo ejemplo concreto del tono, estructura o formato deseado sirve más que todo un párrafo de descripción. Para tareas recurrentes —correos electrónicos a clientes, comentarios sobre revisiones de código y rutinas similares— es útil guardar dos o tres ejemplos “de estándar de oro” en un archivo de notas, listos para pegarse cada vez que surja el mismo tipo de tarea.
5. Explica el porqué, no solo la regla
Esta es una de las técnicas más sorprendentes de esta lista. Técnicamente funciona decirle a Claude “mantén esto por debajo de 280 caracteres”. Pero indicarle que “esto irá directamente a un tuit y todo lo que supere los 280 caracteres se cortará a mitad de frase” genera un resultado claramente más cuidadoso. Es como si dar una razón hiciera que el modelo considere esa restricción durante toda la respuesta, en lugar de solo contar los caracteres al final.
6. Permitir explícitamente la respuesta “No lo sé”
Hay una línea que vale la pena añadir a casi todas las solicitudes de investigación o análisis:
If the available information isn't enough to draw a
conclusion, say so directly instead of guessing.
Si se omite esta línea, existe un riesgo real de obtener respuestas sin sentido que suenan convincentes. Si se incluye, a veces la respuesta es “no hay suficiente información aquí para afirmarlo con certeza”, lo cual resulta insatisfactorio en el momento, pero es mejor que descubrir un hecho fabricado horas después.
7. Especifique el formato de salida, no lo asuma
Hay una diferencia real entre pedir “una tabla” y pedir “una tabla de texto plano formateada de modo que se pegue correctamente en un bloque de código, ya que Medium tiende a dañar las tablas Markdown”. Detallar exactamente cómo debe ser la respuesta evita por completo esa discrepancia.
8. Defina cómo se ve algo “terminado”, no solo la tarea
En lugar de describir la tarea en sí, describir cómo sería un resultado exitoso suele producir resultados más precisos:
I need a competitor comparison so my co-founder can
pick a pricing tier in under 5 minutes without asking
me follow-up questions.
Esa sola oración tiene más peso que tres párrafos llenos de reglas de formato.
Parte 2 — Establecer límites
9. Restricciones negativas: indique qué NO debe hacer
A veces es más rápido definir el objetivo excluyendo lo que no se desea en lugar de intentar especificar con exactitud qué sí se quiere:
Do not sound like: a LinkedIn thought-leader post.
Do not include: "in today's fast-paced world," filler
caveats, or a summary that repeats the intro.
10. Una instrucción de sistema al estilo de “contrato”
Para todo lo que planea reutilizar, redacte la instrucción de sistema como un breve contrato legal en lugar de un boceto del carácter:
Role: technical editor for a solo dev's blog
Goal: tighten prose without changing meaning
Constraints:
- keep first-person voice
- no invented statistics
- flag anything that sounds AI-generated
If unsure: ask one clarifying question, don't guess
Output: plain markdown, no headers added
11. Omita el teatro de “actuar como un experto senior”
Esta es una técnica que vale la pena abandonar. Instruir a Claude para que “actúe como un ingeniero con 20 años de experiencia” no parece cambiar mucho cuando las instrucciones ya son precisas. La definición del personaje tiene mucho menos peso que las restricciones reales que se proporcionan. Recurrir a un rol para compensar la falta de detalles suele ser una señal de que las instrucciones en sí necesitan ser perfeccionadas.
12. Autoevaluación según una rúbrica
En lugar de decir genéricamente “revise su trabajo”, entregue una rúbrica de calificación real y exija una puntuación autoevaluada antes del resultado final:
Score your draft 1-10 on: technical accuracy, whether
a beginner could follow it, and whether it sounds
like a real person wrote it. Then revise based on
your own score. Show only the revised version.
Este enfoque ha detectado errores reales en las explicaciones de código y los resúmenes de datos en más de una ocasión.
13. Seleccione documentos largos en lugar de incluir todo
Incluir más material no mejora automáticamente la respuesta. Pegar todo un código o un PDF extenso sin ningún tipo de filtrado previo tiende a generar respuestas que solo examinan la parte central del documento y se centran en las secciones de inicio y final. Un enfoque mejor es que Claude extraiga primero los pasajes relevantes y luego analice únicamente esos —una versión a pequeña escala de un pipeline de recuperar y luego razonar:
Step 1: extract the 5 passages most relevant to
[my question], quoting them exactly.
Step 2: analyze only those passages.
14. Etiquetar múltiples documentos al comparar fuentes
Al comparar más de una fuente, etiquete y numere cada una explícitamente en lugar de simplemente separarlas con líneas en blanco. Este pequeño ajuste reduce notablemente la posibilidad de que el modelo asocie una afirmación con el documento incorrecto.
<document index="1" name="Q3_report.pdf">...</document>
<document index="2" name="Q2_report.pdf">...</document>
15. Límites estrictos para la salida estructurada
Cuando se requiere JSON estricto o un esquema específico, indíquelo directamente y enumere las claves exactas, en lugar de describir la estructura de forma vaga con la esperanza de que el modelo lo infiera correctamente:
Return only a JSON object with keys: title, summary,
confidence (0-1), open_questions (array of strings).
No text before or after the JSON.
Parte 3 — Hacer que razone en voz alta
16. Solicitar un razonamiento paso a paso para cualquier tarea no trivial
Añadir una instrucción que pida al modelo abordar el problema por etapas antes de dar una respuesta final, y señalar cualquier caso límite en el proceso, requiere más esfuerzo del que parece. Esto vale la pena aplicarlo a cualquier tarea que involucre matemáticas, lógica de múltiples pasos o decisiones que impliquen trade-offs. Omitirlo en tareas que parecen “obviamente simples” es precisamente cuando suelen surgir errores.
17. Enlazar prompts en lugar de hacer una sola solicitud extensa
Es tentador agrupar todo en una sola solicitud: leer esto, resumirlo, convertirlo en publicaciones para redes sociales y sugerir un título. Dividirlo en solicitudes secuenciales da mejores resultados en cada etapa, ya que cada paso individual solo necesita manejar bien una tarea:
[1] extract key facts
|
v
[2] turn facts into a 3-paragraph summary
|
v
[3] turn summary into 5 short takeaways
18. Brainstorming inverso para decisiones estancadas
Inicialmente esta técnica parecía ser un truco, pero resultó ser realmente útil. En lugar de preguntar directamente cómo hacer que un lanzamiento tenga éxito, comience pidiendo lo opuesto:
Brainstorm 10 ways this launch could fail. For each
one, invert it into a concrete thing we'd do
differently. Flag the 3 inversions that are the least
obvious.
Este enfoque revela puntos ciegos que una solicitud directa de “dame una estrategia” tiende a pasar por alto.
19. Debate con múltiples personalidades para decisiones con verdaderos compromisos
Puede que esta sea la técnica más efectiva de la lista. Para decisiones que involucran incentivos contradictorios, pida a Claude que argumente el asunto desde varios puntos de vista distintos antes de sintetizar todo en una recomendación:
Optimist Skeptic End user
"ship faster" "watch runway" "don't care
| | about our
v v problems"
\ | /
\ | /
\ | /
v v v
synthesized recommendation
Una solicitud simple como “dame tu recomendación” tiende a optar por la respuesta que suene más aceptable. Forzar primero un debate interno genera un resultado con argumentos más claros y defendibles.
20. Auto-crítica y revisión, en la misma solicitud
Esto se basa en la idea de las pautas mencionadas anteriormente, pero de forma más sencilla: solicite un borrador inicial, una auto-crítica de ese borrador y una versión final revisada, todo en una sola solicitud en lugar de múltiples intercambios:
Draft 1 -> list 3 weaknesses in Draft 1 -> Draft 2
21. Deje que haga preguntas de aclaración antes de comenzar el trabajo
En caso de algo ambiguo o con consecuencias importantes, indique explícitamente al modelo que no comience aún y que haga las preguntas necesarias antes. Esto genera un breve retraso antes de la primera respuesta real, pero suele evitar tener que volver a trabajar en todo desde cero más tarde.
22. Meta-prompting: hacer que mejore su prompt
Esta es una técnica poco utilizada. Cuando un prompt sigue generando resultados mediocres, en lugar de reescribirlo usted mismo, pregunte directamente:
Here's the prompt I've been using: [paste]. Here's the
output it produces: [paste]. What's wrong with the
prompt, and rewrite it.
Esto suele revelar formulaciones vagas que no habría podido detectar por sí mismo, sobre todo porque ya sabe lo que quería decir y pasa por alto la ambigüedad.
23. Trátelo como una conversación, no como un prompt perfecto único
Este es el cambio de mentalidad más importante aquí, y se trata menos de una técnica que de abandonar un mal hábito: deja de buscar ese prompt perfecto. Pide una versión inicial aproximada, reacciona a ella y perfecciona desde allí. Tratar de incluir todos los requisitos en un único prompt enorme siempre da resultados peores que unas pocas rondas cortas de iteración y retroalimentación.
Parte 4 — Construye un sistema, no un prompt
24. Utiliza archivos de reglas persistentes en lugar de repetirte
Puede que este sea el cambio de hábito más valioso de todos. En lugar de volver a escribir el tono, el público y las restricciones en cada prompt nuevo, guárdalos en un archivo independiente rules.md:
# Writing rules
- tone: direct, no fluff
- audience: builders, not consumers
- never use: "leverage", "in today's world"
- always: specific numbers, source links, one action item
- format: short paragraphs, 3 sentences max
Luego, al inicio de cada sesión, haz referencia a él: “Lee completamente rules.md antes de comenzar. Si estás a punto de violar una de estas reglas, detente y dímelo en su lugar.”
Esto transforma el proceso de generación de instrucciones, que antes consistía en hacer algo nuevo cada vez, en la configuración de una herramienta pequeña y persistente. Es la diferencia entre librar la misma batalla a diario y resolverla una sola vez.
25. Hacer explícito el ciclo de planificar, actuar, verificar e iterar
En tareas que requieren acción automática —tareas de múltiples pasos en las que Claude llama a herramientas, edita archivos o ejecuta comandos— no asuma que el modelo estructurará el proceso por sí solo. Describa directamente este ciclo:
┌─────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ PLAN │ -> │ ACT │ -> │ VERIFY │ -> │ ITERATE│
│ max 5 │ │ use │ │ against│ │ or │
│ steps │ │ tools │ │criteria│ │ done │
└─────────┘ └────────┘ └────────┘ └────────┘
| fail
v
back to ACT
La instrucción que ha evitado la mayoría de los errores silenciosos y en cascada es sencilla: solo pase al siguiente paso una vez que el actual haya superado la verificación.
26. Basar las afirmaciones en hechos recuperados y no en la memoria
Para cualquier información factual, indique explícitamente al modelo que consulte el material que tiene delante en lugar de recurrir a su entrenamiento. Pedirle que “cite la línea o sección específica de donde proviene” convierte una respuesta que suena plausible en una que realmente se puede verificar. Si no puede señalar una fuente, considérelo una señal para hacer una pausa y verificarlo manualmente.
27. Incluir puntos de control humanos antes de acciones irreversibles
Cualquier tarea que envíe un correo electrónico, guarde código o gaste dinero debe incluir una pausa explícita: “deténgase antes de la acción final y muéstreme qué está a punto de hacer”. Ningún sistema — ni ninguna confianza en su propio juicio, por más tarde que sea la noche — es lo suficientemente fiable como para omitir este paso.
28. Reconocer cuándo un prompt extenso no es el enfoque adecuado
Las ventanas de contexto grandes hacen que sea tentador incluir todo el documento con la esperanza de obtener buenos resultados. A veces eso funciona bien, pero con frecuencia un prompt más corto y seleccionado a mano que contenga solo los tres párrafos relevantes rinde mejor que introducir todo el documento, ya que no se obliga al modelo a clasificar y analizar al mismo tiempo. Lo más adecuado es seleccionar primero la información a introducir, y recurrir a pegar todo solo cuando realmente no se sabe qué es relevante.
29. Controla las versiones de tus prompts de la misma manera que controlas las versiones del código
Cuando un prompt se utiliza para tareas reales y recurrentes —como generar informes regulares, entregables para clientes o cualquier actividad continua— guárdalo en un archivo con una marca de fecha y una breve entrada de registro de cambios. Esto puede parecer excesivo hasta que un “pequeño ajuste” rompa silenciosamente un comportamiento del cual dependías, y no tengas registro de cómo era ese prompt la semana anterior.
30. Ejecute el flujo de trabajo localmente cuando prefiera evitar costos por token o mantener los datos fuera de servidores externos
Ninguna de estas técnicas requiere necesariamente una API alojada. Para cualquier cosa en la que vaya a iterar repetidamente —como probar una rúbrica de autoevaluación o el ciclo planear/actuar/verificar descrito anteriormente— suele ser sensato crear un prototipo primero con un modelo local mediante Ollama, y luego transferir el prompt final a Claude para la pasada final. De esta manera, las iteraciones son más económicas y nada sale de su equipo mientras sigue dando forma al prompt.
Versión alojada, para una prueba rápida con la API de Claude:
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 500,
"messages": [{"role": "user", "content": "Score this draft 1-10 on clarity, then revise it: [paste draft]"}]
}'
Equivalente local autoalojado con Ollama, sin clave de API ni cargos por token:
# one-time setup
docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama pull llama3.1
# same self-evaluation prompt, run locally
curl http://localhost:11434/api/generate -d '{
"model": "llama3.1",
"prompt": "Score this draft 1-10 on clarity, then revise it: [paste draft]",
"stream": false
}'
Un modelo local no podrá igualar la sutileza de Claude, pero para iterar sobre la estructura de los prompts —verificar si una rúbrica está bien formada o si realmente se respetan las restricciones— es más que suficiente, y no cuesta nada una vez que está configurado.
Referencia rápida: esfuerzo vs. beneficio
Aquí hay una clasificación aproximada basada en las técnicas que realmente mejoraron la calidad de los resultados y aquellas que solo sonaban impresionantes:
TECHNIQUE EFFORT TO ADOPT PAYOFF
---------------------------------- ---------------- --------
Rules/context file (#24) low very high
Multi-persona debate (#19) low high
Plan-act-verify loop (#25) medium high
Prompt chaining (#17) low high
Permission to say "I don't know"(#6) trivial high
Explain the "why" (#5) trivial high
Reverse brainstorming (#18) low medium-high
Contract system prompt (#10) medium medium
"Act as an expert" persona (#11) trivial low
Si solo va a llevarse una cosa de esta lista, concéntrese en la fila de bajo esfuerzo y alto beneficio: adjunte una razón a sus restricciones y déle explícitamente al modelo permiso para decir que no lo sabe. Esas dos pequeñas adiciones han resuelto silenciosamente más resultados defectuosos que cualquier marco estructural elaborado.
Y si no está de acuerdo con alguna parte de esta clasificación, o ha descubierto que una de estas técnicas en realidad perjudica su caso de uso específico, ese tipo de contrejemplo es mucho más útil que otro artículo genérico sobre “prompts que cambiarán su vida”.
Lecturas relacionadas
- Un plan práctico para escribir un archivo CLAUDE.md efectivo — Aprenda 21 reglas concretas y verificables para reducir el tamaño de un archivo CLAUDE.md excesivo, de modo que Claude Code siga siendo fiable, predecible y fácil de confiar en sesiones prolongadas.