名称: 测试厨房 description: 该技能应在实施具有并行探索或竞争特性的功能时使用。触发条件包括“构建”、“创建”、“实施”、“尝试两种方法”、“比较实现方案”。可路由至omakase-off（设计探索的入口门）或cookoff（并行实施的出口门）。
测试厨房
并行实施框架，包含两个门控技能：
| 技能 | 门控 | 触发条件 |
|---|---|---|
test-kitchen:omakase-off |
入口 | 任何构建/创建/实施请求的首次触发 |
test-kitchen:cookoff |
出口 | 在设计→实施过渡时 |
流程
“构建X” / “创建Y” / “实施Z”
↓
┌─────────────────────────────────────┐
│ OMAKASE-OFF (入口门) │
│ 包装头脑风暴 │
│ │
│ 选择： │
│ 1. 一起头脑风暴 │
│ 2. Omakase (3-5个并行设计方案) │
└─────────────────────────────────────┘
↓
[头脑风暴 / 设计阶段]
↓
设计完成，“让我们实施”
↓
┌─────────────────────────────────────┐
│ COOKOFF (出口门) │
│ 包装实施 │
│ │
│ 选择： │
│ 1. Cookoff (2-5个并行智能体) │
│ 2. 单个子智能体 │
│ 3. 本地实施 │
└─────────────────────────────────────┘
↓
[实施阶段]
核心洞察
技能需要积极的触发条件才能工作。 它们不能被动地检测“不确定性”或“准备就绪”——它们必须占据对话流中的特定时刻。
- Omakase-off：占据构建/创建时刻（头脑风暴之前）
- Cookoff：占据实施时刻（设计之后）
触发时机
Omakase-off (三种触发条件)
触发条件1：头脑风暴之前
- “我想构建…”、“创建一个…”、“实施…”、“添加一个功能…”
- 任何开始构建某物的信号
- 提供选择：一起头脑风暴 或 Omakase（并行设计）
触发条件2：头脑风暴期间（槽位检测）
- 在架构决策上出现2次以上不确定的回应
- “不确定”、“不知道”、“都可以”、“你选吧”、“没偏好”
- 提议并行探索检测到的槽位
触发条件3：明确请求
- “尝试两种方法”、“探索两种方案”、“omakase”
- “实施两种变体”、“让我们看看哪个更好”
Cookoff
- “让我们实施”
- “看起来不错，开始构建吧”
- “准备编码”
- 设计文档刚刚提交
- 任何从设计转向代码的信号
Omakase模式（跳过头脑风暴）
如果用户在入口门选择“Omakase”：
- 快速收集上下文（1-2个问题）
- 生成3-5个最佳架构方案
- 并行实施所有方案
- 通过测试选出优胜者
- 完全跳过详细的头脑风暴
最适合：“我很灵活，用可运行的代码展示选项给我看”
Cookoff模式（并行实施）
如果用户在出口门选择“Cookoff”：
- 每个智能体阅读同一份设计文档
- 每个智能体创建自己的实施计划
- 所有智能体并行实施
- 比较结果，选出优胜者
最适合：“我想看到不同的实施方法”
关键区别
| Omakase-off | Cookoff | |
|---|---|---|
| 门控 | 入口（头脑风暴之前/期间） | 出口（设计之后） |
| 问题 | 如何探索？ | 如何实施？ |
| 并行对象 | 不同的设计方案 | 相同设计，不同的实施计划 |
| 触发条件 | 构建请求、犹豫不决检测、明确请求 | “让我们实施”信号 |
| 跳过内容 | 头脑风暴（可通过短路方式选择） | 无 - 总是在设计之后 |
槽位检测（头脑风暴期间）
当omakase-off将任务委托给头脑风暴时，它会被动跟踪用户表现出不确定性的架构决策：
检测信号：
- “不确定”、“不知道”、“都可以”、“听起来都不错”
- “你选吧”、“你觉得呢”、“没偏好”
- 用户连续推迟2个以上决策
槽位分类：
| 类型 | 示例 | 值得探索吗？ |
|---|---|---|
| 架构性 | 存储引擎、框架、认证方法 | 是 - 不同的代码路径 |
| 琐碎性 | 文件位置、命名、配置格式 | 否 - 易于更改 |
头脑风暴结束时：
- 如果存在架构性槽位 → 提供并行探索
- 如果没有槽位 → 交给cookoff进行实施