As linhas importantes escreves tu

O que é e porque importa

Se fazes a tua app com o Claude e não percebes o código, no dia em que se estraga ficas bloqueado. Não sabes onde procurar e pedes para corrigir uma coisa que nem sabes descrever. Quanto mais a app cresce, mais isto pesa.

O Claude Code já traz uma resposta lá dentro: os estilos de saída. Um estilo é um conjunto de instruções que muda a forma como o Claude te responde durante toda a sessão. Além do básico, chamado Default, inclui quatro: Proactive, Concise, Explanatory e Learning. O Learning é o pensado para aprender.

Com o Learning, o trabalho de rotina continua a ser ele a fazer. Mas quando chega a uma parte com uma decisão a sério, deixa-te escrever umas linhas e, entretanto, explica-te as escolhas dele. Acabas a app na mesma, mas algumas linhas-chave foste tu que as escreveste. É para quem constrói sozinho com o Claude e quer perceber o seu código o suficiente para o corrigir.

1. Como se liga

Há um caminho para cada sítio onde usas o Claude Code. O comando e os dois menus guardam a tua escolha no ficheiro .claude/settings.local.json do projeto: vale só nesse projeto, e só para ti.

1. No terminal: escreve /output-style learning. O comando ignora maiúsculas e minúsculas. Se escreveres só /output-style, mostra-te os estilos e marca o que está ativo.
2. Também no terminal, com o menu: escreve /config e escolhe Output style.
3. Na extensão do VS Code: escreve / na caixa de mensagens e escolhe Output styles.
4. Na app de computador: aqui o /config abre as definições da app, não o menu. Escreve tu o campo outputStyle no ficheiro .claude/settings.local.json do projeto, como aqui em baixo, e depois abre uma sessão nova.

{
  "outputStyle": "Learning"
}

No ficheiro, a maiúscula conta: escreve-se Learning, não learning. Um nome mal escrito não dá erro: deixa-te no estilo Default sem avisar. Se o ficheiro já tiver outras definições, acrescenta só a linha outputStyle dentro das chavetas que já lá estão.

Se quiseres o Learning em todos os projetos, põe o mesmo campo no ficheiro do teu utilizador, ~/.claude/settings.json. Mas as definições de um projeto ganham às do utilizador: se um projeto tiver o seu próprio outputStyle, é esse que vale lá.

Se mudares de estilo a meio da sessão, na versão mais recente do Claude Code o novo estilo vale a partir da tua mensagem seguinte: não é preciso recomeçar.

2. O que acontece enquanto trabalha

Dás-lhe uma tarefa como de costume. A partir daí, é assim:

1. O trabalho de rotina é ele que faz: os ficheiros a criar, as ligações, as partes que só se escrevem de uma maneira.
2. Quando chega a uma parte com uma decisão a sério, para. A documentação dá três exemplos: como tratar um erro, como organizar os dados, uma regra da tua app que se pode escrever de mais de uma forma correta.
3. No ficheiro, no sítio exato, deixa um comentário de marcação: a palavra inglesa para «por fazer» seguida de (human), ou seja, «pessoa». Para o encontrares, procura (human) no ficheiro.
4. Envia-te um pedido Learn by Doing em três partes: Context, o que já está feito; Your Task, o que tens de escrever e onde; Guidance, em que pensar enquanto escreves.
5. Depois para e espera. Tu escreves essas poucas linhas no lugar da marcação e dizes-lhe que acabaste.
6. Lê o teu código, responde com um quadro Insight sobre o que escreveste e retoma o trabalho.

Entretanto, antes ou depois do código que escreve, acrescenta quadros Insight: dois ou três pontos sobre o porquê das escolhas dele, ligados ao teu projeto. Ficam na conversa: não acabam nos teus ficheiros como comentários.

Uma coisa a saber já: um estilo é uma instrução, não uma garantia. É o Claude que decide que partes te deixa, e numa tarefa sem decisões a sério pode não te deixar nada. Se quiseres uma parte específica, pede-lha: é a secção seguinte.

3. Usa-o numa funcionalidade a sério

Rende mais numa funcionalidade de que precisas mesmo do que num exercício. As linhas a guardar para ti são as regras da tua app: são as que vais mudar quando a ideia mudar, e as primeiras que vais ver quando algo não bate certo. Escreve-lhe assim:

Estou a acrescentar [a funcionalidade, por exemplo: no máximo 3 projetos para quem usa a versão grátis]. Escreve tu a parte de rotina: ficheiros, ligações, interface. As regras da minha app, ou seja, o que acontece em cada caso e como tratar os erros, deixa-mas a mim com a marcação (human), uma de cada vez. Para cada uma diz-me em que ficheiro está, o que recebo e o que tenho de devolver.

Quando tiveres escrito as tuas linhas:

Acabei a marcação (human) em [nome do ficheiro]. Lê o meu código e diz-me se há algum caso que não trato, sem o reescreveres tu. Depois continua.

4. Quando estás bloqueado, pede uma pista

Às vezes olhas para a marcação e não sabes por onde começar. Não lhe peças logo a solução: se a leres já feita, da próxima vez estás outra vez no mesmo sítio. Pede-lhe uma pista:

Estou bloqueado na marcação (human) em [nome do ficheiro]. Não escrevas o código. Dá-me só uma pista: a primeira coisa a verificar ou a pergunta que tenho de fazer a mim mesmo. Se depois de duas pistas continuar parado, mostra-me um exemplo parecido, mas não igual.

Se não for mesmo o momento, podes sempre dizer-lhe para escrever ele essa parte. Mas experimenta antes as pistas: é aí que o código passa a ser teu.

5. Quando tens pressa, volta ao Default

O Learning abranda-te, e é assim que deve ser. As respostas são mais longas do que no Default por natureza do estilo, por isso gastas mais tokens de saída. Quando só precisas de despachar uma coisa, volta ao estilo básico:

/output-style default

O Default está na lista com os outros estilos, por isso também o encontras no /config e no menu do VS Code. Na app de computador, tira a linha outputStyle do ficheiro. Quando voltares a ter tempo, volta a pôr o Learning.

6. Se só queres as explicações: Explanatory

Se não te apetece escrever código mas queres perceber o que se passa, há o Explanatory. Faz o trabalho como o Default e acrescenta os mesmos quadros Insight, com o porquê das escolhas dele. Não te deixa nada para escrever e não para à tua espera.

Ativa-se da mesma forma: /output-style explanatory no terminal, ou Explanatory no ficheiro, com o E maiúsculo. Também aqui as respostas são mais longas do que no Default, por isso mais tokens. O Explanatory serve quando entras num código que não conheces; o Learning, quando escreves uma funcionalidade que vais ter de manter tu.

Os erros mais comuns

• Escrever learning em minúsculas no ficheiro. No ficheiro vai Learning: com um nome errado ficas no Default e nada te avisa.
• Esperar uma marcação (human) em cada resposta. É o Claude que decide que partes te deixa: se quiseres uma, pede-a.
• Deixá-lo ligado quando tens pressa. As respostas longas gastam mais tokens: volta ao Default e liga-o outra vez depois.
• Pôr o Learning em ~/.claude/settings.json e não perceber porque é que num projeto não arranca. As definições do projeto ganham: vê se lá há outro outputStyle.
• Criar à mão o .claude/settings.local.json e acabar por o pôr no git. Quando é o Claude Code a criá-lo, deixa-o fora do git sozinho; se o criares tu, acrescenta-o ao .gitignore.

Checklist

• O Learning está ligado no projeto em que estou a trabalhar
• Se o pus no ficheiro, está escrito Learning com o L maiúsculo
• Pedi-lhe para me deixar as regras da minha app com a marcação (human)
• Escrevi as minhas linhas e disse-lhe que tinha acabado
• Li o Insight sobre o meu código
• Sei como voltar ao Default quando tenho pressa

Perguntas frequentes