Pesquisa multiperspectiva
Uma pesquisa simples responde "o que a web diz sobre X". Esta skill responde "quais partes de X são corroboradas independentemente e quais dependem de uma única fonte".
O mecanismo, abstraído do STORM de Stanford (verificado com a fonte em stanford-oval/storm):
(perspectivas × orçamento) → recuperar → (evidência | recusa) → escrever de volta → perguntar novamente
repetir M rodadas, N+1 pistas independentes, convergir apenas no final
↓
working-report.md (mecanismo visível, trilha de auditoria)
↓
reader-report.md (mecanismo invisível, o produto)
↓
resposta ao usuário = reader-report.md na íntegra, nada adicionado
Todo o valor reside em quatro lugares que a maioria das tentativas de pesquisa ignora: as perspectivas devem vir de fora do modelo, cada pergunta deve resultar em uma busca real, a convergência deve ser pontuada, não assumida, e o resultado pontuado deve então sobreviver à leitura por alguém que não esteve presente.
Quando acionar
Execute esta skill em qualquer um destes, vindos das próprias palavras do usuário — o usuário nunca precisa nomear a skill:
- Tokens explícitos: 深度调研 / 深度研究 / 深度分析 / 深入研究 / deep-research / deep research / deep dive / 深入调研.
- Solicitações com advérbios de qualidade: 仔细调研 / 认真调研 / 调研得仔细一点 / 多查几个来源 / 别只给一个来源 / 要确定性结论 / 确定性调研 / 查得踏实一点 / 帮我彻底搞清楚 X / 把 X 查透 / X 到底怎么样 / 不要泛泛而谈.
- Solicitações de método: 多维度调研 / 多视角 / 全景分析 / 正反双方梳理 / 交叉验证 / 多方观点对比 / 交叉比对来源 / 标注"哪些结论有多来源印证、哪些只有单一来源".
- Forma implícita: qualquer solicitação de pesquisa onde o usuário sinalize que uma resposta única não é suficiente.
Regra de sobreposição: anysearch e agent-reach são os proprietários de 调研/搜索/查一下 genéricos (eles são os backends de recuperação e esta skill os usa como ferramentas). No momento em que a solicitação carrega um qualificador de profundidade / cuidado / certeza / validação cruzada, esta skill é a proprietária da solicitação e orienta esses backends dentro de suas pistas. Em caso de dúvida, prefira esta skill: o custo de pesquisar demais é tempo, o custo de pesquisar de menos é uma resposta errada e confiante.
Não para: verificações rápidas de fatos únicos, "consulte o que é esta API", ou consultas de uma única página.
Os dois artefatos
As etapas 1–5 produzem um relatório de trabalho: um artefato com mecanismo visível onde pista, A–E, consulta, rodada e frases de ortogonalidade são o ponto central. Ele está correto e é ilegível para qualquer um que não o tenha executado.
A etapa 6 produz o relatório para o leitor: a coisa que você realmente entrega. Mesmas evidências, mesma honestidade, mesmas fontes — mas a maquinaria desapareceu e a estrutura é reconstruída em torno do que um leitor precisa para decidir algo.
Mantenha ambos os artefatos e nunca deixe a Etapa 6 substituir a Etapa 5.
- O relatório de trabalho é a trilha de auditoria: é o que permite que você (ou uma passagem posterior) verifique se nenhuma afirmação se desviou, nenhum nível foi atualizado e nenhuma linha vazia foi preenchida de memória. Ele é escrito em um arquivo (ex.:
working-report.md) e nunca é colado na resposta. - O relatório para o leitor é a entrega, salvo como
reader-report.md: é o que uma pessoa pode realmente usar, em uma única sessão, sem um glossário.
Regra de entrega (rígida): a resposta final ao usuário é o conteúdo completo e literal de reader-report.md — nada adicionado, nada alterado, nada enrolado ao redor. Veja §Entrega abaixo. Sem preâmbulo ("Terminei, aqui está o relatório"), sem despedida, sem resumo, sem linha de verificação, sem comentários descrevendo o que você fez ou quais arquivos existem. Leia o arquivo e emita exatamente seus bytes como o corpo da sua mensagem. Qualquer coisa que você sinta vontade de adicionar pertence ao relatório de trabalho, não à resposta.
Colapsar os dois em um único documento falha em ambas as direções. Mantenha a maquinaria e os leitores a evitam; remova a maquinaria sem as regras da Etapa 6 e a validação cruzada desaparece silenciosamente — o leitor não consegue mais distinguir "quatro caminhos independentes convergiram aqui" de "um acerto de sorte foi repetido", que era o objetivo principal da skill.
Inegociáveis
- As perspectivas são lidas, não inventadas. Você deve derivá-las de artefatos reais que você buscou (relatórios existentes, documentos de concorrentes, sumários, categorias de fóruns, cabeçalhos regulatórios). Nunca apenas pergunte a si mesmo "quais são três ângulos sobre isso".
- Toda pergunta deve produzir uma busca. Uma pergunta que não pode ser decomposta em consultas que acessam fontes reais não é pesquisa, é especulação. Diga isso e abandone-a.
- As pistas não se comunicam enquanto estão em execução. A independência é a única coisa que torna o acordo informativo. A convergência ocorre uma vez, no final.
- A recusa é um sinal, não uma falha. Quando as buscas de uma pista voltam vazias, registre isso e deixe que oriente a próxima pergunta. Não preencha a lacuna com memória paramétrica.
- Relate o nível de corroboração por afirmação. "Três fontes independentes concordam" e "um blog diz isso" nunca devem parecer iguais no relatório para o leitor.
- O mecanismo é invisível no relatório para o leitor, mas as evidências não são. Um leitor nunca deve precisar saber o que é uma pista; um leitor deve sempre ser capaz de perguntar "quem diz isso, e mais alguém disse?".
- A resposta é o relatório para o leitor, inalterado. A mensagem final para o usuário é
reader-report.mdcopiado na íntegra — sem preâmbulo, sem despedida, sem resumo, sem linha de entrada, sem comentários. Se você deseja que o usuário veja algo diferente, altere o arquivo e re-emita-o; nunca edite no caminho de saída.
Etapa 1 — Ancorar as perspectivas
Não comece pelo tópico. Comece por como este tópico já está estruturado no mundo.
Busque 2–4 artefatos reais cuja estrutura você possa emprestar:
| Tipo de tópico | Onde ler a estrutura |
|---|---|
| Uma entidade, produto, evento | As seções de sua página na Wikipedia + seções de 2 páginas vizinhas/concorrentes |
| Um mercado, indústria | Dois sumários de relatórios de analistas, um índice de arquivamento regulatório, uma agenda de conferência |
| Uma abordagem técnica | A barra lateral dos documentos upstream, cabeçalhos do README de dois projetos rivais |
| Uma questão controversa | Os cabeçalhos da peça a favor mais forte, os cabeçalhos da peça contra mais forte |
| Uma pessoa, organização | A estrutura de seu próprio site vs. a estrutura da cobertura crítica |
Em seguida, derive 3 pistas (mais a pista 0, abaixo). Cada pista é uma razão diferente para se importar com o tópico, não um subtópico diferente:
- ✅ "Alguém que tem que operar isso em produção, preocupado com modos de falha e custo"
- ✅ "Alguém financeiramente exposto a esta decisão, preocupado com quem paga"
- ❌ "Aspectos técnicos" / "Aspectos econômicos" / "Aspectos sociais" — estes são a mesma crença anterior usando três chapéus
Verifique a ortogonalidade antes de gastar o orçamento. Para cada par de pistas, escreva uma frase: "A pista A perguntaria X; a pista B perguntaria X?" Se sim para qualquer par, mescle-as e rederive. Se duas pistas gerariam as mesmas três primeiras perguntas, elas são uma pista. Esta verificação é o minuto de maior alavancagem em todo o procedimento — pule-a e você terá quatro paráfrases de uma única pesquisa.
A pista 0 é obrigatória: uma pista simples de "alguém que precisa dos fatos básicos não controversos, datas, definições, números". É o piso de cobertura que impede que todas as outras pistas sejam especializadas a ponto de se tornarem irrelevantes.
Registre os artefatos âncora e as frases de ortogonalidade; eles vão no relatório de trabalho (Etapa 5) como a proveniência do conjunto de perspectivas. Eles não aparecem no relatório para o leitor (Etapa 6).
Etapa 2 — Defina o orçamento antes de gastá-lo
Escreva o orçamento explicitamente e depois obedeça-o:
| Item | Padrão | Justificativa |
|---|---|---|
| Pistas | 3 + pista 0 = 4 | Mais pistas diluem em vez de diversificar; 4 é o ponto ideal empírico |
| Rodadas por pista | 3 | Suficiente para um acompanhamento; além disso, uma pista geralmente está perdida |
| Consultas por pergunta | 2–3 | Uma consulta é um bilhete de loteria, cinco é uma espingarda |
| Resultados por consulta | 3–5 | Leia os primeiros, não acumule |
| Palavras de evidência por rodada | ~1000 | Force-se a manter apenas as frases que suportam a carga |
| Palavras de contexto da pista | ~2500 | Mantém detalhes recentes, descarta detalhes antigos |
| Pistas paralelas | ≤4 | Concorrência é o ponto; limites de taxa são a restrição |
Orçamento total de recuperação ≈ 4 × 3 × 3 = 36 consultas. Quando ele acabar, pare de pesquisar e comece a convergir. Ficar sem orçamento é um evento planejado, não um acidente.
Etapa 3 — Execute as pistas em paralelo, independentemente
Lance todas as pistas na mesma rodada — use subagentes paralelos quando disponíveis (subagent / workflow), um por pista. Cada pista recebe: o tópico, sua descrição de pista, o orçamento e as regras abaixo. Não dê a cada pista visibilidade sobre as outras pistas.
Dentro de uma pista, para cada rodada:
- Faça uma pergunta de cada vez, na voz da pista. Restrições que não são opcionais:
- pergunte sobre o tópico, não sobre tópicos adjacentes (anti-desvio)
- não pergunte novamente algo já perguntado (anti-repetição)
- se não houver mais nada que valha a pena perguntar, pare a pista — não invente uma pergunta para preencher a rodada
- Decomponha a pergunta em 2–3 consultas de pesquisa. Uma pergunta que não se decompõe é uma pergunta ruim; reescreva-a.
- Pesquise e, em seguida, realmente busque. Trechos são uma pista, não evidência. Busque a página para qualquer coisa que suporte carga.
- Responda apenas com base no que você buscou. Toda frase rastreável a uma URL. Se as fontes não responderem, escreva a recusa literalmente: "nenhuma fonte encontrada para esta pergunta".
- Escreva a rodada de volta no contexto da pista — o esqueleto da pergunta sempre, o detalhe da resposta apenas para as últimas rodadas. Isto é o que torna a próxima pergunta um acompanhamento em vez de um reinício.
Mantenha um registro por pista com, para cada fonte recuperada: url, título, consulta que a encontrou, rodada e a afirmação exata que ela suporta. Os campos consulta e rodada são os que todos esquecem e que a Etapa 4 precisa.
O loop de recusa: quando as pesquisas de uma rodada voltam vazias ou inúteis, isso vai para o contexto da pista e a próxima pergunta deve se afastar disso. Nunca remende um buraco com o que você já acredita.
Etapa 4 — Convergir e pontuar a convergência
Agora, e apenas agora, junte as pistas.
4a. Mescle por fonte, não por resumo. Chaveie cada evidência por URL (normalizada: remova parâmetros de rastreamento, fragmentos, barra final). Mesma URL de duas pistas → uma fonte, união das afirmações que suporta. Esta é a primeira e mais barata convergência e é onde você descobre que duas pistas pousaram independentemente na mesma página.
4b. Construa a matriz afirmação × pista. Agrupe as afirmações extraídas em asserções atômicas (um fato por linha). Para cada afirmação, registre quais pistas e quantas fontes distintas a suportam:
afirmação | URLs de suporte | fontes distintas | pistas que a encontraram | conflitos
4c. Pontue a corroboração. Esta é a espinha dorsal da entrega:
| Nível | Condição | Como declarar |
|---|---|---|
| A — Convergida | encontrada por ≥2 pistas independentes, ≥2 domínios distintos | afirmar diretamente |
| B — Corroborada | ≥2 fontes distintas, mesma pista | afirmar com fontes anexadas |
| C — Fonte única | apenas 1 fonte | afirmar + sinalizar fonte-única |
| D — Contestada | fontes confiáveis discordam | apresentar ambas, não fazer média |
| E — Não encontrada | pesquisou, nada encontrado | dizer explicitamente; não preencher de memória |
Uma afirmação é A apenas se as pistas eram genuinamente independentes — se duas pistas apenas pesquisaram o nome do tópico e ambas obtiveram a página da Wikipedia, isso é uma pista duas vezes, não convergência.
4d. Pese, não conte. Agrupe por domínio, não por URL. Dez páginas citando o mesmo comunicado de imprensa são uma fonte. Duas páginas da mesma organização são uma fonte. Observe dependências upstream (relaciona-se a, de acordo com) — corroboração de um eco não é corroboração.
4e. Caça os conflitos explicitamente. O modo de falha medido do STORM não é alucinação, é ligar fatos que meramente co-ocorreram. Antes de escrever, escaneie a matriz em busca de afirmações cujas fontes de suporte não conectam realmente as duas coisas que estão sendo conectadas. Marque qualquer ligação dessas como inferida-por-mim, nunca como fonte. Procure linhas de nível D e certifique-se de que cada uma está visível no relatório em vez de ser silenciosamente resolvida.
Etapa 5 — Relatório (relatório de trabalho, mecanismo visível)
Escreva um arquivo Markdown. Nome padrão: working-report.md (se o usuário ou o chamador especificou outro diretório de saída ou nome de arquivo para o relatório, obedeça — defina WORKING = <esse caminho> e READER = <caminho do relatório> no início e use essas duas variáveis para o resto da execução, para que a resposta emita o arquivo correto).
Estrutura necessária:
# <Tópico>
## Resumo de corroboração
<contagens: N afirmações convergidas / corroboradas / fonte única / contestadas / não encontradas>
## Como as perspectivas foram escolhidas
<os artefatos âncora realmente buscados + as frases de ortogonalidade + a lista de pistas>
## Descobertas
### <Tema>
<prosa; cada afirmação marcada A/B/C/D/E em linha; citações como [n]>
## Pontos contestados
<todas as linhas de nível D, ambos os lados, fontes anexadas>
## Afirmações de fonte única
<todas as linhas de nível C — leia-as como pistas para verificar, não como fatos>
## O que foi pesquisado e não encontrado
<linhas de nível E, com as consultas usadas>
## Fontes
[n] <url> — encontrada por <pista>, rodada <k>, via consulta "<q>"
Mantenha a proveniência encontrada por pista / rodada / consulta na lista de fontes. Custa quase nada para registrar e é a única coisa que permite a um leitor distinguir "quatro pistas independentes convergiram aqui" de "um acerto de sorte foi repetido".
Este é o artefato que você audita, não o artefato que você entrega. Prossiga para a Etapa 6.
Etapa 6 — Polir para o relatório para o leitor (mecanismo invisível)
Escreva o resultado em reader-report.md (ou <LEITOR> conforme fixado na Etapa 5). Execute isto como uma passagem separada com um contexto novo — um subagente que recebe apenas o relatório de trabalho, não os prompts das pistas, não os registros das pistas, não o seu raciocínio. Uma passagem que viu a maquinaria vazará a maquinaria.
6a. Traduza todo termo do mecanismo para a linguagem do leitor
Este é um mapeamento fixo, não um julgamento. Não invente alternativas.
| Relatório de trabalho | Relatório para o leitor |
|---|---|
| pista | linha de investigação |
| consulta | termo de pesquisa |
| rodada | iteração |
| pontuação de corroboração | nível de certeza |
| nível A | convergido (múltiplas linhas independentes concordaram) |
| nível B | corroborado (múltiplas fontes, mas dentro da mesma linha) |
| nível C | fonte única (apenas uma fonte encontrada) |
| nível D | contestado (fontes discordam) |
| nível E | não encontrado (pesquisado, sem resultado) |
6b. Reconstrua a estrutura em torno de decisões, não de proveniência
O leitor precisa saber: o que decidi, quão certo estou, o que devo verificar a seguir. A estrutura de entrega é:
# <Tópico>
## Resumo executivo
(O que as evidências convergentes dizem. 3–5 frases. Se nada convergiu, diga isso. Liste o número de afirmações em cada nível de certeza.)
## Principais descobertas
(Agrupadas por tema. Cada afirmação com seu nível de certeza e fontes, sem jargão interno. Ex.: "Custo: três fontes independentes estimam €XX/mês. A confiabilidade é relatada apenas pelo fornecedor.")
## Questões não resolvidas
(Cada nível D e E, declarado em linguagem simples. Ex.: "Reivindicações de desempenho variam em até 40% entre as fontes; ninguém publicou benchmarks reproduzíveis.")
## Fontes
(Mesmas fontes, formato limpo. URLs reais, com breve descrição do que cada uma contém.)
6c. Honestidade, não marketing
- Se um nível A é alcançado, diga "esta afirmação é apoiada por fontes independentes" — não "isto é fato".
- Se um nível C não pode ser verificado, diga "esta afirmação vem de uma única fonte" — não "acredita-se que".
- Se um nível E não foi encontrado após busca, diga "não encontrado na pesquisa" — não "sem dados disponíveis".
- Se um nível D tem dois lados, apresente explicitamente ambos — não os combine.
6d. Nunca preencha lacunas
Se a Etapa 5 registrou um nível E, o relatório para o leitor diz "Isso não foi encontrado na pesquisa atual." Não adivinhe. Não se baseie na Wikipedia de memória. A resposta mais honesta para "não sei" é "pesquisei e não encontrei".
Entrega
A resposta final para o usuário é o conteúdo de reader-report.md, sem qualquer invólucro adicional.
Neste ponto, você tem dois arquivos: working-report.md (a trilha de auditoria completa) e reader-report.md (o relatório polido).
Você não diz: "Terminei o relatório de trabalho e o relatório para o leitor. Aqui está o conteúdo."
Você não diz: "Usei o método STORM para pesquisar isto."
Você não diz: "Nota: verifiquei os arquivos."
Você não diz: "As pistas 2 e 3 convergiram em tal afirmação."
Você lê reader-report.md e emite seu conteúdo exato como o corpo da sua mensagem. A mensagem começa com # <Tópico> e termina com a última linha da lista de fontes. Nada antes, nada depois.
Se o usuário disser algo diferente daquilo que está em reader-report.md, você deve alterar o arquivo e reemiti-lo — nunca edite na saída.
O reader-report.md deve ser auto-suficiente: se começar com # <Tópico>, o leitor sabe qual é o tópico. Se listar fontes, o leitor pode clicar nelas. Se usar linguagem clara, o leitor entende sem precisar de explicação adicional. É para isso que serve a Etapa 6.
Notas finais
- Se um usuário pedir explicitamente o relatório de trabalho, forneça-o como uma exceção à regra de entrega. Por padrão, eles obtêm o relatório para o leitor.
- Se você ficar sem orçamento (Etapa 2) antes de atingir convergência, o relatório para o leitor dirá exatamente isso: "Após o orçamento de pesquisa alocado, o seguinte permanece não verificado..."
- O valor desta skill depende da independência real das perspectivas. Se você ignora a Etapa 1 e inventa perspectivas, você está apenas gerando respostas mais longas, não pesquisa mais profunda.