Alibaba Open Code Review no dejó comentarios. ¿Qué archivos revisó?

5 min de lectura · 13 de noviembre de 2026
Última revisión 13 de noviembre de 2026

Una factura, dos intentos de cobro. Antes del cambio, ambos enviaban la misma clave al procesador de pagos. Después, cada intento enviaba una distinta. En nuestro ejemplo cambiamos tanto la implementación en Go como la prueba que define qué debe ocurrir al reintentar. Con la configuración predeterminada, Alibaba Open Code Review solo seleccionó el primero.

¿Qué archivos selecciona Alibaba Open Code Review?

Ejecuta --preview sobre las dos revisiones de Git que delimitan el pull request. La vista previa indica qué archivos entran en la revisión y por qué se excluye cada uno de los demás. Puedes consultarla antes de configurar una clave de API, ya que no llama al modelo. Para el ejemplo usamos la versión 1.13.8 el 13 de noviembre de 2026. Versión 1.13.8 publicada por Alibaba

git diff --name-only main...HEAD
ocr review --from main --to HEAD --preview --format json

Los dos comandos comparan las mismas revisiones. En main, los intentos 1 y 2 de la factura inv-42 compartían clave. En la rama, las claves pasaron a ser inv-42-1 e inv-42-2. La prueba modificada ahora exige que sean distintas. Si el procesador usa esa clave para reconocer un cobro repetido, la prueba permitiría cobrar dos veces cuando se pierde la respuesta del primer intento.

Dos vistas previas del mismo cambio en Git con Open Code Review 1.13.8
Archivo modificado	Selección predeterminada	Con la prueba incluida de forma explícita
`billing/retry.go`	Seleccionado	Seleccionado
`billing/retry_test.go`	Excluido (`default_path`)	Seleccionado

Para la segunda vista previa añadimos una entrada a .opencodereview/rule.json en el repositorio local. Los dos commits eran los mismos. Pasamos de un archivo seleccionado a dos. Puedes incluir una prueba concreta así y conservar el resto de las exclusiones predeterminadas. Selección de archivos y prioridad de las reglas en la versión 1.13.8

{"include":["billing/retry_test.go"]}

Descarga el script para reproducir el ejemplo de los dos archivos. Necesitas Bash, Git 2.41 o posterior, jq y el binario local de OCR 1.13.8. El script crea su propio repositorio Git y comprueba ambas vistas previas. Medimos la selección de archivos. Para saber si el modelo detectaría el posible cobro duplicado habría que ejecutar otra prueba.

¿Qué significa que la lista de comentarios esté vacía en CI?

Empieza por status y warnings en el informe JSON. Una revisión omitida puede devolver "comments": []. El proceso también puede terminar con código 0 si hubo advertencias. Compara el informe final con los archivos modificados según Git y con la vista previa de la revisión exacta que vas a fusionar. Estados del informe JSON, advertencias y códigos de salida de la CLI

También ejecutamos el CLI sin vista previa en una rama que solo modificaba la prueba excluida. Devolvió el código de salida 0, status: skipped, comments: [] y cero archivos revisados. El servidor local registró cero peticiones al modelo. Si el informe guardado sí contiene hallazgos y GitHub no los muestra, comprueba las opciones de publicación y el registro de la acción. Opciones de publicación de la acción de GitHub

Qué haríamos antes de fusionar un pull request sin comentarios
Resultado de la ejecución	Siguiente paso
`skipped`	Comprueba la base de comparación y los filtros. Si quedó fuera un archivo importante, inclúyelo y repite la revisión o asígnalo a una persona.
`partial`, `completed_with_warnings` o `completed_with_errors`	Revisa las rutas afectadas y las advertencias. Repite la parte pendiente o asígnala a un revisor. Conserva los hallazgos válidos de lo que sí se revisó.
`failed`, error fatal o informe ausente	Da la revisión por no disponible. Consulta stderr y comprueba que cualquier informe guardado corresponda a esta ejecución.
`complete` o `success`, archivos previstos cubiertos y cero comentarios	Deja constancia de que el revisor no comunicó hallazgos en ese conjunto. En el ejemplo de facturación, simula la pérdida de la respuesta y comprueba que el reintento solo produce un cobro.

Si el informe incluye un manifiesto, compara manifest.coverage.selected con las rutas que figuran en completed, reused, failed y waived. Comprueba el motivo de cualquier excepción en waived. Guarda los identificadores de los dos commits junto al resultado. Cobertura por archivo en el manifiesto de v1.13.8

¿Qué hace el revisor después de seleccionar un archivo?

La CLI de Alibaba, escrita en Go, selecciona los archivos, aplica las reglas, limita la ejecución y sitúa los comentarios en las líneas modificadas. Puede agrupar los archivos relacionados y revisar varios grupos en paralelo. El agente puede leer un archivo entero, buscar quién llama a una función o consultar el repositorio antes de señalar un defecto. Incluso un archivo excluido de la revisión puede servirle de contexto. Guía de Alibaba sobre arquitectura, integraciones e instalación

Según Alibaba, decenas de miles de desarrolladores usaron su herramienta interna durante dos años y esta identificó millones de defectos. El proyecto público se distribuye con licencia Apache-2.0 y ha superado las 50.000 estrellas en GitHub. Al evaluar su utilidad para un equipo, conviene probarlo con una regresión que ya haya pasado inadvertida en sus controles habituales. Open Code Review en GitHub

¿Qué detectó Open Code Review frente a Claude Code?

En la evaluación de Alibaba con 200 pull requests, una mayor proporción de los comentarios de Open Code Review coincidió con defectos anotados. Claude Code encontró más defectos del conjunto de referencia. Ambos usaron el mismo modelo. El estudio de agosto abarca 50 repositorios, 10 lenguajes y 1.505 problemas anotados. Estudio de OpenCodeReview, diseño de la evaluación y tabla 3

Resultados de AACR-Bench con Claude Opus 4.6, según los autores
Métrica	Open Code Review 1.3.1	Claude Code 2.1.169
Precisión	33,90 %	7,23 %
Proporción de defectos detectados (recall)	20,00 %	28,90 %
F1	25,10 %	11,57 %
Media de tokens por pull request	385.000	5.664.000

Open Code Review identificó 301 de los 1.505 problemas anotados. Claude Code identificó 435. Con mayor precisión, es más probable que merezca la pena investigar un comentario. Con una tasa de detección del 20 %, sigue teniendo sentido probar de forma independiente un fallo costoso. Estas cifras corresponden a las versiones de la tabla. No permiten estimar cuántos cobros duplicados encontraría la CLI actual en tu producto.

¿Qué comprobar antes de aprobar el cambio de facturación?

Pídele a la persona responsable de pagos que confirme qué debe ocurrir en un reintento. Si el primer cobro se procesó pero la respuesta no llegó a tiempo, el segundo intento sobre la misma factura debe dejar un único cargo en el registro. Ejecuta el caso y cuenta los cargos. La prueba unitaria modificada solo demuestra que la función devuelve dos cadenas distintas.

Para probar el revisor con tu equipo, elige un fallo de reintentos que el equipo ya haya corregido y otro cambio parecido que funcione bien. Oculta la corrección al revisor, registra qué rutas cubrió y pide a un ingeniero que compruebe los hallazgos. Nuestra guía de pruebas para código generado con IA desarrolla las verificaciones previas al lanzamiento. Si necesitas presupuestar revisiones más profundas en un servicio alojado, consulta la comparativa de niveles y costes de Greptile.

Preguntas sobre la CLI de Open Code Review

¿Cómo instalo la versión del ejemplo?

Con Git 2.41 o posterior, ejecuta npm install -g @alibaba-group/[email protected] y comprueba la versión con ocr version. El script del ejemplo requiere Bash, Git, jq y el binario de OCR. Puedes ejecutar la vista previa antes de configurar el modelo.

¿Cómo reviso un solo commit?

Pasa a ocr review la opción --commit y el SHA del commit. Para un pull request, usa --from y --to con las dos revisiones que hayas descargado. La comparación empieza en su ancestro común e incluye los cambios introducidos por la rama.

¿Y si el pull request solo modifica pruebas?

Obtén la vista previa del intervalo y comprueba por qué se excluyó cada archivo. Si una prueba define una regla de negocio, inclúyela en la configuración o pide a alguien que la revise. Un cambio limitado a las pruebas puede modificar lo que el equipo acepta para el siguiente lanzamiento.

¿Puedo revisar un directorio entero sin un diff?

Usa ocr scan --path billing para revisar el contenido completo de los archivos del directorio billing. Sirve para examinar código existente. Si quieres comprobar un cambio concreto, conserva el intervalo de commits del pull request para poder identificar lo que cubrió el resultado.

¿Puedo usar el modelo de mi agente de programación?

En una revisión normal, la CLI usa el proveedor y el modelo configurados en OCR. Admite Anthropic y servicios con una API compatible con OpenAI. En modo delegado, el agente de programación aporta su modelo y sus credenciales. Anota qué modo utilizaste si vas a comparar dos ejecuciones.

Independencia y marcas: Wavect publica esta página y es también un proveedor, así que tenemos un interés comercial en ella. No estamos afiliados a las demás empresas nombradas aquí, no contamos con su respaldo y no somos socios suyos, y todos los nombres de empresa, marcas y marcas registradas de terceros pertenecen a sus respectivos titulares. Las afirmaciones sobre otros proveedores proceden de fuentes públicamente accesibles, sobre todo de sus propias páginas publicadas, en la fecha de revisión indicada en esta página, y pueden haber cambiado desde entonces. Verifícalas directamente antes de decidir. Esta página se ha redactado según nuestro leal saber y entender, con la intención de mantenernos objetivos. Si crees que algo aquí es inexacto o injusto, escríbenos y lo corregimos: [email protected]