Guia de exemplos
Procurando código que você possa adaptar, em vez de uma captura de tela que só dá para admirar? Comece identificando a tarefa, o modelo e os dados de resposta de que seu projeto precisa. Este guia separa a busca por repositórios de três fluxos de trabalho ilustrativos. Os links dos modelos abrem a API de modelos, não um repositório da Runware no GitHub; para fazer solicitações à API de modelos, use os exemplos da API de modelos disponíveis no destino.
Um resultado de repositório pode parecer relevante, mas responder à pergunta errada. Confira se o exemplo corresponde ao seu caso de uso antes de copiar a solicitação.
Você precisa transformar uma descrição inserida pelo usuário em uma imagem, mas um exemplo de repositório pode ter a entrada, o modelo ou o tratamento da saída fixados no código. Uma solicitação de exemplo bem-sucedida ainda não é um recurso pronto para o usuário.
Rastreie onde o prompt entra na solicitação, onde a resposta é lida e onde os erros aparecem. Para uma sequência inicial mais ampla, consulte o guia de uso indicado no link.
como usar runware aiVocê quer explorar várias direções visuais a partir do mesmo briefing. Um exemplo pode mostrar um único resultado sem explicar se a escolha do modelo é adequada ao tema ou ao estilo desejado.
Anote o modelo indicado no exemplo e compare os resultados usando o mesmo briefing antes de adotar suas configurações.
modelos runwareVocê encontrou um trecho de código, mas não consegue identificar qual serviço ele acessa, quais credenciais exige ou se o formato da resposta ainda corresponde à documentação do serviço.
Primeiro, identifique o serviço e o fluxo de solicitações documentado. Depois, teste o trecho de código em um ambiente controlado, em vez de tratar o código do repositório como garantia do produto.
o que é runwareSiga estes três caminhos nesta ordem: estabeleça a solicitação básica, examine a escolha do modelo e, depois, confira o que o serviço e o exemplo realmente abrangem.
Os resultados abaixo são verificações ilustrativas de aceitação, não respostas capturadas nem afirmações sobre um repositório específico do GitHub. O resultado observado depende do exemplo que você testar.
Entrada: uma breve descrição de imagem de produto fornecida por um usuário. Resultado esperado da aplicação: exibir a imagem retornada e manter um estado de falha visível caso a solicitação não possa ser concluída. Um exemplo útil mostra tanto a construção da solicitação quanto o tratamento da resposta; uma imagem exibida em um README não comprova que nenhuma das duas coisas funcionará na sua interface. Evite desenvolver com base em um campo de resposta presumido antes de consultar a documentação atual e testar uma resposta real.
Entrada: uma mesma descrição reutilizada em vários testes visuais. Resultado esperado da avaliação: um pequeno registro comparativo com a descrição, o modelo usado e cada resultado observado. Isso ajuda a equipe a explicar por que escolheu uma direção sem confundir a imagem de exemplo de um repositório com um benchmark reproduzível. Se o exemplo oferecer controles, altere um de cada vez; caso contrário, limite a comparação às configurações que você puder verificar.
Entrada: uma solicitação de teste enviada de um ambiente que não seja de produção. Resultado esperado para a engenharia: um registro dos campos de resposta que seu código realmente recebe, além do comportamento diante de solicitações inválidas e resultados indisponíveis. Isso rende menos imagens atraentes do que uma galeria, mas é o ponto em que um trecho de código interessante se torna um candidato confiável à integração. Não registre informações secretas em logs nem presuma que um exemplo abranja novas tentativas, armazenamento ou controle de acesso.
Trate os exemplos do GitHub como código a ser revisado, não como permissão para reutilizar todas as dependências, imagens ou outros recursos que eles contêm. Leia a licença de cada repositório, examine as dependências e confirme se as instruções estão de acordo com a documentação atual do serviço. Não inclua credenciais em arquivos enviados ao repositório, evite usar conteúdo sensível dos usuários em prompts de teste e confira os termos aplicáveis ao uso pretendido. Se um exemplo não tiver uma licença clara ou informações sobre quem o mantém, peça esclarecimentos ou escolha um ponto de partida mais bem documentado.
Explore a geração de imagensPesquise no GitHub o nome do serviço junto com a tarefa que você quer realizar, como geração de imagens ou tratamento de respostas. Confira quem mantém o repositório, o histórico de atualizações e a licença antes de considerar um resultado um ponto de partida confiável.
Não presuma que sim. Um exemplo pode depender de credenciais, identificadores de modelo, versões de bibliotecas ou campos de resposta específicos. Por isso, compare-o com a documentação atual e faça um pequeno teste antes de integrá-lo.
Procure os dados de entrada da solicitação, a seleção do modelo e o código que trata tanto o resultado quanto um erro. Uma imagem de exemplo, por si só, não mostra como o aplicativo recebe ou exibe o resultado.
Confira primeiro a licença e quaisquer avisos específicos dos recursos; o código e as imagens podem ter permissões diferentes. Se os termos não estiverem claros, use seus próprios recursos em vez de presumir que o repositório permite a reutilização.
Considere o resultado desconhecido até executar o exemplo em um ambiente de teste e examinar uma resposta real. Anote os campos observados e verifique como o exemplo se comporta quando uma solicitação falha.