Dikaya Pro 2: revisar código com hipóteses e testes reproduzíveis

Exemplo mínimo de API

Código Python ilustrativo, não uma resposta executada. A chave vem do ambiente e as repetições automáticas estão desativadas. Uma conexão perdida pode deixar resultado e custo desconhecidos: não repita às cegas.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "Crie uma lista de verificação para minha tarefa. Separe fatos e suposições."}],
)
print(response.choices[0].message.content)

Um cálculo de frete começa pelo contrato da função

Considere uma função que calcula frete com base em peso, região e tipo de entrega. O primeiro pedido deve explicar unidades, arredondamento e entradas inválidas. Dizer apenas que o resultado está estranho abre espaço para uma mudança incompatível com a regra comercial. Informe um caso observado e o resultado esperado, com os valores que permitem reproduzir a diferença localmente.

Separe o código necessário de arquivos sem relação com o problema. Inclua a assinatura usada pelos chamadores, a forma dos erros e a versão relevante da linguagem. Se uma dependência estiver ausente, peça que a resposta a identifique. Uma revisão útil admite que falta informação em vez de inventar o retorno de uma biblioteca que não apareceu no material fornecido.

Transforme a hipótese em um teste que possa falhar

Solicite primeiro um cenário mínimo: peso exatamente no limite, região não cadastrada ou entrega sem modalidade. O teste deve verificar o efeito público da função, não uma sequência interna de chamadas escolhida por conveniência. Peça que a proposta explique qual mudança errada faria o teste falhar, tornando explícita a relação entre a hipótese e a asserção escrita.

Execute o teste antes de aceitar a correção sugerida. Depois aplique a menor alteração coerente e rode novamente os testes relevantes. O Pro 2 pode produzir texto de código, mas isso não significa que tenha acesso ao seu terminal. Um relatório de execução deve vir do ambiente em que o comando foi realmente executado, com resultado observado e não presumido.

A demonstração precisa caber numa tarefa bem delimitada

O demo atual usa Pro 2 para texto e possui política própria de requisições, entrada e saída; contas antigas conservam seus snapshots de condições. Portanto, não planeje uma inspeção de repositório completo com base no contexto anunciado do modelo. Envie um caso pequeno e verificável, preservando o espaço necessário para receber o teste e a explicação da alteração proposta.

O limite de saída do demo também inclui raciocínio e não assegura que o orçamento inteiro apareça como resposta final. Um teto explícito menor continua valendo quando é informado. Não interprete uma resposta curta como prova automática de ausência de processamento, nem suponha que mudar o modelo no texto do pedido concede permissões que a conta de demonstração não tem.

No acesso pago, acrescente contexto sem perder o foco

Depois de delimitar o defeito, forneça os chamadores e testes de integração que poderiam ser afetados pela mudança. Peça uma lista de contratos preservados: tipos, unidades, compatibilidade de erros e efeitos laterais. O contexto declarado não elimina limites de JSON, histórico ou anexos do chat. Selecionar material relevante continua sendo parte do trabalho de revisão, mesmo quando existe espaço maior no modelo.

Imagens não são uma capacidade visual nativa do Pro 2 nesta configuração. Capturas de erro podem passar por uma ponte paga de imagem para texto; para stack traces e código, prefira texto copiado e conferido. Isso evita perder caracteres importantes na etapa visual e permite associar a análise a linhas exatas, sem depender apenas da aparência de uma captura de tela.

Integre sem repetir silenciosamente uma tentativa incerta

Use seller-pro-2 no campo model, uma chave de ambiente mantida no servidor e limite explícito de saída. No SDK Python, max_retries=0 desativa repetições automáticas; isso ajuda a tornar cada tentativa visível no seu fluxo. Não transfira os níveis low, high e max de outras identidades para o Pro 2 nem trate a política do demo como configuração universal do acesso pago.

Diferencie a resposta HTTP de rejeição de uma conexão perdida sem confirmação. O segundo caso conserva incerteza sobre processamento e custo. A aplicação deve registrar esse estado, oferecer conferência e só então permitir nova tentativa manual. Uma identificação local de tarefa é útil para organizar sua interface, mas não cria por si só um mecanismo documentado de idempotência na API pública.

Aceite uma alteração com evidência, não com confiança no texto

Na revisão final, confira se o teste originalmente falho ficou verde e se as demais regras continuam cobertas. Um teste positivo isolado não protege o arredondamento em cada intervalo possível. Mantenha uma pequena matriz com caso, resultado esperado e evidência de execução. Separe claramente os comandos sugeridos dos comandos que você de fato executou, especialmente ao compartilhar o parecer com colegas.

O rascunho deste guia pode preparar uma pergunta, não rodar testes nem enviar código automaticamente. Antes de enviar no chat, confira o seletor e o texto que ficou no campo; um rascunho anterior pode prevalecer. Busca explícita no chat pago pode reunir referências, mas não equivale a execução nativa de comandos ou a uma ferramenta de internet disponível em toda integração API.

Perguntas e respostas

Pro 2 e seller-glm-5-3 são intercambiáveis?

Não. A base modificada GLM-5.3 do Pro 2 não transforma seu identificador em seller-glm-5-3. São identidades separadas, com configurações e condições próprias. Para reproduzir uma revisão, registre o campo model exato e não substitua automaticamente uma identidade pela outra apenas porque os nomes fazem referência à mesma família.

O modelo executa os testes que escreve?

A produção de um teste em texto não comprova execução. Rode o comando no seu ambiente, confira o resultado e preserve a saída relevante. Uma integração de IDE pode oferecer ferramentas sob suas próprias condições, mas isso não torna a execução de terminal uma capacidade nativa de toda chamada ao Pro 2.

Por que usar um exemplo pequeno no demo?

A demonstração possui limites de entrada, saída e tentativas diferentes do contexto declarado do modelo. Um exemplo mínimo deixa espaço para explicar o contrato e apresentar um teste verificável. Contas antigas podem preservar outras quotas; consulte as condições efetivas em vez de inferir acesso ilimitado a partir do nome Pro 2.

Como avaliar uma correção que parece convincente?

Comece pelo comportamento observável: o caso defeituoso deve falhar antes da mudança e passar depois. Confira ainda os testes de compatibilidade e os casos de fronteira. Uma justificativa fluente ajuda a entender a proposta, mas não substitui execução, revisão do diff e verificação das regras do projeto.

Fontes

Conteúdo preparado com auxílio de IA. Os exemplos são ilustrativos, não respostas reais nem testes comparativos. As fontes externas não substituem os termos do serviço.

• Dikaya: API, demonstração e limites
  dikaya.cc
• Dikaya: identidades públicas dos modelos
  dikaya.cc
• Dikaya: preços públicos e condições
  dikaya.cc
• SDK Python: configuração de tentativas
  github.com