code-review-graph es una herramienta de gráfico de conocimiento de código local que tiene como objetivo reducir el problema de leer repetidamente todo el almacén durante la revisión del código de IA. Utiliza Tree-sitter para analizar funciones, clases, importaciones, llamadas, herencia y relaciones de prueba, guarda los resultados en la base de datos SQLite dentro del proyecto y luego los proporciona a herramientas de programación de IA como Codex, Claude Code, Cursor a través de MCP, CLI, Skills y ganchos.
Es especialmente adecuado para repositorios grandes, monorepo y relaciones públicas entre archivos: cuando una función cambia, el gráfico puede calcular el radio de impacto a lo largo de las llamadas y dependencias, indicando a la IA qué llamadores, pruebas y flujos de ejecución son más dignos de inspección.
Conclusión rápida
- Requiere Python 3.10 o superior.
- Ejecute
code-review-graph installdespués de la instalación. La herramienta detectará la plataforma de programación de IA instalada y escribirá la configuración MCP correspondiente. - Ejecute
code-review-graph buildpor primera vez. Después de eso, puede usarupdate,watcho ganchos de plataforma para mantener el mapa de forma incremental. - Los datos se guardan en el
.code-review-graph/del proyecto de forma predeterminada, y la composición principal y las consultas no requieren que el código fuente se envíe a servicios externos. - Las modificaciones simples de un solo archivo no necesariamente guardan Tokens; Las llamadas entre archivos, los impactos de las pruebas y las revisiones de grandes almacenes pueden reflejar mejor el valor del mapa.
Instalar código-revisión-gráfico
Se recomienda utilizar un entorno de herramientas Python independiente para evitar contaminar las dependencias del proyecto:
|
|
También puedes usar pip directamente:
|
|
Después de ingresar al repositorio de Git que necesita ser analizado, ejecute:
|
|
install detectará plataformas compatibles como Codex, Claude Code, Cursor, Windsurf, Zed, Continuar, OpenCode, Gemini CLI, GitHub Copilot, etc. y generará reglas de plataforma y configuración de MCP adecuadas. Una vez completado, debe reiniciar el editor o la herramienta de programación de IA.
Si desea configurar solo una plataforma, puede especificar el nombre:
|
|
Al instalar usando uvx, pip o pipx, install hará todo lo posible para identificar la entrada real y generar la configuración correspondiente. Si MCP no se inicia, primero debe confirmar que se puede ejecutar directamente en la terminal:
|
|
Cómo reduce el contexto de revisión del código
El proceso de composición se puede simplificar para:
|
|
Los nodos del gráfico incluyen funciones, clases, archivos e importaciones, y los bordes representan relaciones como llamadas, herencia y cobertura de prueba. Después de que PR modifica un archivo, la herramienta busca:
- Qué funciones y clases se cambian directamente;
- Qué llamantes o dependencias pueden verse afectados;
- Qué flujos de ejecución pasan por estos nodos;
- Si existen pruebas correspondientes y si existen lagunas en la cobertura de las pruebas;
- Qué archivos vale la pena leer para la revisión de la IA.
De esta manera, la IA no tiene que depender únicamente de búsquedas de nombres de archivos, ni tiene que escanear todo el repositorio de forma predeterminada. Para llamadas entre módulos y bases de código desconocidas, esto hace que sea más fácil detectar efectos indirectos que simplemente lanzar una diferencia de PR al modelo.
Si desea obtener información sobre el gráfico de conocimiento del código general y el análisis de la arquitectura, puede comparar el [tutorial del gráfico de conocimiento del código local de CodeGraph] (/es/2026/05/23/codegraph-local-code-knowledge-graph-ai-coding-agent/) y el [flujo de trabajo del gráfico de Claude Code de Graphify] (/es/2026/05/21/safishamsi-graphify-ai-code-knowledge-graph/). code-review-graph está más orientado hacia el impacto del cambio, la puntuación de riesgos y la revisión de relaciones públicas.
Utilizado en Codex o Claude Code
Después de completar la instalación y composición, puede pedirle tareas directamente al asistente de IA:
|
|
El proyecto también proporciona 3 comandos de barra diagonal de uso común:
|
|
Un proceso de revisión práctico es:
- Confirme que
code-review-graph statuses normal en el directorio raíz del almacén; - Modificar el código o cambiar a la sucursal a revisar;
- Ejecute
code-review-graph updatepara actualizar las piezas modificadas; - Ejecute
review-deltaoreview-pren Codex o Claude Code; - Primero observe el radio de influencia, la función de riesgo y la brecha de prueba, y luego deje que AI lea el código fuente necesario;
- Finalmente ejecute las pruebas originales del proyecto en lugar de utilizar los resultados del gráfico como reemplazos de las pruebas.
La CLI también proporciona los comandos diarios correspondientes:
|
|
watch es adecuado para el desarrollo continuo; detect-changes se utiliza para analizar los cambios actuales; visualize generará diagramas HTML interactivos para una fácil visualización de comunidades de código, concentradores, puentes y acoplamientos de excepciones.
¿Qué herramienta MCP debería llamarse primero?
El proyecto proporciona una variedad de herramientas de consulta MCP. No es necesario recuperar el mapa completo de una sola vez para las conversaciones cotidianas; se recomienda comenzar con un contexto mínimo:
| Propósito | Herramientas de sugerencias |
|---|---|
| Consigue primero la entrada minimalista | get_minimal_context_tool |
| Ver el alcance de un cambio | get_impact_radius_tool |
| Obtenga el contexto necesario para la revisión | get_review_context_tool |
| Consulta de llamador, prueba, importación o herencia | query_graph_tool |
| Ver flujo de ejecución afectado | get_affected_flows_tool |
| Verifique los riesgos y las brechas en las pruebas | detect_changes_tool |
| Comprender la arquitectura general | get_architecture_overview_tool |
Si la herramienta MCP no aparece, puede consultar la [guía de solución de problemas de fallas de llamada de la herramienta MCP] (/es/2026/07/08/mcp-tool-call-failure-troubleshooting-faq/), enfocándose en verificar la ubicación del archivo de configuración, si el comando está en la RUTA y si el directorio de trabajo y el editor se han reiniciado.
Mantenga el mapa actualizado
Después del primer build, no es necesario reconstruir todo el repositorio cada vez. Las actualizaciones incrementales se pueden realizar manualmente:
|
|
También puedes continuar monitoreando:
|
|
Con los enlaces de plataforma compatibles habilitados, se pueden activar actualizaciones incrementales cuando se guarda o confirma un archivo. En el ejemplo dado en el README oficial, un proyecto de aproximadamente 2900 archivos se puede actualizar en 2 segundos cuando solo se vuelven a analizar unos pocos archivos modificados, pero el tiempo real aún depende del tamaño del repositorio, el idioma, el disco y las capacidades de posprocesamiento.
Si Git ya rastrea su archivo de compilación, proveedor o directorio grande, pero no desea ingresar al gráfico, puede crear .code-review-graphignore en el directorio raíz del repositorio:
|
|
En los repositorios de Git, la herramienta tiene como valor predeterminado git ls-files como rango de índice, por lo que los archivos no rastreados por Git y excluidos por .gitignore generalmente no se indexan.
Conéctese a GitHub Action para realizar una verificación de riesgos de relaciones públicas
code-review-graph también se puede ejecutar en GitHub Actions. El ejemplo oficial README actual es:
|
|
La acción redactará y consultará localmente en CI Runner, y escribirá la función de riesgo, el flujo de ejecución afectado y las brechas de prueba en el PR. Antes de la adopción formal, debe verificar la última versión o README del almacén, corregir una versión clara y no copiar versiones de muestra que puedan estar desactualizadas durante mucho tiempo.
Si el equipo solo quiere observar los resultados, puede dejar que el flujo de trabajo comente primero; Después de confirmar que la tasa y la velocidad de falsos positivos son aceptables, pueden considerar habilitar fail-on-risk como puerta de fusión.
Cómo entender correctamente el punto de referencia de ahorro de tokens
El README oficial en inglés informa que en las pruebas tema por tema de 6 repositorios reales de código abierto, la reducción media de tokens fue de aproximadamente 82 veces, con un rango de aproximadamente 38 a 528 veces, en relación con la línea de base de “leer todo el corpus de código”. 528 veces proviene de una única mejor muestra, lo que no es un resultado que los proyectos ordinarios puedan lograr.
Cosas a tener en cuenta al leer estos números:
- La lectura completa del almacén es un límite superior ideal. Un agente maduro primero buscará y luego leerá una pequeña cantidad de archivos;
- Para pequeñas modificaciones de un solo archivo, los bordes, rangos de influencia y resúmenes de estructura devueltos por el gráfico pueden ser mayores que la lectura directa de la diferencia;
- Algunos puntos de referencia que afectan el análisis utilizan la verdad fundamental derivada del mismo gráfico, que tiene circularidad y debe considerarse como un límite superior;
- Todavía hay margen de mejora en la clasificación de búsqueda, JavaScript y detección del flujo de ejecución de Go;
- Graph tiende a informar en exceso algunos archivos potencialmente afectados para reducir el riesgo de que falten dependencias.
Por lo tanto, no escriba “hasta 528x” en el presupuesto de costos de su equipo. Un método más confiable es comparar el mismo lote de RP en su propio repositorio: registre la cantidad de archivos realmente leídos por la IA, la longitud del contexto, los falsos positivos, los falsos negativos y el tiempo de revisión.
Solución de problemas comunes
AI no puede ver la herramienta MCP después de la instalación
Primer control:
|
|
Luego vuelva a ejecutar la instalación de la plataforma especificada y reinicie la herramienta:
|
|
Si se instala utilizando un entorno virtual, es posible que la herramienta de IA no encuentre el mismo entorno Python cuando se inicia. pipx o uvx suelen ser más adecuados como puntos de entrada CLI globales.
Los resultados del gráfico no contienen códigos nuevos.
Primera ejecución:
|
|
Confirme también que Git haya rastreado el nuevo archivo y que .gitignore o .code-review-graphignore no lo hayan excluido. Ejecute build completo si es necesario.
Las relaciones públicas pequeñas tienen más contexto
Esta es una sobrecarga fija causada por los metadatos de la estructura del gráfico. Para modificaciones que solo cambian una línea y no tienen dependencias, es más rápido leer diff directamente. Puede dejar que la IA llame a get_minimal_context_tool primero y solo expandir el contexto de revisión completo cuando se encuentren impactos entre archivos.
Cómo desinstalar de forma segura
Obtenga una vista previa del contenido que se eliminará primero:
|
|
Ejecutar después de la confirmación:
|
|
Si solo desea eliminar la integración pero conservar los datos del trazado, utilice:
|
|
¿Para qué proyectos son adecuados?
Más adecuado para:
- Grandes bases de código con muchas llamadas entre archivos;
- monorepo, almacén multilingüe y proyectos de colaboración entre varias personas;
- Utilice con frecuencia Codex, Claude Code o Cursor para revisar relaciones públicas;
- Necesidad de realizar un seguimiento de las personas que llaman, probar las lagunas y el flujo de ejecución;
- No quiero que el gráfico del código central dependa de bases de datos externas en la nube.
No es necesariamente necesario:
- Pequeños proyectos con sólo unos pocos archivos;
- Principalmente revisar documentación o cambios de configuración;
- Cada modificación se limita a un archivo único e independiente;
- El equipo no tiene voluntad de mantener el índice y lidiar con falsos positivos.
Resumen
code-review-graph Agrega una capa de indexación estructural continuamente actualizada a la revisión del código de IA. Puede ayudar a herramientas como Codex y Claude Code a pasar de “buscar archivos que parecen relevantes” a “analizar el impacto de los cambios a lo largo de las relaciones de llamada, dependencia y prueba”.
Para un uso práctico, comience con un PR común: instale, enmarque, ejecute una revisión incremental y luego compare los resultados con la revisión manual y las pruebas reales. Si puede identificar de manera confiable los impactos entre archivos y reducir las lecturas irrelevantes, entonces conectar un reloj, un gancho o una GitHub Action hará que sea más fácil evaluar los beneficios que habilitar todo inicialmente.
Dirección del proyecto: tirth8205/code-review-graph