Graças à estrutura de classificação, conseguimos estimar no nosso desenho qual estratégia realmente funciona.
Antes de tratar com um wrapper o caso de "dá para fornecer, mas não fornece", parece certo olhar primeiro para os 149 casos. Se há um ID na resposta, mas ele não foi mapeado, é bem provável que seja um problema de convenção de nome de campo (id / _id / resource_id / document_id) ou de estrutura aninhada (result.data.id). Esses 149 casos parecem estar dentro de um escopo que dá para resolver corrigindo só a camada de mapeamento, sem mexer na API.
No caso de "não dá para fornecer", acho que será preciso abordar de forma diferente para cada ferramenta.
Em write_file, com a combinação de caminho + hash do conteúdo, dá para detectar se "o mesmo conteúdo foi escrito duas vezes".
Em k8s scale, se o número de réplicas desejado já for igual ao valor atual, na prática é idempotente — dá para evitar a execução duplicada em si consultando o estado antes.
click é diferente. Colocar um ID na própria ação não faz muito sentido; parece mais realista seguir pela linha de comparar snapshots antes e depois para verificar se "a mudança de estado que esse click queria alcançar já aconteceu".
O que estamos discutindo internamente é uma forma de transformar as ferramentas em uma matriz por "possibilidade de retorno de ID × tipo de mudança de estado" para ramificar a estratégia de tratamento. Se vocês puderem compartilhar mais sobre em quais padrões esses 149 casos estão concentrados, isso deve ajudar a definir a estratégia de mapeamento.
Sim! O modelo foi construído com base no tamanho padrão mais comum.
No entanto, no caso de apartamentos que não têm esse tamanho padrão, ele foi implementado para fazer a previsão usando vários tamanhos de amostra.
Testei inserindo o apartamento antigo onde meus pais moram...
Só aparece 33 pyeong, mas esse condomínio antigo tem unidades de 33 e 26 pyeong.
Ele originalmente só oferece suporte a 33 pyeong?
Uau~ Esse é um serviço que eu também queria criar. Por acaso, daria para saber mais ou menos quanto sai o custo do Supabase ao fazer esse tipo de crawling?
Esqueci de incluir no texto a função de compartilhamento de apartamentos haha. Vou deixar aqui, como teste, um link compartilhado do Helio City, um grande condomínio famoso.
(Veja os resultados de previsão apenas como referência; para detalhes da modelagem, consulte o white paper!)
Ele abre direto, sem login, então fique à vontade para clicar e dar uma olhada na UI dos gráficos. https://app.apt-insights.com/s/apt/9NPumhVmCv
Nossa, eu nem sabia que existia um site coreano do cppreference; fiquei feliz ao descobrir por este post...
Mas acho que vou ter que continuar usando o site em inglês como antes.
Se dividirmos os 3.197 casos por motivo, fica assim.
O campo ID não existe na resposta: 2.011 casos (62,9%)
A chamada falhou com erro: 1.037 casos (32,4%)
Há ID na resposta, mas nosso mapeamento não conseguiu capturar: 149 casos (4,7%)
Tem um ponto que eu gostaria de corrigir aqui. Antes foi dito que "a maior parte das duplicações está na faixa que nem dá para rastrear", mas 32% são chamadas que falharam. Como nada aconteceu, não há o que rastrear. O que realmente "aconteceu, mas não foi rastreado" são 2.011 casos. Ainda é um número grande, mas menor que 3.197.
Havia 24 ferramentas que retornavam apenas sucesso/falha. Agrupando por tipo:
Manipulação de navegador (9) — click, type, navigate etc. Só click teve 719 casos
Sistema de arquivos (3) — write_file, edit_file, move_file
Kubernetes (4) — scale, create, apply, delete
Edição de documentos (3) — add_paragraph, add_heading, format_text
Individuais — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
Essas 24 se dividem em dois tipos. Estou acrescentando isso porque acho que pode ser útil no desenho da especificação.
O lado que não pode fornecer ID Cliques no navegador ou edição de arquivos simplesmente não têm uma "entidade criada" de origem. Não dá para atribuir um ID a um clique. No caso de arquivo, o caminho já é o identificador.
O lado que poderia fornecer, mas não fornece github-create_repository é o exemplo mais representativo. Se criou um repositório, obviamente existe um ID, mas ele não vem na resposta. Em emails-send_email, também existe um message ID no nível SMTP, mas ele não é retornado. O mesmo vale para github-fork_repository e excel-write_data_to_excel.
É esse segundo grupo que dá para corrigir. Se vocês incluírem na especificação interna da ferramenta algo como "operações de criação devem obrigatoriamente retornar o ID da entidade na resposta", essa distinção pode servir como critério para decidir onde aplicar isso.
Os 149 casos finais são um problema de mapeamento nosso. Eles se concentram em notion database-query (102 casos) e pptx open_presentation (28 casos), e em ambos os casos eram ferramentas que deixamos intencionalmente fora do escopo, então não foram capturadas. Não é um problema de desenho da ferramenta, e sim de cobertura nossa.
Por acaso, na stack que vocês operam hoje, os trabalhos de escrita ficam mais concentrados em qual desses lados? O que vimos foi um benchmark, então imagino que a composição das ferramentas seja diferente da operação real.
Se você consegue avançar nem que seja um passo por dia, isso já é suficiente.
Estamos em uma era em que produzir fica mais fácil, a validação se torna mais sofisticada e, no fim, a "escolha" passa a ser o ponto central. Por isso, este é um momento em que a capacidade de ler com precisão o rumo das coisas se torna ainda mais importante.
Hoje em dia, agentes de codificação podem compensar as nossas limitações, então acho que, se você souber bem quais são seus pontos fortes e conseguir aproveitá-los, a barreira de entrada pode ficar mais baixa.
Eu também sempre tive problemas com documentação, mas, ao delegar parte disso a um agente de codificação, o peso diminuiu. Além disso, ao revisar o material documentado por ele, sinto que estou desenvolvendo um olhar melhor para documentação.
Obrigado por ler! No passado, havia muitas coisas com que as pessoas precisavam se preocupar diretamente, como documentação, casos de teste e validação, mas agora, como é possível fazer uma boa parte disso junto com agentes de codificação de IA, parece que a dificuldade de manter projetos open source caiu muito mais do que antes!
No momento estou usando a assinatura mensal :( Como o custo não é baixo, estou pensando na viabilidade de manter isso no longo prazo.
Graças à estrutura de classificação, conseguimos estimar no nosso desenho qual estratégia realmente funciona.
Antes de tratar com um wrapper o caso de "dá para fornecer, mas não fornece", parece certo olhar primeiro para os 149 casos. Se há um ID na resposta, mas ele não foi mapeado, é bem provável que seja um problema de convenção de nome de campo (
id/_id/resource_id/document_id) ou de estrutura aninhada (result.data.id). Esses 149 casos parecem estar dentro de um escopo que dá para resolver corrigindo só a camada de mapeamento, sem mexer na API.No caso de "não dá para fornecer", acho que será preciso abordar de forma diferente para cada ferramenta.
write_file, com a combinação de caminho + hash do conteúdo, dá para detectar se "o mesmo conteúdo foi escrito duas vezes".k8s scale, se o número de réplicas desejado já for igual ao valor atual, na prática é idempotente — dá para evitar a execução duplicada em si consultando o estado antes.clické diferente. Colocar um ID na própria ação não faz muito sentido; parece mais realista seguir pela linha de comparar snapshots antes e depois para verificar se "a mudança de estado que esse click queria alcançar já aconteceu".O que estamos discutindo internamente é uma forma de transformar as ferramentas em uma matriz por "possibilidade de retorno de ID × tipo de mudança de estado" para ramificar a estratégia de tratamento. Se vocês puderem compartilhar mais sobre em quais padrões esses 149 casos estão concentrados, isso deve ajudar a definir a estratégia de mapeamento.
Sim! O modelo foi construído com base no tamanho padrão mais comum.
No entanto, no caso de apartamentos que não têm esse tamanho padrão, ele foi implementado para fazer a previsão usando vários tamanhos de amostra.
Testei inserindo o apartamento antigo onde meus pais moram...
Só aparece 33 pyeong, mas esse condomínio antigo tem unidades de 33 e 26 pyeong.
Ele originalmente só oferece suporte a 33 pyeong?
Uau~ Esse é um serviço que eu também queria criar. Por acaso, daria para saber mais ou menos quanto sai o custo do Supabase ao fazer esse tipo de crawling?
Tanto os vídeos quanto as gravações são todos enviados para o servidor?
Esqueci de incluir no texto a função de compartilhamento de apartamentos haha. Vou deixar aqui, como teste, um link compartilhado do Helio City, um grande condomínio famoso.
(Veja os resultados de previsão apenas como referência; para detalhes da modelagem, consulte o white paper!)
Ele abre direto, sem login, então fique à vontade para clicar e dar uma olhada na UI dos gráficos.
https://app.apt-insights.com/s/apt/9NPumhVmCv
Tem muitos apps gratuitos e também é fácil de fazer, então, se for pago, hmm...
Obrigado pela dica. Corrigimos!!
O link do white paper técnico está retornando erro 404!
https://edge.apt-insights.com/v1/public/whitepaper
Nossa, eu nem sabia que existia um site coreano do cppreference; fiquei feliz ao descobrir por este post...
Mas acho que vou ter que continuar usando o site em inglês como antes.
Ah, faz muito tempo que não uso Windows, então eu não sabia bem. Pesquisando, parece ser parecido.
Se dividirmos os 3.197 casos por motivo, fica assim.
O campo ID não existe na resposta: 2.011 casos (62,9%)
A chamada falhou com erro: 1.037 casos (32,4%)
Há ID na resposta, mas nosso mapeamento não conseguiu capturar: 149 casos (4,7%)
Tem um ponto que eu gostaria de corrigir aqui. Antes foi dito que "a maior parte das duplicações está na faixa que nem dá para rastrear", mas 32% são chamadas que falharam. Como nada aconteceu, não há o que rastrear. O que realmente "aconteceu, mas não foi rastreado" são 2.011 casos. Ainda é um número grande, mas menor que 3.197.
Havia 24 ferramentas que retornavam apenas sucesso/falha. Agrupando por tipo:
Manipulação de navegador (9) —
click,type,navigateetc. Sóclickteve 719 casosSistema de arquivos (3) —
write_file,edit_file,move_fileKubernetes (4) —
scale,create,apply,deleteEdição de documentos (3) —
add_paragraph,add_heading,format_textIndividuais —
emails-send_email,excel-write_data_to_excel,snowflake-write_query,logging_write_log,github-fork_repository,github-create_repositoryEssas 24 se dividem em dois tipos. Estou acrescentando isso porque acho que pode ser útil no desenho da especificação.
O lado que não pode fornecer ID Cliques no navegador ou edição de arquivos simplesmente não têm uma "entidade criada" de origem. Não dá para atribuir um ID a um clique. No caso de arquivo, o caminho já é o identificador.
O lado que poderia fornecer, mas não fornece
github-create_repositoryé o exemplo mais representativo. Se criou um repositório, obviamente existe um ID, mas ele não vem na resposta. Ememails-send_email, também existe um message ID no nível SMTP, mas ele não é retornado. O mesmo vale paragithub-fork_repositoryeexcel-write_data_to_excel.É esse segundo grupo que dá para corrigir. Se vocês incluírem na especificação interna da ferramenta algo como "operações de criação devem obrigatoriamente retornar o ID da entidade na resposta", essa distinção pode servir como critério para decidir onde aplicar isso.
Os 149 casos finais são um problema de mapeamento nosso. Eles se concentram em
notion database-query(102 casos) epptx open_presentation(28 casos), e em ambos os casos eram ferramentas que deixamos intencionalmente fora do escopo, então não foram capturadas. Não é um problema de desenho da ferramenta, e sim de cobertura nossa.Por acaso, na stack que vocês operam hoje, os trabalhos de escrita ficam mais concentrados em qual desses lados? O que vimos foi um benchmark, então imagino que a composição das ferramentas seja diferente da operação real.
A versão coreana teve a última atualização em 2016, então acho melhor consultar o original
Se você consegue avançar nem que seja um passo por dia, isso já é suficiente.
Estamos em uma era em que produzir fica mais fácil, a validação se torna mais sofisticada e, no fim, a "escolha" passa a ser o ponto central. Por isso, este é um momento em que a capacidade de ler com precisão o rumo das coisas se torna ainda mais importante.
Seria algo parecido com o recurso nativo do Windows? Windows + V
Uau, com isso aí, acho que não precisa se preocupar com coisas como roleplay.
Ops, já corrigi.
Hoje em dia, agentes de codificação podem compensar as nossas limitações, então acho que, se você souber bem quais são seus pontos fortes e conseguir aproveitá-los, a barreira de entrada pode ficar mais baixa.
Eu também sempre tive problemas com documentação, mas, ao delegar parte disso a um agente de codificação, o peso diminuiu. Além disso, ao revisar o material documentado por ele, sinto que estou desenvolvendo um olhar melhor para documentação.
Obrigado por ler! No passado, havia muitas coisas com que as pessoas precisavam se preocupar diretamente, como documentação, casos de teste e validação, mas agora, como é possível fazer uma boa parte disso junto com agentes de codificação de IA, parece que a dificuldade de manter projetos open source caiu muito mais do que antes!