izittmarvin/agent-skills-zh/prototype

原型

原型是用来回答问题的可丢弃代码。问题本身决定原型应采用什么形态。

选择分支

先确定当前要回答的问题。可以根据用户的提示、周围代码判断；用户在线时，也可以直接询问：

• “这套逻辑或状态模型是否合理？” → 阅读 LOGIC.md。构建一个可分享的单文件 HTML（自由操作按钮加上按 tab 组织的引导走查），让状态机经历那些仅靠纸面推演很难判断的场景，并且非开发者也能亲自操作。
• “它应该长什么样？” → 阅读 UI.md。在同一个路由中生成几种差异足够明显的 UI 方案，并通过 URL 查询参数和底部悬浮切换栏在各方案之间切换。

两个分支会产出完全不同的成果。选错分支，整个原型都会失去价值。问题确实含糊、用户又暂时无法联系时，根据周围代码选择更匹配的分支：后端模块通常选择逻辑原型，页面或组件通常选择 UI 原型。必须在原型顶部明确写出这一假设。

两个分支都适用的规则

1. 从第一天起就把它当作可丢弃代码，并清楚标明这一点。 将原型放在未来真正使用该设计的位置附近，例如对应模块或页面旁边，使上下文一目了然；同时通过命名明确告诉普通读者，这是原型，不是生产代码。一次性 UI 路由应遵循项目现有的路由约定，不要另外发明顶层目录结构。
2. 启动必须足够简单。 UI 原型使用项目已有任务运行器的一条命令启动，例如 pnpm <name>、python <path>、bun <path>。逻辑演示是用户双击即可打开的单个 HTML 文件。无论哪条分支，启动时都不应再做额外判断。
3. 默认不做持久化。 状态保存在内存中。持久化可以是原型要验证的对象，但不应成为原型运行的依赖。问题明确涉及数据库时，使用临时数据库，或使用名称中清楚写有 “PROTOTYPE, wipe me” 的本地文件。
4. 省略打磨工作。 不写测试，不添加超过“保证原型能运行”所需的错误处理，也不建立抽象层。目标是快速得到结论。
5. 展示完整状态。 逻辑原型在每次操作后输出相关状态；UI 原型在每次切换方案时渲染相关状态，使用户能够直接看到变化。
6. 得到结论后捕获它。 交付原型路径、运行方式、它回答的问题、观察结果与局限。原型中的验证不代表生产环境已经成立。用户只要求原型时到此完成；纳入正式代码、提交分支或更新 Issue，分别遵循当前任务的授权。保留用户仍需查看的原型，不自动删除交付物。