Kimi K3 en repositorios grandes: organiza el contexto
Una ventana amplia no sustituye un mapa del proyecto, criterios de aceptación y un registro de las decisiones durante la tarea.
La documentación de Kimi K3 indica una ventana de contexto de un millón de tokens. Es una capacidad declarada, no una prueba de que cualquier repositorio se comprenderá correctamente al enviarlo entero. La utilidad del contexto también depende de la relevancia y la organización del material.
En un proyecto grande, el problema no suele ser la falta de texto. Hay instrucciones antiguas, módulos con nombres parecidos, pruebas que ya no representan producción y decisiones nunca documentadas. Aumentar el espacio permite incluir más contenido, pero no resuelve las contradicciones que existen entre sus partes.
Empieza por un mapa que ayude a decidir
Identifica el punto de entrada, el componente responsable de la regla investigada y las pruebas relacionadas. Explica qué comportamiento es incorrecto y cómo reproducirlo. En lugar de pedir que entienda todo el monorepositorio, solicita que trace una operación concreta y señale los archivos que respaldan su explicación.
Una buena primera respuesta debe poder comprobarse. Si el agente afirma que la validación ocurre en el servidor, necesita señalar el código. Descubrir que solo existe una comprobación en la interfaz cambia la solución necesaria. El mapa debe reducir la investigación, no convertirse en una descripción genérica de todas las carpetas.
Selecciona contexto alrededor de la pregunta
Para corregir una regla de envío suelen importar el cálculo, el origen de los datos, los contratos de entrada y las pruebas. El historial completo de campañas comerciales puede ser irrelevante. Cuando aparezca una dependencia nueva, añade el material necesario y explica por qué forma parte de la investigación.
La selección también facilita la revisión. Una solicitud con diez archivos pertinentes se reconstruye mejor que una conversación con muchos asuntos sin relación explicada. No hay un número ideal de archivos para todas las tareas; debe existir una razón para cada conjunto incluido. Retira las premisas obsoletas cuando cambie la evidencia.
Una sesión larga necesita registro fuera del chat
La documentación de sesiones de Kimi Code describe persistencia y reanudación de conversaciones. Incluso con esa función, conserva una nota del proyecto: objetivo, decisiones confirmadas, archivos modificados, comprobaciones realizadas y siguiente punto de validación.
Imagina una migración interrumpida tras adaptar consultas, pero antes de revisar permisos. Una nota que solo diga “migración casi terminada” puede provocar que otra sesión cierre el trabajo prematuramente. Indicar la comprobación pendiente mantiene la diferencia entre implementación parcial y comportamiento demostrado. La nota debe entenderse sin haber participado en la conversación original.
Revisa cambios en partes comprensibles
Divide las modificaciones por comportamiento y explica sus dependencias. Una etapa puede preparar una interfaz interna, otra actualizar sus consumidores y una posterior retirar la compatibilidad antigua después de probar. No es una receta universal: ilustra cómo hacer posible la revisión sin exigir comprender una modificación enorme de una vez.
Al terminar, contrasta la explicación del agente con los cambios reales y ejecuta los casos pertinentes. Consumir mucho contexto no prueba corrección. La guía de trabajo con Kimi Code aborda la ejecución; la comparación entre modelos explica cómo registrar las condiciones del ensayo. Organizar el trabajo sigue siendo parte de la solución en repositorios grandes.
Sobre el autor
Tiago F SantiagoComentarios
Todavía no hay comentarios
Comparte una pregunta o una experiencia relacionada con el artículo.
Artículos relacionados
