Cuando un texto generado por IA sale mediocre, la reacción habitual es cambiar a un modelo más potente.
Hay otra opción: poner al lado del modelo una redacción obsesivamente exigente que nunca duerme.
Esa redacción revisa el título, comprueba si el cuerpo cumple su promesa, detecta jerga sin explicar, cuenta cautelas repetidas, verifica los 12 idiomas y devuelve únicamente las partes defectuosas para reescribirlas.
TypeScript no tiene talento literario. Pero sí puede construir un proceso editorial que no deja publicar un borrador flojo.
1. Respuesta en 5 segundos: no programes el talento; programa el proceso editorial
Las reglas comunes pueden mejorar la escritura de una IA. El salto importante llega cuando se convierten en un ciclo: generar → comprobar → evaluar el significado → corregir fallos → volver a comprobar.
OpenAI describe los evals como un proceso de definir qué significa “bueno”, medir los resultados y mejorar el sistema incorporando nuevos tipos de error.[1]
En una fábrica de artículos, un fallo no debería arreglar solo una página. Debería convertirse en una comprobación que proteja las cien siguientes.
2. TypeScript no es el escritor; es la línea de producción
El código es muy bueno con comprobaciones deterministas:
- ¿Hay más de un H1?
- ¿
titleyog:titlese contradicen? - ¿Falta alguno de los 12 idiomas?
- ¿Hay encabezados duplicados?
- ¿Fechas o URL tienen formatos extraños?
- ¿Debe volver a revisión si no supera el umbral?
Pero otras preguntas exigen comprender el texto: si la apertura engancha, si una metáfora merece quedarse, si el título expresa la pregunta real del lector o si la investigación ha enterrado la idea original.
La división útil es: TypeScript para lo mecánico; editor de IA para lo semántico.
3. “Editor profesional” funciona mejor cuando se divide en funciones
Edición estructural
Revisa necesidad del lector, orden, ritmo y rapidez de la respuesta.
Edición de estilo
Trabaja título, entrada, repeticiones, palabras y ritmo.
Edición factual
Comprueba cifras, fechas, citas, nivel de certeza y fuentes.
Edición de entrada desde buscadores
Pregunta si el principio del título ya dice de qué trata la página.
Google Search Central explica que los títulos de resultados ayudan a entender rápidamente el contenido y su relevancia; recomienda títulos descriptivos, concisos y diferenciados, y desaconseja el relleno de palabras clave.[2]
Los estudios de usabilidad de NN/g también muestran que los usuarios suelen escanear la web y que las primeras palabras de títulos y enlaces cargan gran parte de la señal informativa.[4][5]
No se trata de poner “palabras SEO mágicas” a la izquierda, sino de hacer reconocible el tema antes de pedir atención.
4. Antes / después: mueve el chiste, no lo mates
Antes
El apellido no tiene la culpa; el diccionario se estrelló — Manko, Wang y Chin y los “nombres peligrosos en otros idiomas”
Tiene personalidad, pero el tema real llega tarde.
Después
Nombres que suenan incómodos en otro idioma — Manko, Wang, Chin y los choques entre lenguas
Y el primer renglón puede recuperar:
El apellido no tiene la culpa. El diccionario se estrelló.
El chiste sigue vivo y funciona mejor porque el lector ya entiende el contexto.
La guía de contenido centrado en las personas de Google también pregunta si el título resume de forma útil y descriptiva el contenido en lugar de buscar tráfico con exageración.[3]
5. Las buenas reglas evitan accidentes repetidos; no clonan todos los artículos
Forzar siempre tres frases, siempre títulos en forma de pregunta y siempre dos ejemplos termina fabricando texto de plantilla.
Mejor definir fallos:
- No esconder la pregunta principal tras un eslogan.
- No prometer en el título algo que el cuerpo no responde.
- No repetir la misma cautela varias veces.
- No lanzar jerga sin explicación.
- Hacer que los subtítulos se entiendan por sí solos.
- Usar la investigación para reforzar la observación original, no para sustituirla.
- No traducir mecánicamente el orden japonés a otros 11 idiomas.
6. P0 / P1 / P2 evita convertir el sistema en una cárcel de reglas
P0: no puede fallar
Hechos, cifras, fechas, citas, coherencia entre título y cuerpo, privacidad, idiomas completos y ausencia de afirmaciones sin apoyo.
P1: muy importante
Respuesta temprana, una idea principal por párrafo, explicación sencilla antes de la jerga, subtítulos claros y menos repetición.
P2: voz
Humor, metáforas, tono conversacional, ritmo y ganchos memorables.
Proteger P0 no exige destruir P2. Si no, el control de calidad termina produciendo prospectos administrativos.
7. El activo real es un bucle de evaluación que aprende de los fallos
- Generar borrador.
- Ejecutar comprobaciones mecánicas.
- Leer semánticamente con un editor de IA.
- Devolver motivos de fallo estructurados.
- Corregir solo lo que falló.
- Volver a comprobar.
- Convertir los fallos nuevos y generalizables en criterios permanentes.
El enfoque de evals de OpenAI destaca precisamente esa mejora continua a partir de errores reales.[1]
Si falla el título, no hace falta regenerar dos mil palabras buenas y crear cinco problemas nuevos.
8. La implementación en TypeScript puede ser sencilla
const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);
if (!hardCheck.ok || editorial.hasCriticalIssue) {
const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
return verifyAgain(revised);
}
return draft;
Lo determinista va al código; lo que exige significado va al editor de IA; los motivos de fallo se convierten en instrucciones precisas de revisión.
9. La automatización también se equivoca: el editor de IA no es un dios
Puede borrar un buen chiste por “redundante”, aplanar estilos minoritarios, perder humor cultural al localizar o puntuar demasiado bien su propio texto.
Por eso una nota semántica es una señal de inspección, no la verdad. Los hechos vuelven a fuentes primarias u oficiales; los casos de alto riesgo se escalan a humanos; cada idioma se juzga como idioma real, no como sombra del japonés.
10. Con 100 o 1000 artículos, lo más valioso es el interés compuesto de la mejora
Un artículo revela que el eslogan escondió la pregunta principal: se añade una comprobación.
Otro demuestra que cuatro “sin embargo” diluyeron la conclusión: se añade otra.
Otro muestra un alemán correcto pero claramente traducido: se crea una regla específica de localización.
El fallo deja de ser una corrección aislada y se convierte en infraestructura editorial.
11. Conclusión: construye una redacción que no duerme, no una montaña de reglas
No se trata de trasplantar talento literario a TypeScript.
Se trata de reproducir juicios útiles de un buen editor: “no se entiende de qué va”, “el título promete algo que el cuerpo no paga”, “no borres el chiste; muévelo”, “esta afirmación necesita fuente”.
Convertidos en comprobaciones, revisión semántica, corrección localizada y revalidación, esos juicios pueden hacer que el mismo modelo entregue un texto final mucho mejor.
Porque aprende el sistema editorial que rodea al modelo.
