Kimi K3 em repositórios grandes: contexto precisa de organização
Uma janela extensa de contexto não substitui mapa do projeto, critérios de aceite e registro das decisões ao longo de uma tarefa.
A documentação de Kimi K3 informa uma janela de contexto de um milhão de tokens. É uma capacidade declarada do modelo, não uma demonstração de que todo repositório será entendido corretamente quando enviado de uma vez. A utilidade do contexto depende também da organização e da relevância do material.
Em um projeto grande, o problema frequentemente não é a falta de texto. Há instruções antigas, módulos com nomes parecidos, exemplos de testes que já não representam produção e decisões nunca registradas. Aumentar o espaço disponível pode permitir incluir mais desses elementos sem resolver as contradições entre eles.
Comece por um mapa que ajude a decidir
Identifique o ponto de entrada, o componente responsável pela regra em análise e os testes relacionados. Informe qual comportamento está errado e como reproduzi-lo. Em vez de pedir “entenda este monorepo”, peça que o agente localize o caminho de uma operação concreta, indicando os ficheiros usados para sustentar a explicação.
Uma boa primeira resposta deve poder ser conferida. Se o agente afirma que uma validação ocorre no servidor, ele precisa apontar o trecho correspondente. Quando só existe uma verificação de interface, essa diferença muda a solução. O mapa deve reduzir a busca, não produzir uma descrição genérica de todas as pastas.
Envie contexto em torno da pergunta
Para corrigir uma regra de frete, normalmente interessa conhecer o cálculo, a origem dos dados, os contratos de entrada e os casos de teste. O histórico completo de campanhas de marketing pode ser irrelevante. Se surgir uma dependência nova, acrescente o material necessário e explique por que ela passou a fazer parte da investigação.
Essa seleção também ajuda quem revisa. Uma solicitação com dez ficheiros pertinentes é mais fácil de reconstruir do que uma conversa que mistura muitos assuntos sem indicar sua relação. Não existe um número ideal de ficheiros para toda tarefa; existe uma justificativa para cada conjunto incluído.
Sessões longas precisam deixar um registro fora do chat
A documentação de sessões do Kimi Code descreve persistência e retomada de conversas. Mesmo com esse recurso, mantenha um resumo de trabalho no projeto: objetivo, decisões confirmadas, ficheiros alterados, verificações executadas e próximo ponto de validação.
Como exemplo hipotético, uma migração é interrompida depois de adaptar consultas, mas antes de revisar as permissões. Um resumo que diga apenas “migração quase pronta” pode levar outra sessão a encerrar o trabalho cedo. Um registro que destaque a verificação pendente conserva a diferença entre implementação parcial e comportamento comprovado.
Revise as mudanças em partes compreensíveis
Divida alterações por comportamento, mantendo dependências claras entre elas. Uma etapa pode preparar uma interface interna; outra muda os consumidores; a seguinte remove a compatibilidade antiga depois dos testes. Essa ordem não é uma receita universal, mas exemplifica como tornar a revisão possível sem exigir que alguém compreenda uma mudança enorme de uma vez.
Ao terminar, confronte a explicação do agente com as alterações reais e execute os casos relevantes. A quantidade de contexto consumido não serve como evidência de correção. O guia de trabalho com Kimi Code aborda a execução das tarefas; a comparação entre modelos explica como registrar as condições do ensaio. Em um repositório grande, organização do trabalho continua sendo parte da solução.
Sobre o autor
Tiago F SantiagoComentários
Ainda sem comentários
Partilhe uma dúvida ou experiência relacionada com o artigo.
Artigos relacionados
