Cuatro tipos de flujos de trabajo diarios: exploración, reparación de bugs, refactorización y pruebas

📚 Navegación de la serie: El artículo anterior 13 · Escritura de prompts (Prompt) te enseñó "cómo expresarte": dividir requisitos vagos en instrucciones precisas que Codex comprenda. Este artículo aterriza el concepto desde otra perspectiva: el 80% del trabajo diario se reduce a cuatro categorías, y te ofrezco un flujo que puedes copiar directamente para cada una, donde solo tendrás que rellenar los huecos para usarlo. El siguiente artículo es 15 · Permisos, sandbox y aprobaciones.

Escuchemos una conversación primero. La semana pasada, un compañero que acababa de cambiarse a Codex me preguntó en el grupo:

"Le pedí que corrigiera un bug, eliminó el error en tres movimientos y lo confirmé. Al día siguiente, volvió a aparecer el mismo problema, ¿qué pasó?"

Yo le pregunté: "¿Le pediste que buscara la causa raíz primero? ¿Añadiste pruebas de regresión?"

Él: "... ¿Ah? ¿Corregir un bug no es simplemente hacer desaparecer el error?"

El problema radica justo aquí. Confundió "hacer desaparecer el error" con "resolver el problema", y no le puso un candado a ese bug. En realidad, explorar, corregir bugs, refactorizar y escribir pruebas tienen cada uno su propia estrategia fija; si sigues el patrón correcto, Codex trabaja de forma rápida y estable; de lo contrario, parecerá que completó la tarea pero te dejará una mina oculta debajo.

El artículo anterior trató sobre las "técnicas de comunicación" generales; este las aplicará en los cuatro escenarios específicos más frecuentes. Llevo más de medio año usando Codex y lo que he consolidado al final son estos cuatro flujos, cada uno adaptado al comportamiento de Codex: en el IDE puede ver los archivos que tienes abiertos, en la CLI requiere que los nombres con @; y como destaca en "tareas autovalidables", debes dejarle una vía para la verificación.

Al terminar este artículo, obtendrás:

• Un flujo de trabajo copiable para cada una de las cuatro tareas frecuentes (exploración / reparación de bugs / refactorización / pruebas), detallando las diferencias entre el IDE y la CLI.
• La lógica clave de "por qué actuar así" para cada categoría, en lugar de memorizar plantillas de memoria.
• Una tabla comparativa resumida de las cuatro tareas; cada sección incluye su tabla de flujo correspondiente y al final se consolidan en una sola.
• Una práctica real completa paso a paso con su resultado esperado (tomando un bug real para recorrer todo el flujo de reparación).

---

01 Identificar primero: cuatro tareas, cuatro herramientas

Antes de empezar a trabajar, clasifica con claridad el "carácter" de estos cuatro tipos de tareas. Los requisitos que plantean a Codex son completamente diferentes y, si te equivocas de estrategia, el resultado se verá muy afectado.

Analogía: Cuatro cuchillos en la cocina, cada uno con su uso específico. Usar un cuchillo de filetear para cortar pescado o una hacha para picar costillas; si usas el de filetear para picar huesos, seguro que dañarás la hoja. Explorar, corregir bugs, refactorizar y probar son como cuatro cuchillos diferentes: la clave no es "saber usar Codex", sino "saber qué cuchillo sacar para esta tarea".

Su diferencia fundamental radica en una sola dimensión: ¿esta tarea modifica tu código?

Tarea	¿Modifica código?	Qué hace principalmente Codex	Qué debes vigilar más
Exploración de la base de código	No (solo lectura)	Leer archivos y explicártelos	Si la explicación es correcta
Reparación de bugs	Sí	Reproducir + localizar causa raíz + modificar	Si detectó la causa raíz y si hay pruebas de regresión
Refactorización	Sí (pero conserva el comportamiento)	Reescribir de forma equivalente	Si el comportamiento cambió al terminar
Escribir pruebas	Añade archivos	Generar pruebas + cubrir casos límite	Si se cubrieron todos los casos límite

¿Lo notas? La exploración tiene riesgo cero (solo lee y no escribe), por lo que puedes preguntar libremente; reparar bugs y refactorizar implican meter mano al código, de modo que debes pedirle que lo explique primero antes de proceder; escribir pruebas está en un término medio, ya que crea archivos nuevos sin tocar tu código original, pero debes vigilar que no sea perezoso y solo pruebe el "caso feliz".

Codex 在「能验证自己工作」的时候，产出质量明显更高。给它复现步骤、验证办法、跑 lint（代码静态检查）和测试的指令——它就有据可依，而不是「看起来对」就交差。 Codex genera resultados de calidad notablemente superior cuando es capaz de "validar su propio trabajo". Proporciónale los pasos para reproducirlo, los métodos de validación y las instrucciones para ejecutar lint (comprobación estática) y pruebas; de este modo tendrá una referencia clara, en lugar de entregar la tarea simplemente porque "parece correcta".

Esta afirmación es la base de los cuatro flujos. Las siguientes cuatro secciones responderán esencialmente a una sola pregunta: para cada una de estas tareas, ¿cómo dejarle una vía a Codex para que valide su trabajo por sí mismo?

💡 Resumen en una frase: Clasifica primero las cuatro tareas según si modifican el código o no: la exploración tiene riesgo cero y se puede preguntar con libertad, mientras que para modificar el código debes pedirle que lo explique primero antes de cambiarlo; y para cada una de ellas, déjale una vía para autovalidarse.

Este diagrama coloca las cuatro tareas frente a frente: una categoría por casilla, marcando si modifica código o no, su estrategia principal y qué debes vigilar más; las siguientes cuatro secciones desglosarán este flujo paso a paso.

---

02 Explorar una base de código desconocida: tres niveles de preguntas de lo general a lo particular

Comenzamos con el escenario más frecuente: recibes un proyecto completamente desconocido y lo primero que debes hacer es comprenderlo.

¿Cómo se hacía esto antes? Abrías la carpeta, te quedabas perplejo ante decenas de directorios y entrabas uno por uno a revisar, sintiéndote perdido incluso después de dos horas. Ahora ya no es necesario: Codex toma tu proyecto como espacio de trabajo y puede leer todo el código por sí mismo, tú solo debes preguntar.

Analogía: Entrar a un gran centro comercial por primera vez: primero miras el mapa general, luego buscas la tienda y finalmente sigues la ruta. No te pones a buscar en las estanterías nada más cruzar la puerta; miras el vestíbulo para entender "cuántos pisos tiene el centro y qué se vende en cada uno" (arquitectura general), luego buscas "en qué piso y sección están los artículos para bebés" (localizar módulos) y finalmente caminas siguiendo la ruta "desde la entrada hasta la tienda" (rastrear flujos). De lo general a lo particular, de la superficie a la línea, este es el ritmo estándar de la exploración.

Aquí hay que explicar un detalle clave sobre cómo formular estas tres capas de preguntas: la extensión del IDE y la CLI de Codex obtienen el contexto de forma diferente; Claude Code también difiere en esto: la CLI de Claude Code detecta automáticamente el contexto de todo el proyecto (mediante CLAUDE.md y el espacio de trabajo), mientras que la CLI de Codex no lo hace: requiere que nombres los archivos explícitamente con @ para que pueda "ver" lo que deseas que revise.

La extensión del IDE incorporará automáticamente los archivos abiertos y el código seleccionado como contexto; en cambio, en la CLI de Codex, por lo general debes detallar las rutas de los archivos explícitamente mediante @ (o usar /mention adjuntando un archivo específico).

En pocas palabras: para explorar en el IDE, abre primero los archivos relacionados y selecciona el fragmento de código de interés antes de preguntar; para explorar en la CLI, debes señalarle el archivo usando @nombre_de_archivo. Esta es la diferencia en la que insiste la documentación oficial, ya que si te confundes, no podrá acceder a lo que deseas.

En el IDE pregunta así (la forma más rápida para exploración local)

Abre los archivos más relacionados y selecciona la sección de código de interés (opcional pero muy recomendado), y luego pregunta. El prompt de exploración oficial tiene esta estructura:

解释一下请求是怎么流过我选中的这段代码的。

请包含：
- 每个涉及的模块各自负责什么，简短说明
- 哪些数据被校验、在哪里校验
- 改这块时要小心的一两个「坑」

Al terminar, si quieres verificar rápidamente si su explicación es correcta, añade una pregunta para que te dé una lista comprobable:

把这个请求流程总结成带编号的步骤列表，然后列出涉及的文件。

En la CLI pregunta así (cuando deseas un historial con scroll y comandos de consola)

Primero inicia la sesión interactiva:

codex

Luego señálale los archivos con @ antes de preguntar (esta es la mayor diferencia entre la CLI y el IDE: debes indicarle los archivos, no los revisará solo):

我要搞懂这个服务用的协议。读一下 @foo.ts @schema.ts，
讲讲它的数据结构和「请求 / 响应」流程，重点说清哪些字段必填、
哪些可选，以及向后兼容的规则。

Aquí hay un hábito seguro que uso cada vez que recibo un proyecto nuevo: restringir los permisos a solo lectura durante la fase de exploración. En el artículo 12 · Comandos de barra diagonal y atajos de teclado explicamos /permissions; cámbialo a Read Only (solo lectura) al explorar: ordénale únicamente leer y explicar, evitando que modifique archivos por iniciativa propia. La exploración debe tener riesgo cero por naturaleza, y cerrar este paso te dará tranquilidad.

El año pasado me hice cargo de un proyecto heredado en Go de unas treinta mil líneas, y el primer día hice exactamente esto: inició en la CLI, señaló varios archivos de entrada mediante @ y le pedí la "arquitectura general y los módulos principales" para comprender los servicios disponibles; luego busqué "qué archivos contienen el código encargado de X" para localizarlos; y finalmente elegí el flujo principal pidiéndole que "resumiera los pasos de esta petición en una lista numerada". En medio día dominé el flujo, algo que en el pasado me habría tomado dos o tres días.

Te presento el flujo de exploración para comparar los métodos en el IDE y en la CLI:

Paso	Extensión de IDE	CLI
1. Dar contexto	Abrir archivos relacionados, seleccionar fragmento de interés	Señalar archivos mediante @nombre_de_archivo o adjuntarlos con /mention
2. Preguntar arquitectura	"Resumen de la arquitectura general, responsabilidades de los módulos principales"	Igual que en la columna de la izquierda, con archivos ya señalados mediante @
3. Localizar módulos	"¿Qué archivos contienen el código responsable de [función X]?"	Igual
4. Rastreo de flujo	"Rastrea la ruta completa de [flujo X]"	Igual
5. Entregable verificable	"Resume los pasos en una lista numerada + lista de archivos relacionados"	Igual
Durante todo el proceso	No permitir cambios en el código	Cambiar a Read Only para forzar el modo de solo lectura

💡 Resumen en una frase: La exploración sigue un único ritmo: avanzar en tres niveles desde la arquitectura general hasta los archivos específicos y luego el flujo de ejecución; recuerda el comportamiento de Codex: el IDE revisa de forma automática los archivos abiertos, mientras que en la CLI debes indicárselos mediante @; la forma más segura es obligarlo a mantenerse en solo lectura.

---

03 Reparar bugs: reproducir → causa raíz → modificar → verificar

La reparación de bugs es otra tarea sumamente habitual y, al mismo tiempo, la más propensa a fallos: el caso del compañero del inicio es un ejemplo claro de esto.

¿Por qué falla tanto? Porque el error más común de los principiantes es: lanzar una traza de error con la frase "ayúdame a corregirlo", y dejar que Codex aplique un cambio que simplemente haga "desaparecer el error". Presta atención: "desaparecer el error" no equivale a "resolver el problema"; a menudo, simplemente cubre el síntoma, pero la causa raíz permanece latente y volverá a fallar con otra secuencia.

Analogía: Si una tubería tiene una fuga, no puedes limitarte a poner un cubo. Ver agua en el suelo y apresurarse a colocar un cubo o limpiar con un paño (hacer desaparecer el error) es una solución temporal; primero debes seguir el rastro del agua para ver qué sección de la tubería se ha agrietado (localizar la causa raíz), sustituir esa sección y abrir el agua de nuevo para comprobar que no tiene fugas (verificar). Con la reparación de bugs es idéntico: busca primero la fuga, no te apresures a recoger el agua.

La estrategia oficial de Codex para reparar bugs se centra en proporcionarle una "receta" que permita reproducirlo, en lugar de una descripción a alto nivel. La explicación oficial es sumamente directa:

由你提供的：复现步骤和约束条件——这些比一句高层描述重要得多。由进行 Codex 提供的：命令输出、它发现的调用点、它触发出来的堆栈信息。 Proporcionado por ti: los pasos de reproducción y las restricciones; estos son mucho más importantes que una descripción a alto nivel. Proporcionado por Codex: la salida de los comandos, los puntos de llamada que detecta y la información de la traza de pila que genera.

Por lo tanto, el flujo correcto para reparar un bug consta de cuatro pasos indispensables:

1. Proporcionar receta de reproducción + archivos sospechosos: error completo, detallando "qué presioné y qué pasos seguí para activarlo", adjuntando además los archivos sospechosos.
2. Pedirle que lo reproduzca primero antes de buscar la causa raíz: la recomendación oficial sugiere pedir explícitamente "reproduce primero este bug en local"; una vez reproducido, el diagnóstico de la causa raíz será confiable, no dejes que adivine sobre el aire.
3. Aplicar la reparación: una vez identificada la causa raíz, déjalo hacer las modificaciones, indicándole "mantener el cambio al mínimo".
4. Ejecutar validación: al terminar, Codex debe volver a ejecutar los pasos de reproducción; si hay un flujo de comprobación estándar, pídele que "ejecute lint + pruebas mínimas relacionadas e informe los comandos y resultados".

El cuarto paso es el que los principiantes suelen omitir con más frecuencia, pero es justo el más valioso. La sugerencia oficial para la "validación posterior a la reparación" es una sola frase:

修复之后，跑一遍 lint + 最小的相关测试套件。把用到的命令和结果报给我。

Esto le pone un candado al bug: al aplicar el cambio las pruebas pasan automáticamente a verde y, si alguien deshace la modificación por accidente en el futuro, las pruebas darán la alarma de inmediato. El bug del compañero del inicio revivió precisamente por no haber dejado este candado; nadie sabía que esa línea de código no se debía tocar.

Reparar bugs en el IDE

Abre el archivo sospechoso junto con sus llamadores más cercanos (el IDE incorporará los archivos abiertos como contexto de forma automática) y escribe:

找出导致「显示已保存但没真正持久化」的 bug。
提出修复方案后，告诉我怎么在界面上验证它修好了。

Reparar bugs en la CLI

Inicia Codex en el directorio raíz del repositorio y proporciónale una receta de reproducción completa. Esta es la estructura de ejemplo oficial: llénala con la información de tu propio bug:

codex

Bug：在设置页点「保存」，有时显示「已保存」但改动没真正生效。

复现：
1) 启动应用：npm run dev
2) 进入 /settings
3) 切换「开启提醒」开关
4) 点保存
5) 刷新页面：开关又弹回去了

约束：
- 不要改 API 的形态。
- 修复尽量小，可行的话补一个回归测试。

先在本地复现这个 bug，然后提出补丁并跑检查。

Nota la precisión de este prompt: detalla paso a paso "cómo activarlo", establece una línea roja de restricciones (no tocar la API) y solicita claramente "reproducir primero". Esto es justo lo que la documentación oficial define como "una receta de reproducción es mucho más valiosa que una descripción a alto nivel".

Te ofrezco una plantilla de referencia rápida para reparar bugs:

Bug：[一句话说清现象]
复现：[编号列出每一步，从启动到触发]
约束：[别碰什么、改动多大]
怀疑文件：[你能定位到的话，@ 点出来]
请你：先复现 → 定位根因（先别改）→ 给最小修复 → 跑 lint 和相关测试报结果。

💡 Resumen en una frase: Flujo de reparación de bugs en cuatro pasos: dar receta de reproducción, pedirle que lo reproduzca antes de buscar la causa raíz, aplicar la mínima modificación y validar con lint y pruebas; una receta de reproducción es más valiosa que descripciones a alto nivel, y sin el candado de la verificación, el bug volverá a aparecer tarde o temprano.

---

04 Refactorización: planificar primero → pasos pequeños → conservar comportamiento → probar antes y después

La refactorización es la tarea de mayor riesgo, ya que modifica código que no presenta fallos.

La reparación de bugs cuenta al menos con un criterio de éxito claro: se eliminó el error o las pruebas pasaron a verde. La refactorización no lo tiene; su meta es "hacer el código más limpio pero sin alterar ni una sola letra del comportamiento externo". Si el comportamiento cambia, estarás introduciendo un bug de forma oculta en nombre de la refactorización; este es el tipo de bug más molesto, porque nadie se pondrá a probar código sobre el que 'solo se hizo una limpieza'.

Analogía: Cambiar piezas de un tren de alta velocidad en marcha, sin detenerlo ni molestar a los pasajeros. Debes garantizar que el tren siga avanzando y que los pasajeros no perciban nada, limitándote a sustituir un componente inferior por uno más fácil de mantener. Refactorizar es "cambiar piezas en movimiento": el servicio externo (la experiencia del pasajero) debe mantenerse idéntico de principio a fin.

Refactorizar suele fallar por dos motivos: reescribir todo de golpe (un cambio tan grande que impide la verificación progresiva) y no tener pruebas de protección (evaluar si el comportamiento cambió puramente a ojo). La estrategia oficial de Codex ataca justo estas dos causas: planificar primero e implementar en pasos pequeños.

Primer paso: Pedirle una propuesta de refactorización primero

La recomendación oficial: antes de tocar el código, pide a Codex que genere un plan de refactorización. Si tienes la Skill $plan instalada, invócala explícitamente (las Skills se invocan con el prefijo $, lo cual difiere del comando de barra diagonal /plan para cambiar al modo plan). La documentación oficial la define como una Skill integrada (nivel SYSTEM) disponible para usar; si no aparece en tu lista, no te preocupes y pídele en lenguaje natural "crea un plan primero y no modifiques nada aún".

El prompt de planificación oficial tiene esta estructura (observa cómo define el objetivo y las restricciones estrictamente):

$plan

我们要重构 auth 子系统，目标：
- 拆分职责（token 解析 / 会话加载 / 权限判断分开）
- 减少循环依赖
- 提升可测试性

约束：
- 对用户可见的行为不能变
- 公开 API 保持稳定
- 给一份分步迁移计划

No apruebes el plan de inmediato al recibirlo; púlelo primero con el modelo: este paso define el éxito o fracaso de la refactorización:

修改一下计划：
- 明确每个里程碑具体动哪几个文件
- 加一个回滚策略

¿Por qué pulir el plan primero? Porque aquí aplica la directriz general oficial: "Codex funciona mejor cuando divides las tareas complejas en pasos más pequeños y enfocados, lo cual también facilita tu revisión". Un plan que detalla "qué archivos modificar en cada etapa + la estrategia de rollback" equivale a fragmentar una gran refactorización en varios cambios pequeños que se pueden validar individualmente.

Segundo paso: Implementación en pasos pequeños, probando en cada uno

Una vez fijado el plan, pídele que lo implemente hito por hito, ejecutando las pruebas tras cada paso para confirmar que el comportamiento sigue siendo el mismo. Aquí hay una regla de oro que debes respetar:

No permitas que Codex refactorice código directamente si no está cubierto por pruebas. Imagina que, para ahorrar tiempo, le pides refactorizar una función auxiliar sin pruebas y decide "optimizar" eliminando una condición límite; esa condición parecía código muerto, pero en realidad gestionaba una entrada poco habitual. Solo te darás cuenta cuando falle en producción.

Por tanto, si el código carece de pruebas actualmente, el primer paso no es refactorizar, sino añadir pruebas: utilízalas para tomar una foto del "comportamiento actual" y compárala tras la refactorización para confirmar el éxito si el comportamiento sigue intacto. Esto coincide con la lógica de reparación de bugs de la sección anterior: deja una vía para que Codex se valide solo, de lo contrario la única señal será que "parece correcto", y una refactorización que solo lo parece suele ocultar fallos.

Yo caí en esta trampa en el pasado: para ahorrar tiempo, dejé que Codex refactorizara una función de formato de monedas que no tenía pruebas; el modelo tomó la iniciativa de "optimizar" eliminando una condición para valores negativos; en local funcionó con normalidad, pero en el entorno de pruebas descubrimos que los valores negativos se mostraban incorrectamente. Desde entonces, mi regla establecida es: si no hay pruebas, se escriben primero antes de refactorizar, sin excepciones. Es un proceso más lento, pero evita fallos.

Te presento el flujo de refactorización:

Paso	Qué hacer	Instrucción clave
1. Crear plan	Pedirle (o usar $plan) un plan de refactorización por pasos	Definir objetivo + restricciones estrictamente: comportamiento idéntico y API estable
2. Pulir plan	Pedirle que detalle "qué archivos modificar en cada paso + la estrategia de rollback"	Dividir en hitos pequeños que se puedan validar individualmente
3. Añadir pruebas	Si carece de ellas, escribir primero pruebas que cubran el comportamiento actual	Tomar una foto del "comportamiento actual"
4. Cambios pequeños	Implementar hito por hito	No dejar que reescriba todo de golpe
5. Probar antes y después	Ejecutar pruebas tras cada paso, confirmando que el resultado coincide con el inicial	Si el comportamiento cambia, detenerse e iniciar rollback de inmediato

ℹ️ Hay una técnica avanzada para refactorizaciones grandes: diseñar y pulir el plan en local y luego "subcontratar" la implementación pesada para que se ejecute en paralelo en la nube. Este es el escenario descrito en [10 · Codex Cloud en la nube]: el entorno local se encarga de la planificación detallada y la inspección, y la nube ejecuta la tarea pesada. En este artículo dominaremos primero el flujo local, y en la sección correspondiente revisaremos la delegación a la nube.

💡 Resumen en una frase: La esencia de la refactorización es "que el comportamiento externo no cambie": pídele un plan por pasos primero, define qué archivos se modificarán en cada uno y realiza la implementación de forma progresiva probando antes y después; si carece de pruebas, escríbelas primero; reescribir todo de golpe y trabajar sin pruebas de protección son los dos grandes enemigos de la refactorización.

---

05 Escribir pruebas: el punto clave es obligarlo a cubrir los casos límite

La última categoría: completar pruebas para el código.

Escribir pruebas es algo que a Codex se le da muy bien; la recomendación oficial incluye la instrucción específica: "sigue las convenciones existentes en las demás pruebas"; el modelo revisará tus archivos de prueba actuales y escribirá siguiendo el framework y estilo de aserciones que ya usas, alineando el estilo de forma automática sin que tengas que enseñarle. Pero hay una trampa que debes conocer: si no se lo pides específicamente, tenderá por defecto a probar solo el "caso feliz" (happy path, el flujo principal donde todo funciona bien).

¿Qué representa probar solo el caso feliz? Por ejemplo, para una función que invierte una lista, el modelo la probará con "[1,2,3] para devolver [3,2,1]"; es correcto, pero ¿y para una lista vacía? ¿O con un solo elemento? ¿O si recibe null? Estos "casos límite (edge case, entradas extremas o anómalas)" son donde realmente ocurren los bugs y lo que las pruebas deben cubrir prioritariamente.

Analogía: Al hacer la prueba de choque de un coche nuevo, no puedes limitarte a conducirlo despacio en línea recta. Las pruebas valiosas consisten en estrellarlo contra la pared, frenar en seco, volcarlo o chocar por detrás, probando las "condiciones extremas". Los fallos siempre ocurren en los límites, no en las condiciones normales. El núcleo de escribir pruebas es obligar a Codex a evaluar estos límites.

Las sugerencias oficiales para ambos métodos indican lo mismo: se debe cubrir tanto el happy path como los edge cases.

Escribir pruebas en el IDE (basado en selección)

Abre el archivo que contiene la función objetivo, selecciona las líneas donde se define dicha función, elige "Add to Codex Thread" (añadir al hilo de Codex) en la paleta de comandos para incorporarlas al contexto y escribe:

给这个函数写单元测试。遵循其他测试里已有的约定。

La acción "Add to Codex Thread" es exclusiva del IDE: alimenta a Codex con el rango exacto de líneas seleccionadas, siendo mucho más preciso que describir "aquella función" con palabras.

Escribir pruebas en la CLI (indicando función y archivo en el prompt)

Inicia Codex, señala el archivo con @, detalla el nombre de la función y pídele explícitamente cubrir los límites:

codex

给 @transform.ts 里的 invert_list 函数加测试。
覆盖正常路径，外加边界情况。

Ten en cuenta que el elemento clave de este ejemplo oficial es el final: "cubriendo también los casos límite"; si lo eliminas, lo más probable es que solo evalúe el flujo normal. Compara ambas formas de preguntar:

❌ Formulación vaga	✅ Formulación precisa
"Escribe pruebas para esta función"	"Escribe pruebas para invert_list en @transform.ts, cubriendo el flujo normal y enfocándote en casos límite como lista vacía, un solo elemento, null y listas extremadamente grandes"
Probará solo el flujo normal, simulando una cobertura alta	Evaluará los puntos donde realmente se puede romper el código

Además, hay un truco para obtener puntos extra: pedirle que complete los casos omitidos por su cuenta. Siempre habrá casos límite que pases por alto, así que deja que los busque:

另外帮我想想还有哪些我没列到的边界情况，一并测上。

Suelo incluir esta frase al escribir pruebas y a menudo detecta combinaciones de entrada en las que ni siquiera había pensado: en una ocasión escribí pruebas para una función de rangos de fechas, e incluí valores vacíos y orden inverso; el modelo añadió por su cuenta la "transición de horario de verano" y "inicio y fin en el mismo día", detalles que yo habría pasado por alto.

Te presento el flujo para escribir pruebas comparando el IDE y la CLI:

Paso	Extensión de IDE	CLI
1. Fijar objetivo	Seleccionar líneas de la función → "Add to Codex Thread"	Señalar archivo mediante @nombre_de_archivo y detallar la función
2. Alinear estilo	"Sigue las convenciones de las demás pruebas"	Igual
3. Forzar límites	"Flujo normal + casos límite: [detallarlos]"	Igual
4. Buscar omisiones	"Busca otros casos límite que haya omitido y pruébalos también"	Igual
5. Ejecución	Pedirle que ejecute las pruebas y corrija los fallos hasta aprobar	Igual

💡 Resumen en una frase: Al pedir pruebas no digas solo "escribe pruebas": oblígalo explícitamente a cubrir casos límite (valores vacíos, un elemento, null o valores extremos); la frase del ejemplo oficial "cubriendo también los casos límite" es la clave; y pídele complementar con los casos que hayas omitido, ya que el flujo normal es en realidad el menos importante.

---

06 Manos a la obra: reparar un bug real para recorrer todo el flujo

Ver el flujo no es suficiente, hay que ejecutarlo. A continuación, utilizaremos la "reparación de bugs" para la práctica: es el flujo con los cuatro pasos completos; si lo completas, sabrás aplicar los otros tres de forma natural. Hemos ocultado un bug real para que lo repares.

Nota sobre diferencias de plataforma: los comandos mkdir / cd se usan directamente en Mac / Linux; en Windows se recomienda ejecutarlos en PowerShell y crear calc.py manualmente con el Bloc de notas.

Primer paso: Crear un proyecto de prueba con un bug

mkdir bug-demo
cd bug-demo

En Mac / Linux escribe el archivo directamente con echo:

echo 'def average(numbers):
    return sum(numbers) / len(numbers)' > calc.py

En Windows crea un archivo calc.py con el Bloc de notas y pega estas dos líneas:

def average(numbers):
    return sum(numbers) / len(numbers)

Esta función average calcula el promedio y parece no tener fallos; sin embargo, al pasarle una lista vacía, fallará por una división por cero. Este es el bug que vamos a reparar.

Resultado esperado: la carpeta bug-demo contiene un archivo calc.py con las dos líneas de la función average.

Segundo paso: Iniciar Codex en el directorio raíz del repositorio

codex

Resultado esperado: entras en la TUI interactiva (interfaz de usuario de terminal), con el área de chat en el medio y el cuadro de entrada en la parte inferior.

Tercer paso: Aplicar el flujo de reparación de bugs proporcionando una receta de reproducción

Escribe en el cuadro de entrada (esta es la estructura de la sección 03 completada; nota que incluye los pasos de reproducción, restricciones y el requisito de "reproducir antes de modificar"):

Bug：调用 calc.py 里的 average([]) 会崩。

复现：
1) 给 average 函数传一个空列表 []
2) 它必现 ZeroDivisionError: division by zero

约束：
- 改动尽量小，别动函数签名。

请你：先复现这个 bug，再定位根因（先别改），然后给最小修复，
最后补一个能复现这个 bug 的回归测试并跑一遍确认通过。

Resultado esperado: Codex reproducirá el error primero y luego te indicará la causa raíz: con una lista vacía len(numbers) es 0, lo que provoca la caída por división por cero; a continuación presentará un diff (comparación de cambios) (por ejemplo, devolver 0 para listas vacías o arrojar una excepción más descriptiva), deteniéndose a la espera de tu aprobación; al confirmarlo, creará además un archivo de pruebas (como test_calc.py) con un caso específico para la lista vacía.

ℹ️ El hecho de que se detenga a pedir aprobación depende de tu estrategia de aprobación actual (en el modo Auto, la modificación de archivos en el espacio de trabajo puede aprobarse automáticamente). Este sistema de sandbox y aprobaciones se detalla en el próximo artículo [15 · Permisos, sandbox y aprobaciones]; por ahora sigue el comportamiento por defecto.

Cuarto paso: Aprobar el cambio y ver la validación

Tras revisar el diff elige "Sí / Yes". Codex procederá a ejecutar la prueba que acaba de escribir; esto es justo lo que la documentación define como "volver a ejecutar la validación al terminar".

Resultado esperado: verás el resultado de las pruebas en la terminal, con una estructura similar a (el formato depende del framework de pruebas de tu máquina):

test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSED

Ver las pruebas en verde = el bug ha sido reparado y se le ha colocado un candado; si alguien revierte la línea en el futuro, las pruebas fallarán de inmediato en rojo.

Quinto paso: Salir y confirmar que el archivo se modificó realmente

Sal de Codex (escribe /exit) y compruébalo en la terminal:

cat calc.py

(En Windows PowerShell usa type calc.py)

Resultado esperado: la función average en calc.py incluye la lógica de validación para la lista vacía, y aparece un archivo de pruebas en el directorio. Coincide con el diff que aprobaste = el flujo completo de reparación de bugs se ha completado con éxito, ¡felicitaciones!

⚠️ Si Codex no tomó la iniciativa de escribir la prueba en el tercer paso, probablemente se deba a que eliminaste la frase "añadir una prueba de regresión" en el prompt. No omitas esa línea: el candado de la verificación marca la diferencia entre principiantes y expertos.

💡 Resumen en una frase: Recorre el flujo de reparación de bugs por ti mismo una vez: introduce un bug real, dale la receta para reproducirlo pidiéndole reproducir antes de cambiar y observa cómo añade pruebas para pasar en verde; al dominar esta categoría, sabrás aplicar los pasos a las demás de forma intuitiva.

---

07 Resumen

En este artículo hemos estructurado el 80% de tus tareas diarias en cuatro categorías, con una estrategia fija y un flujo de referencia para cada una:

Tarea	Núcleo del flujo	Qué vigilar prioritariamente
Exploración de código	"Arquitectura general → localizar código de X → rastrear flujo de petición"	El IDE lee archivos abiertos, la CLI requiere @; mantener en solo lectura
Reparación de bugs	"Dar receta de reproducción → reproducir y buscar causa raíz → mínima reparación → validar"	La receta de reproducción es más valiosa que descripciones abstractas; no omitas la validación
Refactorización	"Crear plan → pulir detalles → pasos pequeños → probar antes y después"	El comportamiento no debe cambiar; escribe pruebas primero si carece de ellas, no reescribas de golpe
Escribir pruebas	"Flujo normal + cobertura estricta de límites, completando omisiones"	Exigir la cobertura de casos límite es clave; no pruebe solo el happy path

La directriz común de estos cuatro flujos es: darle una vía a Codex para validar su trabajo por sí mismo: en la exploración pidiéndole una lista numerada, en los bugs pidiéndole reproducir y probar, en la refactorización comparando con fotos de pruebas y al probar obligándolo a cubrir los límites. Siempre que Codex disponga de un criterio ejecutable, no se detendrá puramente porque "parece correcto".

Ahora deberías ser capaz de: abordar cualquier tarea frecuente sin quedarte perplejo ante el cursor: selecciona el flujo correspondiente, ten claro qué pedirle a Codex en cada paso, qué debes vigilar por tu cuenta y las diferencias de ejecución en el IDE y en la CLI. Estos cuatro flujos te servirán de andamio para la gran mayoría de tus tareas futuras; con la práctica, descubrirás que las tareas complejas no son más que la combinación e integración de estas cuatro categorías.

---

El siguiente artículo [15 · Permisos, sandbox y aprobaciones]: en este artículo te has topado varias veces con "se detuvo a pedir aprobación" o "cambiar a solo lectura al explorar", pero la lógica interna aún no se ha explicado a fondo. ¿Cómo sabe Codex qué paso requiere consultarte y cuál aprobar por su cuenta? ¿Qué límites abarca exactamente su sandbox? En el próximo artículo desglosaremos el trío de permisos, sandbox y aprobaciones, permitiéndote tomar firmemente el control de "qué tanto puede modificar y cuándo debe preguntar". Un pequeño pensamiento: en este artículo, al reparar el bug, el modelo "se detuvo a pedir aprobación antes de modificar archivos"; si quisieras dejarlo realizar modificaciones libres dentro del espacio de trabajo y preguntar solo al salir de él, ¿qué configuración deberías ajustar y a qué nivel?

---

Lecturas recomendadas

• Skills de Agente: empaquetar flujos de trabajo para enseñar a Codex a ejecutarlos solo
• Automatización y CI/CD: dejar que Codex trabaje de forma autónoma en tu ausencia
• Codex Cloud en la nube: delega el trabajo a la nube y espera el resultado tomando un café