Guía de Prompts
Cómo pedirle a Claude que escriba un procedimiento operativo estándar
Un buen POE permite que alguien que nunca ha hecho la tarea la haga correctamente al primer intento.
Claude, de Anthropic, es bueno convirtiendo un proceso que ya sabes hacer en un procedimiento operativo estándar que alguien desconocido pueda seguir realmente: pasos numerados, puntos de parada claros y las excepciones que hacen tropezar a la gente. No es bueno conociendo las partes de tu proceso que solo existen en tu cabeza, las excepciones que nunca has escrito, o las herramientas y nombres específicos que tu equipo usa realmente, a menos que le des esos detalles. La solución es guiar a Claude a través del proceso real como lo explicarías a un nuevo empleado parado a tu lado, no la versión depurada que describirías si alguien te preguntara qué haces en una frase.
Para pedirle a Claude que escriba un procedimiento operativo estándar, describe el proceso paso a paso tal como lo haces realmente, incluyendo las herramientas, sistemas y nombres exactos involucrados, y pídele a Claude que lo formatee como pasos numerados con un punto de inicio y fin claros. Señala cualquier excepción, error común o punto de decisión donde el siguiente paso dependa de una condición, y pídele a Claude que marque cualquier paso donde haya tenido que adivinar un detalle porque no lo especificaste. Lee el borrador contra el proceso real una vez, idealmente mientras haces la tarea, antes de tratarlo como definitivo.
Publicado
Lección gratis · sin crear cuentaConoce a Claude¿Por qué Claude?6 minEmpezar la lección gratisPuntos clave
- Describe el proceso tal como lo haces realmente, no la versión resumida y depurada. Los pasos que te saltas porque son automáticos para ti son exactamente los pasos que un nuevo empleado necesita por escrito.
- Dale a Claude los nombres reales: la herramienta específica, el campo exacto, el sistema donde se inicia sesión. Un paso que dice "actualiza el sistema" es inútil para alguien que no sabe ya cuál sistema.
- Señala los puntos de decisión explícitamente. Un proceso con una bifurcación, "si la solicitud es menor a 500 dólares, haz X; si no, haz Y", necesita esa bifurcación expresada, no solo implícita por un contexto que solo tú tienes.
- Pide un punto de inicio y fin claros. Un POE que no dice cuándo empieza la tarea y cuándo realmente termina deja al lector adivinando si ha terminado.
- Recorre el borrador mientras haces la tarea una vez antes de publicarlo. Un POE que se ve bien en pantalla pero se salta un paso solo se vuelve evidente cuando alguien realmente intenta seguirlo en orden.
- Separa el camino normal de las excepciones. Enterrar un caso excepcional en medio de los pasos principales hace que el caso común sea más difícil de seguir el noventa por ciento del tiempo en que la excepción no aplica.
Copiar y pegar
Prompts que puedes usar hoy
Un primer borrador a partir de un recorrido del proceso
Voy a describir cómo hago [tarea] paso a paso, incluyendo las herramientas y sistemas exactos involucrados. [Recorre el proceso con el mayor detalle posible, incluyendo nombres de herramientas, nombres de campos y todo lo que verificas en el camino]. Convierte esto en un POE numerado con un punto de inicio claro y un punto claro donde la tarea está terminada. Marca cualquier paso donde hayas tenido que adivinar un detalle porque no lo especifiqué.
Describe el proceso tal como realmente lo haces, incluyendo las pequeñas comprobaciones habituales que normalmente no mencionas en voz alta; esos suelen ser los pasos que le falta a un nuevo empleado.
Añadir un punto de decisión del que dependen los pasos
Aquí está mi borrador de POE: [pega tu borrador]. El paso 4 en realidad se bifurca dependiendo de una condición: si [condición], el siguiente paso es [X]; de lo contrario es [Y]. Reescribe el paso 4 para expresar esa bifurcación claramente, para que alguien que siga el POE sepa qué camino le corresponde antes de continuar.
Haz esto para cada bifurcación en el proceso real; un POE que oculta un punto de decisión dentro de un solo paso es la razón más común por la que alguien sigue el camino equivocado.
Separar el caso normal de las excepciones
Aquí está mi borrador de POE para [tarea]: [pega tu borrador]. Extrae cualquier cosa que solo aplique en situaciones inusuales, como [describe la excepción], en una sección separada de "Excepciones" al final, para que los pasos numerados principales solo describan el caso normal. Mantén una referencia breve en los pasos principales indicando dónde revisar si el caso actual no se ajusta al patrón normal.
Esto mantiene el camino común fácil de seguir en lugar de obligar a cada lector a navegar casos excepcionales que aplican a una pequeña fracción de los casos.
Poner a prueba el POE en busca de un vacío
Lee este borrador de POE como si nunca hubieras hecho esta tarea y la siguieras por primera vez: [pega tu borrador]. En cada paso, dime cualquier cosa que necesitarías saber que no esté indicada, cualquier término que no esté definido, o cualquier punto donde no estarías seguro de haber hecho el paso correctamente antes de pasar al siguiente.
Esto saca a la luz los vacíos que son invisibles para ti porque ya conoces el proceso; una lectura fresca detecta lo que la familiaridad oculta.
Adaptar un POE después de que el proceso cambió
Aquí está nuestro POE existente para [tarea]: [pega el POE actual]. El proceso cambió: [describe qué es diferente ahora]. Actualiza el POE para reflejar el nuevo proceso, y señala exactamente qué pasos cambiaron para que el equipo pueda ver qué es diferente de la versión que ya conocen.
Señalar qué cambió, en lugar de reemplazar silenciosamente los pasos antiguos, ayuda a las personas que memorizaron la versión anterior a notar qué es realmente diferente.
La Estructura
Lo que realmente necesita un POE que se pueda seguir
Estas son las piezas que permiten que alguien desconocido con una tarea la complete correctamente en el primer intento.
Un punto de inicio y fin claros
Indica exactamente cuándo empieza la tarea y cómo se ve cuando realmente está terminada. Un POE sin un punto final definido deja al lector adivinando si terminó o se saltó un paso.
Nombres reales para herramientas reales
Usa los nombres reales del sistema, campo y herramienta de tu equipo, no una descripción genérica. "Abre la solicitud" solo es útil si el lector ya sabe dónde viven las solicitudes; nombra el sistema.
Puntos de decisión expresados explícitamente
Si el proceso se bifurca según una condición, dilo directamente en el paso en lugar de dejarlo implícito. Una bifurcación oculta es la razón más común por la que alguien sigue el camino equivocado.
Excepciones separadas de los pasos principales
Mantén el camino normal corto y limpio, y mueve los casos excepcionales a su propia sección. Un POE que entierra excepciones en los pasos principales hace que el caso común sea más difícil de seguir.
Los Pasos que Te Saltas
Por qué el proceso que describirías en una frase no es el proceso que debes darle a Claude
Si alguien te preguntara qué haces para esta tarea, probablemente lo resumirías en una o dos frases: "reviso la solicitud, verifico la cuenta y proceso el reembolso." Ese resumen es exacto, y también le falta casi todo lo que un nuevo empleado realmente necesitaría, porque las pequeñas comprobaciones que haces automáticamente, el campo específico al que echas un vistazo, lo que siempre confirmas antes de continuar, se han vuelto invisibles para ti por la repetición. No son invisibles para alguien que hace la tarea por primera vez.
Este es el vacío que hace que un primer borrador de POE se sienta escaso incluso cuando es técnicamente correcto. Claude solo puede escribir lo que le dices, y si describes la versión resumida y depurada del proceso, obtienes de vuelta un resumen depurado formateado como pasos numerados, no un procedimiento real que alguien desconocido con el trabajo pudiera seguir. La solución es narrar el proceso como lo harías con un nuevo empleado parado a tu lado, incluyendo las partes que se sienten demasiado obvias para mencionar.
Un truco útil para sacar a la luz esos pasos invisibles es hacer la tarea realmente una vez mientras la narras en voz alta, o tan cerca de eso como puedas llegar en un prompt, en lugar de resumirla de memoria después. Las comprobaciones habituales tienden a aparecer naturalmente cuando recorres el proceso en vivo; tienden a desaparecer cuando lo recuerdas de memoria después del hecho, porque la memoria conserva el resumen y descarta los pequeños movimientos que hicieron que el resumen fuera cierto.
Errores Comunes
Lo que hace que un POE falle la primera vez que alguien lo usa realmente
Estos son los vacíos que convierten un documento de aspecto razonable en uno que no sobrevive el contacto con un usuario real y desconocido.
Referencias vagas a herramientas en lugar de nombres reales
"Registra la actualización en el sistema" no significa nada para alguien que no sabe ya qué sistema, qué pantalla, qué campo. Nombra la herramienta real cada vez.
Una decisión oculta enterrada dentro de un paso
Si un paso depende secretamente de una condición que no se indica, el lector no sabrá qué camino aplica a su situación hasta que ya sea demasiado tarde para cambiar fácilmente de rumbo.
Ningún punto final indicado para la tarea
Si el POE no dice cómo se ve "terminado", el lector se queda adivinando si debe continuar o si se saltó un paso que viene después del último escrito.
Excepciones mezcladas con los pasos principales
Un caso excepcional colocado en medio de los pasos normales obliga a cada lector, incluso a los del caso común, a averiguar si aplica antes de continuar.
Mantener Juntos los Materiales Relacionados
Por qué un POE se beneficia de existir junto a sus documentos relacionados
Un procedimiento operativo estándar rara vez existe solo. Generalmente hace referencia a una política que debe cumplir, una versión anterior que reemplazó, o un procedimiento relacionado para una tarea diferente pero conectada, y mantener esos documentos cerca mientras se redacta hace que el resultado sea más consistente que escribir el POE de forma aislada y esperar que coincida con todo lo demás. La función de Proyectos de Claude te permite mantener un conjunto de archivos relacionados en un solo lugar para que cada conversación sobre el POE pueda hacer referencia al mismo material de fondo sin que tengas que volver a pegarlo cada vez, lo cual está documentado en la página de ayuda de Proyectos de support.claude.com.
Esto importa más cuando un POE necesita mantenerse consistente con un documento de política que cambia independientemente del procedimiento mismo. Si la política establece un umbral, como una cantidad de dinero que determina qué camino de aprobación aplica, mantener la política y el POE en el mismo proyecto significa que una actualización futura de uno es más fácil de verificar contra el otro, en lugar de descubrir meses después que el procedimiento y la política que se supone implementa se han separado silenciosamente.
También ayuda cuando un equipo mantiene varios POE relacionados para variaciones de la misma tarea, como un procedimiento para una solicitud estándar y otro para una acelerada. Tener ambos a la vista a la vez facilita mantener los pasos compartidos redactados de manera consistente y las diferencias entre ellos deliberadas en lugar de accidentales, lo cual importa más de lo que parece una vez que dos personas actualizan cada una una versión diferente de lo que se supone es el mismo proceso subyacente.
Antes de Publicarlo
Qué verificar antes de que el POE se convierta en la versión oficial
Recorre el borrador mientras realmente haces la tarea, no solo leyéndolo en tu escritorio. Un paso que parece completo en pantalla a menudo resulta saltarse una pequeña acción que haces automáticamente, y ese vacío es mucho más evidente con las manos en el teclado que leyendo en silencio de principio a fin.
Verifica cada nombre de herramienta, nombre de campo y referencia de sistema contra lo que realmente está en pantalla ahora mismo. Las interfaces cambian, y un POE que todavía hace referencia a un botón renombrado o un sistema retirado enviará a un nuevo empleado a buscar algo que ya no existe, lo cual es un fallo peor que un paso faltante porque parece su error en lugar del error del documento.
Dale el borrador a alguien que nunca haya hecho la tarea, si puedes, y observa dónde duda. El punto donde alguien genuinamente desconocido con el proceso se detiene y pregunta "espera, ¿qué hago aquí?" es la señal más confiable de dónde realmente tiene un vacío el POE, más confiable que tu propia relectura, porque no puedes desconocer el proceso para leerlo como lo lee esa persona.
Claude puede convertir un recorrido detallado en un procedimiento limpio y numerado rápidamente, pero el juicio sobre si ese procedimiento realmente coincide con cómo se hace el trabajo, y si es suficientemente completo para que alguien nuevo lo siga sin hacer una pregunta, sigue siendo algo que solo una prueba real contra la tarea en vivo puede confirmar.
Un buen POE sobrevive a su primer usuario real
Describir un proceso con suficiente detalle para que otra persona realmente pueda seguirlo es una habilidad de escritura específica. Las lecciones gratuitas de Nightschool AI cubren tareas de escritura laboral reales con Claude, incluyendo las decisiones de juicio sobre qué detallar y qué dejar en una sección separada de excepciones.
Preguntas frecuentes
¿Cuál es lo más importante que decirle a Claude antes de que redacte un POE?
Recorre el proceso tal como realmente lo haces, incluyendo los nombres reales de herramientas y campos y las pequeñas comprobaciones habituales que normalmente no mencionas en voz alta. Esos pasos invisibles son lo que realmente necesita un nuevo empleado.
¿Cómo debo manejar un paso que depende de una condición?
Expresa la bifurcación explícitamente en el paso: si una condición es verdadera, haz una cosa; si no, haz otra. Una decisión oculta enterrada dentro de un solo paso es la razón más común por la que alguien sigue el camino equivocado.
¿Deben mezclarse las excepciones con los pasos numerados principales?
No. Mantén el camino normal corto y mueve los casos excepcionales a una sección separada de excepciones, con una referencia breve en los pasos principales indicando dónde revisar si el caso actual no se ajusta al patrón normal.
¿Cómo sé si mi borrador de POE realmente tiene un vacío?
Recórrelo mientras haces la tarea físicamente, o pídele a Claude que lo lea como lo haría alguien desconocido con el proceso y marque todo lo indefinido. Ambos sacan a la luz vacíos que son invisibles una vez que ya conoces el proceso.
¿Puede Claude ayudar a mantener un POE consistente con un documento de política relacionado?
Mantener ambos en el mismo Proyecto de Claude, como se describe en la página de ayuda de Proyectos de support.claude.com, facilita hacer referencia a la política mientras se redacta y verificar luego si hay divergencias entre ambos.
¿Qué debe decir un POE sobre cuándo está terminada la tarea?
Indica un punto final claro: exactamente cómo se ve la tarea cuando realmente está terminada. Sin uno, el lector se queda adivinando si terminó o se saltó un paso que debía venir después del último escrito.
¿Cómo debo actualizar un POE después de que el proceso real cambie?
Dale a Claude el POE existente y describe qué es diferente ahora, y pídele que señale exactamente qué pasos cambiaron. Eso ayuda a las personas que memorizaron la versión anterior a notar qué es realmente diferente en lugar de volver a aprender todo el documento.
¿Quién debería revisar un borrador de POE antes de que se publique?
Alguien que nunca haya hecho la tarea, si es posible. Dónde duda o pregunta qué hacer a continuación es una señal más confiable de un vacío real que tu propia relectura, ya que no puedes leerlo como lo hace alguien desconocido con el proceso.
Un POE solo funciona si alguien nuevo realmente puede seguirlo
La estructura es reutilizable cada vez. Recorrer el proceso real, incluyendo las partes que normalmente te saltas, es la parte que vale la pena hacer bien.