Bloco de Módulos 1 a 10

Público-alvo: Profissional de TI atuando com Service Desk, Microsoft 365, Entra ID, IAM, Intune, cloud, segurança, governança, documentação técnica, troubleshooting e criação de materiais de estudo.

Idioma: Português do Brasil, com termos técnicos em inglês explicados no contexto.

Nota importante sobre atualização: Recursos, nomes de modelos, limites e planos do Claude evoluem com frequência. Sempre que este material mencionar um recurso específico (limites de arquivos, modelos disponíveis, planos), valide na documentação oficial da Anthropic: https://support.claude.com (Claude.ai), https://docs.claude.com (API e recursos técnicos) e https://www.anthropic.com/news (novidades).

Visão geral deste bloco

Estes dez primeiros módulos formam a fundação completa do seu domínio sobre o Claude. Eles foram desenhados em uma progressão pedagógica deliberada: primeiro você entende o que é a ferramenta e como ela pensa (Módulos 1 e 2), depois aprende a escolher e configurar o ambiente certo (Módulos 3, 4 e 5), então desenvolve a habilidade central de todo o curso — prompt engineering (Módulo 6) — e, por fim, aprende a organizar conhecimento em escala com Projects, análise documental, RAG e Artifacts (Módulos 7 a 10).

A lógica é a de uma pirâmide: sem entender tokens e context window (Módulo 4), você não entende por que um Project com 50 documentos se comporta diferente de um chat simples (Módulo 9). Sem dominar prompts (Módulo 6), os Artifacts que você criar (Módulo 10) serão superficiais. Cada módulo prepara o terreno do seguinte.

Ao final deste bloco, você será capaz de: explicar o Claude para colegas e gestores; escolher o modelo certo para cada tarefa; escrever prompts de nível profissional; montar Projects organizados para estudo, documentação e Service Desk; analisar documentos técnicos com critério; e criar materiais interativos (guias, quizzes, checklists) usando Artifacts. Os módulos 11 a 23 (próximos blocos) vão aplicar tudo isso em cenários avançados: criação de cursos, Service Desk, Microsoft 365, segurança, MCP, Claude Code e agentes.

Mapa de progressão

Ordem pedagógica recomendada: siga a ordem numérica. Se você já usa o Claude no dia a dia, pode acelerar os Módulos 1 e 5, mas não pule os Módulos 2, 4 e 6 — eles são a base conceitual de todo o resto.

Sugestão de ritmo: 1 módulo a cada 2–3 dias (com laboratório e exercícios), totalizando 3 a 4 semanas para este bloco.

MÓDULO 1 — Introdução ao Claude

1. Nome do módulo

Introdução ao Claude: o que é, quem faz e qual porta usar

2. Objetivo de aprendizagem

Compreender o que é o Claude, quem é a Anthropic, quais são os produtos do ecossistema (Claude.ai, Claude API, Claude Desktop, Claude Code, Claude for Work/planos corporativos) e para quais tipos de tarefa o Claude entrega mais valor.

3. O que você será capaz de fazer ao final do módulo

• Explicar, em 2 minutos, o que é o Claude para um colega de equipe ou para seu gestor.
• Identificar qual produto do ecossistema usar para cada necessidade (estudar, documentar, automatizar, programar, integrar).
• Listar os tipos de tarefa em que o Claude brilha (análise, escrita, raciocínio, documentação, código, revisão, estruturação de conhecimento) e em quais ele precisa de supervisão.
• Diferenciar uso pessoal de uso corporativo desde o primeiro dia.

4. Por que esse tema importa no uso real do Claude

Muita gente abre o Claude, digita uma pergunta como se fosse um buscador, recebe uma resposta mediana e conclui que "IA não serve para o meu trabalho". O problema quase nunca é a ferramenta — é usar a ferramenta errada do jeito errado. Saber que existe um ecossistema (chat, Projects, Desktop, Code, API) e que cada peça foi feita para um tipo de trabalho muda completamente o resultado. Para uma profissional de TI, isso é análogo a saber a diferença entre o portal do Microsoft 365 Admin Center, o Entra Admin Center e o Intune Admin Center: tudo é "Microsoft", mas cada portal resolve um problema diferente. Errar o portal custa tempo; errar a ferramenta de IA custa qualidade.

5. Explicação simples

O Claude é um assistente de inteligência artificial criado pela empresa Anthropic. Você conversa com ele em linguagem natural — português, inglês, o que preferir — e ele ajuda a escrever, analisar, resumir, explicar, revisar, programar e organizar informações.

Pense nele como um colega de trabalho extremamente bem-lido, disponível 24 horas, que: - Leu uma quantidade gigantesca de textos técnicos, documentação, código e livros; - Escreve muito bem e muito rápido; - Consegue analisar documentos que você envia; - Mas não conhece a sua empresa, não tem acesso aos seus sistemas (a menos que você conecte), pode errar com confiança e precisa de instruções claras para dar o melhor de si.

A Anthropic é uma empresa de pesquisa em IA fundada em 2021, com foco declarado em segurança de IA (AI safety) — ou seja, construir sistemas de IA que sejam úteis, honestos e inofensivos. Esse foco se reflete no comportamento do Claude: ele tende a ser cuidadoso, a admitir incertezas e a recusar pedidos problemáticos.

6. Explicação profunda

O Claude é um LLM (Large Language Model, ou grande modelo de linguagem) — um tipo de sistema de IA treinado sobre volumes massivos de texto para prever e gerar linguagem. Você vai entender a mecânica disso no Módulo 2; por ora, o essencial é entender o ecossistema de produtos construído em torno do modelo:

Claude.ai (web e mobile)

É a interface de chat — o produto que a maioria das pessoas conhece. Acessível pelo navegador (claude.ai) e por apps iOS/Android. É onde você conversa, envia arquivos e imagens, cria Projects (espaços de trabalho persistentes, Módulo 7) e gera Artifacts (conteúdos interativos, Módulo 10). Existem planos gratuitos e pagos (Pro, Team, Enterprise), que diferem em limites de uso, modelos disponíveis e recursos — os detalhes mudam com o tempo, então valide em https://support.claude.com.

Claude Desktop

Aplicativo instalado no computador (Windows/macOS). Oferece a mesma experiência de chat do Claude.ai, mas com vantagens de integração local: acesso mais direto a arquivos e aplicativos da máquina e suporte a conectores locais via MCP (Model Context Protocol, Módulo 15). Para quem trabalha o dia inteiro com documentos e várias janelas abertas, o Desktop reduz fricção.

Claude Code

Ferramenta agentic de programação que roda no terminal, em IDEs (VS Code, JetBrains) ou no app desktop. Diferente do chat, o Claude Code age no seu ambiente: lê o repositório, edita arquivos, executa comandos, roda testes. Não é só para desenvolvedores full-time — uma analista de TI que mantém scripts PowerShell, automações e documentação em repositórios se beneficia muito (Módulo 16 é dedicado a isso).

Claude API

A interface de programação. Empresas e desenvolvedores usam a API para embutir o Claude em seus próprios sistemas: um chatbot interno de Service Desk, uma automação que classifica tickets, uma ferramenta que resume relatórios. Na API, você escolhe o modelo, controla parâmetros e paga por uso (por tokens processados). Documentação: https://docs.claude.com.

Claude for Work (planos Team e Enterprise)

Versões corporativas do Claude.ai com administração centralizada, controles de segurança, gestão de usuários e, no Enterprise, recursos como SSO (Single Sign-On — login único corporativo, algo que você conhece bem do Entra ID), auditoria e maior janela de contexto. Ponto crucial para você: políticas de tratamento de dados diferem entre planos. Antes de enviar qualquer informação corporativa ao Claude, verifique qual plano sua organização usa e o que a política interna permite (o Módulo 20 aprofunda isso).

Para que o Claude é melhor utilizado

O Claude se destaca em tarefas de linguagem, raciocínio e estruturação:

E onde ele precisa de supervisão: fatos muito recentes (a menos que use busca na web), números exatos que ele não pode verificar, decisões que dependem de contexto da sua organização que ele não tem, e qualquer coisa que vá para produção sem revisão humana. Isso não é defeito — é a natureza da ferramenta, e o Módulo 2 explica o porquê.

7. Conceitos-chave

• Claude — assistente de IA da Anthropic, baseado em LLM.
• Anthropic — empresa criadora, fundada em 2021, com foco em segurança de IA.
• LLM (Large Language Model) — modelo de linguagem de grande escala; a tecnologia por trás do Claude.
• Claude.ai — interface de chat web/mobile.
• Claude Desktop — aplicativo local com integrações à máquina.
• Claude Code — ferramenta agentic para código e automação no terminal/IDE.
• Claude API — acesso programático para embutir o Claude em sistemas.
• Claude for Work (Team/Enterprise) — planos corporativos com administração, segurança e governança.
• Assistente vs. autoridade — o Claude propõe; você valida e decide.

8. Analogia didática

Pense no ecossistema Claude como os portais administrativos da Microsoft que você usa todo dia:

• Claude.ai é como o portal do usuário final do Microsoft 365: acessível, visual, para o dia a dia.
• Claude Desktop é como o Outlook instalado vs. Outlook Web: a mesma coisa, mas integrada à sua máquina.
• Claude Code é como o PowerShell com módulos do Graph: menos visual, muito mais poderoso para quem sabe o que quer executar.
• Claude API é como o Microsoft Graph API: a camada que permite construir soluções por cima.
• Claude for Work é como a diferença entre uma conta Microsoft pessoal e um tenant corporativo com Entra ID: mesmo produto na superfície, mas com governança, políticas e administração por trás.

Ninguém administra Conditional Access pelo Outlook — e ninguém deveria tentar automatizar análise de 500 tickets pelo chat manual. Ferramenta certa para o trabalho certo.

9. Exemplo prático usando Claude

Abra o Claude.ai e envie este prompt (pode copiar):

Sou analista de Service Desk em uma empresa que usa Microsoft 365 e Entra ID.
Explique em até 300 palavras, em linguagem simples, o que você (Claude) consegue
fazer para me ajudar no dia a dia, e o que você NÃO consegue fazer sem que eu
forneça informações ou conecte ferramentas. Organize em duas listas.

Observe a resposta: o Claude vai listar capacidades (análise, escrita, troubleshooting conceitual) e limitações (sem acesso aos seus sistemas, sem conhecimento da sua empresa, conhecimento com data de corte). Esse exercício de "entrevista com a ferramenta" é a forma mais rápida de calibrar expectativas.

10. Aplicação no dia a dia de TI

• Segunda-feira de manhã: colar as anotações da reunião de handover e pedir um resumo com pendências e responsáveis.
• Documentação: transformar um procedimento que só existe "na cabeça do colega" em documento formal — você digita como faria verbalmente e o Claude estrutura.
• Estudo: usar o Claude como tutor que explica no seu ritmo, com exemplos do seu ambiente real.
• Comunicação: rascunhar e-mails difíceis (recusar um pedido, cobrar um fornecedor, explicar um atraso) e ajustar o tom antes de enviar.

11. Aplicação em Service Desk

No primeiro nível de contato, o Claude é útil como copiloto de comunicação e estrutura: reescrever a descrição confusa de um ticket em formato padronizado (sintoma, impacto, passos já tentados), sugerir categorização, rascunhar a resposta ao usuário em tom profissional e criar o registro de resolução. Cuidado desde já: nunca cole dados pessoais do usuário (nome completo, e-mail real, telefone) sem necessidade — use placeholders como [USUARIO]. O Módulo 20 formaliza essas regras.

12. Aplicação em Microsoft 365 / Entra ID / IAM / Intune

Use o Claude como explicador e estruturador de raciocínio: "explique a diferença entre Entra joined e hybrid joined com uma tabela comparativa", "quais logs eu olharia primeiro para um erro AADSTS50076?". Ele ajuda a pensar e documentar — mas a validação final é sempre no portal real, nos logs reais (Sign-in logs, Audit logs) e na documentação Microsoft Learn. Regra de ouro deste curso: Claude estrutura, fontes oficiais confirmam.

13. Prompts bons

Prompt bom 1 — apresentação com contexto:

Sou analista de TI (Service Desk / M365 / Entra ID). Estou começando a usar o
Claude profissionalmente. Liste 10 casos de uso concretos para o meu perfil,
ordenados do mais fácil ao mais avançado, com um exemplo de tarefa real em cada.

Prompt bom 2 — calibrando limitações:

Antes de te usar para trabalho, quero entender seus limites. Responda:
1. Você tem acesso à internet ou aos meus sistemas por padrão?
2. Seu conhecimento tem data de corte? O que isso significa na prática?
3. Em que tipos de resposta devo ser mais cética e validar em fontes oficiais?
Seja direto e honesto.

14. Prompts ruins

Prompt ruim 1:

me ajuda com TI

Vago demais: sem contexto, sem tarefa, sem formato. A resposta será genérica porque a pergunta é genérica.

Prompt ruim 2:

Qual foi o último patch Tuesday e quais KBs saíram?

Pergunta sobre fato muito recente sem pedir busca na web. Sem acesso a informação atualizada, o modelo pode responder com dados desatualizados ou inventados. Se a interface tiver busca na web habilitada, peça explicitamente: "pesquise na web e cite as fontes".

15. Por que os prompts bons funcionam melhor

Os prompts bons têm três ingredientes que os ruins não têm: quem você é (contexto do perfil), o que você quer (tarefa específica) e como quer receber (formato: lista, ordenação, limite). O Claude gera a resposta prevendo o texto mais adequado ao que foi pedido — quanto mais precisa a especificação, mais estreito e certeiro o espaço de respostas possíveis. Um prompt vago obriga o modelo a adivinhar suas intenções; um prompt específico transforma adivinhação em execução. Essa é a tese central do Módulo 6.

16. Laboratório prático guiado

Objetivo: conhecer o ecossistema na prática e calibrar expectativas. Tempo estimado: 30 minutos.

1. Acesse o Claude.ai e crie uma conta (ou faça login). Observe a tela inicial: campo de mensagem, seletor de modelo, botão de anexar arquivos, menu lateral com histórico e Projects.
2. Envie o prompt de "entrevista" do exemplo prático (seção 9). Leia a resposta com atenção crítica.
3. Teste uma tarefa de escrita: peça "Escreva um e-mail curto e profissional avisando os usuários que haverá manutenção no Exchange Online sábado das 8h às 12h. Tom: claro e tranquilizador."
4. Teste uma tarefa de análise: cole um parágrafo confuso de qualquer procedimento seu (sem dados sensíveis!) e peça "Reescreva como procedimento numerado, claro, para um técnico júnior."
5. Teste uma limitação de propósito: pergunte algo sobre um sistema interno da sua empresa ("qual o SLA do nosso contrato com o fornecedor X?"). Observe que o Claude não sabe — e o bom comportamento é ele dizer que não sabe.
6. Anote em um bloco de notas: 3 coisas que superaram sua expectativa e 2 que exigirão supervisão sua. Essa lista será seu ponto de partida no Módulo 6.

17. Exercícios de fixação

1. Escreva, com suas palavras, a diferença entre Claude.ai, Claude Desktop, Claude Code e Claude API em uma frase cada.
2. Liste 3 tarefas do seu trabalho desta semana em que o Claude poderia ajudar e classifique cada uma como: escrita, análise, raciocínio, documentação ou código.
3. Identifique 2 tarefas do seu trabalho que você não delegaria ao Claude sem validação e explique por quê.
4. Explique para um colega imaginário por que "colar um log com dados de usuários reais" no Claude sem verificar a política da empresa é um problema.

18. Quiz (5 perguntas)

1. Qual produto do ecossistema você usaria para conversar, enviar um PDF de política e pedir um resumo, sem instalar nada? a) Claude API — b) Claude.ai — c) Claude Code — d) MCP

2. O Claude Code se diferencia do Claude.ai principalmente porque: a) É gratuito — b) Só responde em inglês — c) Age no ambiente: lê arquivos, executa comandos e edita código — d) Não usa LLM

3. Sua empresa quer embutir o Claude no sistema de tickets para classificar chamados automaticamente. O caminho natural é: a) Claude.ai com copy/paste — b) Claude Desktop — c) Claude API — d) Artifacts

4. Sobre o conhecimento do Claude, é correto afirmar: a) Ele conhece os sistemas internos da sua empresa — b) Ele tem uma data de corte de conhecimento e não acessa seus sistemas por padrão — c) Ele nunca erra fatos — d) Ele acessa a internet sempre, em qualquer plano

5. A postura profissional correta ao usar o Claude é: a) Aceitar as respostas como definitivas — b) Usar como assistente e validar informações críticas em fontes oficiais — c) Evitar dar contexto para não "enviesar" — d) Usar apenas para tarefas triviais

19. Gabarito comentado

1 — b. Claude.ai é a interface de chat no navegador: zero instalação, aceita arquivos. A API exige programação; o Code é para trabalho em código; MCP é um protocolo de integração, não um produto de chat. 2 — c. A diferença essencial é que o Claude Code é agentic: não apenas responde, mas executa ações no seu ambiente de trabalho (com sua permissão). 3 — c. Integrar IA a um sistema existente é o caso de uso clássico da API. As outras opções são interfaces para uso humano direto. 4 — b. O modelo tem data de corte de treinamento e não tem acesso nativo aos seus sistemas. Busca na web e conectores podem existir dependendo do plano/configuração, mas não são o padrão universal — por isso a alternativa (d) está errada ao dizer "sempre". 5 — b. O princípio que atravessa todo o curso: o Claude é um assistente poderoso, não uma autoridade. Contexto melhora respostas (por isso a (c) está errada), e limitar a tarefas triviais desperdiça o potencial (por isso a (d) está errada).

20. Checklist do módulo

• Sei explicar o que é o Claude e quem é a Anthropic em 2 minutos.
• Sei diferenciar Claude.ai, Desktop, Code, API e for Work.
• Sei listar 5+ categorias de tarefa em que o Claude agrega valor no meu trabalho.
• Sei citar 3 limitações e como lidar com cada uma.
• Verifiquei (ou sei onde verificar) a política da minha empresa sobre uso de IA.
• Fiz o laboratório e anotei minhas observações.

21. Erros comuns

• Tratar o Claude como buscador: perguntas de uma linha geram respostas de uma linha de qualidade.
• Julgar a ferramenta pelo primeiro prompt ruim: a curva de aprendizado está no seu lado da conversa.
• Ignorar o plano/política corporativa: usar conta pessoal para dados de trabalho é um risco de compliance real.
• Esperar conhecimento em tempo real por padrão: sem busca na web ou conectores, o modelo responde com o que aprendeu até a data de corte.
• Não dar contexto "para testar a IA": você não contrataria um consultor e esconderia o problema dele.

22. Boas práticas

• Comece toda relação de trabalho com a ferramenta fazendo a "entrevista de limitações" (prompt da seção 13).
• Estabeleça desde o dia 1: dados sensíveis não entram sem anonimização e sem respaldo da política interna.
• Mantenha um arquivo pessoal de "prompts que funcionaram" — ele virará sua biblioteca no Módulo 6.
• Ao encontrar um recurso novo na interface, consulte https://support.claude.com em vez de adivinhar.

23. Resumo final

O Claude é o assistente de IA da Anthropic, disponível em múltiplas formas: chat (Claude.ai/Desktop), ferramenta de código (Claude Code), camada de integração (API) e planos corporativos (Team/Enterprise). Ele entrega mais valor em análise, escrita, raciocínio, documentação, código, revisão e estruturação de conhecimento — exatamente o coração do trabalho de TI moderno. Suas limitações (data de corte, sem acesso nativo aos seus sistemas, possibilidade de erro confiante) não o desqualificam: definem o papel correto dele — assistente competente sob supervisão de uma profissional que valida.

24. Mini desafio

Escreva um parágrafo (5–8 linhas) como se fosse apresentar o Claude para sua equipe de Service Desk em uma reunião de 5 minutos: o que é, 3 usos imediatos e 1 regra de segurança. Depois, cole seu parágrafo no Claude e peça: "Revise este texto para uma apresentação de 5 minutos. Aponte o que está claro, o que falta e sugira uma versão melhorada." Compare as versões.

25. Como eu aplicaria isso amanhã no trabalho

Amanhã de manhã, antes de abrir a fila de tickets, eu abriria o Claude.ai e faria três coisas em 15 minutos: (1) colaria minhas anotações soltas do dia anterior e pediria um resumo com pendências; (2) escolheria o ticket com a descrição mais confusa e pediria para reestruturar em formato padrão (sem dados reais de usuário); (3) pediria um rascunho de resposta profissional para o usuário. Três tarefas reais, risco zero, ganho imediato — e a confiança para avançar nos próximos módulos.

Adaptação para Fable — Módulo 1

Título curto para o card: "Conheça o Claude"

Texto de abertura envolvente:

Você já tem um novo colega de equipe — ele lê rápido, escreve bem, nunca perde a paciência e trabalha 24/7. Mas, como todo colega novo, ele precisa que você aprenda a delegar direito. Neste módulo, você vai conhecer o Claude, entender o que ele faz de melhor e descobrir qual "porta" do ecossistema usar para cada tarefa do seu dia.

Divisão sugerida em telas: 1. Tela 1 — "Quem é esse tal de Claude?" (o que é + Anthropic) 2. Tela 2 — "Um produto, cinco portas" (Claude.ai, Desktop, Code, API, for Work — carrossel comparativo) 3. Tela 3 — "Onde ele brilha" (tabela de casos de uso em TI) 4. Tela 4 — "Onde ele precisa de você" (limitações + regra 'Claude estrutura, fontes confirmam') 5. Tela 5 — Laboratório guiado 6. Tela 6 — Quiz + conclusão

Ideia de interação: card de decisão "Qual porta usar?" — o aluno recebe 5 cenários (ex.: "quero classificar 1.000 tickets automaticamente") e arrasta cada um para o produto certo.

Pergunta reflexiva: "Qual tarefa da sua semana passada teria sido 50% mais rápida com um assistente que escreve e estrutura bem? O que te impediu de pedir ajuda?"

Microatividade prática: enviar o prompt de "entrevista de limitações" ao Claude e colar no Fable uma limitação que ele admitiu.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Pronto! Você já sabe o que é o Claude, qual porta usar e — mais importante — qual é o seu papel: a profissional que delega bem e valida sempre. No próximo módulo, vamos abrir o capô e entender como essa máquina pensa.

Sugestão visual para o Fable: diagrama do ecossistema em formato de "hub": Claude (modelo) no centro, com cinco portas ao redor (Claude.ai, Desktop, Code, API, for Work), cada uma com um ícone e um caso de uso de TI.

MÓDULO 2 — Fundamentos de IA necessários para usar Claude bem

1. Nome do módulo

Como o Claude pensa: fundamentos de LLM aplicados ao uso real

2. Objetivo de aprendizagem

Compreender, de forma aplicada e não acadêmica, os conceitos que explicam o comportamento do Claude: LLMs, prompts, tokens, contexto, inferência, alucinação, grounding, RAG, embeddings, ferramentas (tools), agentes e avaliação de respostas — sempre conectando cada conceito a uma decisão prática de uso.

3. O que você será capaz de fazer ao final do módulo

• Explicar por que o Claude às vezes "inventa" informações e como reduzir isso drasticamente.
• Prever quando uma resposta tende a ser confiável e quando exige validação redobrada.
• Usar os termos técnicos corretos (token, context window, grounding, RAG) em conversas profissionais.
• Tomar decisões práticas informadas: "essa tarefa precisa de grounding" ou "aqui vale dividir o contexto".

4. Por que esse tema importa no uso real do Claude

Você não precisa saber construir um motor para dirigir bem — mas precisa saber que motor esquenta, que freio tem distância de frenagem e que pneu careca derrapa. Com LLMs é igual: quem não entende o mínimo da mecânica interpreta mal os comportamentos. Vê uma alucinação e conclui "a IA mente"; vê uma conversa longa degradar e conclui "a IA ficou burra"; cola um documento de 200 páginas e se frustra com respostas rasas. Todos esses fenômenos têm causas técnicas conhecidas e contramedidas práticas — e este módulo entrega as duas coisas. Este é, provavelmente, o módulo com maior retorno por minuto investido do curso inteiro.

5. Explicação simples

Um LLM é um programa que aprendeu, lendo quantidades absurdas de texto, a prever qual palavra vem a seguir. Parece simples demais, mas quando você treina esse "previsor" com trilhões de palavras e uma arquitetura muito sofisticada, ele desenvolve algo que se comporta como compreensão: consegue seguir instruções, raciocinar por etapas, escrever código e adaptar o tom.

Alguns fatos práticos que derivam disso:

• O Claude não consulta um banco de dados de fatos — ele gera texto com base em padrões aprendidos. Por isso pode errar detalhes com total confiança (a famosa alucinação).
• Ele processa texto em pedacinhos chamados tokens, e existe um limite de quantos tokens cabem "na mesa" de uma conversa — a context window (janela de contexto).
• Ele só sabe o que estava nos dados de treino (até uma data de corte) mais o que você colocar na conversa. Colocar informação verdadeira na conversa para ancorar a resposta chama-se grounding.
• Quando há documentos demais para caber na mesa, sistemas buscam só os trechos relevantes antes de responder — isso é RAG (Retrieval-Augmented Generation).

6. Explicação profunda

LLMs e modelos de linguagem

LLMs modernos, como o Claude, são baseados na arquitetura Transformer, treinados em duas grandes fases: o pré-treinamento (aprender padrões da linguagem prevendo texto em escala massiva) e o pós-treinamento/alinhamento (aprender a ser útil, seguir instruções, recusar pedidos nocivos — a Anthropic é conhecida por técnicas como Constitutional AI nessa fase). O resultado é um sistema que não "guarda" fatos como um banco de dados, mas codifica padrões estatísticos e conceituais em bilhões de parâmetros numéricos.

Consequência prática nº 1: conhecimento é reconstruído a cada resposta, não consultado. Fatos muito comuns (o que é DNS) saem quase sempre certos; fatos raros, específicos ou recentes (o parâmetro exato de um cmdlet obscuro, o KB de um patch do mês passado) saem errados com mais frequência — e com a mesma fluência confiante.

Prompt e inferência

Prompt é tudo o que você envia: sua pergunta, o contexto, os arquivos, as instruções do Project. Inferência é o processo de geração: o modelo recebe o prompt inteiro e gera a resposta token a token, cada token escolhido em função de todos os anteriores. Não há "pensar antes em segredo e depois escrever" no modo padrão — a resposta é construída sequencialmente. (Modelos com raciocínio estendido produzem etapas intermediárias de pensamento antes da resposta final, o que melhora tarefas complexas; a disponibilidade e o funcionamento variam por modelo e plano.)

Consequência prática nº 2: a qualidade da saída é função direta da qualidade da entrada. O prompt não é uma "pergunta" — é a especificação completa do trabalho.

Tokens

Token é a unidade mínima de texto que o modelo processa — pedaços de palavras, palavras inteiras, pontuação. Em inglês, 1 token ≈ 0,75 palavra; em português a proporção é um pouco menos eficiente (palavras longas e acentuadas viram mais tokens). Regra de bolso: 100 tokens ≈ 70–75 palavras em PT-BR. Uma página de documento ≈ 500–700 tokens; um PDF de 50 páginas ≈ 25.000–35.000 tokens.

Context window (janela de contexto)

É o limite total de tokens que o modelo consegue considerar de uma vez: tudo — suas mensagens, as respostas dele, arquivos anexados, instruções de Project — compete pelo mesmo espaço. Os modelos Claude atuais têm janelas grandes (na casa de centenas de milhares de tokens; o número exato varia por modelo e plano — valide na documentação). Grande não é infinita, e o Módulo 4 mostra que qualidade de atenção não é uniforme ao longo de janelas muito cheias.

Consequência prática nº 3: conversa longa demais = contexto lotado = respostas que "esquecem" instruções do início. A solução não é reclamar, é gerenciar contexto (Módulo 4).

Alucinação

Alucinação é quando o modelo gera informação falsa com aparência de verdadeira: um cmdlet PowerShell que não existe, um artigo de KB com número inventado, uma citação fabricada. Acontece porque o objetivo do modelo é gerar texto plausível — e "plausível" nem sempre é "verdadeiro". Fatores que aumentam alucinação: perguntas sobre fatos raros/recentes, pedidos de citações e números exatos, contexto insuficiente e perguntas que pressupõem algo falso ("por que o comando X faz Y?" quando X não faz Y).

Contramedidas práticas: 1. Grounding: forneça a fonte (cole o trecho da documentação, anexe o PDF) e peça resposta baseada nela. 2. Permissão para não saber: inclua no prompt "se não tiver certeza, diga explicitamente". 3. Pedir raciocínio visível: "explique como chegou a essa conclusão" expõe premissas frágeis. 4. Verificação assimétrica: valide com rigor proporcional ao risco — um e-mail interno tolera erro; um procedimento de Conditional Access, não.

Grounding

Grounding ("ancoragem") é a prática de fornecer ao modelo a informação factual verdadeira dentro do prompt, para que ele responda com base nela em vez de na memória de treino. É a alavanca de qualidade mais poderosa que existe: um Claude respondendo "de cabeça" sobre a política de MFA da sua empresa vai inventar; um Claude com o PDF da política anexado vai citar. Projects (Módulo 7) e análise documental (Módulo 8) são, essencialmente, grounding organizado.

Embeddings e RAG

Embedding é a representação de um texto como um vetor numérico que captura seu significado — textos com significados parecidos ficam com vetores próximos. É a tecnologia que permite busca semântica: encontrar "reset de senha" quando o usuário escreveu "não consigo entrar na conta".

RAG (Retrieval-Augmented Generation) combina busca + geração: (1) sua pergunta é usada para recuperar os trechos mais relevantes de uma base de documentos (frequentemente via embeddings); (2) esses trechos são inseridos no contexto; (3) o modelo gera a resposta ancorada neles. É assim que sistemas respondem sobre bases enormes que jamais caberiam na context window. No Claude, quando um Project tem muitos documentos, mecanismos de recuperação podem entrar em ação em vez de tudo ser lido integralmente — o Módulo 9 explora as consequências disso para o jeito de perguntar.

Ferramentas (tools) e agentes

Um LLM sozinho só transforma texto em texto. Tools (ferramentas) são capacidades externas que o modelo pode acionar: buscar na web, executar código, ler um arquivo, consultar um sistema via MCP (Módulo 15). Um agente é um LLM que usa ferramentas em ciclo — planeja, executa uma ação, observa o resultado, decide o próximo passo — para completar tarefas de múltiplas etapas. O Claude Code é um agente de programação; o Módulo 17 mostra como montar workflows agentic para o seu contexto.

Limitações estruturais (e contornos)

Avaliação de respostas (preview do Módulo 21)

Três perguntas rápidas para toda resposta importante: (1) Isso é verificável? Se sim, verifique o crítico. (2) O modelo tinha base para saber isso? Se a resposta depende de fato recente/interno que você não forneceu, desconfie. (3) A resposta responde ao que perguntei ou ao que era mais fácil responder? Modelos tendem a "escorregar" para a versão genérica da pergunta.

7. Conceitos-chave

• LLM — modelo de linguagem treinado para gerar texto por previsão de tokens.
• Prompt — a entrada completa: instruções + contexto + pergunta + arquivos.
• Token — unidade mínima de processamento (~0,7 palavra em PT-BR).
• Context window — limite total de tokens de uma conversa.
• Inferência — o processo de geração da resposta, token a token.
• Alucinação — informação falsa gerada com confiança.
• Grounding — ancorar a resposta em fontes fornecidas por você.
• Embedding — vetor numérico que representa o significado de um texto.
• RAG — recuperar trechos relevantes de uma base e gerar resposta com base neles.
• Tool / agente — capacidade externa acionável / LLM que usa tools em ciclo para tarefas multi-etapas.
• Data de corte — limite temporal do conhecimento de treino.

8. Analogia didática

Pense no Claude como um analista sênior recém-contratado, brilhante, mas que chegou hoje na sua empresa:

• Ele tem formação enciclopédica (o pré-treinamento), mas não conhece nada do seu ambiente — não sabe suas políticas, seu tenant, seus fornecedores.
• Se você perguntar "qual é a nossa política de MFA?", ele pode responder com a política típica de mercado como se fosse a sua — isso é a alucinação: preencher a lacuna com o plausível.
• Se você entregar o documento da política antes de perguntar, ele responde com precisão — isso é grounding.
• A mesa dele tem espaço finito (context window): se você empilhar 30 pastas, ele vai folhear, não ler tudo com o mesmo cuidado.
• Se a documentação da empresa é uma sala inteira de arquivos, alguém precisa buscar as pastas certas antes de colocar na mesa dele — esse "alguém" é o RAG.
• E se você der a ele um telefone e acesso aos sistemas (tools), ele deixa de só opinar e passa a executar — virando um agente. Aí a governança importa em dobro.

9. Exemplo prático usando Claude

Faça este experimento em dois atos para sentir a diferença entre memória e grounding:

Ato 1 — sem grounding:

Quais são os requisitos de licenciamento para usar Conditional Access no Entra ID?
Responda de memória e me diga qual é o seu grau de confiança nessa resposta e
o que eu deveria verificar na documentação oficial.

Ato 2 — com grounding: copie a seção de requisitos da página oficial do Microsoft Learn sobre Conditional Access, cole no chat e pergunte:

Com base EXCLUSIVAMENTE no texto acima, responda: quais são os requisitos de
licenciamento para Conditional Access? Se algo não estiver no texto, diga
"não consta na fonte fornecida".

Compare: no Ato 1, resposta plausível com incerteza declarada; no Ato 2, resposta precisa e delimitada. Esse contraste é o coração do uso profissional de LLMs.

10. Aplicação no dia a dia de TI

• Antes de perguntar algo factual e específico, pergunte-se: "o Claude teria base para saber isso?" Se a resposta é "só se eu fornecer", forneça (grounding).
• Ao pedir um script PowerShell, assuma que cmdlets e parâmetros podem estar levemente errados ou desatualizados: teste em ambiente controlado antes de rodar.
• Ao notar respostas repetitivas ou que ignoram instruções antigas em uma conversa longa, reconheça o sintoma: contexto saturado. Resuma e recomece (técnica do Módulo 4).

11. Aplicação em Service Desk

Alucinação em Service Desk tem um risco específico: passar instrução errada para o usuário final. Se o Claude sugerir um caminho de menu que não existe na versão do Outlook do usuário, quem perde credibilidade é você. Contramedida: para procedimentos voltados ao usuário, faça grounding com um print da tela real ou com o artigo oficial, e valide o passo a passo você mesma antes de enviar. Já para estruturar o atendimento (resumir o ticket, organizar hipóteses, redigir a resposta), o risco é baixo e o ganho é alto — comece por aí.

12. Aplicação em Microsoft 365 / Entra ID / IAM / Intune

Códigos de erro são um caso perfeito de uso híbrido: peça ao Claude "explique as causas típicas do erro AADSTS53003 e monte uma árvore de hipóteses de troubleshooting" (raciocínio — ele é ótimo nisso), mas confirme o significado exato do código na documentação Microsoft e nos Sign-in logs reais (fatos — território de validação). O Claude organiza a investigação; os logs decidem.

13. Prompts bons

Prompt bom 1 — com grounding e permissão para não saber:

Vou colar abaixo um trecho da nossa política interna de acesso (anonimizada).
Tarefa: identifique ambiguidades ou pontos que podem gerar interpretação dupla
por parte dos técnicos de Service Desk. Baseie-se APENAS no texto fornecido.
Se precisar de informação que não está no texto, liste o que falta em vez de assumir.

[TEXTO DA POLÍTICA]

Prompt bom 2 — calibrando confiança:

Explique o que causa o erro AADSTS50076 no Entra ID e liste hipóteses de
troubleshooting em ordem de probabilidade. Ao final, indique:
1. O que dessa resposta é conhecimento estável e confiável;
2. O que pode variar por tenant/configuração e devo verificar nos logs;
3. Onde encontro a referência oficial.

14. Prompts ruins

Prompt ruim 1:

Qual o número do KB article da Microsoft sobre erro de MFA?

Pede um identificador exato de memória — receita clássica de alucinação. Números de KB, IDs e URLs específicas devem vir de busca ou fonte fornecida, nunca "de cabeça".

Prompt ruim 2:

Resuma a política da minha empresa sobre BYOD.

Sem anexar a política. O modelo não a conhece — ou vai dizer que não sabe (bom) ou vai descrever uma política genérica de mercado que você pode confundir com a sua (perigoso).

15. Por que os prompts bons funcionam melhor

Os dois prompts bons manipulam deliberadamente os mecanismos deste módulo: o primeiro usa grounding ("apenas o texto fornecido") + permissão estruturada para não saber ("liste o que falta"), fechando as duas portas principais da alucinação. O segundo separa explicitamente conhecimento estável de fato verificável, forçando o modelo a rotular sua própria confiança — o que transforma uma resposta monolítica em um mapa de onde validar. Os ruins fazem o oposto: pedem exatamente os tipos de informação (IDs exatos, conteúdo interno não fornecido) em que a geração por plausibilidade mais falha.

16. Laboratório prático guiado

Objetivo: provocar e neutralizar uma alucinação de propósito. Tempo: 40 minutos.

1. Provoque: pergunte ao Claude algo específico e verificável do seu domínio, sem fornecer fonte. Ex.: "Liste os nomes exatos das configurações de compliance policy do Intune para Windows e o caminho de menu de cada uma."
2. Audite: abra o portal do Intune (ou Microsoft Learn) e confira item por item. Marque: corretos, desatualizados, inventados.
3. Neutralize: copie a página oficial relevante, cole no chat e repita a pergunta com "baseie-se apenas no texto fornecido; sinalize o que não consta".
4. Compare as duas respostas e escreva 3 linhas: o que mudou e por quê.
5. Teste a permissão para não saber: pergunte "Qual é a configuração de senha padrão do tenant da minha empresa?" e observe o modelo (corretamente) declarar que não tem como saber.
6. Registre a regra pessoal: complete a frase "Vou exigir grounding sempre que a pergunta envolver ______" (sugestões: números exatos, procedimentos internos, telas de portal, comandos que vou executar).

17. Exercícios de fixação

1. Explique com suas palavras a diferença entre alucinação e erro por desatualização — e por que a contramedida é parecida.
2. Estime em tokens: um e-mail de 150 palavras; um procedimento de 3 páginas; um export CSV de 2.000 linhas de tickets. (Use as regras de bolso da seção 6.)
3. Para cada cenário, diga se exige grounding: (a) "explique o conceito de Zero Trust"; (b) "resuma nossa política de acesso remoto"; (c) "qual a sintaxe do Get-MgUser?"; (d) "compare Entra joined vs hybrid joined".
4. Descreva em 3 frases como o RAG permite responder perguntas sobre uma base de 500 documentos que não cabe na context window.

18. Quiz (5 perguntas)

1. A causa fundamental da alucinação em LLMs é: a) Bug de software — b) O modelo gerar texto por plausibilidade, não por consulta a fatos — c) Falta de memória RAM — d) Excesso de contexto

2. "Grounding" significa: a) Reiniciar a conversa — b) Fornecer as fontes verdadeiras no prompt para ancorar a resposta — c) Usar o modelo mais caro — d) Desligar a busca na web

3. Em uma context window, competem pelo espaço: a) Apenas suas perguntas — b) Apenas os arquivos — c) Tudo: mensagens, respostas, arquivos e instruções — d) Apenas a última mensagem

4. RAG resolve principalmente o problema de: a) Velocidade de digitação — b) Base de conhecimento maior do que a context window — c) Tradução — d) Formatação de tabelas

5. Qual pergunta tem MAIOR risco de alucinação? a) "Explique o conceito de MFA" — b) "Compare os três tipos de join do Entra" — c) "Qual o número exato do KB que corrige o bug X?" — d) "Reescreva este e-mail em tom formal"

19. Gabarito comentado

1 — b. Alucinação não é defeito pontual, é consequência do mecanismo: o modelo produz o texto mais plausível dado o padrão aprendido. Por isso a solução é mudar o insumo (grounding), não esperar um "patch". 2 — b. Grounding = ancorar. Você coloca a verdade na mesa para o modelo não precisar reconstruí-la de memória. 3 — c. Esse é o ponto que mais surpreende iniciantes: instruções de Project, arquivos e todo o histórico ocupam a mesma janela. Por isso conversas longas "esquecem". 4 — b. RAG busca os trechos relevantes e coloca só eles no contexto — é a ponte entre bases enormes e janelas finitas. 5 — c. Identificadores exatos (KBs, IDs, URLs, números de versão) são fatos raros e pontuais — exatamente onde a geração por plausibilidade mais inventa. As demais são tarefas de conceito ou transformação, terreno seguro.

20. Checklist do módulo

• Sei explicar o que é um LLM e por que ele não é um banco de dados de fatos.
• Sei estimar tokens de um texto e entendo o que é a context window.
• Sei o que causa alucinação e aplico as 4 contramedidas.
• Uso grounding sempre que a pergunta envolve fatos internos, exatos ou recentes.
• Entendo RAG o suficiente para prever seu impacto em Projects grandes.
• Sei o que são tools e agentes e por que exigem governança extra.
• Fiz o laboratório de provocar/neutralizar alucinação.

21. Erros comuns

• Confundir fluência com correção: a resposta bonita e confiante não é evidência de verdade.
• Pedir IDs, KBs e URLs de memória: o pior caso de uso possível de um LLM puro.
• "Testar" o modelo escondendo contexto: você só mede a capacidade dele de adivinhar, não de trabalhar.
• Culpar a ferramenta por conversa saturada: contexto lotado degrada qualquer modelo; gerenciar é seu papel.
• Aplicar o mesmo nível de validação a tudo: valide proporcionalmente ao risco — rigor máximo no que vai para produção ou para o usuário final.

22. Boas práticas

• Adote o mantra: "fatos internos, exatos ou recentes → grounding obrigatório".
• Inclua "se não souber, diga" nos prompts de perguntas factuais.
• Peça ao modelo para rotular a própria confiança e separar o estável do verificável.
• Trate scripts e comandos gerados como código de estagiário talentoso: revisar e testar antes de executar.
• Guarde este módulo como referência: sempre que um comportamento do Claude parecer estranho, volte à tabela de limitações e contornos.

23. Resumo final

O Claude é um LLM: gera texto token a token, por plausibilidade aprendida, dentro de uma context window finita, com conhecimento limitado à data de corte mais o que você fornecer. Dessa mecânica derivam os comportamentos que importam: alucinação (combatida com grounding e permissão para não saber), degradação em conversas longas (combatida com gestão de contexto), e a impossibilidade de conhecer seu ambiente (resolvida fornecendo dados anonimizados ou conectando ferramentas com governança). Embeddings e RAG estendem o alcance a bases grandes; tools e agentes estendem a ação ao mundo real. Quem domina esses fundamentos deixa de ser usuária de chat e passa a ser operadora consciente de um sistema.

24. Mini desafio

Crie um "cartão de bolso" pessoal (máximo 10 linhas) intitulado "Quando desconfiar de uma resposta do Claude", com base neste módulo. Depois peça ao Claude: "Critique este cartão: o que está errado, o que falta, o que está redundante?" Incorpore o que fizer sentido. Você acabou de usar o Claude para melhorar seu próprio protocolo de validação — meta-uso que será tema do Módulo 21.

25. Como eu aplicaria isso amanhã no trabalho

Amanhã, na primeira dúvida técnica do dia, eu faria conscientemente a pergunta-filtro: "isso é conceito estável ou fato verificável?" Se conceito (ex.: como funciona token refresh no OAuth), pergunto direto e aproveito a explicação. Se fato (ex.: configuração exata no portal), abro a fonte oficial, colo o trecho e pergunto com grounding. Duas semanas desse hábito e a distinção vira automática — e a taxa de respostas úteis do Claude sobe visivelmente.

Adaptação para Fable — Módulo 2

Título curto para o card: "Como o Claude pensa"

Texto de abertura envolvente:

Por que uma IA brilhante inventa um número de KB que não existe? Por que uma conversa longa fica "esquecida"? Nada disso é mistério — é mecânica. Neste módulo, você abre o capô do Claude e sai do outro lado sabendo prever quando confiar, quando validar e como extrair o triplo de qualidade com um único hábito: grounding.

Divisão sugerida em telas: 1. Tela 1 — "O previsor de palavras" (LLM em linguagem simples) 2. Tela 2 — "Tokens e a mesa finita" (context window, com visual de mesa enchendo) 3. Tela 3 — "A anatomia de uma alucinação" (cenário real de TI) 4. Tela 4 — "Grounding: a alavanca mestra" (experimento dos dois atos) 5. Tela 5 — "RAG, tools e agentes em 3 minutos" 6. Tela 6 — Laboratório + quiz + conclusão

Ideia de interação: simulação "Detetive de alucinação" — o aluno vê 4 respostas do Claude sobre Entra ID e marca quais trechos exigiriam validação (IDs exatos, caminhos de menu) e quais são conceito estável.

Pergunta reflexiva: "Qual foi a última vez que você repassou uma informação sem verificar a fonte — e o que uma IA fluente e confiante muda nesse risco?"

Microatividade prática: executar o experimento dos dois atos (com e sem grounding) e registrar a diferença em uma frase.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Agora você sabe o segredo que separa usuários frustrados de usuários eficazes: LLMs geram plausibilidade, e você fornece a verdade. Grounding no bolso, validação proporcional ao risco — e nada de pedir número de KB de memória! No próximo módulo: qual modelo do Claude escolher para cada tarefa.

Sugestão visual para o Fable: diagrama de fluxo em duas raias comparando "pergunta sem grounding" (memória de treino → resposta plausível → risco) vs. "pergunta com grounding" (fonte fornecida → resposta ancorada → confiança), com ícones de semáforo.

MÓDULO 3 — Modelos do Claude e escolha do modelo correto

1. Nome do módulo

Rápido, equilibrado ou profundo: escolhendo o modelo certo para cada tarefa

2. Objetivo de aprendizagem

Entender que "Claude" é uma família de modelos com perfis diferentes de velocidade, custo e capacidade de raciocínio — e desenvolver critérios objetivos para escolher o modelo adequado a cada tipo de tarefa do dia a dia de TI.

3. O que você será capaz de fazer ao final do módulo

• Explicar a lógica da família de modelos Claude (níveis rápido, equilibrado e avançado).
• Aplicar uma matriz de decisão: complexidade × risco × volume × custo.
• Reconhecer sintomas de "modelo subdimensionado" e de "modelo superdimensionado".
• Ajustar a escolha durante o trabalho, sem dogmatismo.

4. Por que esse tema importa no uso real do Claude

Usar o modelo mais avançado para reescrever um e-mail de 3 linhas é como abrir um chamado P1 para trocar um mouse: funciona, mas desperdiça recurso e tempo. Usar um modelo rápido para analisar uma política de Conditional Access com implicações de segurança é o erro inverso — e mais caro, porque o custo do erro supera a economia. Em planos pagos e na API, a escolha de modelo afeta diretamente limites de uso e custo financeiro; em qualquer plano, afeta qualidade e tempo. Profissionais que dominam essa escolha extraem o dobro do mesmo plano.

5. Explicação simples

A Anthropic mantém uma família de modelos em níveis de capacidade. Historicamente, a família usou três nomes que ajudam a entender a lógica:

• Haiku — o nível rápido e econômico: respostas quase instantâneas, ótimo para tarefas simples, curtas e em volume (classificar, reformatar, traduzir, responder o direto).
• Sonnet — o nível equilibrado: o "cavalo de batalha" para a maioria das tarefas profissionais — escrita, análise de documentos médios, código, troubleshooting.
• Opus (e, mais recentemente, níveis superiores) — o nível mais avançado: máximo raciocínio e profundidade, para tarefas complexas, ambíguas, longas ou de alto risco.

Pense em três marchas: você não dirige a cidade inteira em primeira, nem sai do estacionamento em quinta. Importante: nomes, versões e disponibilidade de modelos mudam com o tempo (novas gerações são lançadas regularmente). A lógica de níveis permanece; os nomes exatos disponíveis na sua interface você confere no seletor de modelo do Claude.ai e em https://docs.claude.com.

6. Explicação profunda

As dimensões reais da escolha

A diferença entre níveis de modelo não é "inteligência" genérica — são dimensões específicas:

Modelos mais avançados também costumam oferecer raciocínio estendido (extended thinking) — a capacidade de "pensar" por mais etapas antes de responder — que eleva a qualidade em problemas difíceis ao custo de mais tempo e tokens.

A matriz de decisão prática

Para cada tarefa, avalie quatro fatores:

1. Complexidade: quantas etapas de raciocínio? Há ambiguidade? Precisa conectar informações distantes?
2. Risco do erro: o que acontece se a resposta estiver 10% errada? (E-mail interno: nada. Procedimento de acesso publicado: incidente.)
3. Volume: é uma tarefa única ou 200 repetições? Volume alto empurra para modelos rápidos + prompts muito bem calibrados.
4. Necessidade de profundidade: você quer a resposta ou quer análise, alternativas e implicações?

Regra prática em uma frase: complexidade ou risco altos → modelo avançado; tarefa simples em volume → modelo rápido; dúvida → comece no equilibrado e suba se a resposta decepcionar.

Tabela de mapeamento para o seu dia a dia

Sintomas de escolha errada

Modelo subdimensionado: respostas rasas que ignoram partes do prompt; análise que fica na superfície ("verifique as configurações"); inconsistência em documentos longos; erros em lógica de várias etapas. Ação: suba um nível e repita o mesmo prompt — a comparação é instrutiva.

Modelo superdimensionado: você espera mais e consome mais limite para uma tarefa que o nível abaixo faria idêntico. Sintoma honesto: você nunca notou diferença naquela tarefa. Ação: desça um nível nas tarefas repetitivas e reserve o avançado para o que importa.

Modelo × prompt: qual pesa mais?

Um prompt excelente em um modelo equilibrado costuma superar um prompt vago no modelo mais avançado. A escolha do modelo é a segunda alavanca; a primeira é sempre o prompt (Módulo 6). Modelos avançados são mais tolerantes a prompts imperfeitos — o que é conveniência, não desculpa.

7. Conceitos-chave

• Família de modelos — níveis rápido (histórico: Haiku), equilibrado (Sonnet) e avançado (Opus e superiores).
• Latência — tempo de resposta.
• Custo por token — na API, preço cresce com o nível; no chat, consome limites mais rápido.
• Extended thinking — raciocínio estendido antes da resposta, para problemas difíceis.
• Matriz complexidade × risco × volume × profundidade — critério de escolha.
• Sub/superdimensionamento — modelo fraco demais ou forte demais para a tarefa.

8. Analogia didática

Escolher modelo é como escalar um chamado no Service Desk:

• L1 (modelo rápido): resolve o volume — senha, acesso, dúvidas padrão. Rápido, barato, suficiente para 70% dos casos.
• L2 (modelo equilibrado): problemas que exigem investigação e conhecimento amplo. O nível certo para a maioria do trabalho técnico de verdade.
• L3/especialista (modelo avançado): os casos complexos, ambíguos, com impacto — onde errar custa caro e a profundidade paga o preço.

Ninguém escala troca de senha para o L3 — e ninguém deixa um incidente de segurança no L1. Você já faz essa triagem todos os dias; agora vai aplicá-la a modelos.

9. Exemplo prático usando Claude

Rode o mesmo prompt em dois níveis de modelo (troque no seletor) e compare:

Um usuário reporta: "Desde ontem, peço MFA toda hora, várias vezes por dia,
mesmo no notebook corporativo que sempre usei. Meus colegas não têm o problema."
Ambiente: Entra ID com Conditional Access, dispositivos hybrid joined, Intune.

Tarefa: liste as hipóteses de causa em ordem de probabilidade, o que verificar
para confirmar/descartar cada uma (portal + logs) e qual pergunta faria ao
usuário primeiro. Formato: tabela.

No modelo rápido, espere uma lista correta porém genérica. No avançado, espere hipóteses mais finas (ex.: token lifetime, sign-in frequency na política de CA, estado de compliance do dispositivo quebrando o "trusted device", mudança recente de política) e melhor priorização. Sinta a diferença — ela vale mais do que qualquer tabela teórica.

10. Aplicação no dia a dia de TI

Crie sua regra pessoal de triagem e cole num post-it: "Rápido: reformatar, traduzir, classificar. Equilibrado: escrever, documentar, troubleshooting comum. Avançado: segurança, análise de documentos longos, material de estudo, qualquer coisa que eu vá publicar." Em uma semana a escolha vira reflexo.

11. Aplicação em Service Desk

Na triagem matinal de tickets, o modelo rápido resume e categoriza 20 chamados em minutos. Quando um deles se revela um incidente recorrente com padrão estranho, você muda para o avançado, cola o histórico dos casos semelhantes (anonimizado) e pede análise de causa comum. Mesmo fluxo de trabalho, dois modelos, cada um no seu papel.

12. Aplicação em Microsoft 365 / Entra ID / IAM / Intune

Para estudar para SC-300: use o equilibrado para explicações e flashcards do dia a dia (volume alto de interações) e o avançado para simulados comentados e para as sessões de "me explique este cenário de caso complexo de Conditional Access com múltiplas políticas em conflito" — onde a qualidade do raciocínio define o valor.

13. Prompts bons

Prompt bom 1 — pedindo ajuda na própria escolha:

Vou fazer a seguinte tarefa: [analisar 3 versões de uma política de acesso e
produzir um comparativo executivo com riscos]. Considerando complexidade,
risco e profundidade necessária, essa tarefa se beneficia de um modelo mais
avançado ou um intermediário basta? Justifique em 3 linhas.

Prompt bom 2 — extraindo o máximo de um modelo rápido:

Tarefa simples e em volume: vou colar 15 descrições de tickets. Para cada uma,
retorne APENAS: categoria (Hardware/Software/Acesso/Rede/Outro), urgência
sugerida (Baixa/Média/Alta) e um título padronizado de até 8 palavras.
Formato: tabela. Sem comentários adicionais.

14. Prompts ruins

Prompt ruim 1:

[No modelo mais rápido] Analise em profundidade esta política de segurança de
12 páginas, identifique todos os gaps em relação a Zero Trust, avalie riscos,
proponha plano de remediação priorizado e escreva o resumo executivo.

Cinco tarefas complexas encadeadas, alto risco, documento longo — no modelo errado. Resultado provável: análise superficial que "parece" completa. Pior que não fazer: dá falsa sensação de cobertura.

Prompt ruim 2:

[No modelo mais avançado, 40 vezes ao dia] Corrija a gramática desta frase.

Desperdício puro: consome limites/custo do nível mais caro para uma tarefa que o nível mais rápido executa de forma idêntica.

15. Por que os prompts bons funcionam melhor

O primeiro terceiriza a triagem para o próprio Claude com critérios explícitos — útil enquanto você constrói intuição. O segundo mostra a técnica que faz modelos rápidos brilharem: restringir o espaço de saída (só 3 campos, formato fixo, sem prosa). Modelos rápidos falham quando a tarefa exige julgamento aberto; acertam quando o prompt transforma julgamento em classificação. Os ruins violam exatamente isso: pedem julgamento profundo ao modelo de triagem e triagem ao modelo de julgamento.

16. Laboratório prático guiado

Objetivo: calibrar sua intuição comparando níveis. Tempo: 45 minutos.

1. Escolha 3 tarefas reais do seu trabalho: uma trivial (reformatar um texto), uma média (criar um mini procedimento) e uma complexa (analisar um cenário de troubleshooting com várias variáveis).
2. Rode cada tarefa em dois níveis de modelo (mesmo prompt, novo chat para cada rodada — para não contaminar o contexto).
3. Avalie com uma rubrica simples (nota 1–5 em: correção, profundidade, aderência ao formato, utilidade real).
4. Monte sua tabela pessoal: para cada tarefa, o nível a partir do qual a diferença deixou de valer a pena.
5. Bonus: repita a tarefa complexa no modelo avançado com raciocínio estendido habilitado (se disponível no seu plano) e observe o delta.
6. Conclusão escrita: complete: "No meu trabalho, o modelo rápido serve para ; o equilibrado para ; o avançado eu reservo para ___."

17. Exercícios de fixação

1. Classifique pelo nível de modelo ideal: (a) traduzir 30 mensagens de status para inglês; (b) revisar a redação de um incident report que vai para a diretoria; (c) explicar o que é SCIM; (d) analisar 6 meses de tickets recorrentes buscando causa raiz sistêmica.
2. Descreva 2 sintomas de que você está usando um modelo subdimensionado.
3. Verdadeiro ou falso, justifique: "Se eu sempre usar o modelo mais avançado, nunca terei problemas."
4. Reescreva este pedido para funcionar bem em um modelo rápido: "Dá uma olhada nesses tickets e me diz o que você acha."

18. Quiz (5 perguntas)

1. A lógica da família de modelos Claude é: a) Um modelo único com skins — b) Níveis com trade-offs de velocidade, custo e capacidade — c) Modelos por idioma — d) Modelos por sistema operacional

2. Qual tarefa MELHOR justifica o modelo mais avançado? a) Categorizar 50 tickets — b) Corrigir gramática — c) Analisar uma política de segurança e mapear gaps com plano de remediação — d) Traduzir uma frase

3. O principal sintoma de modelo subdimensionado é: a) Resposta muito rápida — b) Análise superficial que ignora nuances e partes do prompt — c) Resposta longa demais — d) Erro de ortografia

4. Sobre prompt × modelo, é correto: a) O modelo avançado dispensa bons prompts — b) Prompt bom em modelo equilibrado costuma superar prompt vago em modelo avançado — c) Prompts só importam em modelos rápidos — d) São independentes

5. Para 200 classificações repetitivas de baixo risco, a escolha racional é: a) Modelo avançado com raciocínio estendido — b) Modelo rápido com prompt de formato restrito — c) Alternar aleatoriamente — d) Não usar IA

19. Gabarito comentado

1 — b. É uma família deliberada de trade-offs: você compra velocidade/custo ou profundidade, conforme a tarefa. 2 — c. Complexidade multi-etapas + risco de segurança + necessidade de nuance: o perfil exato onde o nível avançado paga seu preço. As outras são tarefas mecânicas. 3 — b. Superficialidade e "esquecimento" de requisitos do prompt são os sinais clássicos. Velocidade (a) é característica, não defeito. 4 — b. O prompt é a primeira alavanca de qualidade; o modelo, a segunda. Modelos avançados toleram prompts piores, mas não substituem especificação. 5 — b. Volume + baixo risco + tarefa fechada = território do modelo rápido, desde que o prompt restrinja a saída (formato fixo, campos definidos).

20. Checklist do módulo

• Sei explicar os três níveis da família de modelos e seus trade-offs.
• Aplico a matriz complexidade × risco × volume × profundidade.
• Sei onde verificar os modelos disponíveis no meu plano (seletor + documentação).
• Reconheço sintomas de sub e superdimensionamento.
• Fiz o laboratório comparativo com 3 tarefas reais.
• Tenho minha regra pessoal de triagem escrita.

21. Erros comuns

• Dogmatismo de modelo único: usar sempre o mesmo nível para tudo, por hábito.
• Julgar um nível por uma tarefa inadequada a ele: "o rápido é ruim" após pedir análise profunda a ele.
• Ignorar o seletor de modelo: muita gente nem sabe que ele existe na interface.
• Não recomeçar o chat ao trocar de modelo para comparar: o histórico contamina o teste.
• Economizar no que importa: usar modelo rápido em análise de segurança para "gastar menos limite" — a economia mais cara do mês.

22. Boas práticas

• Padrão de partida: equilibrado; desça para volume mecânico, suba para complexidade/risco.
• Antes de tarefas grandes, gaste 30 segundos na triagem consciente.
• Ao subir de nível, reaproveite o mesmo prompt — a comparação ensina.
• Revise sua regra pessoal a cada nova geração de modelos: os níveis evoluem.
• Em uso corporativo/API, monitore consumo: a escolha de modelo é também uma decisão de orçamento.

23. Resumo final

"Claude" é uma família de modelos em níveis — rápido, equilibrado e avançado — com trade-offs claros de latência, custo e profundidade de raciocínio. A escolha correta segue uma matriz simples: complexidade e risco empurram para cima; volume e simplicidade, para baixo; a dúvida começa no meio. Prompts bem construídos ampliam qualquer nível, e a comparação prática (mesmo prompt, níveis diferentes) é a forma mais rápida de calibrar sua intuição. Nomes e versões mudam; a lógica de triagem — que você já domina do Service Desk — permanece.

24. Mini desafio

Monte a sua "tabela de escalação de modelos" com 9 linhas: 3 tarefas suas de cada nível (rápido, equilibrado, avançado), com uma justificativa de 1 linha por tarefa. Cole no Claude e peça: "Desafie minhas escolhas: em quais linhas você discorda e por quê?" Ajuste o que convencer.

25. Como eu aplicaria isso amanhã no trabalho

Amanhã eu começaria o dia no modelo rápido: triagem e resumo da fila de tickets, respostas padrão, traduções. Às 10h, ao pegar o chamado complexo da semana, trocaria conscientemente para o avançado, colaria o contexto completo e pediria a árvore de hipóteses. No fim do dia, anotaria: "a troca fez diferença onde?" Uma semana desse registro e minha tabela de escalação estaria validada com dados meus, não com teoria.

Adaptação para Fable — Módulo 3

Título curto para o card: "Qual modelo usar?"

Texto de abertura envolvente:

Você não escala troca de senha para o especialista L3, certo? Então por que usaria o modelo mais pesado da família Claude para corrigir uma vírgula — ou o mais leve para analisar uma política de segurança? Neste módulo, você aprende a triagem que separa quem usa IA de quem opera IA.

Divisão sugerida em telas: 1. Tela 1 — "Uma família, três marchas" (níveis e trade-offs) 2. Tela 2 — "A matriz de decisão" (complexidade × risco × volume × profundidade) 3. Tela 3 — "Tarefas de TI mapeadas" (tabela interativa) 4. Tela 4 — "Sintomas de escolha errada" 5. Tela 5 — Laboratório comparativo + quiz

Ideia de interação: card de decisão estilo "triagem de chamados": 8 tarefas de TI aparecem como tickets e o aluno as arrasta para L1/L2/L3 (rápido/equilibrado/avançado), com feedback imediato.

Pergunta reflexiva: "No seu trabalho, qual decisão desta semana merecia o 'especialista' — e recebeu tratamento de triagem?"

Microatividade prática: rodar o mesmo prompt de troubleshooting em dois níveis e colar no Fable uma diferença concreta observada.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Triagem dominada! Rápido para o volume, equilibrado para o dia a dia, avançado para o que tem risco e nuance. No próximo módulo, vamos ao recurso invisível que governa tudo isso por baixo: tokens e a janela de contexto.

Sugestão visual para o Fable: fluxograma de decisão em losangos ("Alto risco? → sim → avançado / não → Volume alto e tarefa fechada? → sim → rápido / não → equilibrado"), no estilo de árvore de troubleshooting que a aluna já conhece.

MÓDULO 4 — Tokens, context window e gerenciamento de contexto

1. Nome do módulo

A mesa de trabalho do Claude: tokens, janela de contexto e como não deixar a conversa degradar

2. Objetivo de aprendizagem

Dominar, na prática, como o Claude "lembra": o que são tokens, como funciona a context window, por que conversas longas perdem qualidade, e as técnicas de gestão de contexto — organizar, dividir, resumir, recomeçar e usar Projects — que mantêm a qualidade alta em trabalhos extensos.

3. O que você será capaz de fazer ao final do módulo

• Estimar o "peso" em tokens de textos, documentos e conversas.
• Reconhecer os sintomas de contexto saturado antes que a qualidade despenque.
• Decidir com critério: continuar a conversa, resumir e recomeçar, dividir a tarefa ou migrar para um Project.
• Estruturar conversas longas (criação de curso, análise extensa) sem perder consistência.

4. Por que esse tema importa no uso real do Claude

Este é o módulo que explica a frustração mais comum de usuários intermediários: "a conversa começou ótima e foi piorando". Você pede um material de estudo, itera 30 vezes, e lá pela mensagem 40 o Claude ignora instruções dadas no início, repete conteúdo e perde o fio. Não é o modelo "cansando" — é física de contexto. Quem entende o mecanismo transforma o problema em rotina de gestão: sabe quando dividir, quando resumir, quando recomeçar. Para quem cria materiais longos e analisa documentos extensos — exatamente o seu caso — esta é uma habilidade de sobrevivência.

5. Explicação simples

Imagine que o Claude trabalha em uma mesa de tamanho fixo. Tudo o que participa da conversa precisa estar sobre a mesa: suas mensagens, as respostas dele, os arquivos anexados, as instruções do Project. Cada palavra ocupa espaço — medido em tokens.

Enquanto a mesa está organizada e com folga, o trabalho flui. Quando a mesa lota:

• Coisas do começo da conversa ficam "soterradas" — tecnicamente ainda estão lá, mas recebem menos atenção;
• O Claude começa a se apoiar no que está mais visível (o recente) e a esquecer combinados antigos;
• A qualidade cai de um jeito sutil: não é um erro gritante, é uma perda gradual de fidelidade às suas instruções.

As soluções são as mesmas de uma mesa real: tirar da mesa o que não é mais necessário (recomeçar o chat), deixar um resumo em vez da pilha inteira (sumarização), trabalhar um dossiê por vez (dividir tarefas) e usar um armário organizado ao lado (Projects, onde instruções e arquivos ficam disponíveis de forma estruturada).

6. Explicação profunda

Tokens: a visão técnica

O texto é convertido em tokens por um tokenizer antes de chegar ao modelo. Tokens são subpalavras estatisticamente frequentes: "documentação" pode virar 3–4 tokens; "the" é 1. Números, código e texto em português tendem a gerar mais tokens por caractere do que prosa em inglês. Referências de bolso para PT-BR:

Context window: o que realmente acontece

A context window é o total de tokens processados em cada inferência. Detalhe que muda tudo: a cada nova mensagem sua, o modelo reprocessa a conversa inteira (dentro do limite) para gerar a próxima resposta. Não existe "memória incremental" — existe releitura da mesa toda, todas as vezes.

Disso derivam três fenômenos:

1. Saturação e truncamento. Se a conversa excede a janela, algo precisa sair — tipicamente conteúdo mais antigo deixa de ser considerado. Suas instruções da mensagem 1 podem literalmente sair da mesa.

2. Degradação de atenção ("lost in the middle"). Mesmo dentro do limite, a atenção não é uniforme: pesquisas mostram que modelos recuperam melhor informações do início e do fim de contextos longos do que do meio. Janela grande ≠ leitura perfeita de tudo. Consequência prática: em documentos longos, peça análises direcionadas por seção em vez de "analise tudo".

3. Acúmulo de ruído. Toda tentativa frustrada, todo rascunho descartado, toda digressão continua na mesa influenciando as próximas respostas. Uma conversa com 15 iterações ruins "ensina" o padrão ruim ao contexto.

Sintomas de contexto saturado (aprenda a reconhecer)

• O Claude ignora uma instrução de formato dada no início ("responda sempre em tabela") que vinha cumprindo.
• Repete conteúdo já produzido como se fosse novo.
• Mistura versões: usa termos do rascunho v1 que você já tinha corrigido na v3.
• Respostas ficam mais genéricas e menos ancoradas nos seus arquivos.
• Em tarefas seriadas (módulo 7 de um curso), o estilo diverge dos módulos 1–6.

O kit de técnicas de gestão de contexto

Técnica 1 — Front-loading (carga inicial organizada). Coloque as instruções permanentes, o contexto e os arquivos essenciais na PRIMEIRA mensagem, bem estruturados (o Módulo 6 ensina XML tags para isso). Instruções no início + reforço quando necessário funcionam melhor do que instruções pingadas ao longo de 30 mensagens.

Técnica 2 — Divisão de tarefas (chunking). Trabalhos grandes viram séries de conversas menores e focadas. Criar um curso de 10 módulos = 1 conversa de estrutura + 1 conversa por bloco de módulos, cada uma recebendo o resumo-mestre. Analisar 5 políticas = 5 análises individuais + 1 conversa de síntese com os 5 resumos.

Técnica 3 — Sumarização de transição (handover). Antes de uma conversa saturar, peça:

Esta conversa está longa. Gere um "resumo de transferência" para eu continuar
em um novo chat, contendo: 1) objetivo do trabalho; 2) decisões tomadas;
3) padrões e formatos combinados (com exemplos curtos); 4) estado atual;
5) próximos passos. Formato: pronto para colar como primeira mensagem.

É literalmente um handover de turno — conceito que você domina do Service Desk. O novo chat começa leve, com só o essencial na mesa.

Técnica 4 — Recomeço estratégico. Iterações ruins acumuladas? Não insista na mesma conversa: extraia o que prestou, monte um prompt melhor e recomece limpo. Chats são descartáveis; o trabalho consolidado é o que importa.

Técnica 5 — Projects como contexto persistente. Quando o mesmo conjunto de instruções + arquivos serve a muitas conversas (estudar para uma certificação, manter documentação), um Project resolve: as Project Instructions e o Knowledge ficam disponíveis a cada novo chat, sem você recolar nada — e cada chat individual permanece curto e limpo. É a diferença entre carregar a pilha de pastas para toda reunião e ter uma sala de guerra montada (Módulo 7).

Técnica 6 — Dieta de contexto. Suba só o que a tarefa exige. O CSV inteiro de 2.000 tickets quando a pergunta é sobre 1 categoria? Filtre antes. As 80 páginas do manual quando a dúvida é sobre o capítulo 3? Extraia o capítulo. Menos ruído = mais atenção ao que importa.

Quando usar o quê — árvore de decisão

1. Tarefa pontual e curta → chat simples, contexto na primeira mensagem.
2. Tarefa longa, mas única (analisar 1 documento grande) → chat simples + análise por seções + dieta de contexto.
3. Trabalho grande e decomponível (curso, análise múltipla) → divisão de tarefas + resumo-mestre entre conversas.
4. Conversa boa começando a saturar → sumarização de transição para novo chat.
5. Conversa contaminada por iterações ruins → recomeço estratégico.
6. Mesmo contexto usado repetidamente por semanas → Project.

7. Conceitos-chave

• Tokenizer — conversor de texto em tokens.
• Context window — limite total reprocessado a cada resposta.
• Saturação — contexto no limite; conteúdo antigo perde efeito.
• Lost in the middle — atenção menor ao meio de contextos longos.
• Front-loading — instruções e contexto estruturados na primeira mensagem.
• Chunking — dividir trabalho grande em conversas focadas.
• Resumo de transferência (handover) — sumário para migrar de chat mantendo o estado.
• Dieta de contexto — subir apenas o necessário.
• Contexto persistente — Projects mantendo instruções/arquivos entre chats.

8. Analogia didática

A context window é a bancada do técnico de campo. Chamado novo, bancada limpa: o diagnóstico flui. Ao longo do dia, a bancada acumula: peças do chamado anterior, três cafés, o manual aberto na página errada. Tecnicamente está tudo "disponível" — na prática, você pega a peça errada porque ela estava por cima. O técnico experiente faz o que você fará com o Claude: limpa a bancada entre chamados (novo chat), leva só a maleta certa (dieta de contexto), cola o checklist na parede (Project Instructions) e, ao passar o turno, escreve o handover em vez de apontar para a pilha e dizer "tá tudo aí" (resumo de transferência).

9. Exemplo prático usando Claude

Simule uma migração de conversa saturada. Em um chat onde você já trabalhou bastante (ou simule com 10+ trocas sobre um tema), envie o prompt de resumo de transferência da Técnica 3. Depois:

1. Abra um chat novo;
2. Cole o resumo como primeira mensagem, seguido de: "Continue o trabalho a partir deste estado. Confirme em 3 linhas o que entendeu antes de prosseguir.";
3. Compare a qualidade da continuação com a do chat antigo.

Você acaba de executar a manobra que separa quem sofre com conversas longas de quem as administra.

10. Aplicação no dia a dia de TI

• Documentação longa: um manual de 40 páginas nasce como estrutura (conversa 1) + capítulos em blocos (conversas 2–5, cada uma com o resumo-mestre) + revisão final (conversa 6 com o documento consolidado).
• Análise de logs/exports: filtre no Excel/PowerShell antes de subir; pergunte por recortes ("apenas eventos de sign-in com erro 50076 desta semana").
• Rotina: ao notar o primeiro sintoma de saturação, não "empurre mais um pouco" — faça o handover na hora. Custa 2 minutos; a degradação custa a tarde.

11. Aplicação em Service Desk

O conceito de handover você já pratica entre turnos e entre níveis (L1→L2). Aplique idêntico ao Claude: ao migrar um troubleshooting longo para um novo chat (ou para um colega usar), o resumo de transferência vira o registro estruturado do caso — sintoma, hipóteses testadas, descartadas, próxima ação. Bônus real: esse mesmo resumo, levemente editado, é a atualização perfeita do ticket.

12. Aplicação em Microsoft 365 / Entra ID / IAM / Intune

Estudo de certificação é maratona de semanas — o caso de uso perfeito para Project (contexto persistente: seu plano de estudos, o outline do exame, seus resumos) + chats curtos por tópico ("hoje: Conditional Access"). Cada sessão de estudo começa limpa, mas informada. Nunca estude 3 semanas na mesma conversa: você estará revisando com um tutor de mesa soterrada.

13. Prompts bons

Prompt bom 1 — análise direcionada de documento longo:

Anexei nossa baseline de segurança (60 páginas). NÃO analise tudo de uma vez.
Primeiro: liste as seções do documento com uma linha de descrição cada.
Vou escolher as seções e pediremos a análise profunda uma seção por vez.

Prompt bom 2 — trabalho seriado com âncora de consistência:

Vamos criar o módulo 4 de um curso. Para manter consistência, aqui está o
resumo-mestre do projeto:
<resumo>
[objetivo do curso, público, tom, estrutura fixa de cada módulo, decisões tomadas]
</resumo>
Siga EXATAMENTE a estrutura e o tom definidos no resumo. Crie apenas o módulo 4.

14. Prompts ruins

Prompt ruim 1:

[Mensagem 47 de uma conversa quilométrica]
Continua o curso daí. Faz o módulo 8 igual aos outros.

"Igual aos outros" aponta para um padrão soterrado em dezenas de milhares de tokens atrás. O modelo vai reconstruir o padrão do que está mais visível — provavelmente divergindo. Faltou a âncora explícita (resumo-mestre).

Prompt ruim 2:

[Anexando 6 PDFs, 300 páginas no total]
Leia tudo e me diga o que é importante.

Sem pergunta definida, sem recorte, com carga máxima de contexto: receita para resposta genérica sobre material caro. "O que é importante" depende de um objetivo que não foi dado.

15. Por que os prompts bons funcionam melhor

Ambos aplicam engenharia de contexto: o primeiro impõe navegação antes de análise (mapa de seções → análise focada), garantindo que cada resposta profunda trabalhe com contexto pequeno e relevante — driblando o "lost in the middle". O segundo substitui uma referência implícita a um histórico gigante ("igual aos outros") por uma âncora explícita e compacta (o resumo-mestre em tags), que cabe confortavelmente na mesa e não depende da atenção ao passado distante. Os ruins fazem o contrário: maximizam carga e minimizam direção.

16. Laboratório prático guiado

Objetivo: vivenciar saturação e dominar o handover. Tempo: 50 minutos.

1. Monte um trabalho seriado: peça ao Claude a estrutura de um mini guia de 6 seções sobre um tema seu (ex.: "onboarding de novo colaborador no M365"). Defina 3 regras de formato na primeira mensagem (ex.: toda seção termina com checklist; tom direto; títulos numerados).
2. Produza as seções 1 a 3 na mesma conversa, iterando pelo menos duas vezes em cada (peça mudanças, gere versões).
3. Observe: na seção 3, as 3 regras da mensagem 1 ainda estão sendo 100% respeitadas? Anote qualquer desvio.
4. Execute o handover: peça o resumo de transferência (Técnica 3). Leia criticamente: ele capturou as 3 regras? Complete o que faltar.
5. Migre: novo chat, cole o resumo, produza as seções 4 a 6.
6. Compare consistência entre as seções 1–3 (conversa carregada) e 4–6 (conversa limpa com âncora).
7. Estime tokens: cole um trecho de 500 palavras e pergunte ao Claude uma estimativa de tokens — calibre sua régua mental.

17. Exercícios de fixação

1. Liste 4 sintomas de contexto saturado que você mesma consiga reconhecer.
2. Um colega reclama: "usei o Claude por 3 horas na mesma conversa e ele ficou burro". Explique tecnicamente o fenômeno e prescreva duas técnicas.
3. Planeje a divisão em conversas de um trabalho real: "criar o manual de troubleshooting de impressoras da empresa (8 capítulos, base: 5 documentos antigos)". Quantas conversas, o que vai em cada uma, o que transita entre elas?
4. Escreva, com suas palavras, seu template pessoal de "resumo de transferência" com 5 campos.

18. Quiz (5 perguntas)

1. A cada nova mensagem em uma conversa, o modelo: a) Lê apenas a mensagem nova — b) Reprocessa toda a conversa dentro do limite da janela — c) Consulta um banco de memórias — d) Lê só os anexos

2. "Lost in the middle" refere-se a: a) Perda de conexão — b) Atenção menor a informações no meio de contextos longos — c) Erro de tradução — d) Falha do tokenizer

3. O melhor momento para o resumo de transferência é: a) Quando a conversa já quebrou — b) Aos primeiros sintomas de saturação/desvio — c) Nunca; conversas devem ser eternas — d) Só em Projects

4. Para analisar um PDF de 80 páginas com qualidade, a melhor estratégia é: a) "Analise tudo e diga o que é importante" — b) Mapear seções e analisar por partes, com perguntas específicas — c) Subir o PDF 3 vezes — d) Usar só o modelo rápido

5. Projects ajudam na gestão de contexto porque: a) Aumentam a context window ao infinito — b) Mantêm instruções e arquivos persistentes, permitindo chats individuais curtos e limpos — c) Desligam o tokenizer — d) Impedem alucinações

19. Gabarito comentado

1 — b. Não há memória incremental: é releitura da mesa toda, a cada turno. Por isso o tamanho e a limpeza da conversa afetam cada resposta. 2 — b. Fenômeno documentado em LLMs: início e fim do contexto recebem mais atenção. Motivo para análises direcionadas em vez de "leia tudo". 3 — b. Handover é manobra preventiva. Depois que o padrão degradou, você ainda pode recomeçar — mas gastou iterações ruins à toa. 4 — b. Mapa primeiro, profundidade depois, uma seção por vez: contexto pequeno e relevante a cada resposta. 5 — b. Projects não aumentam a janela — eles organizam o que entra nela: o essencial persiste, e cada conversa nova começa leve. (E não, nada impede alucinações; isso é grounding + validação.)

20. Checklist do módulo

• Sei estimar tokens com as regras de bolso de PT-BR.
• Entendo que cada resposta reprocessa a conversa inteira.
• Reconheço os 5 sintomas de saturação.
• Domino as 6 técnicas: front-loading, chunking, handover, recomeço, Projects, dieta de contexto.
• Fiz o laboratório de saturação + handover.
• Tenho meu template de resumo de transferência salvo.

21. Erros comuns

• Conversa eterna: manter um único chat para "tudo sobre o projeto X" por semanas.
• Instruções pingadas: definir regras aos poucos, ao longo de 30 mensagens, e esperar que todas persistam.
• Referências implícitas ao passado distante: "como combinamos lá no começo…" — recole o combinado.
• Upload maximalista: subir tudo "por via das dúvidas".
• Insistir em conversa contaminada: tentar consertar com a 12ª iteração o que um recomeço limpo resolveria na 1ª.

22. Boas práticas

• Primeira mensagem = mini briefing completo: papel, objetivo, regras, formato, contexto.
• Um chat, um objetivo. Nomeie os chats pelo objetivo.
• Handover preventivo ao primeiro sinal de desvio.
• Em séries, toda conversa começa com o resumo-mestre — mesmo dentro de um Project.
• Filtre e recorte dados antes de subir; pergunte por seções em documentos longos.

23. Resumo final

O Claude trabalha sobre uma mesa finita — a context window — reprocessada por inteiro a cada resposta. Conversas longas degradam por saturação, atenção desigual (lost in the middle) e acúmulo de ruído; nada disso é defeito misterioso, e tudo tem contramedida: front-loading de instruções, divisão de tarefas, resumo de transferência (o handover que você já pratica no Service Desk), recomeço estratégico, dieta de contexto e Projects para persistência. Gestão de contexto é a competência que sustenta todos os trabalhos longos deste curso — da criação de cursos (Módulo 11) à análise documental (Módulo 8).

24. Mini desafio

Crie e salve o seu "Protocolo de Conversa Longa" em 6 linhas: (1) o que vai na primeira mensagem; (2) quando divido a tarefa; (3) sinais para handover; (4) meu template de resumo de transferência; (5) quando recomeço do zero; (6) quando promovo o trabalho a Project. Valide o protocolo com o próprio Claude e guarde — você o usará no projeto final do curso.

25. Como eu aplicaria isso amanhã no trabalho

Amanhã eu identificaria minha conversa mais longa e bagunçada no Claude (todo mundo tem uma), pediria o resumo de transferência, migraria para um chat limpo e sentiria a diferença na primeira resposta. Depois, no próximo documento grande que precisasse analisar, aplicaria "mapa de seções primeiro, análise por partes depois". Dois hábitos, um dia, qualidade visivelmente maior.

Adaptação para Fable — Módulo 4

Título curto para o card: "A mesa finita do Claude"

Texto de abertura envolvente:

Toda conversa com o Claude acontece sobre uma mesa de tamanho fixo — e tudo compete por espaço: suas mensagens, as respostas, os arquivos. Quando a mesa lota, a qualidade escorrega em silêncio. Neste módulo você aprende a enxergar a mesa, reconhecer os sinais de bagunça e dominar o handover — a mesma manobra que você já faz na troca de turno.

Divisão sugerida em telas: 1. Tela 1 — "Tokens: a moeda do contexto" (régua de estimativas PT-BR) 2. Tela 2 — "A mesa que se enche" (animação: conversa crescendo, itens antigos apagando) 3. Tela 3 — "5 sintomas de saturação" (checklist visual) 4. Tela 4 — "O kit de 6 técnicas" (cards viráveis) 5. Tela 5 — "O handover" (template + demonstração) 6. Tela 6 — Laboratório + quiz

Ideia de interação: simulação "Salve esta conversa": o aluno vê uma transcrição fictícia com sinais de saturação e escolhe entre continuar / resumir e migrar / dividir / recomeçar — com feedback sobre cada escolha.

Pergunta reflexiva: "No seu trabalho, o que acontece quando um turno passa sem handover decente? Agora transfira essa cena para uma conversa de 3 horas com o Claude."

Microatividade prática: pedir um resumo de transferência de uma conversa real e colar no Fable o campo que o Claude esqueceu (e que você precisou completar).

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Mesa sob controle! Você agora administra o recurso invisível que decide a qualidade de todo trabalho longo. No próximo módulo, um tour completo pela interface do Claude.ai — onde tudo isso acontece na prática.

Sugestão visual para o Fable: diagrama "mesa de trabalho" com blocos coloridos representando instruções, arquivos, histórico e resposta — e uma segunda versão da mesma mesa saturada, com blocos do início esmaecidos.

MÓDULO 5 — Claude.ai na prática

1. Nome do módulo

Dominando a interface: chats, arquivos, imagens, organização e fluxo de trabalho no Claude.ai

2. Objetivo de aprendizagem

Operar o Claude.ai com fluidez: navegar a interface, gerenciar conversas, selecionar modelos, enviar arquivos e imagens, aproveitar e exportar respostas, organizar o histórico e montar um fluxo de trabalho pessoal para estudar e trabalhar.

3. O que você será capaz de fazer ao final do módulo

• Localizar e usar todos os controles relevantes da interface (seletor de modelo, anexos, ferramentas, histórico, Projects).
• Enviar documentos e imagens da forma certa para cada tipo de tarefa.
• Reaproveitar, editar e exportar respostas sem retrabalho.
• Manter o histórico organizado e operar com um fluxo diário eficiente.

4. Por que esse tema importa no uso real do Claude

Conhecimento conceitual sem fluência operacional gera atrito: você sabe o que pedir, mas tropeça no como — não acha onde trocar o modelo, cola print como texto, perde respostas boas em conversas sem nome. Fluência na interface é o que transforma o Claude de "site que eu visito" em bancada de trabalho diária. E, como interfaces evoluem, este módulo ensina também o meta-hábito: explorar mudanças com segurança e consultar https://support.claude.com quando algo mudar de lugar.

5. Explicação simples

A interface do Claude.ai gira em torno de poucos elementos:

• Campo de mensagem — onde você escreve. Aceita textos longos (cole à vontade) e quebra de linha (Shift+Enter).
• Botão de anexar (+ / clipe) — envia PDFs, DOCX, TXT, CSV, imagens e outros arquivos para a conversa.
• Seletor de modelo — geralmente junto ao campo de mensagem; alterna entre os níveis da família (Módulo 3).
• Menu de ferramentas — dependendo do plano, ativa/desativa recursos como busca na web, análise de código e criação de arquivos.
• Barra lateral — histórico de conversas, busca, e a área de Projects.
• Área de resposta — onde chegam as respostas, com botões de copiar e, quando o conteúdo é interativo (Artifacts, Módulo 10), um painel próprio.

E três gestos que mudam o jogo: editar sua própria mensagem (refaz a resposta a partir dali — ótimo para consertar um prompt sem poluir o contexto), regenerar/tentar novamente uma resposta, e renomear conversas para achá-las depois.

6. Explicação profunda

Conversas: criar, editar, ramificar

Cada conversa é um contexto isolado (Módulo 4). Práticas que valem ouro:

• Um chat, um objetivo — e renomeie imediatamente ("KB - VPN timeout", "Estudo SC-300 - CA policies"). Daqui a 3 semanas, você vai agradecer.
• Editar mensagem anterior em vez de mandar correção por cima: editar cria uma "ramificação" limpa a partir daquele ponto; corrigir por cima mantém o erro E a correção no contexto, gastando espaço e criando ruído.
• Regenerar quando a resposta veio fraca por azar da geração (acontece — é não-determinismo, Módulo 2): antes de reescrever seu prompt, uma regeneração às vezes resolve.
• Busca no histórico — a barra lateral tem busca; combinada com nomes decentes, torna seu histórico uma base de conhecimento pessoal.

Upload de arquivos

O Claude aceita os formatos que você usa todo dia: PDF, DOCX, TXT, MD, CSV, XLSX, JSON, HTML e imagens (PNG, JPG etc.). Pontos de atenção:

• Arquivos consomem context window (Módulo 4): o PDF de 100 páginas entra inteiro na mesa. Dieta de contexto se aplica.
• PDFs escaneados (imagem de texto, sem camada de texto) são mais difíceis: o Claude consegue ler imagens, mas a extração é menos confiável que texto nativo. Prefira PDFs "de verdade" quando existirem.
• Planilhas: para análises que exigem cálculo (somas, médias, agrupamentos), verifique se o recurso de análise/execução de código está ativo nas ferramentas — com ele, o Claude calcula de fato em vez de estimar lendo o texto (lembre: LLM prevê texto, não calcula nativamente).
• Há limites de tamanho e quantidade por conversa que variam por plano — se um upload falhar, é provavelmente limite; confira no support.claude.com.
• O Módulo 8 dedica-se inteiro à arte de preparar e analisar documentos.

Imagens e visão

O Claude "enxerga": envie prints de tela de erro, diagramas, fotos de quadro branco. Casos de ouro para você:

• Print do erro do usuário → "descreva o erro, causas prováveis e próximos passos de troubleshooting";
• Print de configuração de portal → "explique o que está configurado aqui e aponte riscos";
• Diagrama antigo em foto → "transcreva este diagrama em texto estruturado".

Regra de segurança inegociável: antes de subir qualquer print, verifique o que aparece nele — nome do usuário, e-mail, hostname, IPs internos, tokens em barras de endereço. Recorte ou borre. Um print de tela é um vazamento em potencial (Módulo 20 formaliza).

Ferramentas da conversa

Dependendo de plano e configuração, você pode habilitar: - Busca na web — para fatos recentes; peça citação de fontes e prefira fontes oficiais. - Análise de código / criação de arquivos — o Claude escreve e executa código para calcular, gerar gráficos e produzir arquivos (DOCX, XLSX, PDF) para download. - Artifacts — conteúdo interativo em painel dedicado (Módulo 10). - Conectores/integrações — fontes externas via MCP (Módulo 15) — em contexto corporativo, sujeitos à aprovação da organização.

Hábito profissional: saiba o que está ligado. Busca na web desligada + pergunta sobre novidade = resposta desatualizada; recurso de análise desligado + pedido de cálculo em planilha = números estimados.

Reaproveitamento e exportação

• Copiar blocos de resposta (botão de copiar preserva formatação/Markdown).
• Pedir o formato final na própria conversa: "gere este procedimento como arquivo DOCX para download" (com criação de arquivos ativa) — melhor do que copiar/colar e reformatar.
• Compilar no fim do trabalho: "junte tudo o que aprovamos nesta conversa em um único documento final, sem os rascunhos".
• Dados da conta: é possível exportar seus dados/conversas nas configurações da conta — útil para backup pessoal; em contexto corporativo, siga a política interna.

Um fluxo diário de referência

1. Manhã (5 min): chat rápido de triagem — colar pendências/anotações, pedir organização do dia.
2. Durante o dia: um chat novo por tarefa, nomeado; modelo escolhido por triagem (Módulo 3); arquivos sob dieta de contexto.
3. Tarefas recorrentes: dentro do Project correspondente (Módulo 7).
4. Fim do trabalho: compilar o que foi aprovado; copiar/exportar para o destino final (KB, wiki, OneNote).
5. Sexta (10 min): varrer o histórico, renomear o que ficou sem nome, deletar rascunhos mortos, promover a Project o que virou recorrente.

7. Conceitos-chave

• Seletor de modelo — alternância entre níveis da família.
• Anexos — upload de documentos e imagens para o contexto.
• Editar mensagem / regenerar — corrigir a conversa sem acumular ruído.
• Ferramentas da conversa — busca na web, análise de código, criação de arquivos, conectores.
• Visão (vision) — capacidade de interpretar imagens e prints.
• Artifacts — painel de conteúdo interativo (aprofundado no Módulo 10).
• Histórico nomeado — conversas como base de conhecimento pessoal.

8. Analogia didática

Aprender a interface do Claude.ai é como o primeiro dia com um console de administração novo (pense no seu primeiro contato com o Intune Admin Center): os conceitos você já sabia — política, perfil, compliance — mas produtividade mesmo só veio quando você soube onde ficava cada coisa, o que cada toggle fazia e quais os três caminhos que você usa 90% do tempo. Este módulo é o "tour guiado de console" — e, como todo console, ele muda de layout de vez em quando; o profissional não decora pixels, decora conceitos e sabe onde está a documentação.

9. Exemplo prático usando Claude

Teste a visão com um caso realista e seguro:

1. Tire um print de uma tela de erro genérica (ex.: uma página "não foi possível conectar" do navegador — nada corporativo).
2. Anexe no chat com o prompt:

Print de erro em anexo. 1) Transcreva a mensagem de erro exata.
2) Explique o que ela significa em linguagem simples.
3) Liste 3 causas prováveis em ordem e o teste rápido para cada uma.
4) Escreva a pergunta que eu deveria fazer ao usuário primeiro.

1. Observe a estrutura da resposta — esse formato de 4 passos é reutilizável para praticamente qualquer print de erro do Service Desk (com prints devidamente higienizados).

10. Aplicação no dia a dia de TI

• Configure atalhos mentais: Shift+Enter para parágrafos no prompt; copiar com formatação para colar em Markdown na wiki.
• Padronize nomes de chat com prefixos: KB -, TSHOOT -, ESTUDO -, DOC -. Busca instantânea depois.
• Antes de pedidos com cálculo ou fatos recentes, cheque as ferramentas ativas — 5 segundos que evitam respostas erradas.

11. Aplicação em Service Desk

O gesto de editar a própria mensagem é subestimado no atendimento: você descreve o caso ao Claude, percebe que esqueceu um sintoma crucial, e em vez de mandar "ah, esqueci de dizer que..." (que deixa a linha de raciocínio contaminada), edita a mensagem original incluindo o sintoma. A análise renasce completa e limpa — como refazer a triagem com a informação certa desde o início.

12. Aplicação em Microsoft 365 / Entra ID / IAM / Intune

Prints de portais Microsoft são seu caso de visão mais frequente — e o mais sensível. Um print do Entra mostra tenant, UPNs, object IDs, nomes de políticas. Estabeleça seu ritual: recortar só a área necessária, borrar identificadores, e então pedir "explique o que esta configuração de Conditional Access faz e que efeitos colaterais pode ter". O Claude lê a estrutura da política na imagem e raciocina sobre ela — validação final, como sempre, no portal e na documentação oficial.

13. Prompts bons

Prompt bom 1 — análise de print com estrutura:

Anexei um print (dados sensíveis removidos) de uma política de Conditional Access.
1) Descreva o que a política faz, campo a campo.
2) Aponte combinações de configuração que podem gerar efeito indesejado.
3) Liste o que NÃO é possível determinar só pelo print e onde eu verificaria.

Prompt bom 2 — compilação de fim de conversa:

Chegamos à versão final. Compile em um único documento:
- o procedimento aprovado (última versão de cada seção, ignorando rascunhos);
- o checklist final;
- a nota de limitações que discutimos.
Formato: Markdown pronto para eu colar na wiki. Depois gere também como DOCX.

14. Prompts ruins

Prompt ruim 1:

[Print de tela inteira do portal, com nome do tenant, e-mail do admin e lista de usuários visíveis]
o que ta errado aqui?

Dois problemas graves: vazamento de dados sensíveis no print (risco real de compliance) e pergunta sem direção — "errado" em relação a quê? Que comportamento era esperado?

Prompt ruim 2:

[Colando o conteúdo de um XLSX como texto desalinhado no chat]
soma ai a coluna de horas por categoria

Formato destruído no copy/paste (colunas viram sopa de texto) e pedido de cálculo sem ferramenta de análise — o modelo vai "estimar" a soma lendo texto, com alta chance de erro. O certo: anexar o arquivo e ativar/confirmar a ferramenta de análise.

15. Por que os prompts bons funcionam melhor

O primeiro estrutura a análise da imagem em camadas (descrever → avaliar → delimitar), e a terceira camada — "o que NÃO dá para saber pelo print" — é um antídoto direto contra alucinação visual (o modelo preencher lacunas do que não aparece). O segundo aproveita a interface a favor: manda o Claude fazer a curadoria (versões finais vs. rascunhos) e entrega nos dois formatos de destino, eliminando o retrabalho manual de garimpar a conversa. Os ruins somam risco de segurança, perda de estrutura de dados e ausência de critério — os três pecados operacionais.

16. Laboratório prático guiado

Objetivo: tour completo com produção real. Tempo: 60 minutos.

1. Reconhecimento (10 min): percorra a interface e localize: seletor de modelo, botão de anexos, menu de ferramentas (o que está ativo?), busca do histórico, área de Projects, configurações da conta.
2. Chat com nome e objetivo (10 min): crie "LAB - Procedimento de teste", peça um mini procedimento de 5 passos sobre um tema seu. Itere uma vez pedindo mudança de tom.
3. Edição de mensagem (5 min): edite sua primeira mensagem adicionando um requisito novo ("inclua uma seção de pré-requisitos") e veja a resposta renascer.
4. Upload de documento (10 min): anexe um PDF ou DOCX não sensível e peça: sumário em 5 bullets + 3 perguntas que o documento não responde.
5. Visão (10 min): o exercício do print genérico da seção 9.
6. Exportação (10 min): peça a compilação final (prompt bom 2) e, se disponível, o arquivo DOCX para download.
7. Faxina (5 min): renomeie os chats do laboratório com prefixos, delete o que não serve.

17. Exercícios de fixação

1. Explique a diferença prática entre editar sua mensagem e enviar uma correção por cima — em termos de contexto (Módulo 4).
2. Liste 5 informações sensíveis que costumam aparecer em prints de portais Microsoft e o que fazer com cada uma antes do upload.
3. Por que pedir "soma a coluna X" sem ferramenta de análise ativa é arriscado? Que conceito do Módulo 2 explica?
4. Desenhe (em texto) seu fluxo diário ideal com o Claude, em 5 passos.

18. Quiz (5 perguntas)

1. Editar uma mensagem sua anterior faz com que: a) A conversa seja apagada — b) A resposta seja regenerada a partir dali, sem o ruído da versão errada — c) Nada aconteça — d) O modelo mude sozinho

2. Para cálculos confiáveis sobre uma planilha, você deve: a) Colar a planilha como texto — b) Anexar o arquivo e usar o recurso de análise/execução de código — c) Pedir "capriche nas contas" — d) Converter para PDF

3. Antes de subir um print de portal corporativo, o passo obrigatório é: a) Aumentar a resolução — b) Verificar e remover dados sensíveis visíveis — c) Converter para PDF — d) Nada; prints são seguros

4. A prática que transforma seu histórico em base de conhecimento é: a) Nunca deletar nada — b) Um chat por objetivo + nomes padronizados + revisão periódica — c) Usar um único chat gigante — d) Exportar tudo diariamente

5. Busca na web desligada + pergunta sobre um lançamento do mês passado resulta em: a) Erro de sistema — b) Resposta baseada no conhecimento de treino, possivelmente desatualizada — c) Resposta sempre correta — d) Bloqueio da conta

19. Gabarito comentado

1 — b. Editar ramifica a conversa a partir do ponto corrigido: a linha de raciocínio nova nasce sem o erro no contexto. Corrigir por cima mantém erro + correção ocupando a mesa. 2 — b. LLM prevê texto; ferramenta de análise executa código. Para números, você quer código rodando, não previsão de texto plausível. 3 — b. Print é dado. Nome de tenant, UPNs, IDs e hostnames vazam em um pixel. Higienizar antes é regra inegociável (Módulo 20). 4 — b. Organização é o que torna o histórico pesquisável e reutilizável. Um chat gigante é o anti-padrão do Módulo 4. 5 — b. Sem busca, o modelo responde com o que sabia até a data de corte — com fluência total e nenhum aviso automático de desatualização. Saber o que está ligado é responsabilidade da operadora.

20. Checklist do módulo

• Localizo todos os controles: modelo, anexos, ferramentas, histórico, Projects, configurações.
• Uso editar/regenerar em vez de corrigir por cima.
• Sei anexar documentos e imagens — e higienizo prints antes.
• Sei quando preciso de busca na web ou análise de código, e verifico se estão ativos.
• Tenho padrão de nomes de chat e rotina de organização.
• Sei compilar e exportar o resultado final de uma conversa.

21. Erros comuns

• Colar conteúdo de planilha como texto e esperar análise numérica confiável.
• Prints sem higienização — o erro de segurança mais comum e mais evitável.
• Ignorar o seletor de modelo e as ferramentas — operar sempre "no default" sem saber o que o default é.
• Histórico-lixão: 80 conversas chamadas "Nova conversa".
• Garimpar respostas manualmente no fim de um trabalho longo em vez de pedir a compilação ao próprio Claude.

22. Boas práticas

• Ritual de 5 segundos antes de cada tarefa: modelo certo? ferramentas certas? chat novo ou existente?
• Prefixos de nome de chat (KB -, TSHOOT -, ESTUDO -, DOC -).
• Higienização de prints como reflexo, não como exceção.
• Pedir o formato de destino (Markdown, DOCX, tabela) na própria conversa.
• Sexta-feira: 10 minutos de faxina e promoção de temas recorrentes a Projects.

23. Resumo final

O Claude.ai é sua bancada: campo de mensagem, anexos, seletor de modelo, ferramentas, histórico e Projects. A fluência vem de gestos pequenos com efeito grande — editar em vez de corrigir por cima, nomear conversas, higienizar prints, ativar a ferramenta certa para a tarefa, compilar antes de sair. Interfaces mudam; os conceitos (contexto, grounding, triagem de modelo) e o hábito de consultar a documentação oficial permanecem. Com a bancada dominada, você está pronta para a habilidade central do curso: escrever prompts profissionais.

24. Mini desafio

Monte seu "Setup pessoal do Claude.ai" em uma página: prefixos de nomes que vai usar, ferramentas que mantém ativas por padrão, seu ritual de 5 segundos pré-tarefa, sua rotina de sexta-feira e suas 3 regras de higienização de prints. Cole no Claude e peça uma versão em checklist visual para imprimir.

25. Como eu aplicaria isso amanhã no trabalho

Amanhã eu aplicaria o fluxo completo em um caso só: pegaria um print de erro real (higienizado), abriria um chat nomeado TSHOOT - [tema], usaria o prompt estruturado de análise de imagem, iteraria com edição de mensagem quando percebesse falta de informação, e terminaria pedindo a compilação do diagnóstico em formato de atualização de ticket. Um ciclo completo — entrada visual, análise, iteração limpa, saída pronta — em um chamado de verdade.

Adaptação para Fable — Módulo 5

Título curto para o card: "Sua bancada de trabalho"

Texto de abertura envolvente:

Você já entendeu o motor; agora vamos ao painel de controle. Onde troco o modelo? Como mando um print sem vazar dados? Por que editar a mensagem é melhor que corrigir por cima? Neste módulo, o Claude.ai deixa de ser um site e vira a sua bancada — organizada do seu jeito.

Divisão sugerida em telas: 1. Tela 1 — "Tour pela interface" (hotspots clicáveis sobre um mockup) 2. Tela 2 — "Os 3 gestos de ouro" (editar, regenerar, nomear) 3. Tela 3 — "Arquivos e imagens sem sustos" (+ ritual de higienização de prints) 4. Tela 4 — "Ferramentas: saiba o que está ligado" 5. Tela 5 — "Seu fluxo diário" (linha do tempo manhã→sexta) 6. Tela 6 — Laboratório + quiz

Ideia de interação: cenário prático "Higienize este print": uma imagem fictícia de portal com 6 dados sensíveis; o aluno toca em cada um que precisa ser removido antes do upload (gamificado: 6/6 = aprovado).

Pergunta reflexiva: "Quantas conversas no seu histórico se chamam 'Nova conversa'? O que isso diz sobre reaproveitamento do seu próprio trabalho?"

Microatividade prática: renomear 5 conversas antigas com o padrão de prefixos e relatar qual delas você redescobriu com valor.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Bancada montada, gestos afiados, prints higienizados. Agora vem o módulo mais importante do curso inteiro: a arte de escrever prompts que transformam o Claude de assistente mediano em colega excepcional.

Sugestão visual para o Fable: mockup anotado da interface com callouts numerados (estilo "mapa de console" da documentação Microsoft), mais um card de checklist "ritual de 5 segundos".

MÓDULO 6 — Prompt engineering para Claude

1. Nome do módulo

Prompt engineering: a especificação de trabalho que transforma respostas medianas em resultados profissionais

2. Objetivo de aprendizagem

Dominar a construção de prompts profissionais para o Claude: os componentes de um bom prompt (clareza, contexto, objetivo, papel, formato, restrições, exemplos, critérios), as técnicas estruturais (XML tags, variáveis, decomposição, raciocínio passo a passo) e os padrões específicos para os casos de uso de TI — revisão, estudo, documentação, troubleshooting, criação de cursos, diagramas e análise de incidentes — consolidados em uma biblioteca de prompts reutilizáveis.

3. O que você será capaz de fazer ao final do módulo

• Escrever prompts com os 8 componentes de qualidade, sabendo quando cada um é necessário.
• Estruturar prompts complexos com XML tags e variáveis reutilizáveis.
• Decompor tarefas grandes em cadeias de prompts.
• Diagnosticar por que um prompt falhou e corrigi-lo com método.
• Usar e adaptar uma biblioteca de prompts profissionais para TI.

4. Por que esse tema importa no uso real do Claude

Todos os módulos anteriores prepararam esta cena: você sabe o que é o modelo, como ele pensa, qual nível escolher e onde clicar. Mas a alavanca que responde por 70% da qualidade final é o prompt. A mesma tarefa, no mesmo modelo, pode render uma resposta genérica de blog ou um documento pronto para publicar — e a diferença inteira está na especificação. Pense em como você escreve um bom ticket de escalação para o L3: sintoma preciso, ambiente, o que já foi testado, o que se espera. Um prompt é exatamente isso: um ticket bem escrito para um executor muito capaz e muito literal. Este módulo é o coração do curso; tudo que vem depois (Projects, análise documental, Artifacts, agentes) multiplica o que você constrói aqui.

5. Explicação simples

Um bom prompt responde, no mínimo, a quatro perguntas — as mesmas de qualquer delegação bem feita:

1. Quem você é / o que está acontecendo? (contexto)
2. O que exatamente você quer? (objetivo/tarefa)
3. Como quer receber? (formato de saída)
4. O que não pode acontecer? (restrições)

Compare:

❌ "Escreve um texto sobre MFA."

✅ "Sou analista de Service Desk. Preciso de um texto de 200 palavras explicando aos usuários finais (não técnicos) por que a empresa vai ativar MFA, em tom tranquilizador, sem jargões, terminando com os 3 passos que eles farão na segunda-feira. Não mencione métodos que não usaremos (SMS)."

O segundo prompt não é "mais educado" — é mais especificado. O Claude não adivinha intenções; ele executa especificações. Quanto mais o seu prompt parece uma boa ordem de serviço, melhor o resultado.

6. Explicação profunda

6.1 Os oito componentes de um prompt profissional

1) Clareza. Frases diretas, uma instrução por frase, verbos de ação ("liste", "compare", "reescreva", "identifique"). Ambiguidade no prompt vira loteria na resposta. Teste mental: outra pessoa da equipe executaria esta tarefa do jeito que eu quero, lendo só o que escrevi? Se não, o Claude também não.

2) Contexto. Quem você é, para quem é o resultado, qual a situação, o que já existe. Contexto restringe o espaço de respostas possíveis — é o mesmo mecanismo do grounding (Módulo 2), aplicado à intenção. Sem contexto, o modelo assume o "usuário médio da internet"; e você não é a média.

3) Objetivo. A tarefa em si, com escopo delimitado: o quê, sobre o quê, até onde. "Analise este documento" é infinito; "identifique neste documento inconsistências entre a seção de requisitos e a seção de exceções" é executável.

4) Papel/persona. "Aja como um arquiteto de identidade sênior revisando a política de um cliente" muda o repertório, o vocabulário e o rigor da resposta. Use quando o ponto de vista importa: revisor cético, tutor paciente, auditor ISO, redator técnico. Não use como enfeite ("aja como o melhor especialista do mundo" não adiciona informação — adicione critérios em vez de superlativos).

5) Formato de saída. Tabela, lista numerada, template com campos, Markdown, tamanho-alvo, idioma. Formato é onde mais se perde tempo em retrabalho — e onde é mais barato especificar. Se o resultado vai para a wiki, peça Markdown; se vai para o gestor, peça sumário executivo + detalhes; se vai para comparação, peça tabela com colunas nomeadas.

6) Restrições. O que excluir, limites de tamanho, o que não assumir, políticas a respeitar. Restrições bem colocadas evitam as falhas previsíveis: "não invente números; se um dado não estiver no documento, escreva [VERIFICAR]", "não sugira soluções que exijam licença P2", "máximo de 300 palavras".

7) Exemplos (few-shot). Uma ou duas amostras do resultado desejado valem por parágrafos de descrição. Se você quer tickets padronizados num formato específico, mostre UM ticket exemplar no prompt e diga "siga exatamente este padrão". O modelo é excelente em imitar padrões demonstrados — frequentemente melhor do que em seguir padrões descritos.

8) Critérios de qualidade. Diga como você vai julgar o resultado: "a resposta é boa se: um técnico júnior conseguir executar sem perguntar nada; cada passo tiver um resultado esperado; os riscos estiverem sinalizados". Critérios transformam o modelo no seu primeiro revisor.

Dosagem: nem todo prompt precisa dos oito. Tarefa trivial → contexto + objetivo + formato bastam. Tarefa complexa ou recorrente → todos os oito, e vale escrever com calma (você vai reutilizar).

6.2 Iteração: prompting é diálogo, não tiro único

A primeira resposta é o rascunho de calibração. Método de iteração profissional:

1. Aponte especificamente o que manter e o que mudar ("mantenha a estrutura; a seção 2 está genérica — aprofunde com o cenário de dispositivos não gerenciados").
2. Corrija o prompt, não só a resposta: se o desvio veio de ambiguidade sua, edite a mensagem original (Módulo 5) — conserta a fonte, não o sintoma.
3. Extraia o aprendizado: quando acertar, pergunte-se o que no prompt produziu o acerto, e incorpore ao seu template.
4. Limite de iterações na mesma linha: 3–4 tentativas sem convergir = o problema é estrutural; recomece com prompt redesenhado (Módulo 4, recomeço estratégico).

6.3 Decomposição de tarefas (task decomposition)

Tarefas com muitos julgamentos encadeados rendem mais em etapas do que em um mega-prompt:

• Em cadeia na mesma conversa: "Etapa 1: liste os problemas do documento. [você valida/filtra] Etapa 2: para os problemas 1, 3 e 4, proponha correções. [valida] Etapa 3: gere a versão final." Cada checkpoint seu evita que um erro da etapa 1 contamine tudo.
• Em conversas separadas quando as etapas são pesadas (Módulo 4, chunking).
• Regra prática: se você não consegue descrever a tarefa sem usar "e depois... e aí... e então..." três vezes, decomponha.

6.4 Raciocínio passo a passo (chain-of-thought) — do jeito certo

Para problemas de lógica, diagnóstico e análise, pedir que o modelo mostre o raciocínio antes da conclusão melhora a qualidade e — tão importante — permite auditar as premissas:

Antes de dar a recomendação final, mostre seu raciocínio:
1) premissas que está assumindo; 2) hipóteses consideradas;
3) por que descartou as alternativas. Depois, a recomendação em 3 linhas.

Duas notas de precisão: (a) modelos com extended thinking já fazem deliberação interna — nesses casos, o valor de pedir o raciocínio na resposta é a auditabilidade para você, não só a qualidade; (b) não peça para o modelo "revelar seu processo interno/oculto" — peça uma justificativa estruturada da resposta, que é o que tem valor profissional: premissas explícitas que você pode conferir contra a realidade do seu ambiente.

6.5 XML tags: estrutura que o Claude respeita

O Claude foi treinado para lidar muito bem com marcação estilo XML delimitando as partes do prompt. Em prompts longos, tags eliminam a ambiguidade sobre "o que é instrução, o que é dado, o que é exemplo":

<contexto>
Analista de Service Desk, ambiente M365 + Entra ID + Intune, ~800 usuários.
</contexto>

<tarefa>
Reescrever o procedimento abaixo para técnicos júnior de L1.
</tarefa>

<procedimento_original>
[texto colado aqui — pode ser longo e bagunçado, as tags isolam]
</procedimento_original>

<regras>
- Passos numerados, um comando/ação por passo, com resultado esperado.
- Sinalizar com ⚠️ os passos que exigem escalação para L2.
- Não adicionar passos que não estejam no original; lacunas → [VERIFICAR].
</regras>

<formato_saida>
Markdown: título, pré-requisitos, passos, seção "Quando escalar".
</formato_saida>

Benefícios concretos: o texto colado dentro de <procedimento_original> nunca é confundido com instrução (importante inclusive por segurança — instruções embutidas em documentos de terceiros não devem ser obedecidas); as regras ficam agrupadas e conferíveis; e você pode referenciar as partes ("aplique as também ao anexo").

6.6 Prompts com variáveis: seus templates reutilizáveis

Transforme prompts que funcionaram em templates com placeholders:

<contexto>Analista de TI em ambiente {{AMBIENTE}}.</contexto>
<tarefa>Criar um artigo de KB sobre: {{PROBLEMA}}.</tarefa>
<publico>{{PUBLICO: usuários finais | técnicos L1 | técnicos L2}}</publico>
<insumo>{{RESOLUCAO_DO_TICKET}}</insumo>
<formato_saida>Título; Sintomas; Causa; Resolução passo a passo; Prevenção; Tags.</formato_saida>
<regras>Linguagem adequada ao público; passos testáveis; sem dados de usuários reais.</regras>

Guarde esses templates em um arquivo pessoal (ou no Project Knowledge, Módulo 7). Preencher variáveis leva 30 segundos; redigir do zero, 10 minutos — e a qualidade fica padronizada. Esta é a semente da sua biblioteca (seção 6.8).

6.7 Padrões por caso de uso

Prompts para revisão. Peça revisão em passes separados (técnica de revisores profissionais): "Passe 1: apenas correção técnica — fatos, comandos, lógica. Passe 2: apenas clareza e estrutura. Passe 3: apenas adequação ao público." E exija formato de revisão útil: "para cada problema: trecho, o que está errado, sugestão de correção, severidade (alta/média/baixa)". Revisão sem severidade vira lista indistinta.

Prompts para estudo. Os padrões de maior retorno: explicação em camadas ("explique X em 3 níveis: para leiga, para analista de TI, para especialista em identidade"), ensino socrático ("me faça perguntas sobre o tópico, uma por vez, corrigindo minhas respostas e aprofundando onde eu errar"), teste ativo ("gere 5 questões estilo SC-300 sobre Conditional Access, cenário-based, sem mostrar o gabarito até eu responder") e conexão com prática ("para cada conceito, dê um exemplo de como ele aparece no portal do Entra").

Prompts para documentação técnica. Forneça sempre: público, formato do documento-destino, e o padrão da casa (cole um documento existente como exemplo few-shot). Peça marcadores de lacuna ("[VERIFICAR]", "[PENDENTE: screenshot]") em vez de permitir preenchimento inventado — documentação com lacunas marcadas é honesta; com lacunas inventadas é perigosa.

Prompts para troubleshooting. O padrão-ouro é o de hipóteses ordenadas com testes discriminantes:

<sintoma>...</sintoma> <ambiente>...</ambiente> <ja_testado>...</ja_testado>
Tarefa: hipóteses de causa em ordem de probabilidade; para cada uma, o teste
mais rápido que a confirma ou descarta e o que o resultado indicaria.
Termine com: a pergunta mais valiosa a fazer ao usuário agora.

O campo <ja_testado> é o que separa troubleshooting real de lista genérica — nunca o omita.

Prompts para criação de cursos. Estrutura antes de conteúdo, sempre: primeiro o outline com objetivos por módulo (você aprova), depois produção módulo a módulo com resumo-mestre (Módulo 4), depois revisão de consistência. Pedir "crie um curso completo sobre X" em um prompt único produz volume raso.

Prompts para geração de diagramas. O Claude gera diagramas como código (Mermaid — linguagem de diagramas em texto — ou SVG em Artifacts, Módulo 10). Especifique o tipo certo: flowchart para decisões de troubleshooting, sequence diagram para fluxos de autenticação (perfeito para OAuth/SAML), graph para arquitetura. Ex.: "Gere em Mermaid um sequence diagram do fluxo de login com Entra ID + MFA + Conditional Access, atores: usuário, dispositivo, Entra ID, app. Rotule cada seta com o que trafega."

Prompts para análise de incidentes. Estruture como post-mortem: "... Tarefa: 1) reconstitua a cadeia causal; 2) separe causa raiz de fatores contribuintes; 3) proponha ações corretivas (imediatas/estruturais) com responsável sugerido por papel; 4) liste o que a linha do tempo NÃO permite concluir." O item 4, de novo, é a vacina anti-alucinação.

6.8 Biblioteca de prompts reutilizáveis para TI

Como usar: copie, preencha os {{campos}}, ajuste ao seu ambiente. Todos assumem dados já anonimizados.

P1 — Reestruturar ticket confuso

<ticket_bruto>{{TEXTO}}</ticket_bruto>
Reescreva no padrão: Título (≤10 palavras) | Sintoma | Impacto | Ambiente |
Passos já tentados | Informações faltantes. O que não constar no bruto → "não informado".

P2 — Resposta ao usuário final

Contexto: {{SITUACAO}}. Escreva a resposta ao usuário: tom profissional e empático,
sem jargão, ≤120 palavras, com próximos passos claros e prazo. Versões: PT e EN.

P3 — KB article a partir de resolução

<resolucao>{{NOTAS_DA_RESOLUCAO}}</resolucao>
Gere um KB article para {{PUBLICO}}: Título; Aplica-se a; Sintomas; Causa;
Resolução passo a passo (resultado esperado por passo); Prevenção; Tags.
Lacunas → [VERIFICAR]. Não invente caminhos de menu.

P4 — Troubleshooting com hipóteses

<sintoma>{{S}}</sintoma> <ambiente>{{A}}</ambiente> <ja_testado>{{T}}</ja_testado>
Hipóteses em ordem de probabilidade + teste discriminante de cada + o que cada
resultado indica. Formato: tabela. Final: melhor pergunta a fazer ao usuário agora.

P5 — Explicação em 3 camadas (estudo)

Explique {{CONCEITO}} em 3 camadas: (1) analogia para não técnicos, 5 linhas;
(2) explicação para analista de TI, 15 linhas, termos em inglês explicados;
(3) nuances de especialista: 3 pontos que só quem opera isso na prática sabe.

P6 — Simulado de certificação

Gere {{N}} questões estilo {{EXAME}} sobre {{TOPICO}}, baseadas em cenário,
4 alternativas plausíveis, SEM gabarito. Após minhas respostas, corrija uma a uma
explicando por que cada alternativa está certa/errada e o conceito testado.

P7 — Revisão técnica em 3 passes

<documento>{{DOC}}</documento>
Revise em 3 passes separados: (1) correção técnica; (2) clareza/estrutura;
(3) adequação ao público {{PUBLICO}}. Formato por achado: trecho | problema |
correção sugerida | severidade. Não reescreva o documento ainda.

P8 — Comparação estruturada

Compare {{A}} vs {{B}} vs {{C}} para o cenário: {{CENARIO}}.
Tabela com critérios: {{CRITERIOS}}. Depois: recomendação com trade-offs
explícitos e o que precisaria ser verdade para a recomendação mudar.

P9 — Resumo executivo para gestão

<material>{{CONTEUDO_TECNICO}}</material>
Resumo executivo para gestora não técnica: situação em 2 frases; impacto no
negócio; opções com custo/risco relativo; recomendação; decisão necessária e prazo.
≤200 palavras. Zero jargão sem explicação.

P10 — Análise de print de erro

[anexar print higienizado]
1) Transcreva a mensagem exata. 2) Significado em linguagem simples.
3) 3 causas prováveis + teste rápido de cada. 4) O que o print NÃO permite
concluir. 5) Próxima pergunta ao usuário.

P11 — Handover L1→L2

<caso>{{HISTORICO}}</caso>
Gere o handover: resumo do caso (3 linhas); ambiente; cronologia de ações e
resultados; hipóteses descartadas (com evidência); hipótese atual; o que o L2
deve tentar primeiro; anexos/logs relevantes. Objetivo: o L2 não repetir nada.

P12 — Plano de estudo

Monte um plano de estudos para {{OBJETIVO}} em {{PRAZO}}, com {{HORAS}}/semana.
Base: sessões de {{DURACAO}}. Estrutura semanal: tópicos, prática associada,
revisão espaçada dos anteriores, checkpoint de autoavaliação. Formato: tabela
por semana + lista de marcos.

6.9 Diagnóstico de prompts que falharam

7. Conceitos-chave

• Os 8 componentes — clareza, contexto, objetivo, papel, formato, restrições, exemplos, critérios de qualidade.
• Few-shot — ensinar pelo exemplo dentro do prompt.
• Iteração dirigida — apontar o que manter/mudar; corrigir o prompt na fonte.
• Decomposição — tarefas grandes em etapas com checkpoints humanos.
• Raciocínio passo a passo — justificativa estruturada e auditável antes da conclusão.
• XML tags — delimitação inequívoca de instrução, dado e exemplo.
• Template com variáveis — prompts parametrizados reutilizáveis.
• Regra de lacuna — "[VERIFICAR]" em vez de preenchimento inventado.
• Teste discriminante — no troubleshooting, o teste que separa hipóteses.

8. Analogia didática

Um prompt é um ticket de escalação para o L3 mais competente que você conhece. Você já viu os dois extremos: o ticket "não funciona, urgente" (que volta com 5 perguntas e um dia perdido) e o ticket exemplar — sintoma preciso, ambiente, reprodução, o que foi testado, comportamento esperado — que volta resolvido na primeira. O Claude é um L3 incansável e literal: devolve exatamente a qualidade de especificação que recebe, sem preencher lacunas com bom senso organizacional que ele não tem. Escrever bons prompts é a mesma competência de escrever boas escalações — você já a possui; este módulo só a transfere de domínio.

9. Exemplo prático usando Claude

Pegue uma tarefa real e rode o teste A/B de especificação:

Versão A: Escreve um procedimento de reset de senha.

Versão B:

<contexto>Service Desk, ~800 usuários, M365 + Entra ID com SSPR habilitado.</contexto>
<tarefa>Procedimento de reset de senha para técnicos L1.</tarefa>
<regras>Cobrir: usuário lembra a atual; esqueceu (SSPR); SSPR falha (reset assistido).
Verificação de identidade antes de qualquer reset. Passos numerados com resultado
esperado. ⚠️ nos passos sensíveis. Lacunas → [VERIFICAR].</regras>
<formato_saida>Markdown: título, pré-requisitos, 3 cenários, quando escalar.</formato_saida>
<criterio>Bom se um L1 novo executa sem perguntar nada a ninguém.</criterio>

Rode as duas em chats separados e compare lado a lado. Guarde a versão B: acabou de nascer o primeiro item seu da biblioteca.

10. Aplicação no dia a dia de TI

Adote a regra dos 60 segundos: para qualquer tarefa não trivial, gaste um minuto estruturando o prompt (contexto, objetivo, formato, restrições) antes de enviar. Esse minuto economiza 3–4 iterações. E mantenha o arquivo prompts.md pessoal: toda semana, um prompt que funcionou vira template com variáveis. Em dois meses, você terá a sua biblioteca — mais valiosa que qualquer lista pronta, porque calibrada no seu ambiente.

11. Aplicação em Service Desk

Os prompts P1 (reestruturar ticket), P2 (resposta ao usuário), P4 (troubleshooting) e P11 (handover) cobrem o ciclo de vida completo de um chamado. Sugestão de implantação gradual: semana 1, use só o P1 na triagem matinal; semana 2, adicione o P2 nas respostas; semana 3, o P4 nos casos não óbvios. Ganho incremental, hábito sólido — e no fim do mês você terá material real para propor padronização à equipe.

12. Aplicação em Microsoft 365 / Entra ID / IAM / Intune

Combine P5 + P6 + P12 como kit de certificação: o P12 monta o plano, o P5 destrincha cada conceito em camadas, o P6 testa com simulados comentados. Para o trabalho, o P8 (comparação estruturada) é o mais usado do domínio de identidade: "Entra joined vs registered vs hybrid joined para o cenário {{X}}", "métodos de MFA para população {{Y}}" — sempre com a coluna final "o que precisaria ser verdade para a recomendação mudar", que expõe as premissas escondidas.

13. Prompts bons

Os doze da biblioteca (6.8) e a Versão B do exemplo prático. Destaque para o padrão transversal presente em quase todos: regra de lacuna + delimitação do que não dá para concluir — o par que mais eleva confiabilidade por caractere digitado.

14. Prompts ruins

Prompt ruim 1:

Você é o melhor especialista em Microsoft do mundo, com 30 anos de experiência.
Me ajuda com um problema de login.

Persona-superlativo sem conteúdo (não adiciona critério nenhum) e tarefa sem sintoma, ambiente ou histórico. Papel bom carrega ponto de vista e rigor; adjetivo não.

Prompt ruim 2:

Analisa esse doc, resume, acha os erros, reescreve melhorado, cria um quiz,
traduz pro inglês e faz um diagrama. [anexo de 40 páginas]

Sete tarefas encadeadas, sem prioridade, sem formato, sem público, sobre documento longo. Cada tarefa sairá com 15% da qualidade possível. É o anti-padrão da decomposição.

Prompt ruim 3:

Melhora isso aí.

"Melhorar" em qual dimensão? Para qual público? Mantendo o quê? A resposta vai otimizar uma direção aleatória — e a iteração seguinte começará do zero.

15. Por que os prompts bons funcionam melhor

Todos os prompts da biblioteca compartilham quatro propriedades mensuráveis: delimitam o insumo (tags separam dado de instrução), fecham o formato (a saída já nasce no destino final), bloqueiam a invenção (regra de lacuna, "o que não dá para concluir") e embutem o critério de aceite (o modelo se auto-revisa contra ele). Os ruins violam as quatro: insumo indistinto, saída aberta, licença para inventar e nenhum critério. Não é magia de redação — é engenharia de especificação, a mesma que separa um bom ticket de um "não funciona, urgente".

16. Laboratório prático guiado

Objetivo: construir, quebrar e consertar prompts com método. Tempo: 75 minutos.

1. Baseline (10 min): escolha uma tarefa real média (ex.: criar um comunicado de mudança). Escreva o prompt como escreveria antes deste módulo. Rode e guarde a resposta.
2. Reconstrução (15 min): reescreva com os 8 componentes e XML tags. Rode em chat novo. Compare com a baseline usando 4 critérios: correção, completude, formato, prontidão para uso.
3. Few-shot (10 min): adicione ao prompt um exemplo real do "padrão da casa" (um comunicado antigo bom). Rode de novo. Observe o salto de aderência ao estilo.
4. Decomposição (15 min): pegue o prompt ruim 2 (as sete tarefas) e redesenhe como cadeia de 3 etapas com checkpoints. Execute a cadeia.
5. Diagnóstico (10 min): pegue uma resposta decepcionante do seu histórico, identifique na tabela 6.9 a causa provável e conserte o prompt original.
6. Biblioteca (15 min): transforme seus 2 melhores prompts do laboratório em templates com {{variáveis}} e salve no seu prompts.md.

17. Exercícios de fixação

1. Reescreva com os 8 componentes: "faz um email avisando que o sistema vai ficar fora".
2. Para cada situação, diga qual componente faltou: (a) resposta veio em inglês; (b) resposta inventou um caminho de menu; (c) resposta ignorou 2 dos 5 pedidos; (d) resposta tecnicamente certa mas incompreensível para o usuário final.
3. Escreva um prompt de estudo socrático para um tópico que você domina pouco.
4. Converta o P3 (KB article) para o seu ambiente real: preencha as variáveis com um caso desta semana.
5. Explique a diferença entre pedir "justificativa estruturada da resposta" e pedir "seu processo interno de pensamento" — e por que a primeira é a prática correta.

18. Quiz (5 perguntas)

1. O componente que mais reduz retrabalho de reformatação é: a) Persona — b) Formato de saída explícito — c) Saudação educada — d) Tamanho do prompt

2. Few-shot significa: a) Prompt curto — b) Incluir exemplos do resultado desejado no prompt — c) Usar modelo rápido — d) Fazer poucas perguntas

3. A "regra de lacuna" ([VERIFICAR]) combate diretamente: a) Lentidão — b) Preenchimento inventado de informações ausentes — c) Excesso de formato — d) Custo de tokens

4. XML tags em prompts longos servem principalmente para: a) Deixar bonito — b) Delimitar sem ambiguidade instrução, dado e exemplo — c) Acelerar a resposta — d) Ativar recursos ocultos

5. Sua resposta veio genérica e superficial. Pela tabela de diagnóstico, as primeiras correções são: a) Reclamar e regenerar 5 vezes — b) Adicionar contexto/público e, se o tema é complexo, subir o modelo e pedir análise por partes — c) Trocar de idioma — d) Encurtar o prompt

19. Gabarito comentado

1 — b. Formato é barato de especificar e caro de consertar depois. Persona ajuda no ponto de vista, mas não define a embalagem da entrega. 2 — b. "Shots" são os exemplos. Modelos imitam padrões demonstrados com precisão notável — frequentemente maior do que seguindo descrições. 3 — b. É a instrução que troca "plausível" por "honesto": onde não há dado, marca-se a lacuna. Vacina direta contra alucinação em documentação. 4 — b. A ambiguidade entre "o que é ordem" e "o que é matéria-prima" é fonte clássica de desvios — inclusive de segurança, quando documentos de terceiros contêm instruções embutidas que não devem ser obedecidas. 5 — b. Genérico = falta de restrição de espaço (contexto/público). Superficial em tema difícil = possível subdimensionamento (Módulo 3) ou pedido monolítico (decomposição). O diagnóstico aponta a causa antes da força bruta.

20. Checklist do módulo

• Escrevo prompts com os 8 componentes, dosando conforme a tarefa.
• Uso XML tags em prompts longos e para isolar material colado.
• Aplico regra de lacuna e "o que não dá para concluir" em tarefas factuais.
• Decomponho tarefas grandes com checkpoints.
• Peço justificativa estruturada em diagnósticos e decisões.
• Itero com direção específica e corrijo o prompt na fonte.
• Tenho meu `prompts.md` iniciado com templates parametrizados.
• Sei usar a tabela de diagnóstico de prompts falhos.

21. Erros comuns

• Prompt-telegrama para tarefa complexa ("melhora isso aí").
• Mega-prompt de 7 tarefas sem decomposição.
• Persona-superlativo no lugar de critérios.
• Iterar sem direção ("não gostei, tenta de novo") — o modelo otimiza no escuro.
• Não capturar o que funcionou — reescrever do zero o prompt que já tinha dado certo semana passada.
• Esquecer a regra de lacuna em documentação — e publicar caminho de menu inventado.

22. Boas práticas

• Regra dos 60 segundos antes de tarefas não triviais.
• Todo material colado entra entre tags; instruções ficam fora delas.
• Um exemplo real vale mais que três parágrafos de descrição de estilo.
• Critério de aceite no prompt = primeira revisão grátis.
• Biblioteca pessoal viva: um template novo por semana, calibrado no seu ambiente.
• Ao acertar um prompt difícil, pergunte ao próprio Claude: "o que neste prompt mais contribuiu para a qualidade? o que eu poderia remover sem perda?" — meta-aprendizado.

23. Resumo final

Prompt engineering é engenharia de especificação: contexto, objetivo, formato, restrições, exemplos e critérios transformam um executor literal e capaz em resultados prontos para uso. As técnicas estruturais — XML tags, variáveis, decomposição, justificativa auditável, regra de lacuna — são o ferramental; a biblioteca pessoal parametrizada é o ativo que se acumula. A competência não é nova para você: é a mesma que escreve boas escalações e bons tickets, agora apontada para o colega mais literal da equipe. Tudo o que vem a seguir no curso — Projects, análise documental, Artifacts, agentes — multiplica exatamente esta habilidade.

24. Mini desafio

Escolha o pior prompt que você já mandou no Claude (todo histórico tem um). Reescreva-o com tudo deste módulo. Rode os dois em chats separados, cole as duas respostas lado a lado e escreva 5 linhas: quais componentes causaram a diferença? Depois, transforme a versão boa em template e inaugure (ou alimente) seu prompts.md.

25. Como eu aplicaria isso amanhã no trabalho

Amanhã eu aplicaria a regra dos 60 segundos três vezes: na triagem (P1 num ticket confuso), num atendimento (P4 com <ja_testado> preenchido de verdade) e num fechamento (P3 gerando o KB da resolução). No fim do dia, os três prompts preenchidos iriam para o prompts.md com variáveis. Um dia, três templates validados em produção — e a biblioteca deixaria de ser teoria do curso para ser ferramenta minha.

Adaptação para Fable — Módulo 6

Título curto para o card: "A arte do prompt"

Texto de abertura envolvente:

Você já escreveu um ticket de escalação perfeito — daqueles que voltam resolvidos na primeira. Prompt engineering é exatamente essa habilidade, apontada para o colega mais capaz e mais literal que você já teve. Neste módulo — o coração do curso — você aprende os 8 componentes, as técnicas estruturais e sai com uma biblioteca de 12 prompts prontos para o seu dia a dia.

Divisão sugerida em telas: 1. Tela 1 — "O ticket perfeito" (analogia de abertura + teste A/B) 2. Tela 2 — "Os 8 componentes" (cards expansíveis, um por componente) 3. Tela 3 — "XML tags e variáveis" (antes/depois interativo) 4. Tela 4 — "Decomposição e raciocínio auditável" 5. Tela 5 — "Padrões por caso de uso" (revisão, estudo, docs, troubleshooting, cursos, diagramas, incidentes) 6. Tela 6 — "A biblioteca P1–P12" (cards copiáveis) 7. Tela 7 — "Diagnóstico de prompts falhos" (tabela interativa) 8. Tela 8 — Laboratório + quiz

Ideia de interação: "Monte o prompt": o aluno recebe uma tarefa de TI e blocos arrastáveis (contexto, objetivo, formato, restrições, exemplo, critério) para compor o prompt na ordem; depois, um "modo sabotagem" remove um bloco e o aluno prevê qual defeito a resposta terá.

Pergunta reflexiva: "Pense no melhor ticket de escalação que você já escreveu. O que ele tinha que os outros não tinham? Agora: quantos dos seus prompts têm isso?"

Microatividade prática: rodar o teste A/B da seção 9 com uma tarefa real e colar no Fable a diferença mais gritante entre as duas respostas.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Você agora escreve especificações, não perguntas. Com os 8 componentes no reflexo e 12 templates no bolso, é hora de dar um lar permanente a tudo isso: os Claude Projects.

Sugestão visual para o Fable: infográfico "anatomia de um prompt profissional" — um prompt real anotado com callouts coloridos para cada um dos 8 componentes, no estilo de diagrama de anatomia.

MÓDULO 7 — Claude Projects: seu ambiente de trabalho persistente

1. Nome do módulo

Claude Projects: criando ambientes de trabalho com contexto e instruções permanentes

2. Objetivo de aprendizagem

Dominar a criação, organização e manutenção de Projects no Claude.ai, entendendo como Project Instructions e Project Knowledge transformam conversas avulsas em um ambiente de trabalho consistente, reutilizável e alinhado ao seu contexto profissional.

3. O que a pessoa será capaz de fazer ao final do módulo

• Criar Projects bem estruturados para diferentes frentes de trabalho (Service Desk, estudo, documentação, projetos específicos).
• Escrever Project Instructions eficazes que moldam o comportamento do Claude em todas as conversas daquele Project.
• Decidir o que colocar (e o que não colocar) no Project Knowledge.
• Organizar uma arquitetura pessoal de Projects que evita duplicação e confusão.
• Aplicar critérios de segurança e privacidade ao alimentar Projects com material corporativo.

4. Por que esse tema importa no uso real do Claude

Nos Módulos 4 e 5 você viu duas dores reais: o contexto de uma conversa se esgota e se degrada, e repetir o mesmo preâmbulo ("sou analista de Service Desk, ambiente M365, responda em PT-BR...") em toda conversa é desperdício de tempo e de tokens.

Projects resolvem as duas dores de uma vez. Eles são a diferença entre "usar o Claude como um chat" e "usar o Claude como uma plataforma de trabalho". Um Project bem montado faz com que cada conversa nova já comece com 80% do contexto pronto — sem você digitar nada. Para quem trabalha com temas recorrentes (e Service Desk é o reino da recorrência), isso muda o patamar de produtividade e de consistência das respostas.

5. Explicação simples

Um Project é uma pasta inteligente dentro do Claude.ai. Dentro dela você guarda:

• Project Instructions: um texto fixo dizendo ao Claude quem você é, como ele deve responder e quais regras seguir. Vale para todas as conversas dentro do Project.
• Project Knowledge: arquivos e textos de referência (manuais, procedimentos, glossários) que o Claude consulta em todas as conversas do Project.
• Conversas: todos os chats criados dentro do Project ficam agrupados ali.

É como configurar uma estação de trabalho uma única vez: da próxima vez que você senta, está tudo no lugar.

6. Explicação profunda

Vamos entender o que acontece tecnicamente quando você conversa dentro de um Project.

Como as Instructions entram no contexto. As Project Instructions são injetadas no início do contexto de cada conversa do Project, funcionando como uma camada de "system prompt" personalizada (lembra do Módulo 2: instruções que moldam o comportamento antes da sua primeira mensagem). Elas consomem tokens da context window em toda conversa — por isso devem ser densas e enxutas, não um romance.

Como o Knowledge entra no contexto. Aqui há um detalhe técnico importante que se conecta ao Módulo 9. Dependendo do volume de arquivos:

• Knowledge pequeno: o conteúdo pode caber integralmente na context window. O Claude "enxerga" tudo, o tempo todo.
• Knowledge grande: o Claude passa a usar recuperação (retrieval/RAG): em vez de carregar tudo, ele busca os trechos mais relevantes para a sua pergunta. Isso muda a forma como você deve perguntar — e é exatamente o assunto do Módulo 9.

Instructions vs. Knowledge — a divisão de papéis:

Isolamento entre Projects. Cada Project é um universo próprio: as Instructions e o Knowledge de um Project não vazam para outro nem para conversas fora de Projects. Isso é uma vantagem de governança — você pode ter um Project com material do trabalho e outro pessoal, sem contaminação de contexto.

Persistência ≠ memória. Atenção a uma confusão comum: o Project não "lembra" das conversas anteriores dentro dele automaticamente como parte do contexto de uma conversa nova. O que persiste são Instructions e Knowledge. Se uma conversa produziu uma decisão importante, destile-a (resumo de handover do Módulo 4) e adicione ao Knowledge ou às Instructions — esse é o ciclo de curadoria que mantém um Project vivo.

Limites e recursos mudam. Cotas de Knowledge, tamanho máximo e recursos como compartilhamento de Projects em planos Team/Enterprise evoluem com o tempo. Valide sempre em https://support.claude.com.

7. Conceitos-chave

• Project: contêiner que agrupa conversas, instruções fixas e arquivos de referência.
• Project Instructions: instruções permanentes de comportamento aplicadas a todas as conversas do Project.
• Project Knowledge: base de arquivos/textos de referência disponível em todas as conversas do Project.
• System prompt: camada de instruções que precede a conversa e molda o comportamento do modelo.
• Curadoria: ciclo de manutenção (adicionar, atualizar, remover) que mantém Instructions e Knowledge úteis e atuais.
• Isolamento de contexto: cada Project é independente; nada vaza entre Projects.

8. Analogia didática

Pense na diferença entre atender um chamado num computador emprestado e atender na sua própria estação.

No computador emprestado (conversa avulsa), você perde 10 minutos configurando tudo: abrir os consoles, logar, achar os procedimentos, lembrar as senhas de rede. Toda vez.

Na sua estação (Project), tudo já está pronto: atalhos na barra, consoles salvos, a pasta de procedimentos mapeada, o bloco de notas com seus templates. Você senta e produz.

E tem mais: você não tem uma estação, tem bancadas especializadas — uma para atendimento, outra para estudo, outra para documentação. Cada uma com as ferramentas certas para aquela função. Essa é a arquitetura de Projects.

9. Exemplo prático usando Claude

Vamos montar o Project "Service Desk M365" do zero — este exemplo será a espinha dorsal do laboratório.

Passo 1 — Criar o Project com nome claro: Service Desk M365.

Passo 2 — Escrever as Project Instructions. Um modelo real e testado:

CONTEXTO PERMANENTE
Sou analista de Service Desk N1/N2 em ambiente Microsoft 365:
Entra ID (identidades, MFA, Conditional Access), Exchange Online,
Teams, SharePoint/OneDrive, Intune (Windows e mobile).
Ferramenta de tickets: [nome da ferramenta].

COMO RESPONDER
1. Sempre em português do Brasil; termos técnicos em inglês
   quando forem os termos de mercado (ex.: Conditional Access).
2. Para troubleshooting: hipóteses ordenadas por probabilidade,
   com um teste discriminante para cada uma.
3. Para procedimentos: passos numerados, com o caminho de portal
   completo (ex.: Entra admin center > Users > ...).
4. Sinalize com [VERIFICAR] qualquer informação que possa variar
   por tenant, licença ou versão.
5. Quando usar arquivos do Knowledge deste Project, diga QUAL
   arquivo embasou a resposta.
6. Nunca presuma que tenho licença E5; pergunte ou ofereça
   alternativas por nível de licença.

O QUE NÃO FAZER
- Não invente nomes de menus ou de políticas.
- Não recomende mudanças de produção sem alertar sobre
  necessidade de change management.

Passo 3 — Popular o Knowledge (tudo higienizado, sem dados de clientes): - glossario-interno.md — siglas e nomes de sistemas da empresa. - procedimento-reset-mfa.md, procedimento-onboarding.md — POPs oficiais. - matriz-escalacao.md — o que é N1, N2, N3 e quando escalar. - template-kb.md — o modelo de artigo KB da empresa (do Módulo 6).

Passo 4 — Testar. Nova conversa no Project: "Usuária relata que o Authenticator parou de pedir aprovação após trocar de celular. O que fazer?" — e observe: a resposta já vem em PT-BR, com hipóteses ordenadas, caminho de portal, [VERIFICAR] onde cabe e citando o procedimento-reset-mfa.md. Zero preâmbulo digitado.

10. Aplicação no dia a dia de TI

Uma arquitetura pessoal de Projects que cobre a vida real de quem é de infraestrutura/suporte:

1. Service Desk M365 — atendimento e troubleshooting (o do exemplo).
2. Documentação técnica — Instructions com o padrão de escrita da empresa + templates; Knowledge com exemplos de documentos aprovados.
3. Estudos — [Certificação] (ex.: SC-300, MD-102) — Instructions no modo professor socrático (Módulo 6); Knowledge com seus resumos e o outline oficial do exame.
4. Projetos pontuais — ex.: "Migração Intune", vivo só durante o projeto, arquivado depois.

Regra prática de arquitetura: um Project por "chapéu" que você veste, não um por assunto microscópico. Cinco Projects bem curados valem mais que vinte abandonados.

11. Aplicação em Service Desk

O Project "Service Desk M365" vira o copiloto do turno:

• Consistência de time: em planos Team/Enterprise, Projects podem ser compartilhados — todo o time responde com o mesmo padrão, os mesmos POPs, o mesmo template de KB [VERIFICAR disponibilidade no seu plano em https://support.claude.com].
• Onboarding de novatos: o novato entra no Project e herda instantaneamente o contexto que os veteranos levaram anos para construir.
• Ciclo virtuoso com a KB: resolveu um caso inédito? Gere o KB article (prompt P3), valide, e adicione ao Knowledge. O Project fica mais inteligente a cada semana.
• Handover entre turnos: o resumo de handover (Módulo 4) colado numa conversa nova do Project ganha, de graça, todo o contexto permanente das Instructions.

12. Aplicação em Microsoft 365, Entra ID, IAM, Intune e segurança

• Project "Governança de identidades": Knowledge com a política de acesso da empresa (versão pública/higienizada), matriz de perfis e nomenclatura de grupos. Uso: "esse pedido de acesso está aderente à política?" — o Claude compara com o documento real, não com uma ideia genérica de política.
• Project "Intune & Endpoint": Knowledge com baseline de configuração, perfis de compliance documentados e convenções de nomenclatura. Uso: revisar propostas de política, redigir documentação de perfis, preparar comunicados de mudança.
• Cuidado de segurança essencial: Project Knowledge é um repositório persistente. Antes de subir qualquer arquivo, aplique o ritual de higienização do Módulo 5 e pergunte-se: "este documento pode viver aqui por meses?" Nunca suba: exports reais de usuários, segredos/chaves, relatórios de vulnerabilidade com IPs reais, dados pessoais de clientes. Prefira versões sanitizadas: estrutura e regras, sem dados vivos. E siga a política de IA da sua empresa — se o plano for corporativo (Claude for Work), alinhe com o time de segurança o que é permitido no Knowledge.

13. Prompts bons

Para desenhar as Instructions com ajuda do próprio Claude:

Vou criar um Project no Claude.ai para [finalidade].
Me entreviste com até 6 perguntas sobre meu contexto, padrões
de resposta desejados e restrições. Depois, redija Project
Instructions enxutas (máx. 300 palavras) em blocos: CONTEXTO
PERMANENTE, COMO RESPONDER, O QUE NÃO FAZER.

Para auditar um Project existente:

Estas são as Instructions do meu Project: [colar].
Este é o índice do Knowledge: [listar arquivos].
Avalie: 1) redundâncias entre Instructions e Knowledge;
2) instruções vagas que eu deveria tornar verificáveis;
3) o que está faltando para o objetivo "[objetivo]";
4) o que eu deveria REMOVER.

Para usar o Knowledge com rastreabilidade:

Com base APENAS nos arquivos deste Project, descreva o
procedimento de [tarefa]. Cite o arquivo-fonte de cada passo.
Se algum passo não estiver coberto pelos arquivos, marque
como [SEM FONTE NO PROJECT] em vez de completar por conta.

14. Prompts ruins

Crie um project pra mim

(O Claude não cria o Project por você — isso é ação sua na interface; e sem finalidade definida não há o que desenhar.)

[Instructions com 2.000 palavras colando 5 procedimentos inteiros]

(Procedimento é Knowledge, não Instruction. Instructions gigantes queimam contexto em toda conversa e diluem as regras importantes.)

Você lembra do que resolvemos na conversa de ontem aqui no Project?

(Conversas não são memória compartilhada. O que persiste é Instructions + Knowledge.)

15. Por que os prompts bons funcionam melhor

Os bons prompts respeitam a divisão de papéis do Project: comportamento nas Instructions, fatos no Knowledge, decisões destiladas pela curadoria. O prompt de entrevista extrai o contexto que você esqueceria de escrever; o de auditoria combate a entropia natural (Projects incham com o tempo); o de rastreabilidade ("cite o arquivo-fonte", "[SEM FONTE NO PROJECT]") converte o Knowledge de "inspiração" em "fonte auditável" — a mesma lógica anti-alucinação dos Módulos 2 e 6, agora aplicada à sua própria base.

Os ruins falham por inverter papéis (procedimento em Instruction), por presumir capacidades que não existem (memória entre conversas) ou por delegar ao Claude uma ação que é da interface.

16. Laboratório prático guiado

Objetivo: sair com o Project "Service Desk M365" (ou equivalente da sua realidade) funcionando.

1. Crie o Project com nome no padrão [Área] — [Finalidade].
2. Gere as Instructions usando o prompt de entrevista da seção 13, numa conversa fora do Project. Revise linha a linha: cada instrução é verificável? Está abaixo de ~300 palavras?
3. Cole as Instructions no Project.
4. Prepare 3 arquivos de Knowledge higienizados: um glossário, um procedimento real, um template. (Sem material da empresa à mão? Crie versões fictícias realistas com o próprio Claude.)
5. Teste A/B: faça a mesma pergunta de troubleshooting numa conversa fora do Project e numa dentro. Compare: formato, aderência às suas regras, citação de fontes.
6. Teste de rastreabilidade: use o 3º prompt da seção 13 e confira se o Claude cita os arquivos certos e marca lacunas.
7. Sabotagem didática: pergunte algo que NÃO está no Knowledge e veja se ele respeita o [SEM FONTE NO PROJECT]. Se não respeitar, endureça a instrução correspondente.

17. Exercícios de fixação

1. Escreva, em uma frase cada, a diferença de papel entre Project Instructions e Project Knowledge.
2. Liste 3 itens da sua rotina que pertencem às Instructions e 3 que pertencem ao Knowledge.
3. Desenhe sua arquitetura pessoal: quais 3–5 Projects você criaria? Nome e finalidade de cada um.
4. Pegue um documento real do seu trabalho e liste o que precisaria higienizar antes de subi-lo ao Knowledge.
5. Escreva uma instrução vaga ("seja técnico") e reescreva-a de forma verificável.

18. Quiz

1. As Project Instructions se aplicam: a) — Só à primeira conversa do Project b) — A todas as conversas dentro do Project c) — A todas as conversas da sua conta d) — Só quando você as menciona no prompt

2. Qual item pertence ao Knowledge, e não às Instructions? a) — "Responda sempre em PT-BR" b) — "Use passos numerados" c) — O procedimento completo de reset de MFA d) — "Sinalize incertezas com [VERIFICAR]"

3. O que persiste automaticamente entre conversas de um Project? a) — Todo o histórico de todas as conversas b) — Instructions e Knowledge c) — Apenas a última conversa d) — Nada

4. Por que Instructions muito longas são um problema? a) — O Claude ignora Instructions longas b) — Elas consomem contexto em toda conversa e diluem as regras importantes c) — O limite é de 100 palavras d) — Elas apagam o Knowledge

5. Qual arquivo NÃO deveria ir para o Knowledge de um Project corporativo? a) — Glossário de siglas internas b) — Template de KB article c) — Export real de usuários do Entra ID com e-mails e telefones d) — Procedimento de onboarding higienizado

19. Gabarito comentado

1 — b. Instructions são a camada permanente de comportamento de todas as conversas daquele Project (e só dele — isolamento entre Projects).

2 — c. Procedimento é material de referência: Knowledge. As demais são regras de comportamento: Instructions. Essa divisão de papéis é o coração do módulo.

3 — b. Conversas não viram memória automática. O ciclo de curadoria (destilar decisões e promovê-las a Knowledge/Instructions) é manual — e é o que mantém o Project vivo.

4 — b. Instructions entram no contexto de toda conversa (Módulo 4: tokens são finitos) e regras demais competem entre si. Denso e enxuto vence.

5 — c. Dados pessoais reais em repositório persistente = risco de privacidade e violação provável da política da empresa. Estrutura e regras sim; dados vivos não.

20. Checklist do módulo

• Criei ao menos 1 Project com nome claro e finalidade definida
• Escrevi Instructions enxutas nos blocos CONTEXTO / COMO RESPONDER / O QUE NÃO FAZER
• Sei explicar a divisão Instructions × Knowledge
• Subi arquivos de Knowledge higienizados
• Testei rastreabilidade ("cite o arquivo-fonte")
• Fiz o teste A/B dentro × fora do Project
• Defini minha arquitetura pessoal de 3–5 Projects
• Sei o que nunca subir ao Knowledge

21. Erros comuns

1. Project-lixeira: um único Project para tudo. O Knowledge vira sopa e as Instructions se contradizem.
2. Procedimentos nas Instructions: incha o contexto de toda conversa com material que deveria ser consultado sob demanda.
3. Knowledge desatualizado: procedimento mudou, arquivo ficou. O Claude responde com confiança baseado em material velho — pior que não ter Knowledge.
4. Esperar memória entre conversas: "como falamos ontem..." — não. Destile e promova ao Knowledge.
5. Subir dado sensível "só dessa vez": repositório persistente não tem "só dessa vez".
6. Nunca auditar: Projects sofrem entropia. Sem revisão trimestral, viram museu.

22. Boas práticas

1. Nomeie com padrão: [Área] — [Finalidade] (e prefixos de conversa do Módulo 5 dentro).
2. Instructions ≤ ~300 palavras, em blocos, cada regra verificável.
3. Data no nome dos arquivos de Knowledge (procedimento-mfa-2026-06.md): você e o Claude enxergam a vigência.
4. Ritual de curadoria mensal: 15 minutos — remover o obsoleto, promover decisões novas, testar 2 perguntas de regressão.
5. Rastreabilidade por padrão: a instrução "cite qual arquivo embasou a resposta" custa uma linha e paga-se todos os dias.
6. Um Project-piloto primeiro: domine um antes de criar cinco.

23. Resumo final

Projects transformam o Claude de chat em plataforma: Instructions definem como responder (camada permanente de comportamento), Knowledge define com base em quê (referência consultável), e a curadoria — destilar decisões das conversas e promovê-las — é o que mantém tudo vivo. A arquitetura ideal é um Project por "chapéu" profissional, com nomes claros, Instructions enxutas e verificáveis, Knowledge higienizado e datado. Segurança não é opcional: o Knowledge é persistente, então só entra material que pode viver ali por meses. No próximo módulo, mergulhamos fundo no lado documental: formatos, extração, comparação e transformação de arquivos.

24. Mini desafio

Monte o Project espelho do seu maior ladrão de tempo. Identifique a categoria de tarefa que mais consome sua semana, crie um Project dedicado a ela (Instructions + 3 arquivos de Knowledge) e use-o de verdade por 3 dias. No fim, escreva 3 linhas: o que o Project acertou sozinho, o que precisou de ajuste, e qual arquivo faltou no Knowledge.

25. Como aplicar isso amanhã no trabalho

Como eu aplicaria isso amanhã: chegaria 20 minutos antes do turno e criaria o Project "Service Desk M365" com as Instructions do exemplo da seção 9, adaptando duas linhas à minha realidade. Subiria só um arquivo — o procedimento que eu mais consulto, higienizado. Durante o dia, atenderia normalmente, mas rodaria os casos de M365 dentro do Project. No fim do turno, avaliaria: quantas vezes deixei de digitar preâmbulo? A resposta citou meu procedimento? Se sim, na sexta eu subiria mais dois arquivos e mostraria o teste A/B para o coordenador — com a proposta de padronizar para o time.

🎨 Adaptação para o Fable — Módulo 7

Título curto para o card: "Sua base de operações"

Texto de abertura envolvente:

Quantas vezes você já digitou "sou analista de Service Desk, ambiente M365, responda em português..."? A partir de hoje: zero. Neste módulo você constrói Projects — ambientes onde o Claude já sabe quem você é, segue suas regras e consulta seus documentos. Configure uma vez, colha em toda conversa.

Divisão sugerida em telas: 1. Tela 1 — "O computador emprestado" (analogia da estação de trabalho) 2. Tela 2 — "Anatomia de um Project" (Instructions + Knowledge + conversas) 3. Tela 3 — "Instructions: as regras da casa" (modelo em 3 blocos) 4. Tela 4 — "Knowledge: a estante de referência" (o que entra, o que nunca entra) 5. Tela 5 — "Montando o Service Desk M365" (passo a passo do exemplo) 6. Tela 6 — "Curadoria: mantendo o Project vivo" 7. Tela 7 — Laboratório + quiz

Ideia de interação: "Instructions ou Knowledge?" — o aluno recebe 8 cards (ex.: "responda em PT-BR", "procedimento de reset de MFA", "glossário de siglas", "use passos numerados") e arrasta cada um para a caixa correta. Feedback imediato explica cada classificação.

Pergunta reflexiva: "Qual preâmbulo você mais repete nas suas conversas com o Claude? O que isso revela sobre qual deveria ser o seu primeiro Project?"

Microatividade prática: criar um Project real, colar Instructions geradas pelo prompt de entrevista e registrar no Fable a primeira resposta que veio "no formato certo sem pedir".

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Sua base de operações está de pé. Mas um Project é tão bom quanto os documentos que o alimentam — e trabalhar com documentos é uma arte própria. No próximo módulo: formatos, extração, comparação e os segredos da análise documental.

Sugestão visual para o Fable: diagrama de "planta baixa" — o Project desenhado como uma sala: quadro de regras na parede (Instructions), estante de pastas (Knowledge), mesas de conversa no centro; ao lado, um corredor mostrando outras salas isoladas (outros Projects), reforçando o isolamento de contexto.

MÓDULO 8 — Project Knowledge, arquivos e análise documental

1. Nome do módulo

Análise documental profissional: dominando PDFs, planilhas, prints e tudo que você joga no Claude

2. Objetivo de aprendizagem

Aprender a preparar, enviar e explorar documentos no Claude com técnica: escolher o formato certo, higienizar antes de subir, formular pedidos de extração, comparação e transformação que produzem resultados auditáveis — e reconhecer os limites da leitura de máquina.

3. O que a pessoa será capaz de fazer ao final do módulo

• Escolher o melhor formato de arquivo para cada tipo de análise (e converter quando necessário).
• Preparar documentos antes do upload: nomear, limpar, higienizar, fragmentar.
• Pedir os 6 movimentos documentais: extração, resumo, comparação, transformação, auditoria e síntese multi-documento.
• Transformar material bruto (relatório, print, HTML, política) em entregáveis de TI (plano de ação, guia de troubleshooting, curso, parecer).
• Identificar quando o Claude leu mal um documento e corrigir o processo.

4. Por que esse tema importa no uso real do Claude

Grande parte do valor do Claude para quem é de TI não está em "conversar" — está em digerir documentos: o PDF de 80 páginas da política de segurança, o CSV com 3 mil linhas de tickets, o print de erro que o usuário mandou, a documentação da Microsoft que você precisa transformar em manual interno.

Só que existe um abismo entre "anexar um arquivo e pedir um resumo" e fazer análise documental profissional. O primeiro produz textos genéricos que você não pode confiar; o segundo produz extrações auditáveis, comparações célula a célula e transformações que economizam tardes inteiras. A diferença está em como você prepara o arquivo e como formula o pedido — e é exatamente isso que este módulo ensina.

5. Explicação simples

O Claude lê arquivos que você anexa na conversa ou coloca no Knowledge de um Project. Ele entende texto (PDF, DOCX, TXT, MD, HTML, JSON), dados tabulares (CSV, XLSX) e imagens (PNG, JPG — incluindo prints de tela).

Três regras simples resolvem 80% dos problemas:

1. Prepare antes de subir: nome claro, sem dados sensíveis, sem páginas inúteis.
2. Peça uma coisa de cada vez: primeiro extrair, depois analisar, depois transformar.
3. Exija rastreabilidade: "indique a página/seção de onde tirou cada informação".

6. Explicação profunda

Como o Claude "lê" cada formato — e o que isso muda na prática:

Tokens: todo documento é contexto. Lembra do Módulo 4: um arquivo anexado consome tokens como qualquer texto. Um PDF de 100 páginas pode ocupar 65–75 mil tokens — boa parte da mesa. Consequências práticas:

• Anexe o necessário, não o disponível. Precisa das seções 3 e 4? Extraia-as (ou peça análise focada nelas).
• Documento grande + tarefa complexa = dividir: uma conversa para extrair/destilar, outra para trabalhar sobre o destilado (padrão de decomposição do Módulo 6).
• No Knowledge de Project, o mecanismo de recuperação ajuda com volume (Módulo 9), mas em conversa avulsa é tudo contexto vivo.

Os 6 movimentos documentais. Toda análise documental profissional é combinação de seis operações — nomeá-las ajuda a pedir melhor:

1. Extração — puxar dados específicos: "liste todos os prazos e responsáveis mencionados, com a página de cada um".
2. Resumo — condensar com propósito: resumo executivo ≠ resumo técnico ≠ resumo para estudo. Diga o público e o uso.
3. Comparação — confrontar 2+ documentos: "tabela com as diferenças entre a política v2 e v3, seção a seção".
4. Transformação — mudar de formato/gênero: relatório → plano de ação; HTML → curso; procedimento → checklist.
5. Auditoria — verificar contra critérios: "confira este procedimento contra o checklist X e aponte não conformidades".
6. Síntese multi-documento — consolidar vários em um: "a partir destes 4 POPs, escreva o fluxo unificado, sinalizando conflitos entre eles".

Rastreabilidade: a regra de ouro. A instrução que separa amador de profissional: "para cada afirmação, indique página/seção de origem; o que não estiver no documento, marque [NÃO CONSTA]". Isso ativa o grounding (Módulo 2), permite auditoria por amostragem (você confere 3 citações e calibra a confiança no resto) e impede que o Claude complete lacunas com plausibilidade.

Quando a leitura falha. Sinais: números que não batem, citação de seção inexistente, tabela "reconstruída" diferente do original. Causas típicas: PDF escaneado ruim, tabela complexa, documento maior que o digerível. Contramedidas: pedir transcrição literal de um trecho e conferir; converter para MD/TXT; fragmentar; melhorar a qualidade do print.

7. Conceitos-chave

• Higienização: remover dados sensíveis antes do upload (ritual do Módulo 5).
• Rastreabilidade: exigir origem (página/seção) para cada afirmação extraída.
• [NÃO CONSTA]: marcador que impede o preenchimento de lacunas por invenção.
• Movimentos documentais: extração, resumo, comparação, transformação, auditoria, síntese.
• Transcrição de verificação: pedir um trecho literal para testar se a leitura do arquivo está fiel.
• Fragmentação: dividir documentos grandes em partes digeríveis alinhadas à tarefa.

8. Analogia didática

Pense no Claude como um perito documental que você contratou. Se você despeja uma caixa de papéis amassados na mesa dele e diz "me fala o que tem aí", ele vai folhear e devolver impressões gerais — algumas certeiras, outras imprecisas.

Mas se você entrega pastas etiquetadas ("política-acesso-v3.pdf", "tickets-junho.csv"), diz o que procura ("quero as divergências entre v2 e v3 na seção de MFA"), e exige método ("cite a página de cada achado; o que não achar, diga que não achou") — aí o perito produz um laudo que você pode levar para a reunião.

O perito é o mesmo. O que mudou foi o protocolo de entrega.

9. Exemplo prático usando Claude

Cenário real: a empresa atualizou a "Política de Acesso Remoto" da v2 para a v3, e você precisa saber o que muda para o Service Desk.

Passo 1 — Preparação: renomeie os arquivos para politica-acesso-remoto-v2-2024.pdf e politica-acesso-remoto-v3-2026.pdf. Confira que não há dados pessoais (são políticas, normalmente ok).

Passo 2 — Comparação com rastreabilidade:

Anexei duas versões da Política de Acesso Remoto (v2-2024 e
v3-2026). Compare-as e produza:

1. Tabela de mudanças: | Seção | v2 dizia | v3 diz | Impacto
   para o Service Desk | — cite página de cada versão.
2. Lista do que foi REMOVIDO na v3 (com página da v2).
3. Lista do que é NOVO na v3 (com página).
4. Marque [NÃO CONSTA] se alguma seção citada em uma versão
   não tiver equivalente claro na outra.

Não interprete além do texto: se algo estiver ambíguo,
aponte a ambiguidade em vez de resolvê-la.

Passo 3 — Auditoria por amostragem: escolha 3 linhas da tabela e confira nas páginas citadas. Bateu? Confiança calibrada.

Passo 4 — Transformação:

Com base na tabela validada acima, escreva um comunicado de
1 página para o time de Service Desk: o que muda no atendimento
a partir de [data], em linguagem direta, com os 3 impactos
mais frequentes primeiro. Formato: nosso template de comunicado
[colar template].

Resultado: em uma tarde, o que levaria dois dias — e com trilha de auditoria.

10. Aplicação no dia a dia de TI

Os 6 movimentos aplicados à rotina:

• Extração: do PDF de 60 páginas do fornecedor → "todos os requisitos técnicos de infraestrutura, com página".
• Resumo: da ata de reunião de 5 páginas → "as 5 decisões e os 4 action items com responsáveis".
• Comparação: proposta comercial A vs. B → tabela por critério (preço, SLA, suporte, requisitos).
• Transformação: relatório de auditoria → plano de ação com prioridade, esforço estimado e responsável sugerido; página HTML da documentação Microsoft (salva e limpa) → guia interno em PT-BR.
• Auditoria: seu procedimento de onboarding → conferido contra o checklist de segurança da empresa.
• Síntese: 4 POPs sobrepostos escritos por pessoas diferentes → um fluxo unificado com os conflitos sinalizados para decisão humana.

11. Aplicação em Service Desk

• Print → troubleshooting: usuário manda print de erro. Higienize (Módulo 5), anexe e use o P10 (Módulo 6): transcrição literal do erro + hipóteses ordenadas + testes discriminantes. A transcrição literal primeiro é crucial — é sua verificação de que o Claude leu o print corretamente.
• CSV de tickets → inteligência: export mensal higienizado (sem nomes/e-mails) → "agrupe por causa-raiz aparente, ranqueie por volume, sugira os 3 KB articles que mais reduziriam chamados". Transforma dado morto em prevenção.
• Relatório de incidente → KB: o post-mortem do incidente da semana passada → artigo KB no template da empresa (P3), com sintomas, causa e workaround.
• E-mail confuso do usuário → ticket estruturado: colar o texto (higienizado) → reestruturar no formato do P1.

12. Aplicação em Microsoft 365, Entra ID, IAM, Intune e segurança

• Documentação Microsoft → material interno: salve a página do Microsoft Learn sobre, digamos, métodos de autenticação; limpe o HTML; peça a transformação em guia interno com os padrões da sua empresa. Sempre com o carimbo: "validar contra a página original, que é a fonte viva" — documentação Microsoft muda com frequência.
• Export de Conditional Access (JSON) → revisão: um export de políticas de CA de laboratório ou higienizado (sem GUIDs/nomes reais se a política interna exigir) → "explique cada política em linguagem humana: quem afeta, o que exige, quais exceções; sinalize sobreposições e lacunas de cobertura". Excelente para preparar revisões — a decisão final é sua, no portal.
• CSV de dispositivos Intune → diagnóstico: inventário higienizado → "agrupe não conformidades por política, identifique padrões (modelo, versão de OS), proponha ordem de ataque".
• Cuidado redobrado: exports de ambientes de identidade são densos em dados pessoais e em detalhes de segurança. Higienize sempre; prefira amostras; siga a política da empresa; e lembre que estrutura e lógica analisam-se tão bem com dados fictícios quanto com reais.

13. Prompts bons

Extração auditável:

Do PDF anexado (contrato-suporte-fornecedorX.pdf), extraia:
todos os SLAs (serviço, métrica, prazo, penalidade), em tabela,
com a página de cada linha. O que não estiver explícito no
contrato, marque [NÃO CONSTA] — não deduza.

Verificação de leitura (antes de confiar):

Antes de qualquer análise: transcreva literalmente o título e
o primeiro parágrafo da seção 4 do PDF anexado. Vou conferir
com o original antes de seguirmos.

Transformação com propósito e público:

Anexei o relatório de auditoria de acessos (12 páginas).
Transforme em plano de ação para minha coordenadora aprovar:
| # | Achado (página) | Risco | Ação proposta | Esforço (P/M/G) |
Prazo sugerido |. Máximo 15 linhas — consolide achados
duplicados e diga quais consolidou.

Síntese multi-documento com gestão de conflitos:

Anexei 4 procedimentos de onboarding escritos por pessoas
diferentes. Produza o fluxo unificado em passos numerados.
Quando os documentos conflitarem entre si, NÃO escolha por
mim: liste o conflito em uma seção "DECISÕES PENDENTES"
citando o que cada documento diz e a página.

14. Prompts ruins

resume esse pdf

(Resumo para quê? Para quem? Que tamanho? Você recebe o resumo genérico que serve para nada específico.)

[anexa 6 PDFs de 50 páginas] analisa tudo e me diz o que é importante

("Importante" sem critério = opinião do modelo; 300 páginas de uma vez = contexto saturado e leitura rasa. Divida e defina critérios.)

o que essa planilha diz sobre nossos problemas?

(Sem dizer quais colunas importam, o que é "problema" e que período analisar, a resposta será impressionista.)

[anexa print sem higienizar, com e-mail e nome do usuário visíveis] o que é esse erro?

(Violação de privacidade — e falta o pedido de transcrição literal que valida a leitura.)

15. Por que os prompts bons funcionam melhor

Todos os bons prompts compartilham três engrenagens: propósito declarado (resumo "para minha coordenadora aprovar" produz outra escrita que resumo "para estudar"), rastreabilidade obrigatória (página + [NÃO CONSTA] = grounding auditável, Módulo 2) e gestão explícita de ambiguidade ("não escolha por mim", "aponte a ambiguidade") — que mantém as decisões onde devem estar: com você. O prompt de transcrição literal acrescenta a quarta engrenagem: verificação da leitura antes da análise, o equivalente documental de "testar o cabo antes de trocar a placa".

Os ruins delegam critérios ("o que é importante?"), ignoram limites físicos (300 páginas de uma vez) ou pulam a segurança — e o resultado é retrabalho ou risco.

16. Laboratório prático guiado

Objetivo: executar os 6 movimentos com material real (ou fictício realista).

1. Escolha um documento real do trabalho (política, procedimento, relatório) — higienize.
2. Verificação de leitura: peça a transcrição literal de um trecho e confira. Só siga se bater.
3. Extração: peça 5 dados específicos com página. Audite 2 por amostragem.
4. Resumo com propósito: peça DOIS resumos do mesmo documento — um executivo (para gestora) e um técnico (para colega N2). Compare como o propósito mudou o texto.
5. Transformação: transforme o documento em outro gênero (checklist, plano de ação ou guia de bolso).
6. Comparação (se tiver 2 versões de algo) ou síntese (se tiver 2+ documentos do mesmo tema): rode com a regra "conflitos vão para DECISÕES PENDENTES".
7. Sabotagem didática: pergunte sobre algo que NÃO está no documento e verifique se veio [NÃO CONSTA] ou invenção. Ajuste as instruções se necessário.

17. Exercícios de fixação

1. Nomeie os 6 movimentos documentais e dê um exemplo da sua rotina para cada um.
2. Você recebeu um PDF escaneado de qualidade mediana. Quais 2 precauções tomar antes de confiar na análise?
3. Reescreva "resume esse pdf" como um prompt profissional (propósito, público, formato, rastreabilidade).
4. Liste 4 itens a higienizar num export CSV de tickets antes do upload.
5. Por que "pedir dois resumos com públicos diferentes" é um bom teste da sua compreensão sobre prompts documentais?

18. Quiz

1. Qual formato é o mais "confiável" para o Claude ler com fidelidade? a) — PDF escaneado b) — TXT/Markdown c) — XLSX com muitas abas d) — Print de tela

2. O marcador [NÃO CONSTA] serve para: a) — Indicar páginas em branco b) — Impedir que lacunas do documento sejam preenchidas por invenção c) — Marcar arquivos corrompidos d) — Sinalizar texto em outro idioma

3. Antes de confiar na análise de um PDF escaneado, você deve: a) — Converter para XLSX b) — Pedir transcrição literal de um trecho e conferir com o original c) — Anexar o arquivo duas vezes d) — Usar um modelo mais rápido

4. "Compare as políticas e, quando conflitarem, liste em DECISÕES PENDENTES" é um bom padrão porque: a) — Reduz o tamanho da resposta b) — Mantém decisões ambíguas com o humano, em vez de o modelo escolher sozinho c) — Evita usar tokens d) — Dispensa a leitura dos documentos

5. Um PDF de 100 páginas anexado numa conversa avulsa: a) — Não consome contexto b) — Consome uma fração relevante da context window e pode exigir fragmentação c) — É lido apenas na primeira mensagem d) — Vira automaticamente Knowledge de Project

19. Gabarito comentado

1 — b. Texto puro (TXT/MD) chega ao modelo sem camadas de conversão — sem OCR, sem extração de layout. Quando puder escolher o formato, escolha o mais simples.

2 — b. É a aplicação documental do grounding (Módulo 2): o modelo tende a completar lacunas com plausibilidade; o marcador dá a ele uma saída legítima para dizer "não está aqui".

3 — b. A transcrição de verificação testa a fidelidade da leitura antes de você construir análise em cima. Se a transcrição falha, nada do que vem depois é confiável.

4 — b. Delegar a resolução de conflitos ao modelo é delegar decisão sem accountability. O padrão DECISÕES PENDENTES usa o Claude para encontrar os conflitos e reserva a escolha para quem responde por ela.

5 — b. Todo documento anexado é contexto (Módulo 4). 100 páginas ≈ dezenas de milhares de tokens: cabe, mas aperta — e tarefas complexas sobre documentos grandes pedem decomposição.

20. Checklist do módulo

• Sei qual formato escolher (e por que TXT/MD é o mais fiel)
• Higienizo e renomeio arquivos antes de subir
• Uso transcrição de verificação em PDFs escaneados e prints
• Peço rastreabilidade (página/seção) por padrão
• Uso [NÃO CONSTA] contra preenchimento de lacunas
• Sei nomear e pedir os 6 movimentos documentais
• Declaro propósito e público em todo resumo/transformação
• Mando conflitos para DECISÕES PENDENTES em vez de deixar o modelo escolher

21. Erros comuns

1. Anexar tudo "por via das dúvidas": 6 PDFs quando a tarefa usa 1 → contexto saturado, leitura rasa.
2. Confiar em tabela reconstruída sem conferir: tabelas complexas de PDF são o ponto fraco clássico — audite por amostragem.
3. Resumo sem propósito: "resume aí" → texto genérico que você relê inteiro depois. Propósito + público sempre.
4. Print cru: dados do usuário visíveis = incidente de privacidade autoinfligido.
5. Pular a verificação de leitura em escaneados: análise brilhante sobre texto lido errado = lixo confiante.
6. Deixar o modelo resolver conflitos entre documentos: a escolha silenciosa dele vira "decisão da empresa" sem ninguém ter decidido.

22. Boas práticas

1. Nomes de arquivo autoexplicativos com versão e data: politica-acesso-v3-2026.pdf — o Claude usa o nome como pista de contexto.
2. Um movimento por vez: extrair → validar → transformar. Pipeline, não liquidificador.
3. Auditoria por amostragem sempre: 3 citações conferidas calibram a confiança no todo.
4. Converta para MD quando o documento for seu: fidelidade máxima, tokens mínimos.
5. Para web/HTML: salve, limpe menus e rodapés, e registre a URL de origem no topo do arquivo — rastreabilidade até a fonte viva.
6. Guarde os prompts documentais que funcionaram no seu prompts.md (Módulo 6) — análise documental é o território mais reutilizável de todos.

23. Resumo final

Análise documental profissional = preparação (nomear, higienizar, escolher formato) + pedido técnico (movimento certo, propósito, público, formato) + auditoria (transcrição de verificação, rastreabilidade por página, [NÃO CONSTA], amostragem). Os 6 movimentos — extração, resumo, comparação, transformação, auditoria, síntese — cobrem praticamente tudo que você fará com documentos em TI. Documentos consomem contexto como qualquer texto, então fragmente o grande e anexe o necessário. E conflitos entre fontes são achados para humanos decidirem, não para o modelo resolver em silêncio. No próximo módulo, veremos o que acontece quando o volume cresce além do contexto: RAG.

24. Mini desafio

A tarde de duas horas em vinte minutos: escolha o documento mais chato que você adiou ler este mês (relatório, política, manual de fornecedor). Rode o pipeline completo: verificação de leitura → extração auditável dos 5 pontos que interessam a você → resumo com propósito → transformação em um entregável (checklist ou plano de ação). Audite 3 citações. Registre quanto tempo levou e o que você teria perdido lendo "na diagonal".

25. Como aplicar isso amanhã no trabalho

Como eu aplicaria isso amanhã: pegaria o export de tickets do mês (higienizado: sem nomes, e-mails ou hostnames reais) e rodaria a extração + agrupamento por causa-raiz com rastreabilidade por linha. Auditaria 3 agrupamentos contra o CSV original. Com o resultado validado, pediria a transformação: "os 3 KB articles que mais reduziriam volume, no nosso template". Na reunião semanal, eu chegaria não com "sinto que tem muito chamado de MFA", mas com números, agrupamentos e dois rascunhos de KB prontos para revisão — material de quem trabalha com dados, não com impressões.

🎨 Adaptação para o Fable — Módulo 8

Título curto para o card: "O perito documental"

Texto de abertura envolvente:

Um PDF de 80 páginas. Um CSV com 3 mil tickets. Um print de erro borrado. Sua tarde inteira — ou vinte minutos, dependendo de como você trabalha. Neste módulo, você aprende o protocolo do perito: preparar, pedir com método e auditar. Nunca mais "resume esse pdf".

Divisão sugerida em telas: 1. Tela 1 — "A caixa de papéis amassados" (analogia do perito) 2. Tela 2 — "Cada formato, uma leitura" (tabela interativa de formatos) 3. Tela 3 — "Os 6 movimentos documentais" (carrossel com exemplo de cada) 4. Tela 4 — "Rastreabilidade: página, seção, [NÃO CONSTA]" 5. Tela 5 — "O caso das duas políticas" (exemplo guiado v2 vs v3) 6. Tela 6 — "Quando a leitura falha" (sinais e contramedidas) 7. Tela 7 — Laboratório + quiz

Ideia de interação: "Qual movimento é esse?" — o aluno vê 6 pedidos reais de TI ("transformar post-mortem em KB", "confrontar duas propostas de fornecedor"...) e conecta cada um ao movimento documental correto. Depois, um desafio-bônus: identificar qual dos 6 pedidos está mal formulado e consertá-lo.

Pergunta reflexiva: "Qual foi a última vez que você confiou numa análise de documento sem conferir nenhuma citação? O que estava em jogo se a leitura estivesse errada?"

Microatividade prática: rodar o pipeline (verificação → extração → transformação) com um documento real higienizado e colar no Fable uma citação auditada que bateu — ou uma que não bateu, e o que isso ensinou.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Você agora tem protocolo de perito: prepara, pede com método, audita. Mas o que acontece quando são 50 documentos, e nem tudo cabe na mesa? É aí que entra a recuperação inteligente — RAG, o assunto do próximo módulo.

Sugestão visual para o Fable: infográfico "pipeline documental" — esteira em 5 estações (higienizar → verificar leitura → extrair com página → auditar amostra → transformar), com um documento estilizado avançando pelas estações e ganhando carimbos de "verificado".

MÓDULO 9 — RAG no Claude: quando a base de conhecimento cresce

1. Nome do módulo

RAG na prática: entendendo a recuperação de informação para perguntar melhor em Projects grandes

2. Objetivo de aprendizagem

Compreender o que é Retrieval-Augmented Generation (geração aumentada por recuperação), como e quando o Claude usa recuperação em vez de contexto direto, o que isso muda na qualidade das respostas — e, principalmente, como formular perguntas que funcionam bem quando o Project tem muitos documentos.

3. O que a pessoa será capaz de fazer ao final do módulo

• Explicar RAG em linguagem simples e em linguagem técnica.
• Distinguir "documento no contexto" de "documento recuperado" e prever as consequências práticas de cada modo.
• Reconhecer os sintomas de recuperação falha (o Claude "não achou" algo que está lá).
• Formular perguntas com vocabulário-âncora que maximizam a chance de recuperar os trechos certos.
• Estruturar o Knowledge de um Project pensando em recuperabilidade.
• Saber quando RAG resolve — e quando a solução é outra (fragmentar, resumir, redesenhar o Project).

4. Por que esse tema importa no uso real do Claude

Nos Módulos 7 e 8 você montou Projects e aprendeu análise documental. Cedo ou tarde, seu Project de Service Desk terá 30 procedimentos, seu Project de estudos terá 15 resumos, e você notará algo estranho: às vezes o Claude responde com precisão cirúrgica citando o documento certo; outras vezes parece "não ter visto" um arquivo que está lá.

Isso não é aleatório. É o comportamento previsível de um sistema de recuperação: quando o volume ultrapassa o que cabe na mesa (Módulo 4), o Claude deixa de ler tudo e passa a buscar os trechos mais parecidos com a sua pergunta. Entender essa mecânica transforma frustração ("ele ignorou meu documento!") em técnica ("vou perguntar com as palavras que estão no documento"). É a diferença entre usar uma base de conhecimento e brigar com ela.

5. Explicação simples

Imagine dois cenários:

Cenário A — poucos documentos: tudo cabe na mesa do Claude. Ele lê tudo, o tempo todo. Qualquer pergunta enxerga qualquer documento.

Cenário B — muitos documentos: não cabe tudo. Então funciona assim: sua pergunta vira uma "chave de busca"; um mecanismo procura, em todos os documentos, os trechos mais parecidos com a pergunta; só esses trechos vão para a mesa; e o Claude responde com base neles.

Isso é RAG: Retrieval (buscar os trechos) + Augmented Generation (gerar a resposta usando o que foi buscado).

A consequência prática que muda tudo: no cenário B, a qualidade da resposta depende da qualidade da busca — e a busca depende das palavras da sua pergunta. Perguntas vagas recuperam trechos errados; perguntas com o vocabulário do documento recuperam os trechos certos.

6. Explicação profunda

A mecânica, passo a passo. Relembre os embeddings do Módulo 2: representações numéricas de texto onde significados parecidos ficam "próximos". Um pipeline de RAG típico:

1. Chunking (fatiamento): cada documento é dividido em pedaços (chunks) — parágrafos ou seções.
2. Indexação: cada chunk vira um embedding e é guardado num índice.
3. Consulta: sua pergunta também vira um embedding.
4. Busca por similaridade: o sistema encontra os chunks cujos embeddings estão mais próximos do embedding da pergunta.
5. Montagem do contexto: os top-N chunks entram na context window, junto com sua pergunta.
6. Geração: o Claude responde com base nesses chunks (e no resto do contexto).

Por que isso explica os "pontos cegos". Três fenômenos que agora fazem sentido:

• Vocabulário desalinhado: você pergunta "problema de senha" e o documento fala em "redefinição de credenciais". A similaridade semântica ajuda (embeddings capturam significado, não só palavras), mas quanto mais distante o vocabulário, menor a chance de o chunk certo vencer a disputa pelos top-N.
• Informação fragmentada entre chunks: a resposta completa exige juntar o chunk 3 do documento A com o chunk 12 do documento B. Se só um deles é recuperado, a resposta sai pela metade — com confiança.
• Perguntas panorâmicas: "me dê uma visão geral de todos os procedimentos" é péssima para RAG — não existe chunk que "se pareça" com uma visão geral. Recuperação favorece perguntas específicas; panoramas pedem outra estratégia (índice manual, resumos por documento).

Contexto direto × RAG — a tabela de decisão:

O que isso significa no Claude, na prática. No Claude.ai, você não configura chunking nem índice — a plataforma decide o mecanismo conforme o volume do Project Knowledge (pouco material tende a entrar direto; muito material aciona recuperação). Os detalhes de implementação evoluem e não são todos públicos — o comportamento exato deve ser validado em https://support.claude.com. Mas a física é a descrita acima, e as técnicas de pergunta deste módulo funcionam nos dois regimes: elas apenas se tornam críticas no regime de recuperação. (Na API, dá para construir pipelines de RAG sob medida — fica no horizonte do Módulo 16 em diante.)

Limitação honesta e contorno. RAG resolve volume, não resolve raciocínio global. "Quais dos 40 procedimentos contradizem a política de acesso?" exige confrontar tudo com tudo — recuperação não faz isso bem. Contorno: decompor (Módulo 6) — confrontar a política com grupos de 5 procedimentos por conversa, consolidando ao final; ou manter um documento-índice (ver seção 22) que dá ao Claude o mapa do acervo.

7. Conceitos-chave

• RAG (Retrieval-Augmented Generation): gerar respostas usando trechos recuperados de uma base, em vez de (ou além de) o que está no contexto.
• Chunk: fatia de documento indexada e recuperável individualmente.
• Embedding: representação numérica de significado usada para busca por similaridade (Módulo 2).
• Busca semântica: encontrar por proximidade de significado, não por palavra exata.
• Top-N: os N trechos mais similares que entram no contexto.
• Vocabulário-âncora: termos da pergunta escolhidos para "puxar" os chunks certos.
• Pergunta panorâmica: pedido de visão geral — o ponto fraco estrutural da recuperação.

8. Analogia didática

Pense na diferença entre a sua mesa e o arquivo morto do prédio.

Com 3 pastas na mesa, qualquer pergunta é fácil: está tudo à vista. É o contexto direto.

Com 300 pastas no arquivo do porão, você não traz tudo para a mesa — você pede ao estagiário: "traga as pastas sobre X". E aqui mora o segredo: o estagiário busca pelas etiquetas e pelo texto. Se você pede "aquele negócio da confusão de acesso" e a pasta se chama "Redefinição de credenciais — Entra ID", ele volta com a pasta errada — e você, sem saber, trabalha com o material errado.

O estagiário é a recuperação. As etiquetas são os chunks indexados. E o seu pedido — as palavras exatas dele — decide o que chega à mesa. RAG não é o Claude "sabendo menos"; é o Claude trabalhando com um arquivo maior do que a mesa, através de um assistente literal.

9. Exemplo prático usando Claude

Cenário: seu Project "Service Desk M365" (Módulo 7) cresceu — 25 procedimentos no Knowledge. Vamos ver as duas faces da recuperação.

Rodada 1 — pergunta vaga:

como resolvo problema de acesso?

Resultado provável: resposta genérica misturando trechos de 3 procedimentos diferentes (VPN, MFA, SharePoint) — porque "problema de acesso" é parecido com quase tudo. Nenhum documento citado com precisão.

Rodada 2 — pergunta com vocabulário-âncora:

Consultando o Knowledge deste Project: qual é o procedimento
para REDEFINIR O MFA de um usuário que TROCOU DE CELULAR?
Cite o arquivo-fonte e siga exatamente os passos dele.
Se o procedimento não estiver no Knowledge, diga
[SEM FONTE NO PROJECT] — não improvise.

Resultado: recuperação certeira do procedimento-reset-mfa.md, passos fiéis, fonte citada. Os termos "redefinir MFA" e "trocou de celular" estão no documento — a busca acha.

Rodada 3 — teste de ponto cego: pergunte sobre um procedimento que você SABE que está lá, mas usando sinônimos distantes ("aparelho novo do colaborador precisa do segundo fator de novo"). Se a resposta vier vaga ou com [SEM FONTE], você acabou de ver um miss de recuperação ao vivo — e a correção: repetir com o vocabulário do documento. Esse experimento vale mais que qualquer teoria.

10. Aplicação no dia a dia de TI

• Trate o Knowledge como você trata uma KB corporativa: você já sabe, do seu sistema de tickets, que a busca acha o que os títulos e palavras-chave permitem achar. Mesma lógica: documentos com títulos descritivos e termos de busca no corpo são "recuperáveis"; documentos crípticos são invisíveis.
• Pergunte como quem pesquisa numa KB: específico, com os termos do domínio, um assunto por pergunta.
• Para trabalho fino em 1–2 documentos: anexe-os diretamente na conversa (contexto direto), mesmo que também estejam no Knowledge — cobertura total garante a análise integral (Módulo 8).
• Para consulta pontual num acervo grande: confie na recuperação, mas com vocabulário-âncora e exigência de fonte.

11. Aplicação em Service Desk

• O Project de procedimentos como "L0" do analista: com 30+ POPs no Knowledge, a pergunta bem formulada ("procedimento para liberar remetente bloqueado no quarentena do Exchange Online") devolve o passo a passo certo, com fonte, em segundos — mais rápido que navegar na intranet.
• Blindagem contra o miss silencioso: a instrução permanente no Project (Módulo 7) — "cite o arquivo-fonte; sem fonte, diga [SEM FONTE NO PROJECT]" — converte o pior cenário (resposta inventada por falta de chunk) no cenário gerenciável (aviso claro de que não achou).
• Curadoria orientada a busca: ao adicionar um KB novo ao Knowledge, inclua no topo uma linha de sinônimos ("também conhecido como: segundo fator, autenticador, aprovação no celular"). Você está semeando âncoras para as buscas de amanhã.
• Diagnóstico de "não achou": quando o Claude não encontra algo que existe, a ordem de suspeita é: (1º) vocabulário desalinhado → reformule; (2º) informação enterrada num documento gigante → fragmente o arquivo; (3º) documento realmente não cobre → atualize o Knowledge.

12. Aplicação em Microsoft 365, Entra ID, IAM e estudos de certificação

• Project de estudos SC-300 com 15 resumos: perguntas de revisão funcionam melhor com os termos do exame — "diferença entre Entra joined e Entra hybrid joined no fluxo de autenticação" recupera o resumo certo; "aquele lance dos tipos de dispositivo" não.
• Cuidado com perguntas panorâmicas na véspera da prova: "me revise tudo sobre identidades" recuperará um mosaico parcial. Melhor: mantenha um 00-indice-do-project.md listando cada resumo e seus tópicos; peça "consulte o índice e monte um plano de revisão"; então revise tópico a tópico — cada pergunta específica, cada recuperação certeira.
• Governança de IAM: num Project com todas as políticas de acesso, perguntas de auditoria pontuais ("o que a política diz sobre contas de serviço com privilégios permanentes?") brilham; confrontos globais ("tudo que conflita com Zero Trust") pedem decomposição por grupos de documentos.

13. Prompts bons

Consulta com âncora + fonte obrigatória:

Consultando o Knowledge: qual o procedimento para [tarefa,
usando os termos que o documento usa]? Cite o arquivo-fonte.
Sem fonte no Knowledge → responda [SEM FONTE NO PROJECT].

Reformulação após um miss:

Você não encontrou. O documento existe e deve usar termos como
[termo A], [termo B] ou [termo C]. Busque novamente no Knowledge
considerando esses termos e me diga qual arquivo encontrou.

Panorama via índice (contornando o ponto fraco):

Abra o arquivo 00-indice-do-project.md e liste os documentos
relacionados a [tema]. Depois, para cada um, me dê o resumo de
2 linhas registrado no índice. Vou escolher por onde aprofundar.

Auditoria de recuperabilidade do próprio Knowledge:

Vou testar a "encontrabilidade" do meu Knowledge. Para o tema
[tema], quais arquivos você localiza e que termos de cada um
sustentaram a localização? Liste também sinônimos comuns em TI
que os documentos NÃO usam — vou adicioná-los como âncoras.

14. Prompts ruins

me fala tudo que tem nos documentos

(Panorâmica pura: não há chunk parecido com "tudo". Resultado: mosaico aleatório apresentado como completo.)

aquele problema que a gente sempre tem, como resolve mesmo?

(Zero âncoras. A busca não tem com que trabalhar — recupera lixo ou nada.)

por que você está ignorando meu documento?? ele está aí!!

(O modelo não "ignora por má vontade" — houve um miss de recuperação. Brigar não reformula a busca; o prompt de reformulação da seção 13 sim.)

15. Por que os prompts bons funcionam melhor

Todos exploram a mesma física: a pergunta é a chave de busca. O prompt com âncoras alinha o vocabulário da chave ao vocabulário dos chunks (maximiza similaridade); a exigência de fonte transforma miss silencioso em aviso explícito; o padrão do índice substitui a operação que a recuperação não faz (panorama) por uma sequência de operações que ela faz muito bem (consultas específicas); e a auditoria de encontrabilidade inverte o jogo — em vez de torcer para a busca funcionar, você projeta o Knowledge para ser encontrado. Os prompts ruins pedem à recuperação exatamente o que ela não sabe entregar: totalidade, adivinhação e intenção.

16. Laboratório prático guiado

Objetivo: ver a recuperação funcionando, falhando e sendo consertada — no seu próprio Project.

1. Prepare o terreno: use o Project do Módulo 7 e garanta ao menos 8–10 arquivos no Knowledge (se precisar, gere procedimentos fictícios realistas com o Claude em outra conversa).
2. Crie o índice: peça ao Claude — "gere um 00-indice-do-project.md: para cada arquivo, nome + resumo de 2 linhas + 5 palavras-chave". Revise e suba ao Knowledge.
3. Teste de acerto: 3 perguntas específicas com vocabulário dos documentos. Confira fontes citadas.
4. Teste de miss: 2 perguntas sobre conteúdo existente, mas com sinônimos distantes. Observe o comportamento (vago? [SEM FONTE]? mistura?).
5. Conserto: aplique o prompt de reformulação com os termos corretos. Compare.
6. Semeadura de âncoras: rode a auditoria de encontrabilidade e adicione as linhas de sinônimos sugeridas a 2 documentos.
7. Reteste o miss do passo 4: agora deve acertar. Você acabou de fazer engenharia de recuperabilidade.

17. Exercícios de fixação

1. Explique RAG para um colega em 3 frases, usando a analogia do arquivo do porão.
2. Liste as 3 causas de "não achou" em ordem de suspeita, com a correção de cada uma.
3. Reescreva "me fala tudo sobre segurança que tem aí" usando o padrão do índice.
4. Por que "documento no contexto" e "documento no Knowledge grande" podem gerar respostas diferentes para a mesma pergunta?
5. Escreva a linha de sinônimos que você adicionaria ao topo de um procedimento de "Redefinição de credenciais".

18. Quiz

1. Em RAG, o que determina quais trechos chegam ao modelo? a) — A ordem alfabética dos arquivos b) — A similaridade entre a pergunta e os chunks indexados c) — O tamanho dos documentos d) — A data de upload

2. Perguntas panorâmicas funcionam mal com recuperação porque: a) — São longas demais b) — Não existe chunk que "se pareça" com uma visão geral c) — Consomem muitos tokens d) — O modelo se recusa a respondê-las

3. O Claude respondeu vagamente sobre um procedimento que ESTÁ no Knowledge. Primeira suspeita: a) — O arquivo está corrompido b) — Vocabulário da pergunta desalinhado do documento c) — O modelo está sobrecarregado d) — O Project atingiu o limite

4. A instrução "cite o arquivo-fonte; sem fonte → [SEM FONTE NO PROJECT]" serve para: a) — Acelerar a busca b) — Converter falhas silenciosas de recuperação em avisos explícitos c) — Reduzir o consumo de tokens d) — Impedir uploads duplicados

5. Para análise fina e integral de 2 documentos, o melhor é: a) — Colocá-los num Project com outros 40 arquivos e perguntar b) — Anexá-los diretamente na conversa (contexto direto) c) — Pedir uma visão geral panorâmica d) — Dividi-los em 50 chunks manualmente

19. Gabarito comentado

1 — b. O coração do RAG: pergunta vira embedding, chunks viram embeddings, os mais próximos vencem. Por isso as palavras da pergunta importam tanto.

2 — b. Recuperação é busca por semelhança com a pergunta. "Visão geral de tudo" não se parece com nenhum trecho específico — o mecanismo devolve um mosaico parcial. Contorno: documento-índice + perguntas específicas.

3 — b. A ordem de suspeita: vocabulário (mais comum e mais barato de corrigir) → fragmentação do documento → lacuna real. Reformular com os termos do documento resolve a maioria dos casos.

4 — b. O pior cenário em RAG é o miss silencioso: chunk certo não veio e o modelo completa com plausibilidade. A instrução dá saída legítima ("não achei") — mesmo princípio do [NÃO CONSTA] do Módulo 8.

5 — b. Contexto direto garante cobertura total — essencial para comparação integral (Módulo 8). RAG é para volume e consulta pontual; análise fina de poucos documentos dispensa e até desaconselha a recuperação.

20. Checklist do módulo

• Sei explicar RAG com e sem jargão
• Distingo contexto direto de recuperação e sei quando preferir cada um
• Uso vocabulário-âncora nas perguntas a Projects grandes
• Exijo fonte + [SEM FONTE NO PROJECT] por padrão
• Sei diagnosticar um miss (vocabulário → fragmentação → lacuna)
• Mantenho um documento-índice no Project
• Semeio sinônimos nos documentos importantes
• Evito perguntas panorâmicas — ou as roteio pelo índice

21. Erros comuns

1. Interpretar miss como má vontade do modelo: e insistir com a mesma pergunta em vez de reformular com âncoras.
2. Knowledge-monolito: um PDF de 200 páginas com tudo dentro — chunks enormes, recuperação imprecisa. Fragmente por tema.
3. Confiar em panorama de recuperação: "visão geral" que parece completa mas amostrou 6 de 25 documentos.
4. Títulos crípticos (doc_final_v3_REVISADO.pdf): invisíveis para a busca e para você.
5. Testar o Project só com perguntas fáceis: os misses aparecem em produção, na pior hora. Teste sinônimos de propósito (passo 4 do laboratório).
6. Usar RAG para confronto global: "o que conflita entre todos os documentos?" — decomposição em grupos é o caminho.

22. Boas práticas

1. Documento-índice 00-indice-do-project.md: nome, resumo de 2 linhas, palavras-chave de cada arquivo. É o mapa do arquivo do porão — e o roteador de panoramas.
2. Linha de sinônimos no topo de cada documento importante: engenharia de recuperabilidade barata e eficaz.
3. Um tema por arquivo: arquivos focados = chunks focados = recuperação precisa.
4. Instrução permanente de fonte no Project (Módulo 7): rastreabilidade sem custo por pergunta.
5. Pergunte como busca, não como conversa: substantivos do domínio, específicos, um assunto por vez.
6. Reteste após grandes adições ao Knowledge: 3 perguntas de regressão garantem que o crescimento não degradou a encontrabilidade.

23. Resumo final

RAG é a resposta ao problema "o arquivo é maior que a mesa": em vez de ler tudo, o sistema busca os trechos mais similares à pergunta e responde com base neles. Isso escala volume, mas cria uma dependência nova: a resposta é tão boa quanto a recuperação, e a recuperação é tão boa quanto as palavras da sua pergunta e a estrutura do seu acervo. As técnicas: vocabulário-âncora, fonte obrigatória com [SEM FONTE NO PROJECT], documento-índice para panoramas, sinônimos semeados, um tema por arquivo, e contexto direto quando a análise exige cobertura integral. Você aprendeu a projetar conhecimento para ser encontrado — no próximo módulo, aprenderá a transformar respostas em coisas que funcionam: os Artifacts.

24. Mini desafio

Caça ao ponto cego: no seu Project mais usado, escreva 5 perguntas sobre conteúdos que você tem certeza que estão no Knowledge — mas usando deliberadamente sinônimos e paráfrases distantes. Registre quantas falharam. Para cada falha, aplique um conserto (reformulação, sinônimos no documento, fragmentação) e reteste. Meta: 5/5 no reteste. Você terá auditado e blindado a encontrabilidade do seu acervo.

25. Como aplicar isso amanhã no trabalho

Como eu aplicaria isso amanhã: abriria meu Project de Service Desk e gastaria 15 minutos criando o 00-indice-do-project.md com ajuda do próprio Claude. Depois rodaria a auditoria de encontrabilidade nos 3 procedimentos mais consultados e adicionaria as linhas de sinônimos que faltam — incluindo os termos que os usuários usam ("token", "aprovação no celular"), não só os oficiais ("MFA", "autenticação multifator"). No turno, cada consulta ao Project seria formulada como busca: específica, com âncoras, exigindo fonte. E quando um colega reclamasse "o Claude não achou meu documento", eu teria o diagnóstico em três passos na ponta da língua.

🎨 Adaptação para o Fable — Módulo 9

Título curto para o card: "O arquivo do porão"

Texto de abertura envolvente:

Seu Project cresceu: 25 procedimentos, 15 resumos. E de repente o Claude "não acha" um documento que está bem ali. Não é teimosia — é recuperação. Neste módulo você entende a física do RAG e aprende a perguntar de um jeito que a busca sempre encontra. Spoiler: as palavras da sua pergunta são a chave do arquivo.

Divisão sugerida em telas: 1. Tela 1 — "A mesa e o porão" (analogia do estagiário literal) 2. Tela 2 — "Como funciona a busca" (pipeline: chunk → embedding → similaridade → top-N) 3. Tela 3 — "Por que ele 'não achou'" (os 3 diagnósticos de miss) 4. Tela 4 — "Vocabulário-âncora" (antes/depois de perguntas reais) 5. Tela 5 — "O ponto fraco: panoramas" (e o contorno do índice) 6. Tela 6 — "Projetando para ser encontrado" (índice, sinônimos, um tema por arquivo) 7. Tela 7 — Laboratório + quiz

Ideia de interação: "Simulador de recuperação" — o aluno vê 6 etiquetas de documentos e 3 formulações de uma mesma pergunta; para cada formulação, prevê qual documento a busca vai trazer, e então revela o resultado. A terceira formulação (vaga) traz o documento errado — momento "aha!" da mecânica de similaridade.

Pergunta reflexiva: "Pense na busca do seu sistema de tickets: que truques de palavras você já usa para achar o que precisa? Quantos deles você já aplica quando pergunta ao Claude?"

Microatividade prática: rodar a "caça ao ponto cego" (mini desafio) com 3 perguntas no próprio Project e registrar no Fable um miss real + o conserto que funcionou.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Você agora projeta conhecimento para ser encontrado — índice, âncoras, sinônimos, fonte obrigatória. Seu Project deixou de ser uma pasta e virou uma base de conhecimento de verdade. Próxima parada: transformar respostas em coisas vivas — guias interativos, dashboards, quizzes. Bem-vinda aos Artifacts.

Sugestão visual para o Fable: diagrama animado em duas cenas — cena 1: mesa pequena com 3 pastas e o Claude lendo tudo ("contexto direto"); cena 2: porão com 300 pastas, uma pergunta virando "chave de busca" luminosa que atrai as 3 pastas mais parecidas até a mesa ("RAG"), com uma pasta certa quase sendo deixada para trás quando a chave está mal formulada.

MÓDULO 10 — Artifacts: transformando respostas em entregáveis vivos

1. Nome do módulo

Artifacts: criando guias interativos, dashboards, quizzes e mini apps sem escrever uma linha de código

2. Objetivo de aprendizagem

Dominar os Artifacts do Claude: entender o que são, quando aparecem, para que tipos de entregável servem, como iterar sobre eles com precisão (alterações, redesign, versões) e como evitar o resultado genérico — extraindo deles materiais didáticos, operacionais e visuais de nível profissional.

3. O que a pessoa será capaz de fazer ao final do módulo

• Reconhecer quando um pedido gera (ou deveria gerar) um Artifact.
• Criar guias HTML, checklists interativos, quizzes, flashcards, dashboards, diagramas e mini apps de estudo.
• Pedir alterações cirúrgicas ("mude só X") em vez de regenerações que destroem o que estava bom.
• Conduzir redesigns e melhorias visuais com vocabulário de direção de arte simples.
• Aplicar o processo anti-superficialidade: conteúdo primeiro, estrutura depois, interface por último.
• Publicar/exportar o resultado e decidir quando um Artifact é a ferramenta certa (e quando não é).

4. Por que esse tema importa no uso real do Claude

Até aqui, tudo que o Claude produziu para você foi texto na conversa — excelente para análise e raciocínio, mas nem sempre o formato final que o trabalho pede. Um guia de troubleshooting é mais útil como página navegável; um quiz de certificação, como algo clicável; um checklist de onboarding, como lista interativa; um comparativo de políticas, como dashboard visual.

Artifacts fecham essa lacuna: o Claude constrói o entregável de verdade — um documento, uma página HTML funcional, um diagrama, um pequeno aplicativo — numa janela dedicada, que você itera, versiona e usa. Para quem cria materiais de estudo e documentação (seu caso), isso é o módulo que transforma "respostas boas" em "produtos prontos": o simulado vira simulador, o resumo vira guia navegável, o procedimento vira checklist que o time realmente segue.

5. Explicação simples

Quando você pede algo que é mais "coisa" do que "conversa" — um documento longo, uma página, um quiz, um diagrama, um app simples — o Claude abre um painel separado ao lado do chat: o Artifact.

Pense assim: o chat é onde vocês conversam; o Artifact é a bancada onde a coisa está sendo construída. Você olha o resultado, volta ao chat e diz o que mudar ("deixe o título maior", "adicione uma seção de erros comuns"), e o Claude atualiza a bancada — sem apagar o resto.

Três ideias-chave:

1. Artifact = entregável, não resposta. É algo que você vai usar, salvar, compartilhar.
2. Você itera conversando: cada pedido de mudança gera uma nova versão, e dá para voltar às anteriores.
3. HTML interativo funciona de verdade: quizzes clicáveis, flashcards que viram, checklists que marcam — rodando ali no painel.

6. Explicação profunda

O que pode ser um Artifact. Os tipos que mais importam para o seu trabalho:

Quando o Artifact aparece. O Claude decide criar um Artifact quando o pedido resulta em conteúdo substancial, autocontido e reutilizável — um guia, uma página, um app. Conteúdo curto ou conversacional fica no chat. Você pode forçar a mão: "crie como um Artifact HTML" — e deve, quando quer o entregável. (Detalhes de disponibilidade e recursos de compartilhamento variam por plano e evoluem: https://support.claude.com.)

Versões: o superpoder subestimado. Cada alteração gera uma nova versão do Artifact, e você navega entre elas. Consequências práticas:

• Iterar sem medo: um redesign que piorou não destrói nada — volte à versão anterior.
• Alterar ≠ regenerar: "mude apenas a seção 3" preserva o resto; "refaça tudo" joga fora acertos. A regra: peça a menor mudança que resolve.
• Comparar direções: gere a v2 minimalista, volte, gere a v3 colorida, compare, escolha.

Interatividade real. Um Artifact HTML executa JavaScript: botões funcionam, respostas do quiz são corrigidas na hora, flashcards viram ao clique, filtros filtram. Limites importantes para não se frustrar:

• Sem persistência: o Artifact não grava dados entre sessões (o checklist marcado hoje volta desmarcado amanhã). É uma página, não um sistema com banco de dados.
• Autocontido: tudo (estilo, lógica, conteúdo) vive dentro do próprio Artifact; não conte com o acesso irrestrito a recursos externos.
• Não é hospedagem corporativa: para o time usar, exporte/copie o HTML para a intranet ou compartilhe conforme o plano permitir — seguindo a política da empresa.

O processo anti-superficialidade. O maior erro com Artifacts é pedir tudo de uma vez: "crie um guia HTML completo e bonito sobre MFA". O resultado tende a ser raso — genérico no conteúdo, padrão no visual — porque o modelo dividiu a atenção entre o que dizer, como organizar e como pintar. O antídoto é o pipeline em três estágios, herdando tudo dos módulos anteriores:

1. Conteúdo primeiro (no chat, sem Artifact): produza e revise a substância — com fontes anexadas (Módulo 8), rastreabilidade, profundidade validada. "Ainda sem criar o Artifact: escreva o conteúdo completo do guia, seção por seção."
2. Estrutura depois: acorde o esqueleto — seções, navegação, hierarquia. "Proponha a estrutura da página: menu, ordem das seções, o que é expansível."
3. Interface por último: só então, "agora crie o Artifact HTML com esse conteúdo e essa estrutura" — e itere o visual em pedidos pequenos.

Conteúdo validado + estrutura acordada + visual iterado = entregável profissional. Tudo de uma vez = pôster bonito de conteúdo raso.

Vocabulário de direção visual. Você não precisa saber design; precisa de meia dúzia de termos que o Claude entende bem: "estilo limpo e corporativo, tipo documentação da Microsoft", "paleta sóbria: azul-escuro, cinza, branco", "bastante espaço em branco", "cards com cantos arredondados", "modo escuro", "tipografia grande e legível". Referências de estilo ("parecido com o Microsoft Learn") funcionam melhor que adjetivos vagos ("bonito", "moderno").

7. Conceitos-chave

• Artifact: entregável autocontido construído num painel dedicado, iterável e versionado.
• Versão: cada estado salvo do Artifact após uma alteração; navegável para frente e para trás.
• Alteração cirúrgica: pedido de mudança mínimo e localizado ("apenas a seção X"), preservando o resto.
• Redesign: mudança de direção visual mantendo o conteúdo.
• Pipeline conteúdo → estrutura → interface: o processo anti-superficialidade.
• Autocontido / sem persistência: o Artifact carrega tudo dentro de si e não grava dados entre sessões.
• Mermaid: linguagem de diagramas por texto que o Claude usa para fluxos (detalhes no Módulo 19).

8. Analogia didática

Pense na diferença entre explicar uma reforma por telefone e estar na obra com o mestre de obras.

No telefone (chat puro), tudo é descrição: "a parede seria azul, a bancada ficaria à esquerda...". Você imagina, mas não vê.

Na obra (Artifact), a parede está azul, diante de você. E aí a conversa muda de natureza: "essa parede, um tom mais claro"; "essa bancada, 20 cm para a direita". Cada ajuste é feito sobre o que existe — e se o tom novo ficar pior, o mestre tem foto de como estava (versões) e volta.

E o segredo dos bons reformadores vale igual: ninguém escolhe cor de parede antes de definir a planta, e ninguém define a planta antes de saber para que serve o cômodo. Função → estrutura → acabamento. Conteúdo → estrutura → interface.

9. Exemplo prático usando Claude

Cenário: transformar seu material de estudos de SC-300 num simulado interativo — o exemplo completo do pipeline.

Estágio 1 — Conteúdo (no chat):

Ainda SEM criar Artifact. Com base no resumo anexado
(resumo-sc300-identidades.md), escreva 10 questões de múltipla
escolha estilo exame Microsoft sobre gerenciamento de
identidades: cenário realista, 4 alternativas plausíveis,
1 correta, e justificativa comentada para CADA alternativa
(por que está certa/errada). Nível: intermediário.

Revise as 10 questões tecnicamente. Corrija o que precisar — este é o momento de qualidade, não depois.

Estágio 2 — Estrutura:

Vamos transformar em simulado interativo. Antes de construir,
proponha a estrutura: tela inicial, navegação entre questões,
como mostrar o gabarito comentado (só ao final ou por questão?),
placar, e botão de refazer. Me apresente 2 opções de fluxo.

Escolha o fluxo (ex.: correção por questão + placar final).

Estágio 3 — Interface:

Agora crie o Artifact HTML do simulado com as 10 questões
validadas e o fluxo B. Estilo: limpo, corporativo, paleta
azul-escuro/branco, tipografia grande, uma questão por vez,
barra de progresso no topo.

Iteração cirúrgica:

Ótimo. Três ajustes, sem mexer no resto:
1. No feedback de erro, destaque em verde a alternativa correta.
2. Placar final: mostre também quais questões errei, com link
   para revê-las.
3. Aumente o contraste do texto das alternativas.

Resultado: um simulador de verdade, com conteúdo que você validou — pronto para estudar e para compartilhar com colegas que estudam para a mesma prova.

10. Aplicação no dia a dia de TI

• Guia navegável de procedimento: o POP validado (Módulo 8) vira página HTML com menu lateral, passos expansíveis e caixa de "erros comuns" — muito mais consultável que um PDF de 12 páginas.
• Dashboard de análise pontual: o resultado da análise do CSV de tickets (Módulo 8) vira painel visual com os números e gráficos principais — para apresentar na reunião semanal sem abrir o Excel.
• Checklist interativo de onboarding: passos clicáveis por etapa (conta, MFA, Intune, acessos) — lembrando: sem persistência; para registro oficial, o sistema da empresa continua sendo o lugar.
• Diagrama de fluxo: "crie um Artifact Mermaid com o fluxo de decisão deste troubleshooting" — o mapa visual do P4 (Módulo 6), pronto para colar na KB (aprofundamos no Módulo 19).
• Documentos longos: apostilas e relatórios como Artifact Markdown — mais fáceis de exportar e versionar do que texto solto no chat.

11. Aplicação em Service Desk

• KB article em dois formatos de uma vez: o mesmo conteúdo validado vira (a) Markdown para colar no sistema de KB e (b) página HTML navegável para a intranet — dois Artifacts, um conteúdo.
• Fluxo de triagem visual para N1: as 5 causas mais comuns de "não consigo logar" viram um fluxograma interativo: o analista clica na resposta do usuário e o fluxo o conduz ao próximo teste discriminante. Treinamento de novato que se usa sozinho.
• Simulador de atendimento: cenários de tickets fictícios em que o novato escolhe a próxima ação e recebe feedback — onboarding ativo em vez de leitura passiva.
• Kit de comunicação de incidente: durante um incidente maior, um Artifact com os templates de comunicação por estágio (identificado → em análise → workaround → resolvido), prontos para copiar — consistência sob pressão.

12. Aplicação em Microsoft 365, Entra ID, IAM, Intune e estudos

• Flashcards de certificação: baralho HTML com clique-para-virar a partir dos seus resumos — "20 cards: termo do exame SC-300 na frente, definição de 2 linhas + pegadinha comum no verso".
• Comparativo visual Entra joined × registered × hybrid: tabela interativa com filtros por cenário ("BYOD?", "dispositivo corporativo?") — o tipo de material que fixa o que texto corrido não fixa.
• Mapa de Conditional Access didático: diagrama do fluxo de avaliação de políticas (sinais → decisões → controles) para explicar a colegas — com dados fictícios, claro; a política real fica no portal.
• Guia do usuário final ilustrado: página HTML "Como configurar o MFA no celular novo" com passos numerados e capturas fictícias/genéricas — linguagem de usuário, visual amigável, pronta para a intranet.
• Regra de segurança de sempre: Artifacts são exportáveis e compartilháveis por natureza — então nada de dados reais dentro deles: nomes fictícios, tenants de exemplo, números redondos. O Artifact herda a política de higienização de tudo que entra nele.

13. Prompts bons

Forçar o formato certo:

Crie como um Artifact HTML: [entregável]. Conteúdo: o texto
validado acima. Estilo: limpo e corporativo, paleta
azul-escuro/branco, tipografia legível.

Alteração cirúrgica:

No Artifact atual, altere APENAS: [mudança 1]; [mudança 2].
Não mexa em mais nada — nem no texto, nem no estilo das
demais seções.

Redesign preservando conteúdo:

Mantenha 100% do conteúdo e da estrutura. Redesenhe apenas o
visual: [direção — ex.: "modo escuro, densidade maior, estilo
painel de monitoramento"]. Se alguma escolha visual prejudicar
a leitura, priorize a leitura e me avise.

Autoauditoria antes da entrega:

Antes de eu considerar pronto: revise o Artifact como um
usuário exigente. Liste problemas de (1) conteúdo raso ou
genérico, (2) navegação confusa, (3) contraste/legibilidade.
Proponha correções — só aplique depois do meu OK.

14. Prompts ruins

faz um guia HTML completo e bonito sobre MFA

(Tudo-de-uma-vez: conteúdo, estrutura e visual disputando atenção = raso nos três. É o anti-pipeline.)

refaz tudo, não gostei

(Sem diagnóstico, o modelo troca acertos junto com os erros — e a v2 pode ficar pior. Diga O QUE não funcionou.)

adiciona umas questões aí no quiz

(Quantas? Sobre quê? Nível? Com gabarito comentado? Convite ao enchimento genérico dentro de um material que era bom.)

[cola o export real de usuários] transforma isso num dashboard pra eu apresentar

(Dados reais + formato feito para circular = vazamento com capricho visual. Higienize antes — sempre.)

15. Por que os prompts bons funcionam melhor

Os bons prompts tratam o Artifact como obra em andamento com escopo controlado: o primeiro fixa o formato e injeta conteúdo já validado (pipeline); o cirúrgico delimita o raio da mudança e protege o que está bom (versões tornam isso seguro, escopo torna eficiente); o redesign separa as camadas — conteúdo congelado, visual em movimento — e ainda dá ao modelo um critério de desempate ("priorize a leitura"); a autoauditoria usa o padrão de revisão do Módulo 6 dentro do contexto de Artifacts, pegando superficialidade antes da entrega. Os ruins misturam camadas, apagam sem diagnóstico, convidam ao genérico ou embalam dado sensível num formato feito para circular.

16. Laboratório prático guiado

Objetivo: construir um quiz interativo profissional do zero, vivenciando pipeline, iteração cirúrgica e versões.

1. Escolha o tema: um assunto que você domina (ex.: reset de MFA, tipos de join do Entra).
2. Estágio conteúdo: no chat, sem Artifact, gere 8 questões com gabarito comentado. Revise tecnicamente — corrija pelo menos 1 questão (sempre há o que corrigir; é o ponto do estágio).
3. Estágio estrutura: peça 2 opções de fluxo do quiz; escolha uma com justificativa.
4. Estágio interface: peça o Artifact HTML com direção visual explícita (estilo, paleta, tipografia).
5. Três iterações cirúrgicas: (a) um ajuste de conteúdo numa questão; (b) um ajuste de comportamento (ex.: mostrar explicação só após responder); (c) um ajuste visual (contraste, espaçamento).
6. Teste de versões: peça um redesign radical ("modo escuro, estilo terminal"); avalie; volte à versão anterior — sinta a segurança do versionamento.
7. Autoauditoria: rode o prompt da seção 13 e aplique as correções que fizerem sentido.
8. Use de verdade: responda o quiz inteiro. O que incomodou no uso real? Última iteração.

17. Exercícios de fixação

1. Explique com suas palavras a diferença entre "resposta no chat" e "Artifact" — e dê 2 exemplos do seu trabalho para cada um.
2. Por que "conteúdo → estrutura → interface" produz resultados melhores que "tudo de uma vez"? Conecte com o que você sabe sobre decomposição (Módulo 6).
3. Reescreva "refaz tudo, não gostei" como um pedido de iteração útil.
4. Liste 3 limitações dos Artifacts (persistência, autocontenção, hospedagem) e o contorno prático de cada uma.
5. Que regra de segurança um Artifact herda automaticamente — e por que ela é ainda mais crítica nesse formato?

18. Quiz

1. Um Artifact é, essencialmente: a) — Uma resposta mais longa no chat b) — Um entregável autocontido, construído num painel dedicado, iterável e versionado c) — Um arquivo do Project Knowledge d) — Um recurso exclusivo da API

2. O pipeline anti-superficialidade é: a) — Interface → conteúdo → estrutura b) — Conteúdo → estrutura → interface c) — Estrutura → interface → conteúdo d) — Pedir tudo de uma vez com mais adjetivos

3. "Altere APENAS a seção 3, não mexa no resto" é melhor que "refaça" porque: a) — Gasta menos tokens, apenas b) — Preserva os acertos existentes e limita o raio da mudança c) — Impede a criação de novas versões d) — Força o uso de um modelo mais avançado

4. Sobre persistência, um checklist interativo em Artifact: a) — Grava as marcações para sempre b) — Não mantém dados entre sessões — não substitui o sistema de registro oficial c) — Sincroniza com o Project Knowledge d) — Salva automaticamente na intranet

5. Antes de colocar dados num Artifact que será compartilhado, você deve: a) — Aumentar o contraste b) — Higienizar: dados fictícios, sem nomes/identificadores reais c) — Converter para PDF d) — Reduzir o número de versões

19. Gabarito comentado

1 — b. A definição completa importa: entregável (não conversa), autocontido (carrega tudo), iterável (muda por pedidos) e versionado (histórico navegável). Cada atributo habilita uma técnica do módulo.

2 — b. Substância antes de esqueleto, esqueleto antes de acabamento. Pedir tudo junto divide a atenção do modelo e produz raso nos três níveis — é a decomposição do Módulo 6 aplicada a entregáveis.

3 — b. Regenerações totais jogam fora acertos junto com erros. A alteração cirúrgica define escopo — e o versionamento garante a rota de volta se ainda assim piorar.

4 — b. Artifact é página, não sistema: nada de banco de dados. Ótimo para usar, treinar e demonstrar; o registro oficial continua nos sistemas da empresa.

5 — b. Artifacts nascem para circular (exportar, compartilhar, colar na intranet) — o que multiplica o alcance de qualquer dado embutido. A higienização (Módulo 5) não é opcional; é pré-requisito do formato.

20. Checklist do módulo

• Sei quando um pedido deve virar Artifact — e forço o formato quando preciso
• Aplico o pipeline: conteúdo validado → estrutura acordada → interface
• Peço alterações cirúrgicas com escopo explícito
• Uso versões para experimentar sem medo (e voltar)
• Dou direção visual com referências, não adjetivos vagos
• Conheço os limites: sem persistência, autocontido, não é hospedagem
• Rodo autoauditoria antes de considerar pronto
• Só coloco dados higienizados em Artifacts

21. Erros comuns

1. Tudo-de-uma-vez: "guia completo e bonito" num prompt só → raso no conteúdo, genérico no visual.
2. Regenerar em vez de iterar: "refaz" destrói acertos; a v2 fica diferente, não melhor.
3. Validar conteúdo depois da interface: erro técnico embalado em página bonita é erro que se espalha mais rápido.
4. Esperar persistência: montar "controle de tarefas do time" num Artifact e perder tudo na sessão seguinte.
5. Adjetivos vagos como direção visual: "moderno e clean" significa nada; "estilo Microsoft Learn, paleta sóbria" significa muito.
6. Dados reais no material compartilhável: o erro de higienização com o maior raio de dano.

22. Boas práticas

1. Conteúdo no chat, entregável no Artifact: valide a substância antes de construir a casca.
2. Uma direção visual por iteração: mudanças visuais empilhadas confundem o diagnóstico do que funcionou.
3. Guarde os "prompts de estilo" que deram certo no seu prompts.md (Módulo 6): sua identidade visual reutilizável.
4. Feche com uso real: sempre teste o Artifact como usuário (responda o quiz, navegue o guia) antes de compartilhar.
5. Dois formatos do mesmo conteúdo quando fizer sentido: Markdown para sistemas, HTML para pessoas.
6. Nomeie a versão boa: ao chegar numa versão de referência, peça "registre no topo: v1.0 — [data]" — âncora humana no histórico.

23. Resumo final

Artifacts transformam o Claude de conversador em construtor: guias navegáveis, quizzes que corrigem, dashboards, flashcards, diagramas e mini apps — entregáveis autocontidos, iteráveis e versionados. A técnica que separa o profissional do genérico é o pipeline (conteúdo validado → estrutura acordada → interface iterada), somado a alterações cirúrgicas com escopo explícito, direção visual por referências e autoauditoria final. Os limites são claros e contornáveis: sem persistência (registro oficial fica nos sistemas), autocontido (tudo dentro), não é hospedagem (exporte para a intranet). E a regra de ouro viaja junto: material feito para circular só carrega dados higienizados. Com este módulo, o bloco fecha seu arco: você entende o Claude (M1–M4), opera a plataforma (M5), escreve prompts profissionais (M6), constrói ambientes e bases de conhecimento (M7–M9) — e agora entrega produtos (M10).

24. Mini desafio

Do texto ao produto em uma hora: pegue o melhor material que você produziu neste curso até aqui (o KB do Módulo 6, o comunicado do Módulo 8, os resumos de estudo) e transforme-o num Artifact HTML navegável usando o pipeline completo — incluindo 3 iterações cirúrgicas e 1 autoauditoria. Critério de sucesso: mostrar para uma pessoa (colega, chefe, amigo de estudos) e ela conseguir usar sem você explicar nada.

25. Como aplicar isso amanhã no trabalho

Como eu aplicaria isso amanhã: pegaria o KB article de reset de MFA que já validei e pediria dois Artifacts do mesmo conteúdo — o Markdown para o sistema de KB e uma página HTML com passos expansíveis para a intranet. Direção visual: "limpo, corporativo, estilo Microsoft Learn". Três iterações cirúrgicas no máximo, autoauditoria, teste de uso real com um colega do turno. Se a página passar no teste do "usou sem eu explicar", eu proporia no daily transformar os 5 KBs mais acessados no mesmo formato — e de repente o Service Desk tem uma mini central de autoatendimento que nasceu de uma tarde de trabalho.

🎨 Adaptação para o Fable — Módulo 10

Título curto para o card: "Da resposta ao produto"

Texto de abertura envolvente:

Até agora, o Claude te deu respostas. Neste módulo, ele te entrega produtos: o resumo vira guia navegável, o simulado vira simulador clicável, o procedimento vira checklist interativo. Você vai aprender o pipeline dos profissionais — conteúdo, estrutura, interface — e o segredo de iterar sem nunca perder o que estava bom.

Divisão sugerida em telas: 1. Tela 1 — "O telefone e a obra" (analogia da reforma) 2. Tela 2 — "O que pode ser um Artifact" (galeria de tipos com exemplos de TI) 3. Tela 3 — "O pipeline anti-superficialidade" (3 estágios, com o anti-exemplo "tudo de uma vez") 4. Tela 4 — "Iteração cirúrgica e versões" (antes/depois de pedidos de mudança) 5. Tela 5 — "Direção visual sem ser designer" (vocabulário + referências) 6. Tela 6 — "Limites e segurança" (persistência, autocontenção, higienização) 7. Tela 7 — Laboratório do quiz interativo + quiz do módulo

Ideia de interação: "A reforma certa" — o aluno recebe o pedido "guia HTML completo e bonito sobre MFA" e deve reordenar/reescrever os passos no pipeline correto (3 cards: conteúdo, estrutura, interface). Depois, um mini-jogo de iteração: diante de um Artifact com 3 defeitos (1 de conteúdo, 1 de navegação, 1 visual), escolher entre "refaz tudo" e três pedidos cirúrgicos — e ver as consequências de cada escolha.

Pergunta reflexiva: "Qual material do seu trabalho é tecnicamente bom, mas ninguém usa porque o formato afasta? O que mudaria se ele fosse navegável e interativo?"

Microatividade prática: executar o mini desafio (texto → produto) e colar no Fable o feedback da pessoa que testou o Artifact sem explicações.

Quiz rápido: as 5 questões da seção 18.

Mensagem de conclusão:

Você fechou o primeiro bloco do curso: entende como o Claude pensa, opera a plataforma como profissional, escreve prompts que são especificações, mantém bases de conhecimento encontráveis — e agora transforma tudo isso em produtos que as pessoas realmente usam. A revisão geral do bloco te espera: hora de consolidar antes de subir o próximo degrau.

Sugestão visual para o Fable: ilustração "linha de produção" — três estações (bancada de conteúdo com lupa de validação → mesa de plantas com o esqueleto da página → cavalete de pintura com a interface), e ao final uma prateleira de produtos: guia, quiz, dashboard, flashcards — cada um com selo "validado".

🏁 ENCERRAMENTO DO BLOCO — Módulos 1 a 10

1. Revisão geral do bloco

Este bloco construiu, degrau por degrau, a base completa para usar o Claude como plataforma profissional de trabalho. O arco narrativo foi intencional:

Fundamentos (M1–M4): entender a ferramenta. - M1 apresentou o ecossistema: Claude.ai, Desktop, Code, API e for Work — e a regra que atravessa o curso inteiro: o Claude estrutura, as fontes oficiais confirmam. - M2 abriu a caixa: LLMs, tokens, context window, alucinação e suas contramedidas (grounding, rastreabilidade), embeddings, RAG e agentes — cada conceito ancorado num uso prático. - M3 ensinou a escolher o modelo pelo trio complexidade × risco × volume, com a analogia do escalonamento L1/L2/L3. - M4 tratou da mesa finita: saturação, "lost in the middle", e o kit de sobrevivência — front-loading, chunking, resumo de handover, recomeço estratégico, dieta de contexto.

Operação (M5): dominar a bancada. - M5 percorreu a interface: os 3 gestos de ouro (editar = ramificar, regenerar, renomear com prefixos), formatos de arquivo, o ritual de higienização de prints — a regra de segurança inegociável — e o fluxo diário com faxina de sexta-feira.

Comunicação (M6): o coração do curso. - M6 transformou perguntas em especificações: os 8 componentes do prompt, XML tags, variáveis, decomposição, raciocínio auditável, padrões por caso de uso (revisão em 3 passes, troubleshooting com testes discriminantes, documentação com [VERIFICAR]) e a biblioteca P1–P12.

Conhecimento em escala (M7–M9): construir ambientes. - M7 ergueu os Projects: Instructions (como responder) × Knowledge (com base em quê), curadoria, isolamento, arquitetura de 3–5 Projects por "chapéu" profissional. - M8 profissionalizou a análise documental: os 6 movimentos (extração, resumo, comparação, transformação, auditoria, síntese), transcrição de verificação, [NÃO CONSTA], DECISÕES PENDENTES. - M9 explicou a física do RAG: chunks, embeddings, top-N, vocabulário-âncora, o documento-índice, engenharia de encontrabilidade.

Entrega (M10): produzir produtos. - M10 fechou o arco com Artifacts: o pipeline conteúdo → estrutura → interface, iteração cirúrgica, versões, direção visual por referências — da resposta ao produto que o time realmente usa.

Os 5 fios que costuram tudo: 1. Grounding e rastreabilidade: fonte citada, [VERIFICAR], [NÃO CONSTA], [SEM FONTE NO PROJECT] — a mesma ideia em quatro uniformes. 2. Decomposição: tarefas grandes viram etapas — em prompts (M6), documentos (M8), confrontos globais (M9) e Artifacts (M10). 3. Higienização: nada sensível entra — em prints (M5), Knowledge (M7), exports (M8) e Artifacts (M10). 4. Contexto é finito: tokens (M2), mesa (M4), documentos (M8), Instructions enxutas (M7). 5. Você decide, o Claude estrutura: conflitos vão para humanos, validação técnica é sua, fontes oficiais confirmam.

2. Checklist geral dos 10 módulos

Fundamentos

• Sei explicar o que cada produto do ecossistema Claude faz e quando usar cada um (M1)
• Sei explicar tokens, context window e alucinação — e as contramedidas de cada limitação (M2)
• Escolho o modelo pelo trio complexidade × risco × volume (M3)
• Reconheço saturação de contexto e aplico handover ou recomeço estratégico (M4)

Operação

• Uso os 3 gestos de ouro e nomeio conversas com prefixos (M5)
• Higienizo TODO print e arquivo antes do upload — sem exceção (M5)

Comunicação

• Meus prompts têm os componentes necessários: contexto, objetivo, formato, restrições, critérios (M6)
• Uso XML tags e variáveis em prompts reutilizáveis (M6)
• Tenho meu arquivo `prompts.md` vivo, com a biblioteca P1–P12 adaptada (M6)

Conhecimento em escala

• Tenho 1+ Project com Instructions enxutas em 3 blocos e Knowledge higienizado (M7)
• Executo os 6 movimentos documentais com rastreabilidade e auditoria por amostragem (M8)
• Meu Project tem documento-índice e sinônimos semeados; pergunto com vocabulário-âncora (M9)

Entrega

• Construo Artifacts pelo pipeline conteúdo → estrutura → interface (M10)
• Itero com pedidos cirúrgicos e uso versões para experimentar sem medo (M10)

Transversal

• Valido informação de produto em https://support.claude.com e https://docs.claude.com
• Nunca aceito resposta técnica sem revisão — o Claude é assistente, não autoridade

3. Mini projeto prático integrando os 10 módulos

🎯 Projeto: "Central de Conhecimento de Troubleshooting de Login M365"

Missão: construir, do zero, um mini ecossistema de conhecimento sobre o tema que mais gera chamados — problemas de login no Microsoft 365 — usando TODAS as habilidades do bloco.

Entregáveis e módulos exercitados:

Regras do projeto: - Escolha consciente de modelo em cada etapa, com justificativa de 1 linha (M3). - Toda análise com fonte citada; toda lacuna com [NÃO CONSTA] (M2, M8). - Zero dados reais em qualquer entregável (M5). - Se alguma conversa saturar, aplicar handover documentado (M4).

Critério de conclusão: um colega consegue usar o guia HTML e o quiz sem nenhuma explicação sua — e você consegue explicar cada decisão técnica do caminho.

Tempo estimado: 4–6 horas, distribuíveis em uma semana.

4. Lista de prompts reutilizáveis aprendidos no bloco

A biblioteca P1–P12 (Módulo 6) — o núcleo:

Os prompts estruturais que surgiram nos módulos 7–10:

Ação recomendada: consolidar tudo no seu prompts.md pessoal, organizado por categoria, com uma linha de "quando usar" em cada — ele é o artefato mais valioso que você leva deste bloco.

5. Sugestão de como transformar os 10 módulos em telas no Fable

Arquitetura geral da experiência: - 1 trilha = 10 cards (um por módulo), com progressão linear e desbloqueio sequencial. - 6–8 telas por card, seguindo o padrão já detalhado em cada módulo: abertura com analogia → conceito visual → aprofundamento interativo → exemplo guiado de TI → interação principal → laboratório → quiz → conclusão com gancho. - Duração-alvo por card: 20–30 minutos de tela + laboratório assíncrono no Claude real.

Padrões transversais de tela: 1. Tela de abertura: sempre a analogia do módulo (hub de portas, analista novo, escalação L1/L2/L3, mesa finita, bancada, ticket perfeito, base de operações, perito, porão, obra) — ilustrada, com a pergunta reflexiva como convite. 2. Interação central: cada módulo tem a sua já especificada (arrastar blocos do prompt, "Instructions ou Knowledge?", simulador de recuperação, "a reforma certa" etc.) — são o coração do engajamento. 3. Telas de laboratório: formato "missão fora do Fable" — instruções passo a passo, campo para colar evidência (a resposta do Claude, o miss de RAG, o feedback do colega), e critério de "missão cumprida". 4. Quiz padronizado: 5 questões por módulo, feedback comentado imediato (o gabarito comentado já escrito), nota mínima sugerida de 4/5 para desbloquear o próximo card. 5. Tela de conclusão: mensagem de fechamento + preview do próximo módulo (os ganchos já estão escritos).

Marcos de jornada (gamificação leve): - Após M4: selo "Fundamentos" (entende a máquina). - Após M6: selo "Engenheira de Prompts" (o coração do curso). - Após M9: selo "Arquiteta de Conhecimento". - Após M10 + mini projeto: selo "Construtora" e certificado do bloco.

Tela final do bloco: o mini projeto integrador como "missão de formatura", com os 8 entregáveis como sub-missões marcáveis e upload de evidências.

6. Sugestão de avaliação final para o bloco

Formato híbrido: 60% prática + 40% teórica.

Parte A — Avaliação teórica (40 pontos): 20 questões de múltipla escolha, 2 pontos cada, cobrindo: - 4 questões de fundamentos (M1–M2): ecossistema, tokens, alucinação, grounding. - 3 de escolha de modelo e contexto (M3–M4): cenários "qual modelo/qual técnica". - 5 de prompt engineering (M6): identificar o componente faltante, corrigir prompt falho. - 4 de Projects/documentos/RAG (M7–M9): Instructions × Knowledge, movimentos documentais, diagnóstico de miss. - 4 de Artifacts e segurança transversal (M5, M10): pipeline, higienização, limites. - Estilo das questões: sempre cenário realista de TI ("Você recebeu um PDF escaneado de 40 páginas e precisa..."), nunca decoreba de definição. - Aprovação: 28/40 (70%).

Parte B — Avaliação prática (60 pontos): o mini projeto integrador, avaliado por rubrica:

• Aprovação: 42/60 (70%), sem zerar nenhuma dimensão.

Parte C — Reflexão escrita (qualitativa, não pontuada): meia página respondendo "qual hábito de trabalho você mudou de verdade neste bloco, e que evidência você tem disso?" — o termômetro real de transferência para o dia a dia.

7. Pontos a revisar antes de avançar para os próximos 10 módulos

Autodiagnóstico honesto — volte ao módulo se marcar "não":

1. [M2/M4] Tokens e contexto: você consegue explicar, sem consultar, por que uma conversa longa degrada e o que fazer quando degrada? (Base para agentes e workflows longos do próximo bloco.)
2. [M6] Prompts como especificações: seus últimos 5 prompts reais tinham contexto, objetivo, formato e restrições? Abra o histórico e confira — a memória mente, o histórico não. (Tudo no próximo bloco é prompt engineering aplicado.)
3. [M7] Project vivo: você tem ao menos 1 Project em uso real há 1+ semana, com curadoria feita? (Os módulos de Service Desk, M365 e governança constroem sobre Projects existentes.)
4. [M8] Rastreabilidade no reflexo: você pede fonte/página automaticamente, sem pensar? (A análise de tickets e incidentes do próximo bloco depende disso.)
5. [M9] Diagnóstico de miss: você saberia consertar, em 3 passos, um "não achou" no seu Project? (Bases maiores vêm aí.)
6. [M10] Pipeline internalizado: seu último Artifact nasceu conteúdo-primeiro ou "tudo de uma vez"? (Materiais didáticos completos — Módulo 11 — são pipelines encadeados.)
7. [Transversal] Higienização inegociável: nas últimas 2 semanas, algum dado real escapou para um prompt, print ou Knowledge? Se sim, revise o ritual do M5 antes de seguir — o próximo bloco trabalha com tickets, logs e políticas, onde o risco multiplica.

O que vem no próximo bloco (Módulos 11–20): criação completa de materiais de estudo (M11), Claude aplicado ao Service Desk (M12), ao universo Microsoft 365/Entra/Intune (M13) e à segurança/governança (M14), connectors e MCP (M15), Claude Code (M16), agentes e workflows (M17), escrita profissional (M18), criação visual e diagramas (M19) e uso responsável (M20). Tudo construído sobre as fundações deste bloco — por isso a revisão acima importa: degrau firme, próximo degrau.

Recomendação de ritmo: 3–5 dias de consolidação (mini projeto + revisão dos pontos fracos) antes de iniciar o Módulo 11. Avançar com lacuna nos fundamentos custa mais caro depois.

Fim do Bloco 1 (Módulos 1–10). Recursos e limites de produto evoluem: valide detalhes em https://support.claude.com, https://docs.claude.com e https://www.anthropic.com/news.