Plataforma
Inspect-to-prompt para a entrega séria de software com IA
Clique em qualquer elemento na app em execução para o referenciar no seu próximo pedido — para que a alteração chegue à coisa que apontou, não à coisa que a IA adivinhou.
O inspect-to-prompt é uma funcionalidade do Ciao Builder que lhe permite clicar em qualquer elemento na pré-visualização ao vivo — um botão, tabela, gráfico ou campo de formulário — e referenciá-lo diretamente no seu próximo pedido. Ao contrário de descrever a interface por palavras e esperar que a IA conte os mesmos cartões que você, o inspect-to-prompt torna o alvo inequívoco, para que as edições cheguem delimitadas ao componente selecionado com um diff pequeno e revisível.
Publicado 2026-07-03 · Última atualização 2026-07-03
A maioria dos pedidos falhados são moradas erradas, não ideias erradas
"Torna o terceiro cartão mais pequeno" funciona até a IA contar cartões diferentes de si. Descrever uma interface de utilizador por palavras é um exercício com perdas: o seu "cabeçalho", o "cabeçalho" do modelo e o "cabeçalho" do código podem ser três coisas diferentes. A ambiguidade entra, a edição errada sai, e passa os três pedidos seguintes a desfazer danos em elementos que nunca mencionou.
O inspect-to-prompt remove o problema de endereçamento. A app corre ao vivo ao lado do chat enquanto é construída; clique em qualquer elemento nessa pré-visualização e ele é referenciado no seu próximo pedido. O Builder sabe exatamente a que componente se refere — sem contar, sem descrever, sem negociação de vocabulário.
É uma pequena interação com consequências desproporcionadas. O Builder emparelha uma conversa com uma aplicação em execução precisamente para que apontar seja possível — a pré-visualização não é um painel de demonstração, é um quadro de referência partilhado entre si e a IA.
Como funciona o inspect-to-prompt
O ciclo demora segundos, e é o mesmo para um fundador a polir uma landing page e um engenheiro a ajustar uma tabela de administração.
1. Abra a pré-visualização ao vivo
A aplicação corre ao lado da conversa à medida que é construída — componentes reais, estruturas de dados reais, cliques reais.
2. Clique no elemento que quer dizer
Um botão, uma coluna de tabela, um gráfico, um campo de formulário, um rótulo perdido. A seleção funciona na app em execução, não numa captura de ecrã.
3. Torna-se parte do seu próximo pedido
O elemento selecionado é referenciado diretamente no pedido, para que o Builder o resolva no componente exato no código.
4. Descreva a alteração em linguagem simples
"Torna isto um dropdown", "move isto para cima do resumo", "isto só deve aparecer para administradores." O quê mantém-se natural; o onde já está resolvido.
5. A edição chega delimitada
A alteração visa o componente selecionado, produzindo um diff pequeno num branch git real em vez de uma reescrita especulativa.
6. Verifique no local
A pré-visualização atualiza-se ao lado do chat. Se ainda não estiver certo, clique de novo — o desfazer e os checkpoints tornam a iteração barata.
Porque é que isto importa
A precisão acumula-se. Quando as edições chegam onde apontou, as iterações diminuem, os diffs encolhem, e a revisão torna-se mais fácil — um revisor a confirmar "o botão selecionado mudou" trabalha mais depressa do que um a auditar uma reescrita. Alterações pequenas e delimitadas são também exatamente aquilo em que o Guardrails e o QA são melhores a controlar.
Também alarga quem pode dirigir o trabalho. Um fundador, designer ou cliente não precisa de vocabulário de CSS para dizer o que quer dizer — apontam para a app em execução. O fosso entre "pessoa que vê o problema" e "pessoa que consegue exprimir a correção" fecha-se a um clique.
As equipas sentem a diferença mais durante as rondas de feedback. Uma chamada de revisão onde as alterações pedidas chegam enquanto as pessoas observam é uma relação de produto diferente de uma chamada que produz uma lista de tickets para a semana seguinte.
Quem usa o inspect-to-prompt
Qualquer pessoa que consiga ver o problema pode agora endereçá-lo com precisão:
- Fundadores e designers — Polem interfaces apontando, sem aprender a diferença entre padding e margin.
- Agências — Transformam feedback de clientes do tipo "move isso ali" em edições exatas durante as chamadas de revisão, não depois delas.
- Gestores de produto — Dirigem alterações para o elemento preciso de que um stakeholder se queixou, sem perda de tradução por ticket.
- Programadores — Delimitam as edições de IA de forma restrita para que os diffs se mantenham pequenos e as revisões rápidas.
Notas de segurança e governança
A precisão não afrouxa as regras — as alterações apontadas passam pelos mesmos gates que as escritas.
- ✓ As edições delimitadas produzem diffs pequenos e revisíveis em branches git reais.
- ✓ Cada alteração — apontada ou escrita — passa pela revisão de política do Guardrails antes do merge.
- ✓ O registo de auditoria apenas de acréscimo regista o pedido e a alteração resultante juntos.
- ✓ O desfazer e a restauração de checkpoints tornam qualquer erro recuperável em segundos.
- ✓ O controlo de acesso baseado em funções rege quem pode editar e quem pode integrar.
Descrever alterações de interface: só palavras vs inspect-to-prompt
A comparação deixa de ser subtil depois da primeira tarde a trabalhar das duas formas.
| Só palavras | Inspect-to-prompt | |
|---|---|---|
| Direcionamento | Depende de vocabulário partilhado e contagem | Clicar no elemento exato na app em execução |
| Iterações | Várias tentativas enquanto as descrições são refinadas | Menos — a referência é inequívoca |
| Efeitos secundários | As edições podem chegar a elementos parecidos | Delimitadas ao componente selecionado |
| Tamanho do diff | Frequentemente maior do que o pedido | Pequeno e ligado a um elemento |
| Quem pode dirigir o trabalho | Pessoas fluentes em vocabulário de interface | Qualquer pessoa que consiga apontar para o problema |
Perguntas frequentes
O inspect-to-prompt funciona em qualquer parte da app?
Pode selecionar elementos em toda a interface em execução — botões, tabelas, gráficos, formulários, rótulos — porque a pré-visualização ao vivo é a aplicação real, não uma imagem. A seleção resolve-se no componente real no código React e TypeScript gerado.
Preciso de compreender o código para o usar?
Não. Aponta para o elemento e descreve a alteração em linguagem simples. O Builder trata do mapeamento do elemento selecionado para o componente no código, e o diff está lá para quem quiser lê-lo.
E quanto a alterações que afetam muitos elementos de uma vez?
Descreva o padrão no pedido — "aplica este estilo a todos os cartões de resumo" — ou coloque em fila uma sequência de alterações delimitadas com a fila de pedidos. O inspect-to-prompt é para precisão; não o impede de fazer alterações amplas quando as quiser.
Há um registo do que foi selecionado e alterado?
Sim. Cada alteração é um diff num branch git, e o registo de auditoria apenas de acréscimo regista pedidos, merges e deploys. Os revisores conseguem ver o que foi pedido e exatamente o que mudou.
O inspect-to-prompt está incluído nos planos self-serve?
Sim — é uma capacidade central do Builder, e os criadores individuais começam em self-serve com créditos. Os programas de produção sérios começam em 10.000 USD por ano.
Páginas relacionadas
Construa o software que antes tinha de esperar.
Inspect-to-Prompt: Clique na Interface, Peça com Exatidão | Ciao