specsfy-specialist-prototyping

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Prototipação

原型构建

Quando usar

适用场景

Acionar quando existe uma pergunta técnica, de interação ou visual específica que só um artefato executável (não um documento) consegue responder com confiança.
Acionar também para comparar duas ou mais alternativas concretas antes de uma decisão cara de reverter.
Não acionar quando a pergunta já tem resposta documentada em fonte primária — nesse caso
```
$specsfy-specialist-technical-research
```
resolve mais rápido e sem o custo de construir algo.
Não promover o código do protótipo diretamente a produção — a fidelidade reduzida do protótipo (sem cobertura, sem tratamento de erro, sem segurança) é uma escolha deliberada válida apenas enquanto ele é descartável.

当存在特定的技术、交互或视觉问题，且只有可执行制品（而非文档）能可靠回答时，启动此流程。
当需要在做出难以逆转的高成本决策前，比较两种或多种具体方案时，也可启动此流程。
若问题已在原始来源中有文档化答案，则请勿启动此流程——这种情况下，
```
$specsfy-specialist-technical-research
```
能更快解决问题，且无需承担构建成本。
不得将原型代码直接投入生产——原型的低保真度（无测试覆盖、无错误处理、无安全防护）是刻意选择的，仅在其作为可丢弃制品时才合理。

Fluxo

流程

Formular uma única pergunta e o critério que decide a resposta antes de escrever qualquer código — sem isso, o protótipo vira exploração sem fim.
Definir o que precisa ser real (o mecanismo sob teste) e o que pode ser simulado ou mockado (tudo que não afeta a resposta à pergunta).
Escolher a fidelidade mínima suficiente, um tempo limite explícito e um local claramente descartável no repositório ou fora dele.
Construir mais de uma alternativa quando a comparação direta entre elas for mais informativa que testar uma só contra a expectativa.
Executar o cenário planejado e coletar evidência observável — não impressão subjetiva de "parece que funciona".
Responder à pergunta original explicitamente (aceita, rejeitada ou ainda inconclusiva) e registrar as limitações do que foi testado.
Descartar o protótipo ou arquivá-lo explicitamente como não-produção, sem deixar nenhuma dependência de runtime apontando para ele.

在编写任何代码前，明确提出单一问题及判定答案的标准——否则原型会沦为无目的的探索。
确定需要真实实现的部分（待测试的核心机制）以及可模拟或 mock 的部分（所有不影响问题答案的内容）。
选择最低必要的保真度、明确的时间限制，以及在仓库内或仓库外的可明确丢弃位置。
当直接对比多种方案比单独测试一种方案更能获取有效信息时，构建多个备选原型。
执行规划好的场景，收集可观测的证据——而非“看起来可行”的主观印象。
明确回答原始问题（接受、拒绝或仍无定论），并记录测试内容的局限性。
丢弃原型或明确将其归档为非生产制品，确保没有任何运行时依赖指向它。

Padrões

最佳实践

Não confundir uma demo convincente com uma arquitetura válida — um protótipo que "funciona na demo" não provou nada sobre concorrência, escala, erro ou segurança que não foi deliberadamente exercitado.
Manter dados reais, credenciais de produção e integrações reais fora do protótipo, salvo quando a própria pergunta exige testar contra o sistema real (e mesmo assim, com escopo e autorização explícitos).
Para protótipo de interface, usar conteúdo realista (não "lorem ipsum") e estados extremos (texto muito longo, lista vazia, erro) — a pergunta sobre UI raramente é sobre o caminho feliz.
Para protótipo de lógica/estado, expor as transições e invariantes numa interface mínima (CLI, teste executável) que as torne observáveis, em vez de escondê-las atrás de uma UI completa desnecessária à pergunta.
Não gastar tempo com abstração, cobertura de teste ou acabamento visual fora do que a pergunta exige — isso é o oposto do propósito do protótipo.
Marcar o código como descartável de forma que impeça import acidental por código de produção (diretório isolado, nome inequívoco, sem export público).
Converter todo aprendizado relevante em requisito, decisão registrada ou teste no owner correto (spec, ADR, backlog) — o protótipo em si não é fonte de verdade depois de descartado.

不要将有说服力的演示等同于有效的架构——“演示中可行”的原型，并未证明任何未刻意测试的并发、扩展、错误处理或安全相关能力。
除非问题本身要求测试真实系统，否则请勿将真实数据、生产凭据和真实集成纳入原型（即便需要，也要有明确的范围和授权）。
对于界面原型，使用真实内容（而非“Lorem Ipsum”占位文本）和极端状态（超长文本、空列表、错误状态）——UI相关问题很少只涉及理想路径。
对于逻辑/状态原型，在最小化界面（CLI、可执行测试）中暴露状态转换和不变量，使其可观测，而非将其隐藏在与问题无关的完整UI背后。
不要在问题所需范围之外，花费时间进行抽象、测试覆盖或视觉优化——这与原型的目的背道而驰。
将代码标记为可丢弃，避免被生产代码意外引用（使用独立目录、明确命名、不公开导出）。
将所有相关经验转化为对应负责人管理的需求、已记录的决策或测试（规格文档、架构决策记录ADR、待办事项）——原型被丢弃后，其本身不再是事实依据。

Antipadrões

反模式

Deixar o protótipo "temporário" rodando em produção porque "funcionou" — sem a validação completa (segurança, erro, escala) que o protótipo deliberadamente pulou, ele carrega risco invisível para produção.
Testar várias perguntas ao mesmo tempo no mesmo protótipo — quando o resultado é ambíguo, não dá para saber qual variável causou o quê.
Investir em polimento visual ou arquitetura "só por garantia" quando a pergunta era puramente sobre viabilidade técnica de um mecanismo.
Herdar a dívida do protótipo silenciosamente: reaproveitar o arquivo do protótipo como base do código de produção sem reescrevê-lo com os padrões normais de qualidade.

因为原型“可行”，就让“临时”原型在生产环境运行——原型刻意跳过了完整的验证（安全、错误处理、扩展），会给生产环境带来隐形风险。
在同一个原型中同时测试多个问题——结果模糊时，无法确定是哪个变量导致的问题。
当问题仅涉及某一机制的技术可行性时，仍投入精力进行视觉优化或“为了稳妥”的架构设计。
隐性继承原型的技术债务：将原型文件直接作为生产代码的基础，而未按照常规质量标准重写。

Validação

验证

O critério de decisão foi definido antes da execução, e o resultado é reproduzível por outra pessoa que rode o mesmo cenário.
A pergunta original tem resposta explícita: hipótese aceita, rejeitada ou ainda inconclusiva (e, nesse caso, o que falta para decidir).
As limitações do protótipo e as diferenças em relação ao que produção exigiria estão registradas explicitamente.
Nenhum artefato do protótipo permanece conectado ao runtime final — verificado, não apenas assumido.
Não declarar uma abordagem "viável para produção" só com base no protótipo — isso exige a implementação e validação completas descritas no padrão do projeto.

决策标准已在执行前定义，且其他人员运行相同场景可复现结果。
原始问题得到明确回答：假设被接受、拒绝或仍无定论（若为后者，需说明还需哪些信息才能决策）。
原型的局限性以及与生产环境要求的差异已被明确记录。
原型的任何制品均未与最终运行环境关联——需进行验证，而非仅假设。
不得仅基于原型就宣称某方案“适用于生产”——这需要项目标准中描述的完整实现和验证流程。

specsfy-specialist-prototyping

Original

Translation

Prototipação

原型构建

Quando usar

适用场景

Fluxo

流程

Padrões

最佳实践

Antipadrões

反模式

Validação

验证

Skills relacionadas

相关技能