Delimite a decisão antes de construir

“Construir um assistente de IA” é uma capacidade, não uma decisão de produto. Antes do código, nomeie quem usará a saída, o que essa pessoa decide com ela e o que o sistema não pode fazer.

A armadilha: um prompt amplo esconde uma obrigação ampla

Nosso caso sintético recorrente é o Event Brief: ele redige um briefing de evento a partir de notas fictícias para revisão de uma pessoa coordenadora de operações de eventos. “Resuma as notas” deixa em aberto se o rascunho é aconselhamento, atualização de registro ou mensagem para participantes. Cada interpretação exige evidência diferente. A fronteira do produto precisa escolher uma.

Imagine a passagem de bastão. Uma pessoa coordenadora abre uma nota que diz “a sala pode mudar; confirme a sinalização” e pede ajuda antes de um evento movimentado. Um assistente vago poderia inventar uma nova sala, atualizar um registro ou redigir uma mensagem. As três saídas podem parecer úteis. Nenhuma responde à pergunta mais estreita: o que essa pessoa deve verificar primeiro e o que ela pode conferir na nota?

A distinção é prática. Uma decisão de produto nomeia o próximo movimento permitido para uma pessoa definida. Um rótulo de capacidade—“assistente de briefing com IA”—não faz isso. Se duas pessoas razoáveis do time construiriam coisas diferentes a partir da mesma frase, a frase ainda é um pedido de escopo, não um escopo.

O movimento: torne a fronteira inspecionável

Um cartão de escopo registra a menor promessa útil. Neste caso, a saída ajuda uma pessoa que coordena as operações de eventos a decidir o que verificar primeiro. É um rascunho revisável com trechos de origem, não uma recomendação específica do domínio.

Leia o cartão como recusa e como promessa

O diagrama é um caminho de decisão, não uma arquitetura de sistema. A caixa à esquerda é a única entrada desta fatia didática. A caixa do meio registra por que a saída existe e qual falha importa. A caixa à direita é deliberadamente rascunho + trechos: uma pessoa revisora pode comparar uma afirmação com a nota sintética, em vez de aceitar um parágrafo fluente por confiança.

Execute o mesmo pedido em duas versões. A diz: “Redija um item de briefing com o trecho de origem da nota de mudança de sala.” B diz: “Avise aos participantes que a sala mudará.” A fica dentro do cartão: produz material de revisão para a coordenação. B cruza o não objetivo coral porque envia uma mensagem a outro público e cria uma ação externa. O resultado correto para B não é um prompt melhor. É fora de escopo.

scope_card = {
    "user": "event operations coordinator",
    "input": "synthetic event notes",
    "output": "event briefing draft with source spans",
    "decision": "what to verify first",
    "failure": "invented briefing item",
    "non_goal": "domain-specific advice",
}

Use o cartão antes de discutir modelo, interface ou provedor. Se você não consegue preencher um campo sem dizer “depende”, mantenha a incerteza no cartão: escolha uma entrada menor, uma decisão menor ou uma recusa explícita. É assim que APD.2 consegue transformar a fronteira em campos e estados, em vez de herdar ambiguidade como comportamento de produto.