Aither (Português (BR))

Primeiros passos com Astro-Theme-Aither

Sat, 14 Mar 2026 08:00:00 GMT

Este guia leva você do zero até um blog multilíngue publicado. Leia tudo com calma ou pule direto para a seção que precisa agora. ## Pré-requisitos - [Node.js](https://nodejs.org/) 22 LTS ou superior - [pnpm](https://pnpm.io/) 10 ou superior - Uma conta no GitHub - Uma conta na [Cloudflare](https://cloudflare.com/) para deploy ## Instalação ```bash git clone https://github.com/YOUR_USERNAME/YOUR_REPO.git cd YOUR_REPO corepack enable pnpm install pnpm validate pnpm dev ``` Depois, abra `http://localhost:4321`. ## Estrutura do projeto ```text src/ ├── components/ # Componentes Astro e React ├── config/site.ts # Nome do site, navegação, rodapé e links sociais ├── content/posts/ # Posts organizados por locale ├── i18n/ # Traduções da interface ├── layouts/ # Layouts ├── lib/ # Utilitários ├── pages/ # Páginas e rotas └── styles/global.css # Tokens de tema do Tailwind v4 ``` ## Configuração ### Site Config `src/config/site.ts` é a fonte única de configuração do site: ```typescript export const siteConfig = { name: 'Nome do seu blog', title: 'Seu slogan', description: 'Sua descrição para SEO', author: { name: 'Seu nome', avatar: '', }, }; ``` ### Variáveis de ambiente ```bash cp .env.example .env ``` Se alguma variável ficar vazia, a integração correspondente será desativada automaticamente. ### URL do site Defina a URL de produção em `astro.config.mjs`: ```javascript import { defineConfig } from 'astro/config'; import aither from '@aither/astro'; export default defineConfig({ site: 'https://your-domain.pages.dev', integrations: [aither()], }); ``` ## Escrevendo posts Crie um arquivo `.mdx` em `src/content/posts/en/`: ```markdown --- title: Meu primeiro post date: "2026-03-14T16:00:00+08:00" category: General description: Um resumo curto para SEO e previews sociais. tags: [Topic, Another] pinned: false --- Seu conteúdo começa aqui. ``` ### Referência de frontmatter | Campo | Tipo | Obrigatório | Descrição | |------|------|-------------|-----------| | `title` | string | Sim | Título do post | | `date` | date | Sim | Data e hora de publicação (ex.: `2026-03-14T16:00:00+08:00`) | | `category` | string | Não | Categoria | | `description` | string | Não | Descrição SEO | | `tags` | string[] | Não | Lista de tags | | `pinned` | boolean | Não | Fixar no topo | | `image` | string | Não | Imagem de capa | ### Componentes MDX Você pode importar componentes diretamente dentro do conteúdo: ```mdx import MyChart from '@/components/MyChart' ``` ## Internacionalização O tema suporta 11 idiomas por padrão. Para adicionar uma tradução, crie o mesmo nome de arquivo na pasta da locale desejada: ```text src/content/posts/en/my-post.mdx src/content/posts/pt-br/my-post.mdx src/content/posts/zh-hans/my-post.mdx ``` Os textos de interface ficam em `src/i18n/messages/`. ## Seções de conteúdo personalizadas Você pode registrar coleções como traduções, notas ou tutoriais em `src/content.config.ts` e `src/config/site.ts`. As páginas de lista e detalhe serão geradas automaticamente. ## Temas O sistema funciona em duas camadas: - modo de cor: `light`, `dark`, `system` - estilo visual: `default` ou estilos integrados como `evolution` ```typescript ui: { defaultMode: 'system', defaultStyle: 'default', showMoreThemesMenu: true, }, ``` As cores ficam em `src/styles/global.css`. A fonte padrão é uma pilha sans-serif do sistema, com monospace para blocos de código. ## SEO e AI Cada página já expõe estas saídas: - `/sitemap-index.xml` - `/rss.xml` - `/robots.txt` - `/llms.txt` - `/llms-full.txt` - `/posts/slug.md` - JSON-LD e Open Graph ## Deploy ### Cloudflare Pages Boa prática: crie primeiro o projeto do Pages. O fluxo usa o nome do repositório por padrão, ou `CLOUDFLARE_PAGES_PROJECT_NAME` se você precisar sobrescrever. Configure estes secrets no GitHub: - `CLOUDFLARE_API_TOKEN` - `CLOUDFLARE_ACCOUNT_ID` Depois rode `pnpm validate` e faça push para `main`. ## Comandos úteis | Comando | Descrição | |--------|-----------| | `pnpm dev` | Inicia o servidor de desenvolvimento | | `pnpm validate` | Executa a validação completa antes do push | | `pnpm build` | Gera a build de produção | | `pnpm preview` | Faz prévia local da build | ## Esquema de versão As tags públicas de release seguem nomes no estilo CalVer, como `v2026.04.08`.

Boas práticas para agentes de IA em projetos reais (Exemplo)

Sat, 10 Jan 2026 08:00:00 GMT

Agentes de IA são mais úteis quando deixam de parecer mágicos e começam a agir como uma ferramenta operacional. As equipes que obtêm os melhores resultados não pedem para um agente "resolver tudo". Elas definem a tarefa, fornecem o contexto certo e fazem com que o resultado seja fácil de verificar. Parece simples, mas muda tudo. Um agente bem orientado pode avançar rápido e produzir um trabalho surpreendentemente sólido. Um agente com escopo mal definido desperdiça contexto, faz desvios desnecessários e devolve algo que soa confiante, mas não resolve a tarefa real. ## Comece com uma tarefa estreita As melhores tarefas para um agente são concretas e delimitadas. Em vez de dizer "melhore este app", diga "corrija a sobreposição da navegação mobile na página do blog" ou "adicione um teste rápido para o feed RSS". Uma tarefa estreita dá ao agente um alvo estável e reduz a chance de ele editar partes não relacionadas do sistema. Isso também facilita a revisão. Quando a tarefa é pequena, fica mais claro o que mudou, o que precisa ser testado e se o resultado está realmente correto. ## Torne o contexto explícito Agentes trabalham melhor quando o contexto importante está escrito, e não apenas implícito. Um bom briefing normalmente inclui: - o objetivo exato - os arquivos ou diretórios relevantes - as restrições e o que não pode mudar - o resultado esperado ou definição de pronto - o comando de validação a ser executado no final Pessoas conseguem inferir muita coisa a partir de instruções incompletas. Agentes são mais literais. Se um detalhe importa, escreva. ## Prefira ferramentas a adivinhação Um agente deve inspecionar o sistema atual antes de propor mudanças. Isso significa ler os arquivos relevantes, verificar a configuração de build e entender as convenções existentes, em vez de depender apenas de conhecimento genérico. O mesmo vale para sistemas externos. Se a resposta depende de documentação atual, configurações de implantação ou comportamento real, o agente deve usar ferramentas para verificar o estado verdadeiro, não chutar com base na memória. É por isso que interfaces legíveis por máquina importam tanto. Estrutura de arquivos clara, scripts de validação, esquemas tipados e configuração explícita tornam os agentes mais confiáveis porque o próprio ambiente se explica. ## Mantenha a saída verificável Um bom fluxo de trabalho com um agente não termina com "aqui está a resposta". Ele termina com evidência. Peça ao agente para informar o que mudou, o que foi testado e o que ele não conseguiu verificar. Prefira saídas que possam ser conferidas rapidamente: - um diff pequeno - um comando de validação aprovado - uma captura ou prévia reproduzível - uma nota curta sobre riscos ou suposições Verificação transforma um resultado plausível em um resultado confiável. ## Desenhe para recuperar rápido Mesmo bons agentes tomam caminhos errados. A resposta certa não é evitá-los, mas tornar a recuperação barata. Use tarefas pequenas, scripts estáveis e checkpoints. Mantenha operações idempotentes quando possível. Evite fluxos em que um único passo errado cria uma grande bagunça para desfazer. Se a tarefa puder ser dividida em ler, planejar, implementar e verificar, faça isso. Agentes performam melhor em sistemas fáceis de inspecionar, fáceis de testar e fáceis de seguir adiante. ## A revisão humana continua importante Agentes são excelentes em velocidade, cobertura e repetição. Humanos continuam responsáveis por julgamento. Trade-offs de produto, limites de segurança, tom, marca e manutenibilidade de longo prazo ainda devem ser revisados por alguém que entenda o contexto mais amplo. O objetivo não é tirar humanos do circuito. O objetivo é fazer com que eles gastem menos tempo com trabalho mecânico e mais tempo com decisões que realmente exigem critério e responsabilidade. ## Um modelo mental prático Trate um agente de IA como um operador capaz, rápido, incansável e literal. Dê uma tarefa clara. Dê as ferramentas certas. Peça para ele mostrar o trabalho. Depois revise o resultado com a mesma disciplina que você aplicaria a qualquer mudança importante. É aí que surge a verdadeira alavancagem.

Agentes de IA e Uso de Ferramentas (Exemplo)

Fri, 09 Jan 2026 08:00:00 GMT

Um agente de IA é um modelo de linguagem que pode tomar ações — não apenas gerar texto. Ele pode buscar na web, executar código, chamar APIs, ler arquivos e tomar decisões sobre o que fazer em seguida. Essa mudança da geração passiva de texto para a resolução ativa de problemas representa um dos desenvolvimentos mais significativos na IA aplicada. ## De Chat para Ação Um chatbot responde perguntas. Um agente resolve problemas. A diferença é autonomia: agentes decidem quais ferramentas usar, em que ordem e como lidar com erros. Considere a diferença na prática. Você pergunta a um chatbot: "Como está o clima em Tóquio?" Ele pode responder com base em seus dados de treinamento — que têm meses ou anos e quase certamente estão errados. Você faz a mesma pergunta a um agente, e ele chama uma API de clima, recupera os dados atuais e retorna uma resposta precisa e atualizada. O chatbot gera texto plausível. O agente interage com o mundo. ### O Espectro da Autonomia Nem todos os agentes são igualmente autônomos. Existe um espectro: 1. **Chat assistido por ferramentas** — o modelo pode chamar ferramentas, mas apenas em resposta direta às solicitações do usuário. Uma chamada de ferramenta por turno. 2. **Agentes multi-etapas** — o modelo pode encadear múltiplas chamadas de ferramentas para realizar uma tarefa, decidindo a sequência por conta própria. 3. **Agentes totalmente autônomos** — o modelo opera independentemente por períodos prolongados, tomando decisões, lidando com erros e perseguindo objetivos com supervisão humana mínima. A maioria dos sistemas em produção hoje está nos níveis 1-2. Agentes totalmente autônomos são uma área ativa de pesquisa com desafios significativos de segurança ainda a resolver. ## Uso de Ferramentas Tool use permite que um modelo de IA chame funções externas. O modelo decide quando uma ferramenta é necessária, gera os parâmetros corretos e incorpora o resultado em sua resposta. Isso transforma um gerador de texto em um assistente capaz. ### Como Funciona o Tool Use A mecânica é direta: 1. **Definição da ferramenta** — você descreve as ferramentas disponíveis para o modelo, incluindo seus nomes, parâmetros e o que fazem. Isso é tipicamente fornecido como JSON estruturado no prompt do sistema ou via um campo de API dedicado. 2. **Decisão** — ao processar uma solicitação do usuário, o modelo decide se uma ferramenta seria útil. Se sim, gera uma chamada de ferramenta com os parâmetros apropriados. 3. **Execução** — sua aplicação executa a chamada da ferramenta (o modelo não a executa diretamente) e retorna o resultado. 4. **Integração** — o modelo incorpora o resultado da ferramenta em sua resposta ao usuário. ### Exemplo de Definição de Ferramenta ```json { "name": "search_documentation", "description": "Search the product documentation for relevant articles", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "The search query" }, "max_results": { "type": "integer", "description": "Maximum number of results to return", "default": 5 } }, "required": ["query"] } } ``` O modelo vê essa definição e sabe que pode pesquisar na documentação. Quando um usuário faz uma pergunta sobre o produto, o modelo gera uma chamada como `search_documentation(query="how to reset password")`, seu sistema executa a busca, e o modelo usa os resultados para compor uma resposta precisa. ### Categorias Comuns de Ferramentas Sistemas de agentes em produção tipicamente oferecem ferramentas em várias categorias: - **Recuperação de informações** — busca web, consultas a banco de dados, leitura de arquivos, chamadas de API - **Execução de código** — executar Python, JavaScript ou comandos shell em um ambiente sandboxed - **Comunicação** — enviar emails, postar mensagens, criar tickets - **Manipulação de arquivos** — criar, editar e organizar arquivos - **Operações de sistema** — deploy de código, gerenciamento de infraestrutura, execução de pipelines CI As ferramentas que você fornece definem os limites do que o agente pode fazer. Um conjunto de ferramentas bem projetado dá ao agente capacidade suficiente para ser útil sem poder suficiente para ser perigoso. ## Loops Agênticos O padrão mais poderoso é o loop agêntico: o modelo planeja um passo, executa, observa o resultado e decide o próximo passo. Esse loop continua até que a tarefa seja concluída ou o modelo determine que não pode prosseguir. ### O Loop na Prática Considere um agente encarregado de debugar um teste falhando: 1. **Planejar** — "Devo primeiro ler o arquivo de teste para entender o que ele está testando" 2. **Executar** — chama `read_file("tests/auth.test.ts")` 3. **Observar** — vê que o teste espera um status 200 mas recebe 401 4. **Planejar** — "Devo verificar o middleware de autenticação para ver o que está retornando 401" 5. **Executar** — chama `read_file("src/middleware/auth.ts")` 6. **Observar** — encontra um bug na verificação de expiração do token 7. **Planejar** — "Devo corrigir a comparação de expiração" 8. **Executar** — chama `edit_file(...)` com a correção 9. **Observar** — confirma que a edição foi feita 10. **Planejar** — "Devo executar o teste para verificar a correção" 11. **Executar** — chama `run_command("pnpm test tests/auth.test.ts")` 12. **Observar** — teste passa 13. **Concluído** — reporta a correção ao usuário Cada passo envolve o modelo raciocinando sobre o estado atual, decidindo o que fazer em seguida e se adaptando com base no que descobre. Isso é fundamentalmente diferente de um script linear — o agente lida com descobertas inesperadas e muda de curso quando necessário. ### Lidando com Erros no Loop Agentes robustos devem lidar com falhas graciosamente. Uma ferramenta pode retornar um erro, um arquivo pode não existir, ou uma API pode estar com rate limit. Um bom design de agente inclui: - **Lógica de retry** — retentar falhas transitórias com backoff - **Estratégias alternativas** — se uma abordagem falha, tentar outra - **Degradação graciosa** — se a tarefa não pode ser completamente realizada, completar o máximo possível e explicar o que resta - **Limites de loop** — definir um número máximo de iterações para prevenir loops infinitos quando o agente fica travado ## Projetando Ferramentas Eficazes A qualidade de um sistema de agentes depende fortemente da qualidade de suas ferramentas. Ferramentas mal projetadas levam a agentes confusos e resultados incorretos. ### Princípios de Design de Ferramentas - **Nomes claros** — `search_users` é melhor que `query_db_1`. O modelo usa o nome para decidir quando chamar a ferramenta. - **Parâmetros descritivos** — inclua descrições para cada parâmetro. O modelo lê essas descrições para determinar quais valores passar. - **Escopo focado** — cada ferramenta deve fazer uma coisa bem. Uma ferramenta `read_file` e uma ferramenta `write_file` são melhores que uma ferramenta `file_operations` com um parâmetro de modo. - **Erros úteis** — retorne mensagens de erro claras que ajudem o modelo a entender o que deu errado e o que tentar em seguida. - **Idempotentes quando possível** — ferramentas que podem ser retentadas com segurança simplificam o tratamento de erros. ## Riscos Agentes que podem tomar ações podem tomar ações erradas. Sandboxing, passos de confirmação e revisão humana são medidas de segurança essenciais para qualquer sistema de agentes em produção. ### Categorias de Risco - **Ações destrutivas** — um agente com acesso ao sistema de arquivos poderia deletar arquivos importantes. Um agente com acesso ao banco de dados poderia dropar tabelas. Ambientes sandbox e limites de permissão são essenciais. - **Exfiltração de dados** — um agente que pode tanto ler dados sensíveis quanto fazer requisições de rede poderia inadvertidamente (ou por injeção de prompt) vazar informações. - **Custos descontrolados** — um agente em loop chamando APIs caras pode acumular custos significativos rapidamente. Limites de orçamento e rate limiting são necessidades práticas. - **Ações incorretas executadas com confiança** — o agente pode entender mal uma solicitação e tomar uma ação irreversível. Para operações de alto risco, sempre exija confirmação humana. ### Padrões de Segurança Sistemas de agentes em produção devem implementar vários padrões de segurança: 1. **Privilégio mínimo** — dê ao agente apenas as ferramentas necessárias para sua tarefa específica, nada mais 2. **Sandboxing** — execute código e operações de arquivo em ambientes isolados 3. **Portões de confirmação** — exija aprovação humana para ações destrutivas ou irreversíveis 4. **Log de auditoria** — registre cada chamada de ferramenta e seu resultado para revisão 5. **Kill switches** — forneça mecanismos para parar imediatamente um agente em execução 6. **Limites de orçamento** — defina limites rígidos para chamadas de API, uso de tokens e tempo de computação O objetivo não é impedir os agentes de serem úteis — é garantir que sejam úteis dentro de limites bem definidos.

✨ Por que Astro-Theme-Aither

Sat, 03 Jan 2026 08:00:00 GMT

Um tema Astro AI-nativo que acredita que o texto por si só é bonito. Astro-Theme-Aither é construído para leitores que vêm pelas palavras, não pela decoração. ## Filosofia de Design A maioria dos temas de blog compete por atenção com imagens de destaque, animações, barras laterais e pop-ups. Nada disso ajuda na leitura — ajuda na visualização, que é uma atividade completamente diferente. Astro-Theme-Aither adota a abordagem oposta: design mínimo, não engenharia mínima. Quando não há visuais chamativos para distrair dos problemas, cada falha tipográfica e cada atraso de carregamento é amplificado. Design mínimo exige qualidade de engenharia mais alta. ## Tipografia Parâmetros tipográficos seguem as Apple Human Interface Guidelines: - **Tamanho de fonte** — base 17px - **Altura de linha** — 1.47 - **Espaçamento entre letras** — -0.022em - **Escala de títulos** — 31px → 22px → 19px → 17px - **Largura de leitura** — limitada a 65–75 caracteres por linha ## Construído sobre Astro Astro gera HTML estático por padrão. A arquitetura de islands significa que componentes interativos hidratam independentemente enquanto o resto da página permanece estático. ## Recursos - **Tailwind CSS v4** — tokens de design `@theme` - **Tipografia Apple HIG** - **View Transitions API** — animação circular reveal para troca de tema - **i18n** — suporte multilíngue com detecção automática de idioma do navegador - **Fixação de posts** — fixe posts importantes no topo - **Content Collections** — Markdown type-safe - **Modo escuro** — Claro / Escuro / Sistema - **SEO** — Open Graph, URLs canônicas - **RSS + Sitemap** — auto-gerados - **Google Analytics** — opcional, em Partytown Web Worker - **Testes** — Vitest + Playwright - **Cloudflare Pages** — fluxo de implantação com prévias de PR ## Para Quem É - **Blogueiros pessoais** que querem sua escrita em primeiro plano - **Escritores técnicos** que precisam de boa renderização de blocos de código - **Autores multilíngues** que precisam de i18n embutido - **Desenvolvedores** que apreciam uma codebase bem engenheirada Escreva sobre qualquer coisa — a tipografia vai fazer parecer bonito.

📝 Guia de Estilo Markdown

Fri, 02 Jan 2026 08:00:00 GMT

Este post demonstra cada recurso Markdown suportado pelo Astro-Theme-Aither. Use como referência ao escrever seus próprios posts. Adicione esta página aos favoritos — ela cobre toda a gama de opções de formatação disponíveis. ## Títulos Use `##` para títulos de seção, `###` para subseções e `####` para sub-subseções. Evite `#` no conteúdo do post — o título do post já é renderizado como título de nível superior. ### Título de Terceiro Nível Títulos de terceiro nível são ideais para dividir uma seção em tópicos distintos. Eles criam hierarquia visual sem serem muito proeminentes. #### Título de Quarto Nível Títulos de quarto nível funcionam para subseções detalhadas. Use-os com moderação — se seu esboço vai além de quatro níveis, considere reestruturar seu conteúdo. ### Práticas Recomendadas para Títulos Algumas diretrizes para uso eficaz de títulos: - **Não pule níveis** — vá de `##` para `###`, nunca de `##` direto para `####`. Pular níveis quebra a estrutura do documento e pode confundir leitores de tela. - **Use títulos descritivos** — "Configuração" é melhor que "Coisas de Setup". Leitores escaneiam títulos antes de decidir se leem uma seção. - **Use sentence case** — capitalize apenas a primeira palavra e nomes próprios. ## Parágrafos e Quebras de Linha Texto de parágrafo flui naturalmente. Deixe uma linha em branco entre parágrafos para separá-los. Este é um segundo parágrafo. Mantenha parágrafos focados em uma ideia para a melhor experiência de leitura. Ao escrever para a web, parágrafos mais curtos tendem a funcionar melhor que longos blocos de texto. Um parágrafo de três a cinco frases é uma unidade de leitura confortável em telas. Se um parágrafo ultrapassa seis ou sete frases, considere dividi-lo. Quebras de linha simples dentro de um parágrafo (sem linha em branco) serão tratadas como espaço, não como nova linha. Se precisar de uma quebra de linha forçada sem iniciar novo parágrafo, termine a linha com dois espaços ou use uma tag `
` — embora isso raramente seja necessário na prática. ## Ênfase - **Texto em negrito** com `**asteriscos duplos**` - *Texto em itálico* com `*asteriscos simples*` - ***Negrito e itálico*** com `***asteriscos triplos***` - ~~Riscado~~ com `~~tils duplos~~` ### Quando Usar Cada Estilo **Negrito** funciona melhor para termos-chave, avisos importantes ou definições — qualquer coisa que o leitor não deve perder mesmo ao escanear. Use para a frase mais importante de um parágrafo, não para frases inteiras. *Itálico* serve para ênfase dentro de uma frase, títulos de livros e publicações, termos técnicos na primeira utilização e expressões estrangeiras. Fornece uma ênfase mais leve que o negrito. ~~Riscado~~ é útil para mostrar correções, informações obsoletas ou itens concluídos em um changelog. Tem um conjunto mais restrito de usos, mas é valioso quando necessário. ## Links [Link inline](https://astro.build) com sintaxe `[texto](url)`. Links também podem referenciar outros posts em seu site usando caminhos relativos. Use texto de link descritivo — "leia o guia Markdown" é melhor que "clique aqui". Bom texto de link ajuda tanto leitores quanto mecanismos de busca a entender para onde o link leva. Você também pode criar links que se leem naturalmente dentro da frase. Por exemplo: a [documentação do Astro](https://docs.astro.build) cobre cada recurso em detalhe. ## Listas Lista não ordenada: - Primeiro item - Segundo item - Item aninhado - Outro item aninhado - Terceiro item Lista ordenada: 1. Primeiro passo 2. Segundo passo 1. Sub-passo um 2. Sub-passo dois 3. Terceiro passo Lista de tarefas: - [x] Configurar o projeto - [x] Escrever o primeiro post - [ ] Deploy para produção ### Dicas de Formatação de Listas Listas são uma das ferramentas mais eficazes na escrita web. Elas quebram texto denso, tornam informações escaneáveis e comunicam claramente sequências ou coleções de itens. **Use listas não ordenadas** quando os itens não têm sequência inerente — recursos, requisitos, opções ou exemplos. **Use listas ordenadas** quando a sequência importa — passos em um processo, itens ranqueados ou instruções que devem ser seguidas em ordem. **Use listas de tarefas** para acompanhar progresso, checklists de projeto ou itens de tarefas. Mantenha itens de lista paralelos em estrutura. Se o primeiro item começa com um verbo, todos os itens devem começar com um verbo. ## Citações > O propósito da abstração não é ser vago, mas criar um novo nível semântico no qual se pode ser absolutamente preciso. > > — Edsger W. Dijkstra Citações aninhadas: > Primeiro nível > > > Segundo nível > > > > > Terceiro nível ### Uso de Citações Citações servem a vários propósitos além de citar pessoas famosas: - **Citar fontes** — ao referenciar outro artigo, livro ou documento - **Destaques** — destacar informações importantes ou avisos - **Estilo email** — mostrar o que alguém disse em uma conversa à qual você está respondendo - **Pull quotes** — chamar atenção para uma passagem-chave do seu próprio artigo Ao usar citações com atribuição, coloque o nome do autor em uma linha separada precedida por um travessão, como mostrado no exemplo de Dijkstra acima. ## Código `Código` inline com crases. Use código inline para nomes de funções como `getPublishedPosts()`, caminhos de arquivo como `src/content/posts/`, instruções de linha de comando como `pnpm dev` e quaisquer valores literais que apareçam no texto corrido. Bloco de código com destaque de sintaxe: ```typescript interface Post { title: string; date: Date; description?: string; tags?: string[]; draft?: boolean; } function getPublishedPosts(posts: Post[]): Post[] { return posts .filter((post) => !post.draft) .sort((a, b) => b.date.getTime() - a.date.getTime()); } ``` ```css @theme { --font-sans: 'system-ui', sans-serif; --font-serif: 'ui-serif', 'Georgia', serif; } ``` ### Dicas para Blocos de Código Sempre especifique o identificador de linguagem após as crases triplas de abertura. Isso ativa o destaque de sintaxe, que melhora drasticamente a legibilidade. Identificadores comuns incluem `typescript`, `javascript`, `css`, `html`, `bash`, `json`, `python` e `markdown`. Para comandos shell, use `bash` ou `sh`: ```bash # Instalar dependências pnpm install # Iniciar o servidor de desenvolvimento pnpm dev # Compilar para produção pnpm build ``` Para arquivos de configuração JSON: ```json { "name": "my-blog", "version": "1.0.0", "scripts": { "dev": "astro dev", "build": "astro build" } } ``` Mantenha blocos de código focados. Mostre apenas as linhas relevantes em vez de colar um arquivo inteiro. Se contexto for necessário, adicione um comentário indicando onde o código está. ## Tabelas | Recurso | Status | Notas | |---|---|---| | Modo escuro | Suportado | Claro / Escuro / Sistema | | Feed RSS | Embutido | `/rss.xml` | | Sitemap | Auto-gerado | Via `@astrojs/sitemap` | | SEO | Embutido | Open Graph + URLs canônicas | Colunas alinhadas à direita e centralizadas: | Esquerda | Centro | Direita | |:---|:---:|---:| | Texto | Texto | Texto | | Texto mais longo | Texto mais longo | Texto mais longo | ### Diretrizes para Tabelas Tabelas funcionam melhor para dados estruturados com colunas e linhas claras. São ideais para comparações de recursos, opções de configuração, parâmetros de API e dados de referência. Mantenha tabelas simples. Se uma tabela tem mais de cinco ou seis colunas, fica difícil de ler em dispositivos móveis. Considere dividir tabelas complexas em várias menores, ou use formato de lista. O alinhamento de colunas é controlado com dois-pontos na linha separadora: - `:---` para alinhamento à esquerda (padrão) - `:---:` para centralização - `---:` para alinhamento à direita Use alinhamento à direita para dados numéricos para que pontos decimais se alinhem visualmente. ## Linha Horizontal Use `---` para criar uma linha horizontal: --- Conteúdo após a linha. Linhas horizontais são úteis para separar seções principais de um post, indicar mudança de tópico ou quebrar visualmente artigos muito longos. Use-as com parcimônia — se precisar de separadores frequentes, títulos podem ser uma escolha estrutural melhor. ## Imagens Imagens são suportadas com sintaxe Markdown padrão: ```markdown ![Texto alternativo](./image.jpg) ``` Este tema é focado em tipografia, mas imagens funcionam quando você precisa delas. ### Práticas Recomendadas para Imagens - **Sempre inclua texto alternativo** — é essencial para acessibilidade e também aparece quando imagens falham ao carregar - **Use nomes de arquivo descritivos** — `dashboard-error-state.png` é melhor que `screenshot-2.png` - **Otimize tamanhos de arquivo** — comprima imagens antes de adicioná-las ao seu repositório; imagens grandes desaceleram o carregamento das páginas - **Considere o fluxo de leitura** — posicione imagens perto do texto que as referencia, não a parágrafos de distância ## Conclusão Os recursos Markdown descritos neste guia cobrem a grande maioria do que você precisará para escrever em blog. A chave para um bom Markdown é usar o elemento certo para o propósito certo: títulos para estrutura, ênfase para importância, listas para coleções, blocos de código para conteúdo técnico e parágrafos para todo o resto. Escreva com clareza, formate com consistência e deixe a tipografia fazer seu trabalho.

👋 Olá Mundo

Thu, 01 Jan 2026 08:00:00 GMT

Bem-vindo ao Astro-Theme-Aither. Este é um tema para blog construído sobre uma crença: boa escrita merece boa tipografia. Fontes sans-serif, um ritmo de leitura limpo e uma estrutura de página que não atrapalha. Tudo aqui serve a um único objetivo — fazer suas palavras parecerem e se sentirem bonitas. ## Por que Outro Tema para Blog A web está cheia de temas para blog, então uma pergunta justa é: por que construir outro? A resposta está nas prioridades. A maioria dos temas otimiza para impacto visual — imagens de destaque grandes, estruturas de página complexas e transições animadas. Isso impressiona em demonstrações, mas atrapalha quando alguém realmente senta para ler um artigo de 2.000 palavras. Astro-Theme-Aither parte de uma premissa diferente. O conteúdo é o produto. O trabalho do tema é apresentar esse conteúdo com o cuidado que ele merece. ## Começando 1. **Clone o repositório** — use o botão de template do GitHub ou clone diretamente com `git clone` 2. **Instale dependências** — execute `pnpm install` 3. **Configure seu site** — edite `src/config/site.ts` 4. **Substitua o conteúdo de exemplo** — troque os posts em `src/content/posts/` 5. **Comece a desenvolver** — execute `pnpm dev` 6. **Publique** — faça push para o GitHub e deixe o fluxo de CI cuidar do deploy no Cloudflare Pages ### Estrutura do Projeto ``` src/ ├── components/ # Componentes Astro reutilizáveis ├── config/ # Configuração do site ├── content/ # Seus posts Markdown e conteúdo ├── layouts/ # Layouts de página (Layout.astro) ├── pages/ # Páginas de rotas └── styles/ # CSS global com tokens Tailwind v4 ``` ### Escrevendo Seu Primeiro Post Crie um novo arquivo `.md` em `src/content/posts/` com o seguinte frontmatter: ```markdown --- title: Título do Seu Post date: "2026-01-15T16:00:00+08:00" category: General description: Um breve resumo para SEO e prévias sociais tags: [Tema, Outro] --- Seu conteúdo começa aqui. ``` ## O Que Você Recebe ### Recursos de Conteúdo - **Feed RSS** — gerado automaticamente em `/rss.xml` - **Sitemap** — auto-gerado via `@astrojs/sitemap` - **Meta tags SEO** — Open Graph, Twitter cards e URLs canônicas - **Modo escuro** — toggle de três vias (Claro / Escuro / Sistema) com persistência `localStorage` ### Recursos para Desenvolvedores - **TypeScript** — modo strict, componentes e utilitários totalmente tipados - **Content Collections** — Markdown type-safe com validação de frontmatter - **Tailwind CSS v4** — tokens de design `@theme` - **Vitest + Playwright** — testes unitários e E2E integrados ao CI - **Cloudflare Pages** — fluxo de implantação com URLs de prévia de PR ### Performance Como o tema gera HTML estático com JavaScript mínimo, a performance é excelente por padrão. Espere pontuações Lighthouse de 100 em todas as categorias. ## Nota sobre Filosofia de Design A simplicidade visual deste tema é intencional, mas não é o mesmo que simplicidade de engenharia. Sob o capô, o tema lida com uma quantidade surpreendente de preocupações: escalas tipográficas responsivas, contraste de cores acessível, estrutura HTML semântica e atenção cuidadosa à experiência de leitura em todas as telas. Bom design é invisível. Quando você lê um artigo neste tema e simplesmente aprecia a escrita — o design está funcionando exatamente como planejado. Boa escrita.