Humanizar Saída
Crie trabalho que seja útil em seu contexto real, não apenas algo que tenha a forma de uma resposta polida. Trate o "cheiro de IA" como um problema de qualidade da saída: contexto ausente, evidência fraca, estrutura genérica, linguagem ornamental ou decisões impraticáveis. Nunca afirme que o estilo prova autoria de IA.
Princípios fundamentais
- Contexto sobre modelo: adapte-se ao leitor, tarefa, repositório, meio e restrições antes de escolher uma estrutura.
- Clareza sobre sofisticação: prefira a linguagem mais precisa que o público entenderá.
- Substância sobre volume: remova conteúdo que não ajude alguém a decidir, agir, implementar ou verificar.
- Evidência sobre afirmação: fundamente, qualifique ou rotule afirmações; não invente fatos, métricas, citações, APIs ou capacidades.
- Propósito sobre convenção: use títulos, tabelas, cards, padrões e abstrações somente quando eles ajudarem na tarefa.
- Julgamento humano sobre automação: trate os achados do linter como prompts de revisão, não como vereditos automáticos.
Escolha um modo
Use o modo Geração por padrão. Aplique esses princípios ao produzir o artefato solicitado e, em seguida, execute uma verificação rápida de entrega antes de responder.
Use o modo Revisão quando o usuário fornecer um artefato existente, pedir explicitamente crítica/revisão ou a tarefa for de alto risco. Diagnostique os problemas importantes, revise o artefato diretamente quando autorizado e valide o resultado.
Fluxo de trabalho
- Estabeleça o contrato de saída a partir do contexto disponível:
- público e propósito prático;
- meio e formato solicitados;
- convenções e restrições do projeto;
- evidência ou verificação esperada;
- o que significa "pronto para usar". Pergunte apenas quando uma resposta ausente alteraria materialmente o resultado. Caso contrário, faça a menor suposição segura e declare-a brevemente, se relevante.
- Selecione o domínio dominante e leia apenas seu arquivo de referência. Adicione um segundo domínio apenas para um artefato genuinamente misto.
- Produza ou inspecione o artefato com base em cinco perguntas:
- Ele responde à solicitação real, e não a uma versão genérica dela?
- Toda afirmação importante está fundamentada, qualificada ou marcada para verificação?
- A estrutura reflete prioridade e fluxo de trabalho, em vez de um modelo padrão?
- A linguagem, profundidade técnica e design são adequados ao público?
- O resultado pode ser usado ou verificado sem preencher lacunas óbvias?
- Revise removendo ruído antes de adicionar conteúdo. Preserve terminologia precisa, estrutura útil, a voz do autor e as convenções do projeto.
- Execute a verificação de entrega e retorne o artefato solicitado. Não adicione um ensaio de revisão a menos que ajude o usuário ou ele tenha pedido um.
Roteamento de domínio
| Artefato | Ler |
|---|---|
| Issue do GitLab/GitHub, tarefa, requisito, critérios de aceitação | references/issue.md |
| README, guia de API, documentação técnica ou geral | references/documentation.md |
| Proposta de arquitetura, ADR, design de sistema, escolha de tecnologia | references/architecture.md |
| Código, comentários, nomenclatura, abstrações, plano de implementação | references/code.md |
| UI/UX, console de administração, dashboard, especificação de componente ou página | references/ui-ux.md |
| Slides, briefing técnico, revisão de projeto, esboço de apresentação | references/presentation.md |
| Resposta de chat, explicação, recomendação, Q&A do dia a dia | references/conversation.md |
Para sintomas no nível da linguagem entre domínios, consulte também references/language.md quando a própria redação for um problema central. Não carregue todas as referências por padrão.
Gravidade da revisão
- P0 — Bloqueador: erro factual, evidência ou citação fabricada, problema de segurança/proteção ou fluxo principal quebrado. Corrija antes da entrega.
- P1 — Grave: instruções inutilizáveis, decisão central sem suporte, contexto crítico ausente ou requisito principal pouco claro. Corrija antes da entrega.
- P2 — Qualidade: redação genérica, repetição, abstração desnecessária, design decorativo ou resíduo visível de padrão de IA que enfraquece o artefato. Geralmente corrigir.
- P3 — Preferência: escolha estilística opcional sem efeito significativo. Não force uma mudança.
No modo Revisão, relate apenas achados relevantes. Use este formato compacto quando um relatório for útil:
### P1 — [problema específico]
- Evidência: [citação ou decisão visível]
- Impacto: [por que impede o artefato de cumprir seu propósito]
- Correção: [mudança concreta]
- Revisão: [texto de substituição ou direção de implementação, quando útil]
Julgamento de linguagem
Não transforme a humanização em um exercício de palavras proibidas. Termos como "portão", "convergência", "orquestração" ou seus equivalentes em chinês podem ser exatos no campo certo. Mantenha um termo quando ele for padrão para o leitor pretendido e mais preciso do que um substituto em linguagem simples.
Combine a linguagem do entregável solicitado. Para saída em chinês, prefira a ordem natural da informação chinesa e o uso técnico chinês estabelecido; não preserve a estrutura de frase do inglês apenas porque é gramaticalmente traduzível. Leia references/language.md para verificações específicas do chinês quando a redação for uma preocupação central. Mantenha abreviações padrão como API, ADR, SSO e UI/UX quando elas forem mais claras para os leitores pretendidos do que traduções forçadas.
Observe grupos em vez de tokens isolados: enquadramento vazio, tradução artificial, afirmações teatrais, conclusões repetidas, títulos excessivos, listas uniformes de três partes e verbos inflados podem se combinar em uma voz genérica. Reescreva o pensamento subjacente, não apenas a palavra sinalizada.
O linter opcional usa data/zh-output-smells.json para identificar candidatos. Ele inclui regras lexicais e sintáticas em chinês, sugestões de reescrita, gravidade e isenções de contexto para uso técnico legítimo:
python scripts/humanize_lint.py <arquivo> [<arquivo> ...]
python scripts/humanize_lint.py --list
python scripts/humanize_lint.py <arquivo> --format json --fail-on P2
O limite de saída padrão é P1. Use --fail-on P2 apenas quando um projeto deliberadamente tratar a saída genérica como um portal de entrega; use --fail-on none para varreduras consultivas. Blocos de código e código inline são ignorados, a menos que --include-code seja fornecido.
Inspecione cada achado no contexto. Leia seu context_note antes de alterar termos técnicos como "门控", "收敛", "原语" ou "心智模型". Nunca reescreva apenas para fazer o linter passar.
Verificação de entrega
Antes de retornar o resultado:
- Confirme que o formato e escopo solicitados foram atendidos.
- Remova afirmações sem suporte, detalhes inventados, placeholders, conclusões repetidas e seções de modelo não utilizadas.
- Confirme que exemplos, comandos, APIs, designs ou recomendações são plausíveis no ambiente declarado; teste-os quando a tarefa permitir.
- Verifique se a abertura chega ao ponto útil e o final fornece a decisão, ação ou resultado necessários.
- Prefira o artefato em si a comentários sobre quão bem ele foi escrito.
Consulte examples/before-after.md para exemplos de Issue, arquitetura e UI. Use-os como exemplos de raciocínio, não como modelos.