Com base em um caso real de programação automática com Claude Code, compartilho algumas técnicas de prompts

2/11/2026
4 min read

Este artigo, através de um caso real, compartilha com todos um exemplo de uso real do Claude Code. Antes de compartilhar, vamos fazer uma pequena pesquisa

Requisito original: um usuário pago e respeitado desejava que eu adicionasse o horário de modificação do artigo

À primeira vista, esse requisito parece um pouco difícil de implementar. Porque os artigos do meu site não estão armazenados em um banco de dados, todos são construídos usando SSG do next.js. Eles simplesmente não têm um horário de atualização.

Uma técnica aqui é: ao resolver problemas, não devemos alimentar diretamente o requisito original para o Claude Code, pelas seguintes razões

1. O requisito original é relativamente vago, pode haver mal-entendidos. Se houver um mal-entendido, mesmo que ele adicione um horário, esse horário pode não ser confiável

2. O consumo de Token do Claude Code é realmente muito caro. Portanto, requisitos vagos podem levar a um grande consumo de Token sem sentido

Portanto, precisamos decompor o requisito original. Primeiro consultei no deepseek, que me deu duas soluções

1. Horário de construção do arquivo. A cada build, precisamos obter o horário de construção do arquivo. Mas a estratégia de empacotamento do turbopack é um pouco diferente. A cada construção, o hash do arquivo muda, então esse horário de construção pode não ser confiável

2. Horário de commit do git. Pensei que essa deveria ser uma opção mais confiável

Com uma direção geral de solução, tive este prompt simples: Compilar o horário de commit do git no cabeçalho de cada artigo .mdx

O Claude Code é bastante confiável. Se o prompt for preciso, geralmente não há problemas. Ele simplesmente executa tudo rapidamente

Depois de consumir 7 dólares do meu crédito, levando cerca de 20 minutos, finalmente foi executado com sucesso.

Como esperado, ocorreu um imprevisto: ele pulou a modificação de 171 arquivos.

Um ponto muito problemático aqui é que, na verdade, os arquivos pulados apenas receberam um parâmetro adicional pass, todo o resto era exatamente o mesmo

<PostLayout pass>...

Mas ele não foi flexível, definindo esse parâmetro extra como um componente personalizado completamente diferente. E então pulou sem processar ~ ~

import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
  const gitInfo = getGitFileInfo('src/app/seu_caminho/page.mdx');
  return (
    
      {children}
    
  );
}

Mas a situação real é que eu precisava deste resultado, e o resultado da execução seria completamente idêntico.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    
      {children}
    
  );
}

E então, nesse momento, caí em uma armadilha com o prompt

Digitei o prompt novamente: Refatore os 171 arquivos pulados usando o mesmo método acima

Minha expressão, pensando bem, tem um pouco de ambiguidade. Porque o Claude Code já me deu uma solução sugerida, mas eu não aceitei essa solução. Minha intenção era modificar os arquivos pulados usando o mesmo esquema dos centenas de arquivos já modificados. Mas durante a execução, ele entendeu como: a solução que ele sugeriu acima

Essa ambiguidade fez com que ele executasse por 20 minutos seguindo a solução que eu não queria, ocorrendo ainda 2 erros de auto-correção no meio, consumindo meus tokens vorazmente. As duas interpretações ambíguas começaram a conflitar, causando erros.

Finalmente, tive que abandonar essa execução e esclarecer novamente minha intenção.

Resumo

1. Nos prompts, é melhor incluir soluções relativamente estáveis e precisas. Quanto menos a IA precisar pensar, melhor, isso pode reduzir a taxa de alucinações.

2. Os prompts de requisitos não devem ter ambiguidade. A ambiguidade pode facilmente levar a erros. Embora o Claude Code possa eventualmente corrigir, isso causará um grande consumo de tokens. E como os LLMs produzem resultados com base em mecanismos de previsão, mal-entendidos ou ambiguidades iniciais farão com que cada passo subsequente se afaste ainda mais na direção errada. Ele ainda tentará ser logicamente consistente, gerando coisas que não existem, piorando cada vez mais o problema e aumentando a dificuldade de revisão do desenvolvedor. Se você for enganado por suas alucinações, as consequências podem ser graves.

3. As restrições da linguagem natural não são tão precisas quanto o código. Incluir nomes de arquivos, variáveis de código, termos específicos de código e terminologia técnica nos prompts reduzirá drasticamente as alucinações do Claude Code.

Published in Technology

You Might Also Like