Projetos no ChatGPT e no Claude: como montar contexto fixo

Projetos no ChatGPT e no Claude: como montar contexto fixo

Um projeto no ChatGPT ou no Claude é um espaço de trabalho que guarda instruções e arquivos de base, de modo que cada conversa nova dentro dele comece com o mesmo contexto. Para montar um, escolha uma tarefa recorrente, escreva instruções curtas sobre papel, formato e limites, anexe poucos documentos confiáveis e defina uma pessoa responsável por revisá-los em ciclo fixo. A configuração inicial é a parte fácil: o que mantém o projeto útil é a rotina de atualização.

Principais pontos

• Projeto serve para tarefas que se repetem e dependem das mesmas regras, do mesmo tom e dos mesmos documentos.
• As instruções devem dizer quem a IA é naquela tarefa, o que entregar, em que formato e o que nunca fazer.
• Poucos arquivos bons funcionam melhor do que uma pasta inteira despejada, e cada um precisa de data de revisão e dono.
• Contexto envelhece: sem rotina de revisão, o assistente passa a responder com regras que a empresa já mudou.
• Dados pessoais, segredos e documentos de terceiros pedem decisão prévia, não improviso.

O que é um projeto e quando ele vale a pena?

Nas duas ferramentas, a ideia é parecida: você cria um espaço com um nome, escreve instruções que valem para todas as conversas dentro dele e anexa arquivos que o assistente pode consultar. Em vez de colar o mesmo texto de contexto toda vez que alguém abre um chat, o contexto já está lá. Os detalhes variam entre ChatGPT e Claude (como os arquivos são consultados, o que é compartilhado com a equipe, quais planos oferecem o recurso e quais são os limites). Confirme isso na documentação oficial de cada produto antes de decidir, porque esses pontos mudam com o tempo.

Vale a pena quando a tarefa tem três características: acontece com frequência, segue regras que cabem em uma página ou duas e depende de material de referência estável. Exemplos comuns: rascunhar respostas a pedidos de orçamento, resumir atas no formato da empresa, revisar textos conforme um guia de marca, preparar a primeira versão de relatórios semanais.

Não vale a pena quando a tarefa é única, quando cada caso exige consulta a sistemas internos em tempo real ou quando o conteúdo é sensível demais para sair do ambiente da empresa. Nesses casos, um projeto vira uma falsa sensação de controle.

Uma observação sobre a origem do que escrevemos aqui: as descrições de recursos vêm da documentação das ferramentas e devem ser conferidas lá. As recomendações de estrutura, rotina e revisão vêm de experiência de implementação e são tratadas como boas práticas, não como regra oficial.

O que escrever nas instruções do projeto?

Instruções são o contrato do assistente com a tarefa. Texto longo e vago atrapalha, e texto curto e específico ajuda. Um bom bloco de instruções costuma ter estas partes:

• Papel e objetivo: para quem o assistente trabalha e qual resultado a tarefa entrega.
• Público e tom: quem vai ler o resultado e como a empresa fala com essa pessoa.
• Formato de saída: estrutura fixa, tamanho aproximado, o que vem primeiro e o que fica de fora.
• Fontes permitidas: quais arquivos do projeto valem como verdade e o que fazer quando a resposta não estiver neles.
• Limites: o que o assistente nunca deve prometer, inventar ou decidir sozinho.
• Quando parar e perguntar: lista de situações em que ele deve pedir informação ou sinalizar revisão humana.

A instrução sobre ausência de informação é a mais subestimada. Escreva algo como: se o dado não estiver nos arquivos, diga que não encontrou e liste o que falta, sem estimar. Isso reduz respostas plausíveis e erradas. Para quem já escreve instruções de atendimento, o raciocínio é o mesmo descrito em como escrever prompt para atendimento ao cliente com IA.

Evite colar políticas inteiras dentro das instruções. Instrução diz como trabalhar, e o arquivo de base diz o que é verdade. Misturar os dois dificulta a atualização, porque você passa a mexer no contrato toda vez que um preço de tabela, prazo ou regra interna muda.

Quais arquivos de base entram e quais ficam de fora?

A regra prática é: entra o que o assistente precisaria consultar para fazer a tarefa bem, e só isso. A Anthropic descreve, em seu material sobre engenharia de contexto para agentes, que o contexto é um recurso limitado e que o objetivo é reunir o menor conjunto de informação que leve ao resultado desejado. Para um projeto de uso diário, isso se traduz em curadoria. Para entender o limite técnico por trás disso, vale ler sobre a janela de contexto em IA.

Entram bem:

• Guia de tom e exemplos aprovados de boas respostas ou entregas.
• Regras de negócio em versão enxuta, com data de revisão no início do arquivo.
• Modelos de documento (proposta, ata, relatório) com os campos já definidos.
• Glossário com os termos da empresa e as grafias corretas de produtos e serviços.
• Lista de perguntas frequentes já respondidas pela equipe.

Ficam de fora:

• Planilhas com dados de clientes, contratos assinados e qualquer arquivo com dados pessoais sem necessidade clara.
• Versões antigas e rascunhos que se contradizem. O assistente não sabe qual é a vigente.
• Documentos longos que ninguém revisou, só porque estavam à mão.
• Credenciais, chaves de acesso e senhas, em qualquer formato.

Dê nomes de arquivo que expliquem o conteúdo e a versão, como guia-de-tom-revisado-em-mes-ano. Quando o assistente cita a fonte, o nome do arquivo ajuda a equipe a conferir.

Como montar o primeiro projeto, passo a passo

Comece pequeno e com uma única tarefa. O roteiro abaixo funciona nas duas ferramentas.

• Passo 1: escolha a tarefa e descreva como ela é feita hoje, com entrada, saída e quem revisa.
• Passo 2: junte três a cinco exemplos reais já aprovados, com dados pessoais removidos.
• Passo 3: escreva as instruções com as seis partes da seção anterior, em uma página.
• Passo 4: separe os arquivos de base, confira se não se contradizem e coloque data e responsável em cada um.
• Passo 5: teste com casos antigos cujo resultado correto você já conhece e compare lado a lado.
• Passo 6: anote onde o assistente errou e corrija a causa, que costuma ser instrução ambígua ou arquivo desatualizado.
• Passo 7: libere para um grupo pequeno, com a regra de que toda entrega externa passa por revisão humana.
• Passo 8: marque a primeira revisão do projeto no calendário antes de liberar.

O passo 5 é o que separa um projeto útil de uma demonstração bonita. Se você tem dez pedidos antigos e sabe como foram bem respondidos, rode-os e observe as diferenças. Para estruturar esse tipo de checagem em escala maior, o guia da OpenAI sobre avaliações (evals) mostra a lógica, mesmo que o seu teste comece em uma planilha simples.

Cenário ilustrativo: respostas a pedidos de orçamento

Cenário ilustrativo: uma empresa de serviços técnicos recebe pedidos de orçamento por e-mail e por formulário. Hoje, cada vendedor escreve a resposta do zero e o tom varia. O gestor cria um projeto chamado Primeira resposta de orçamento.

As instruções definem que o assistente prepara um rascunho com saudação, resumo do que o cliente pediu, perguntas que faltam para orçar e próximos passos. Elas proíbem informar valores e prazos, porque esses dados dependem de avaliação humana. Os arquivos de base são o guia de tom, dois modelos de resposta aprovados, a lista de serviços oferecidos com descrição curta e um documento com as perguntas padrão de levantamento.

O vendedor cola o pedido do cliente, remove dados desnecessários e recebe o rascunho. Se o pedido citar um serviço fora da lista, o assistente avisa em vez de inventar. O vendedor revisa, ajusta e envia. A cada mês, o gestor confere se a lista de serviços e as perguntas padrão ainda refletem a operação e substitui o arquivo, mantendo a data de revisão no topo.

Note o que o projeto não faz: não decide preço, não acessa o sistema da empresa e não envia nada sozinho. Essa fronteira é proposital.

Como manter o contexto atualizado sem virar burocracia

O erro mais comum é tratar o projeto como instalação única. Meses depois, o assistente continua seguindo uma política que a empresa já trocou, e ninguém percebe porque o texto continua bem escrito. Para evitar isso, três hábitos bastam.

Primeiro, atribua um dono. Uma pessoa responde pelo projeto, mesmo que várias editem. Segundo, registre um calendário de revisão, com frequência proporcional à velocidade de mudança do assunto: regras que mudam toda semana pedem revisão semanal, e guias de tom podem esperar mais. Terceiro, mantenha um registro de mudanças curto, com data, o que mudou e por quê, no próprio arquivo ou em um documento separado.

Um gatilho adicional ajuda: toda vez que alguém corrigir o mesmo erro do assistente duas vezes, isso vira item de manutenção. Ou a instrução precisa ficar mais clara, ou falta um arquivo, ou existe um arquivo errado. Corrigir só no chat resolve aquele caso e deixa o problema no projeto.

Por fim, defina quando aposentar. Se ninguém usa o projeto há muito tempo ou se a tarefa mudou, arquive. Projeto abandonado com regras antigas é risco, não ativo.

Que cuidados de dados e segurança aplicar?

Projetos concentram contexto, e contexto concentrado merece regra. Antes de anexar qualquer arquivo, responda: esse documento tem dados pessoais? Precisa ter? Quem da equipe terá acesso ao projeto? Para onde esses dados vão quando uso a ferramenta? Sobre a última pergunta, vale ler sobre transferência internacional de dados com IA e a LGPD e consultar as orientações da ANPD. Defina também o que a equipe pode ou não colocar nas ferramentas, como descrito em política de uso de ChatGPT na empresa.

Há ainda o risco de instruções escondidas em arquivos ou textos colados. Um documento de terceiros pode conter comandos que tentam desviar o assistente. A folha de referência da OWASP sobre prompt injection explica o problema e as defesas. Na prática de um projeto, a defesa mais simples é só anexar material que a empresa produziu ou revisou, e nunca agir sobre uma saída sem olhar.

No método que usamos em consultoria, o projeto passa pelas mesmas quatro etapas de qualquer uso de IA. Mapear: descrever a tarefa como ela é feita hoje e quem revisa. Limitar: definir quais dados entram e quais ações o assistente nunca executa. Pilotar: testar uma tarefa real com casos conhecidos e um critério de sucesso combinado. Transferir: entregar dono, calendário de revisão e a decisão de expandir, ajustar ou parar.

Perguntas frequentes

Qual a diferença entre um projeto e um GPT ou assistente personalizado? Um projeto agrupa conversas, instruções e arquivos em um espaço de trabalho, e é pensado para uma linha de trabalho contínua. Assistentes personalizados costumam ser empacotados para reutilização e compartilhamento mais amplo. As fronteiras entre os recursos mudam, então confira a documentação atual de cada ferramenta.

Com que frequência devo revisar os arquivos de base? Depende da velocidade de mudança do assunto. Regras comerciais, prazos e políticas internas pedem revisão em ciclo curto, e guias de tom e glossários podem esperar mais. O importante é que a data e o responsável estejam escritos em cada arquivo e que a revisão esteja no calendário.

Posso colocar dados de clientes no projeto? Só se houver necessidade clara, base legal adequada e regra definida de acesso, e a primeira escolha deve ser remover ou anonimizar o que não for indispensável. Antes de decidir, entenda para onde os dados são enviados e o que a política da ferramenta prevê. Em caso de dúvida, alinhe com quem cuida da LGPD na empresa.

O projeto substitui treinar ou ajustar um modelo? Não. O projeto fornece contexto para cada conversa, mas não altera o modelo em si. Para a maioria das tarefas recorrentes de escritório, instruções claras e bons arquivos de base já resolvem, e o ajuste de modelo fica para casos específicos que justifiquem o esforço.

Fontes

• Anthropic: Effective context engineering for AI agents
• OWASP: prompt injection prevention
• OpenAI: evals guide
• ANPD: Autoridade Nacional de Proteção de Dados