specsfy-specialist-prototyping

原型设计

适用场景

• 当存在一个具体的技术、交互或视觉问题，只有可执行产物（而非文档）才能可靠地回答时，启用。
• 在做出难以撤销的决策之前，需要比较两个或多个具体方案时，也启用。
• 如果已有一手资料记录了问题的答案，则不要启用——此时 $specsfy-specialist-technical-research 能更快地解决问题，也无需承担构建成本。
• 不要直接将原型代码用于生产环境——原型有意降低保真度（没有测试覆盖、错误处理或安全性），仅在它可随时丢弃时才是合理选择。

流程

1. 编写任何代码之前，先明确一个问题和判定答案的标准——否则原型就会变成无休止的探索。
2. 明确哪些部分必须是真实的（待测试的机制），哪些可以模拟或使用 mock（所有不影响问题答案的部分）。
3. 选择足够满足需求的最低保真度、明确的时间限制，以及代码库中或代码库之外明确可丢弃的位置。
4. 如果直接比较多个方案比只测试一个方案是否符合预期更有参考价值，就构建多个方案。
5. 执行计划好的场景并收集可观察的证据——不要依赖“看起来能用”之类的主观印象。
6. 明确回答最初的问题（接受、拒绝或仍无定论），并记录测试内容的局限性。
7. 丢弃原型，或明确归档为非生产代码；不要留下任何指向它的运行时依赖。

模式

• 不要把有说服力的演示误认为有效的架构——一个“演示中能用”的原型，并不能证明它在并发、扩展性、错误处理或安全性方面表现如何，除非这些方面经过了有意的测试。
• 将真实数据、生产凭据和真实集成排除在原型之外，除非问题本身要求针对真实系统进行测试（即便如此，也要明确范围并获得授权）。
• 对于界面原型，使用符合实际的内容（不要用“lorem ipsum”）和极端状态（超长文本、空列表、错误）——UI 问题很少只关乎正常流程。
• 对于逻辑或状态原型，通过最小化的界面（CLI、可执行测试）展示状态转换和不变量，使其可供观察；不要把它们藏在与问题无关的完整 UI 后面。
• 不要在问题要求之外花时间进行抽象、增加测试覆盖或打磨视觉效果——这与原型的目的背道而驰。
• 明确标记代码为可丢弃，并防止生产代码意外导入它（使用隔离目录、明确无歧义的名称，不提供公共导出）。
• 将所有有价值的经验转化为正确归属处的需求、决策记录或测试（spec、ADR、backlog）——原型一旦丢弃，就不再是事实来源。

反模式

• 因为“能用”就让“临时”原型继续在生产环境运行——原型有意跳过了完整验证（安全性、错误处理、扩展性），若未经这些验证就用于生产，会带来难以察觉的风险。
• 在同一个原型中同时测试多个问题——结果一旦含糊不清，就无法判断是哪一个变量导致了什么。
• 当问题纯粹关乎某个机制在技术上是否可行时，却投入精力打磨视觉效果或“以防万一”地设计架构。
• 默默继承原型带来的技术债：不按常规质量标准重写，直接将原型文件用作生产代码的基础。

验证

• 决策标准在执行前已确定，其他人运行相同场景即可复现结果。
• 原始问题有明确答案：假设已接受、已拒绝或仍无法得出结论（此时需说明还缺少什么才能作出判断）。
• 已明确记录原型的局限，以及与生产环境要求之间的差异。
• 原型的任何产物都未连接到最终运行时——已验证，而非仅仅假定。
• 不要仅凭原型就宣称某种方案“适用于生产”；这需要按照项目标准完成所述的完整实现和验证。

相关 Skills

• 当问题可通过一手来源回答、无需构建任何内容时，使用 $specsfy-specialist-technical-research。
• 当原型揭示出尚未建模的领域概念时，使用 $specsfy-specialist-domain-modeling——将学到的内容转化为模型，而不是留在一次性代码中。
• 当原型涉及界面，且除了具体问题之外，还需要严谨的流程设计或视觉层级设计时，使用 $specsfy-specialist-ux-design 或 $specsfy-specialist-ui-design。

请阅读 references/standards.md，了解不同问题类型的保真度等级、输出格式和官方来源。