图 05 · 原型边界

如何在不直接上线原型代码的情况下保留原型的决策？

双轨桥梁图：左侧是原型轨（可扔掉的代码，用来回答设计问题），右侧是生产轨（从决策开始，重新构建）。两轨在决策点相遇，原型代码被丢弃，只有决策被保留。

原型边界双轨桥梁图 左侧为原型轨（{prototype}、设计问题、基准测试、丢弃原型代码），中间为决策点（提取ADR），右侧为生产轨（/grill-with-docs更新CONTEXT、/to-spec、/implement、tdd、code-review）。 原型轨（THROWAWAY TRACK） [Agent / 工程] {prototype} 构建可运行实验，回答一个具体的设计问题 设计问题（可运行比讨论便宜） 「EventEmitter vs 直接回调：10k 实体下谁更快？」 需要真实基准测试数据支持架构抉择 观察结果与实测数据 「直接回调快 2.3×，GC 压力低 40%，且更易测试」 实测证明直接回调是更优解 产物 · 决策证据 Benchmark 结果 + 探索笔记 仅作为决策依据，代码本身不具备生产质量 ⊗ 丢弃全部原型代码（Throw Away Code） 原型缺少错误处理、类型守卫与测试，切勿强行推入生产！ 决策点 提取 ADR ✓ 仅保留决策 生产轨（PRODUCTION TRACK） [用户 / 工程] /grill-with-docs 将 ADR 架构决策记录持久化到 CONTEXT.md [用户 / 工程] /to-spec 在决策约束下重新描述行为规范与前置/后置条件 [用户 / 工程] /to-tickets → /implement 从零构建生产实现切片，严禁复用原型捷径代码 [Agent / 工程] {tdd} → {code-review} 先写测试驱动接口，确保测试覆盖率；双轴审查确保无接口扩张 产出：高质量、深实现、小接口的可维护模块 ✓ 生产级可维护交付物（Production Code） 具备完整测试套件、错误处理、类型守卫与架构记录

什么时候值得做原型？

  • 存在一个具体的设计问题，可运行的实验比讨论更便宜
  • 有两个以上的选项，性能或 DX 差异需要实测才能判断
  • 原型结果可以转化为一个 ADR（架构决策记录）

不适合做原型的情况：如果问题可以通过 /research（文档查阅）回答，原型浪费时间。

原型代码为什么要丢弃？

原型优化速度而非质量：没有测试、没有错误处理、耦合严重。把原型代码硬推进生产轨会积累技术债。决策点的作用是提取观察到的「事实」，丢弃实现的「捷径」。

实例：EventEmitter vs 直接回调

原型轨内容

用 Vitest bench 在 1k/10k/100k 实体规模下运行两种实现，测量每次 activate() 的平均耗时和 GC 压力。测试文件约 120 行，不含任何错误处理。

决策点提取的 ADR

ADR-003: 使用直接回调而非 EventEmitter
理由：在 10k 实体下快 2.3×，且测试中不需要 mock EventEmitter。代价：需要自己管理取消注册。

线性阅读顺序：识别一个具体的设计问题（哪种实现更好）→ {prototype} 构建可扔掉的实验 → 观察结果（基准测试、DX 测试）→ 决策点：提取 ADR，丢弃原型代码 → 生产轨从 /grill-with-docs 更新 CONTEXT.md 开始 → /to-spec 在决策约束下重写 → /to-tickets → /implement → {tdd} → {code-review}。
相关技能
{prototype} {research} /grill-with-docs /to-spec /to-tickets {tdd}