E também me perguntaram sobre o experimento relacionado ao número de encadeamentos de prompts,
Na verdade, isso pode acabar sendo, no sentido mais coloquial, um bom elemento para o autor trapacear.
O próprio ato de desenvolver envolve muitas opções de caminho, e, se você acumular prompts em uma direção em que o uso de tokens aumente mais, esse número vai crescer ainda mais como uma bola de neve.
Na pesquisa, existe uma filosofia chamada Cumulative Science.
Como, pelo menos pelos meus critérios, eu ainda não encontrei sequer um estudo sobre uso de tokens em um único comando,
em vez de partir imediatamente para um estudo de N execuções, optei por focar em tratar de um teste sólido de uma única execução e de suas conclusões,
quanto ao estudo de N execuções, ele pode dar continuidade a esta pesquisa mais adiante.
Resumindo brevemente, ele aborda testes e resultados mostrando que a qualidade das saídas varia de acordo com a codebase fornecida como entrada para a IA.
Isso significa que, dependendo da qualidade e da direção da codebase inicial, a qualidade do código produzido em seguida pode se manter ou continuar piorando.
Ou seja, o custo de refatoração na fase inicial do projeto e o custo de refatoração de um projeto já bastante avançado podem ser muito diferentes.
Se a pessoa que perguntou for desenvolvedora, talvez já tenha ouvido a expressão "um porta-aviões sobre um veleiro" ao menos uma vez.
Refatoração é um tema profundo, em que o momento em que ela deve ser feita — ou os princípios e o design aplicados no início do projeto — podem alterar enormemente os custos.
Em vez de incluir isso como variável e chegar a uma conclusão instável,
foi realizado um teste que permite explicar com segurança pelo menos o seguinte: "ah, então quando a qualidade da codebase é boa, o uso de tokens diminui".
O espectro de quem pratica vibe coding é amplo, indo de não desenvolvedores a desenvolvedores experientes. Dependendo do nível de conhecimento que cada um possui, a qualidade do resultado pode variar enormemente, independentemente do conteúdo deste texto.
Alguém pode naturalmente trabalhar assumindo o uso do cursor e manter em .cursorrules convenções básicas de OOP e regras de separação entre classes/métodos, operando de uma forma que quase não exige refatoração,
enquanto outra pessoa pode estar produzindo código de baixo nível por simplesmente não compreender nem os pontos principais mais básicos.
Além disso, já existem muitos textos e relatos defendendo, de forma geral, que a qualidade do código deve ser mantida alta por meio da configuração de regras do projeto.
Isso sugere a possibilidade de que algumas pessoas já estejam obtendo ganhos em termos de uso de tokens mesmo sem refatoração explícita.
No entanto, os casos acima não organizam de forma clara a redução de uso de tokens por unidade de execução a partir da definição dessas regras. Por isso, neste texto foi testada a diferença no uso de tokens de acordo com a qualidade da codebase, e os resultados foram organizados.
Ou seja, dependendo do usuário, o número de refatorações explícitas volta a ser, por si só, uma variável de 0 a n vezes,
E acho que a intenção essencial deste texto pode ser entendida como uma explicação de por que vale a pena se preocupar com uma codebase de boa qualidade.
Não entendi muito bem o que você quis dizer no comentário. O meu ponto era que, para comparar os dois métodos de forma justa, não deveríamos comparar o número total de tokens consumidos? Refatoração também não consome tokens?
Além disso, o que você respondeu nem está escrito no texto e também me parece não ter sido testado no experimento. Pelo que entendi, você quer dizer que, em vez de comparar os tokens por consulta única, ao fazer várias consultas o overhead da refatoração diminui e, como o número esperado de tokens por consulta cai, haveria ganho no total de tokens. Mas isso só valeria se, em várias consultas, a redução de custo continuasse como você imagina, o que me parece uma situação bastante idealizada. Não dá para garantir que a redução de custo causada pela refatoração será mantida independentemente do número de consultas seguintes, nem dá para assumir isso sem experimento. Se você quer sustentar esse ponto, acho que bastaria mostrar em experimento a redução de custo ao longo de mais de uma consulta. Mas o experimento não foi feito apenas uma vez e depois comparado?
Além disso, isso é só uma suposição minha, mas, se repetirmos indefinidamente as consultas para atingir o mesmo objetivo (a saída final ideal), em uma situação ideal o código deveria convergir para a mesma forma com ou sem refatoração. (A saída final ideal é única.)
Se essa for uma suposição razoável, então, à medida que as consultas se repetem, a diferença entre ter ou não refatoração diminui, então o ganho de redução de custo em tokens também tenderia a cair gradualmente. Por isso, pensando de forma mais ampla, se esse ganho de redução de custo não se sustentar por tempo suficiente, talvez a diferença no número total de tokens usados nas consultas nem seja significativa.
Como este texto tem um caráter mais próximo de uma pesquisa de "experimento",
todos os números incluídos aqui foram pensados para permitir que qualquer pessoa que leia este texto consiga "reproduzir" os resultados.
Por isso, registrei integralmente o código-fonte original utilizado e todos os procedimentos usados nos testes,
fazendo com que o foco do conteúdo esteja em fornecer informações para que todos os experimentadores possam obter os mesmos resultados.
Pela atmosfera que percebo nos comentários,
estou pensando se, daqui para frente, não seria melhor separar em dois textos: um com estilo de resumo em 3 linhas e outro para quem quiser saber os detalhes.
Se vocês puderem me dizer quais partes deste texto pareceram excessivamente complexas ou prolixas,
isso provavelmente vai me ajudar bastante na redação dos próximos textos.
É necessário comparar o código-fonte antes e depois do pré-processamento.
O subtítulo não combina muito com o conteúdo. Reorganizando, algo como "é necessária uma análise mais clara dos fatores que levam à redução de tokens" parece mais adequado como subtítulo.
Concordo com muitos pontos deste conteúdo. No entanto, a natureza deste texto também inclui o elemento de "sugerir formas realistas de aplicação para quem está lendo".
Só de ver os comentários já deixados neste texto, já dá para perceber o clima; algo que eu também descobri recentemente é que, entre os usuários de AI, estima-se que haja muitos vibecoders não desenvolvedores.
Quando se obtém um grande resultado a partir de código ajustado diretamente pelo autor, sem passar pela AI,
isso pode facilmente ser visto como o autor exibindo sua habilidade de desenvolvimento e diminuindo o valor da capacidade da AI.
Por isso, passei a tratar o resultado por meio do elemento "prompt", que outros vibecoders também podem utilizar, com exemplos que qualquer pessoa consiga perceber na prática.
Espero que, dando continuidade a esta pesquisa, surjam estudos que possam detalhar ainda mais os fatores que influenciam o uso de tokens de AI.
No vibe coding, o resultado não é concluído com um único prompt.
Se, por meio de uma única alteração estrutural, obtiver-se o efeito de reduzir a taxa de consumo de tokens de n prompts, a quantidade de tokens reduzida será refletida ao longo dessas mesmas n execuções. n é um valor determinado pelo objetivo do projeto, pelo número de funcionalidades e pela quantidade e complexidade do código necessária para isso,
e também, como os agentes recentes do Cursor / Claude Code vêm recebendo atualizações que reduzem a unidade de execução para resolver problemas de repetição infinita ou uso indiscriminado de tokens pela IA,
considero correto que o estudo sobre o valor de n em relação à complexidade do projeto seja conduzido separadamente.
Para ajudar na compreensão ao máximo, usei como exemplo a melhoria de código a partir de um código escrito pela IA com problemas estruturais, quando não há instruções adicionais.
O ponto que não deve ser ignorado aqui é que a melhoria da estrutura nunca é algo que acontece de forma absolutamente independente do desenvolvimento do código.
É algo que pode influenciar como contexto base por meio do prompt inicial ou de restrições como um ruleset de IA (.cursorrules),
e, no meio do ciclo de desenvolvimento do projeto, uma única melhoria estrutural não pode resolver tudo.
Ou seja, em vez de planejar melhorias de código em intervalos regulares, a direção mais adequada é induzir a estrutura correta como contexto base.
Além disso, parece correto que o estudo sobre a diferença entre existir ou não uma regra de instrução para indução estrutural como contexto base seja conduzido separadamente.
Resumindo o item 1,
quando há uma regra de instrução para indução estrutural como contexto base, também existe a possibilidade de o uso total de tokens diminuir, e
como existe a variável de obtenção do resultado final por meio de n comandos de prompt,
a alegação de que o uso de tokens de um único prompt de melhoria estrutural deve ser somado ao cálculo é problemática.
Eu também tive uma impressão parecida.
Entendo qual foi a intenção de quem escreveu, mas acho que o texto ficou excessivamente complexo em comparação com o que foi feito.
Parece que ele quis incorporar ao máximo no texto os detalhes usados no experimento e por isso escreveu dessa forma,
mas acho que, se resumisse apenas os pontos principais, quem se interessa por esse tipo de tema provavelmente entenderia sem dificuldade.
Acho que ficaria melhor se cortasse sem medo os detalhes e condensasse só o essencial.
Eu achei a intenção e o resultado em si interessantes.
O argumento principal parece ser que um código-fonte melhor leva a um consumo menor de tokens,
e me parece que foi feito e executado um desenho experimental relacionado a isso.
Se eu listar apenas o que entendi sobre o experimento:
Foram preparados dois códigos-fonte para consultar a IA: o código-fonte original e outro código-fonte pré-processado via prompt (?)
No GPT5 e no Sonnet, cada um dos dois códigos-fonte foi executado 5 vezes, e o consumo de tokens foi comparado
Acho que é isso.
E, se entendi corretamente, a conclusão parece ser que o código-fonte pré-processado por prompt tende, em geral, a consumir menos tokens.
É uma conclusão interessante, mas minha opinião sobre o experimento é a seguinte.
Não é uma comparação justa
Pelos números, parece que houve redução, mas acho que o correto seria comparar pelo número total de tokens necessários para processar o código-fonte.
Em outras palavras, o número de tokens usado no pré-processamento também deveria ser considerado.
Se o número de tokens usado para pré-processar for excessivamente grande, na prática isso acaba consumindo ainda mais tokens e perde o sentido; mesmo que seja pequeno, a diferença real no consumo de tokens provavelmente seria bem menor do que o texto sugere.
É preciso comparar o código-fonte antes e depois do pré-processamento
Se desconsiderarmos os tokens usados no pré-processamento, o consumo de tokens durante a consulta realmente parece ter diminuído de forma significativa.
Ainda assim, se fosse analisado exatamente que diferença no código-fonte causou esse resultado, o texto ganharia muito mais valor.
Porque isso significaria que seria possível otimizar o prompt de pré-processamento para maximizar essa diferença.
O autor diz que a refatoração da estrutura do código levou a esse resultado, mas eu não concordo e acho que ainda não dá para saber.
Porque pode haver redução no consumo de tokens mesmo quando se pede para a IA melhorar outros aspectos além da refatoração.
São necessários experimentos mais variados
Acho que seria preciso rodar o mesmo experimento em outras bases de código além da atual.
Porque é preciso avaliar se isso produz resultados bons de forma consistente ou não.
Mas entendo que, na prática, isso pode ser difícil de testar, então talvez seja melhor encarar isso apenas como referência.
Vou complementar com um resumo do conteúdo relacionado ao prompt usado adicionalmente.
De qualquer forma, isso tende a ser mais vantajoso para desenvolvedores na hora de escrever prompts voltados à melhoria estrutural. Como cada programa tem características diferentes, para obter melhorias eficientes é necessário ter algum nível de conhecimento em desenvolvimento.
Isso não significa, porém, que vibecoders não desenvolvedores não possam usar esse método. Pode haver diferença de eficiência, mas mesmo com comandos simples como "Dá uma organizada no código do projeto. Remove os códigos que não estão sendo usados.", a IA também separa e organiza arquivos e classes.
No entanto, como diferenças nos detalhes da melhoria estrutural podem gerar diferenças de eficiência, é preciso ter cuidado ao consultar os materiais.
Agradeço muito pelo interesse neste texto. Como o objetivo principal era a divulgação no exterior, o texto acabou sendo escrito em inglês, e isso parece ter causado vários tipos de problemas.
Por isso, compartilho um post organizado em coreano.
O ponto principal é que, após instruir a IA a refatorar a estrutura do código, a quantidade de tokens consumidos diminuiu.
Por outro lado, também dá para explicar que, se os comandos continuarem sendo dados enquanto o código estiver com defeitos estruturais, o uso de tokens aumenta.
Resumindo, a mensagem é que a estrutura do código-fonte precisa ser melhorada, e não que o prompt deva conter apenas o essencial de forma lógica.
É preciso colocar no prompt apenas o essencial, de forma lógica. Ou seja, quanto mais coisas você acrescenta ao prompt, mais ruído ele gera, e o código produzido como resultado também fica mais complexo e com mais ruído — é isso?
Eu também achei esta introdução e o texto original prolixos demais, como se tivessem sido escritos por alguém que não escreve bem, então foi difícil ler durante o processo.
O ponto principal é
"adicione uma instrução de uma linha contendo uma restrição estrutural para reduzir tokens"
mais ou menos isso.
E também me perguntaram sobre o experimento relacionado ao número de encadeamentos de prompts,
Na verdade, isso pode acabar sendo, no sentido mais coloquial, um bom elemento para o autor trapacear.
O próprio ato de desenvolver envolve muitas opções de caminho, e, se você acumular prompts em uma direção em que o uso de tokens aumente mais, esse número vai crescer ainda mais como uma bola de neve.
Na pesquisa, existe uma filosofia chamada
Cumulative Science.Como, pelo menos pelos meus critérios, eu ainda não encontrei sequer um estudo sobre uso de tokens em um único comando,
em vez de partir imediatamente para um estudo de N execuções, optei por focar em tratar de um teste sólido de uma única execução e de suas conclusões,
quanto ao estudo de N execuções, ele pode dar continuidade a esta pesquisa mais adiante.
Se você faz algo como engenharia civil, isso já é usado até nas aulas da universidade.
Além disso, em outro texto, já tratei da diferença no comportamento da IA conforme as diferenças na codebase.
(Isto também já foi apresentado aqui no GeekNews: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Resumindo brevemente, ele aborda testes e resultados mostrando que a qualidade das saídas varia de acordo com a codebase fornecida como entrada para a IA.
Isso significa que, dependendo da qualidade e da direção da codebase inicial, a qualidade do código produzido em seguida pode se manter ou continuar piorando.
Ou seja, o custo de refatoração na fase inicial do projeto e o custo de refatoração de um projeto já bastante avançado podem ser muito diferentes.
Se a pessoa que perguntou for desenvolvedora, talvez já tenha ouvido a expressão "um porta-aviões sobre um veleiro" ao menos uma vez.
Refatoração é um tema profundo, em que o momento em que ela deve ser feita — ou os princípios e o design aplicados no início do projeto — podem alterar enormemente os custos.
Em vez de incluir isso como variável e chegar a uma conclusão instável,
foi realizado um teste que permite explicar com segurança pelo menos o seguinte: "ah, então quando a qualidade da codebase é boa, o uso de tokens diminui".
Vou tentar explicar de novo.
O espectro de quem pratica vibe coding é amplo, indo de não desenvolvedores a desenvolvedores experientes. Dependendo do nível de conhecimento que cada um possui, a qualidade do resultado pode variar enormemente, independentemente do conteúdo deste texto.
Alguém pode naturalmente trabalhar assumindo o uso do cursor e manter em
.cursorrulesconvenções básicas de OOP e regras de separação entre classes/métodos, operando de uma forma que quase não exige refatoração,enquanto outra pessoa pode estar produzindo código de baixo nível por simplesmente não compreender nem os pontos principais mais básicos.
Além disso, já existem muitos textos e relatos defendendo, de forma geral, que a qualidade do código deve ser mantida alta por meio da configuração de regras do projeto.
Isso sugere a possibilidade de que algumas pessoas já estejam obtendo ganhos em termos de uso de tokens mesmo sem refatoração explícita.
No entanto, os casos acima não organizam de forma clara a redução de uso de tokens por unidade de execução a partir da definição dessas regras. Por isso, neste texto foi testada a diferença no uso de tokens de acordo com a qualidade da codebase, e os resultados foram organizados.
Ou seja, dependendo do usuário, o número de refatorações explícitas volta a ser, por si só, uma variável de 0 a n vezes,
E acho que a intenção essencial deste texto pode ser entendida como uma explicação de por que vale a pena se preocupar com uma codebase de boa qualidade.
Não entendi muito bem o que você quis dizer no comentário. O meu ponto era que, para comparar os dois métodos de forma justa, não deveríamos comparar o número total de tokens consumidos? Refatoração também não consome tokens?
Além disso, o que você respondeu nem está escrito no texto e também me parece não ter sido testado no experimento. Pelo que entendi, você quer dizer que, em vez de comparar os tokens por consulta única, ao fazer várias consultas o overhead da refatoração diminui e, como o número esperado de tokens por consulta cai, haveria ganho no total de tokens. Mas isso só valeria se, em várias consultas, a redução de custo continuasse como você imagina, o que me parece uma situação bastante idealizada. Não dá para garantir que a redução de custo causada pela refatoração será mantida independentemente do número de consultas seguintes, nem dá para assumir isso sem experimento. Se você quer sustentar esse ponto, acho que bastaria mostrar em experimento a redução de custo ao longo de mais de uma consulta. Mas o experimento não foi feito apenas uma vez e depois comparado?
Além disso, isso é só uma suposição minha, mas, se repetirmos indefinidamente as consultas para atingir o mesmo objetivo (a saída final ideal), em uma situação ideal o código deveria convergir para a mesma forma com ou sem refatoração. (A saída final ideal é única.) Se essa for uma suposição razoável, então, à medida que as consultas se repetem, a diferença entre ter ou não refatoração diminui, então o ganho de redução de custo em tokens também tenderia a cair gradualmente. Por isso, pensando de forma mais ampla, se esse ganho de redução de custo não se sustentar por tempo suficiente, talvez a diferença no número total de tokens usados nas consultas nem seja significativa.
Como este texto tem um caráter mais próximo de uma pesquisa de "experimento",
todos os números incluídos aqui foram pensados para permitir que qualquer pessoa que leia este texto consiga "reproduzir" os resultados.
Por isso, registrei integralmente o código-fonte original utilizado e todos os procedimentos usados nos testes,
fazendo com que o foco do conteúdo esteja em fornecer informações para que todos os experimentadores possam obter os mesmos resultados.
Pela atmosfera que percebo nos comentários,
estou pensando se, daqui para frente, não seria melhor separar em dois textos: um com estilo de resumo em 3 linhas e outro para quem quiser saber os detalhes.
Se vocês puderem me dizer quais partes deste texto pareceram excessivamente complexas ou prolixas,
isso provavelmente vai me ajudar bastante na redação dos próximos textos.
Concordo totalmente. Críticas desse tipo são muito bem-vindas.
Ninguém vive sozinho no mundo, e as capacidades ou circunstâncias de cada pessoa são diferentes.
Eu também sou apenas um desenvolvedor e não consigo realizar todos os testes com recursos próprios.
Espero que este texto sirva como semente, gere um impacto positivo em muitas pessoas e se torne o ponto de partida para muitas pesquisas futuras.
O subtítulo não combina muito com o conteúdo. Reorganizando, algo como "é necessária uma análise mais clara dos fatores que levam à redução de tokens" parece mais adequado como subtítulo.
Concordo com muitos pontos deste conteúdo. No entanto, a natureza deste texto também inclui o elemento de "sugerir formas realistas de aplicação para quem está lendo".
Só de ver os comentários já deixados neste texto, já dá para perceber o clima; algo que eu também descobri recentemente é que, entre os usuários de AI, estima-se que haja muitos vibecoders não desenvolvedores.
Quando se obtém um grande resultado a partir de código ajustado diretamente pelo autor, sem passar pela AI,
isso pode facilmente ser visto como o autor exibindo sua habilidade de desenvolvimento e diminuindo o valor da capacidade da AI.
Por isso, passei a tratar o resultado por meio do elemento "prompt", que outros vibecoders também podem utilizar, com exemplos que qualquer pessoa consiga perceber na prática.
Espero que, dando continuidade a esta pesquisa, surjam estudos que possam detalhar ainda mais os fatores que influenciam o uso de tokens de AI.
Se, por meio de uma única alteração estrutural, obtiver-se o efeito de reduzir a taxa de consumo de tokens de n prompts, a quantidade de tokens reduzida será refletida ao longo dessas mesmas n execuções.
né um valor determinado pelo objetivo do projeto, pelo número de funcionalidades e pela quantidade e complexidade do código necessária para isso,e também, como os agentes recentes do Cursor / Claude Code vêm recebendo atualizações que reduzem a unidade de execução para resolver problemas de repetição infinita ou uso indiscriminado de tokens pela IA,
considero correto que o estudo sobre o valor de
nem relação à complexidade do projeto seja conduzido separadamente.O ponto que não deve ser ignorado aqui é que a melhoria da estrutura nunca é algo que acontece de forma absolutamente independente do desenvolvimento do código.
É algo que pode influenciar como contexto base por meio do prompt inicial ou de restrições como um ruleset de IA (
.cursorrules),e, no meio do ciclo de desenvolvimento do projeto, uma única melhoria estrutural não pode resolver tudo.
Ou seja, em vez de planejar melhorias de código em intervalos regulares, a direção mais adequada é induzir a estrutura correta como contexto base.
Além disso, parece correto que o estudo sobre a diferença entre existir ou não uma regra de instrução para indução estrutural como contexto base seja conduzido separadamente.
Resumindo o item 1,
a alegação de que o uso de tokens de um único prompt de melhoria estrutural deve ser somado ao cálculo é problemática.
Eu também tive uma impressão parecida.
Entendo qual foi a intenção de quem escreveu, mas acho que o texto ficou excessivamente complexo em comparação com o que foi feito.
Parece que ele quis incorporar ao máximo no texto os detalhes usados no experimento e por isso escreveu dessa forma,
mas acho que, se resumisse apenas os pontos principais, quem se interessa por esse tipo de tema provavelmente entenderia sem dificuldade.
Acho que ficaria melhor se cortasse sem medo os detalhes e condensasse só o essencial.
Eu achei a intenção e o resultado em si interessantes.
O argumento principal parece ser que um código-fonte melhor leva a um consumo menor de tokens,
e me parece que foi feito e executado um desenho experimental relacionado a isso.
Se eu listar apenas o que entendi sobre o experimento:
Acho que é isso.
E, se entendi corretamente, a conclusão parece ser que o código-fonte pré-processado por prompt tende, em geral, a consumir menos tokens.
É uma conclusão interessante, mas minha opinião sobre o experimento é a seguinte.
Não é uma comparação justa
Pelos números, parece que houve redução, mas acho que o correto seria comparar pelo número total de tokens necessários para processar o código-fonte.
Em outras palavras, o número de tokens usado no pré-processamento também deveria ser considerado.
Se o número de tokens usado para pré-processar for excessivamente grande, na prática isso acaba consumindo ainda mais tokens e perde o sentido; mesmo que seja pequeno, a diferença real no consumo de tokens provavelmente seria bem menor do que o texto sugere.
É preciso comparar o código-fonte antes e depois do pré-processamento
Se desconsiderarmos os tokens usados no pré-processamento, o consumo de tokens durante a consulta realmente parece ter diminuído de forma significativa.
Ainda assim, se fosse analisado exatamente que diferença no código-fonte causou esse resultado, o texto ganharia muito mais valor.
Porque isso significaria que seria possível otimizar o prompt de pré-processamento para maximizar essa diferença.
O autor diz que a refatoração da estrutura do código levou a esse resultado, mas eu não concordo e acho que ainda não dá para saber.
Porque pode haver redução no consumo de tokens mesmo quando se pede para a IA melhorar outros aspectos além da refatoração.
São necessários experimentos mais variados
Acho que seria preciso rodar o mesmo experimento em outras bases de código além da atual.
Porque é preciso avaliar se isso produz resultados bons de forma consistente ou não.
Mas entendo que, na prática, isso pode ser difícil de testar, então talvez seja melhor encarar isso apenas como referência.
Parece que dar presentes inúteis está em alta... acho que vai ser legal para descobrir novos presentes inúteis.
Vou complementar com um resumo do conteúdo relacionado ao prompt usado adicionalmente.
De qualquer forma, isso tende a ser mais vantajoso para desenvolvedores na hora de escrever prompts voltados à melhoria estrutural. Como cada programa tem características diferentes, para obter melhorias eficientes é necessário ter algum nível de conhecimento em desenvolvimento.
Isso não significa, porém, que vibecoders não desenvolvedores não possam usar esse método. Pode haver diferença de eficiência, mas mesmo com comandos simples como "Dá uma organizada no código do projeto. Remove os códigos que não estão sendo usados.", a IA também separa e organiza arquivos e classes.
No entanto, como diferenças nos detalhes da melhoria estrutural podem gerar diferenças de eficiência, é preciso ter cuidado ao consultar os materiais.
Se você precisar trabalhar com informações geoespaciais, é uma ótima escolha.
Agradeço muito pelo interesse neste texto. Como o objetivo principal era a divulgação no exterior, o texto acabou sendo escrito em inglês, e isso parece ter causado vários tipos de problemas.
Por isso, compartilho um post organizado em coreano.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
O ponto principal é que, após instruir a IA a refatorar a estrutura do código, a quantidade de tokens consumidos diminuiu.
Por outro lado, também dá para explicar que, se os comandos continuarem sendo dados enquanto o código estiver com defeitos estruturais, o uso de tokens aumenta.
Resumindo, a mensagem é que a estrutura do código-fonte precisa ser melhorada, e não que o prompt deva conter apenas o essencial de forma lógica.
É preciso colocar no prompt apenas o essencial, de forma lógica. Ou seja, quanto mais coisas você acrescenta ao prompt, mais ruído ele gera, e o código produzido como resultado também fica mais complexo e com mais ruído — é isso?
Uma redundância desnecessária
Sou o autor. Obrigado pelo feedback. Vou levar isso em consideração ao escrever o próximo texto.
Eu também achei esta introdução e o texto original prolixos demais, como se tivessem sido escritos por alguém que não escreve bem, então foi difícil ler durante o processo.
O ponto principal é
"adicione uma instrução de uma linha contendo uma restrição estrutural para reduzir tokens"
mais ou menos isso.
De repente, todos os pontos desapareceram