simmer-setup

Simmer 设置

检查产物，推断“更好”意味着什么以及如何衡量，向用户提出评估方案，并生成驱动整个优化循环的设置简报。

**核心原则：**先检查，再推断，然后提出，最后确认。由 Agent 负责思考——用户进行验证、调整或否决。绝不询问用户描述 Agent 能读取的内容。

阶段 1：识别并检查

识别产物

查找：

• 上下文中提及或打开的文件路径
• 用户粘贴的文本
• 目录路径或工作区
• 从零开始生成内容的描述（无种子模式）

如果有歧义，只询问一次：

What are we refining?
1. A file (give me the path)
2. Something you'll paste
3. A workspace/directory (give me the path)
4. Generate from a description (I'll create the starting point)

设置模式和产物类型：

模式	产物类型	适用情况
from-file	单文件	用户提供文件路径
from-paste	单文件	用户粘贴内容
from-workspace	工作区	用户提供目录路径
seedless	单文件或工作区	用户描述要创建的内容

检查产物

对于单文件（from-file 或 from-paste）：

• 读取文件/内容
• 确定产物类型（散文、代码、提示词、配置等）
• 记录任何评估器引用（注释中提及的测试命令、基准测试脚本）
• 记录内容中可见的输出格式要求

对于工作区（from-workspace）：

• 列出目录内容
• 读取关键文件：配置文件、入口点、脚本、README
• 特别查找：
  • 评估器脚本：名为 evaluate.*、test.*、benchmark.* 的文件，或配置/README 中引用的脚本
  • 验证脚本：名为 validate.*、check.* 的文件，或快速测试变体
  • 配置文件：config.json、config.yaml、.env 等——这些文件会揭示哪些参数可以调整
  • 输出示例：任何示例输出、预期输出或真实值文件
  • 策略/插件目录：如 strategies/、plugins/、models/ 等目录，表明存在可扩展点
  • 提示词文件：prompt.md、system.txt、模板文件——生成器可修改的内容 对于无种子模式：
• 无需检查——根据用户的描述进行处理
• 根据描述对产物类型进行分类

阶段 2：分类并推断

问题类别检测

根据检查时发现的内容推断问题类别。绝不询问用户这属于哪一类。

IF mode == "seedless" AND description is prose/creative:
    → text/creative

ELSE IF artifact_type == "workspace" AND (evaluator script found OR user mentioned evaluator):
    → pipeline/engineering

ELSE IF evaluator found OR artifact is code:
    → code/testable

ELSE:
    → text/creative

各类别的推断内容

文本/创作——仅推断标准：

• 根据产物类型建议 2-3 项标准（参见下方的种子标准表）
• 不设契约、评估器或搜索空间
• 此路径应保持轻量

代码/可测试——推断标准 + 评估方式：

• 根据代码用途建议标准
• 如果找到评估器脚本，将其记录为拟议的评估器
• 如果代码会生成结构化输出，则根据其格式推断输出契约
• 记录代码中可见的任何约束（模型引用、API 端点等）

流水线/工程——推断所有内容：

• 标准：根据评估器输出指标推断（如果能读取评估器脚本，请查看它衡量的内容）
• 评估器：检查时找到的评估器脚本
• 输出契约：根据流水线输出格式、评估器要求或示例输出推断
• 验证命令：使用找到的快速测试脚本，或提出子集运行方案（例如，“仅对 1 个输入运行，而非全部 N 个”）
• 搜索空间：根据配置参数（模型、温度、策略）、可扩展点（策略目录）和提示词文件推断
• 背景信息：根据配置值（API 端点、已配置的模型名称）和目录结构推断

种子标准表

提出标准时使用。Agent 应优先采用根据实际制品推断出的标准，而不是这些通用种子标准。

制品类型	建议标准
文档 / 规范	清晰度、完整性、可执行性
创意写作	叙事张力、具体性、风格一致性
电子邮件 / 沟通内容	价值主张的清晰度、语气契合度、行动号召的力度
提示词 / 指令	指令精确度、输出可预测性、边缘情况覆盖度
API 设计	契约完整性、开发者体验、一致性
代码（非烹饪赛）	简洁性、健壮性、可读性
冒险钩子 / 游戏内容	叙事张力、玩家自主性、具体性
博客文章 / 文章	论点清晰度、吸引力、结构
流水线 / 工作流	覆盖度、效率、噪声
配置 / 基础设施	正确性、资源效率、可维护性

阶段 3：提出方案或直接继续

充分性检查： 提出方案前，检查用户的初始提示和检查结果是否已包含制定简报所需的全部信息：

• 是否已确定制品？（路径、内容或描述）
• 是否能确定标准？（用户已说明，或可从评估器推断）
• 是否已说明首要标准？（用户已说明，或对于文本 / 创意内容不适用）
• 是否已知评估方法？（已找到评估脚本，或文本仅由评审判断）
• 迭代次数？（用户已说明，或默认为 3 次）

如果所有字段都已涵盖（来自用户提示和检查结果），则跳过方案，直接进入阶段 5（生成简报）。作为子 Agent 运行时，这是常见情况——调用提示会提供意图 / 约束，检查则会补齐契约。

**如果有些字段缺失或含糊不清，**则将所有推断内容作为一次完整的对话式评估呈现。用户可以确认、调整或覆盖。这只发一条消息，不要连续提问。

文本 / 创意内容评估

This is a [artifact type] — I'll use judge-only evaluation (no scripts to run).

For criteria, I'd suggest:
- [criterion 1]: [inferred description of what good looks like]
- [criterion 2]: [inferred description]
- [criterion 3]: [inferred description]

3 iterations, starting from [seed description].
Sound right, or want to adjust anything?

代码 / 可测试内容评估

This is [what the code does]. I found [evaluator/test script] which I'll
use to evaluate each iteration.

For criteria:
- [criterion 1]: [inferred from evaluator metrics or code purpose]
- [criterion 2]: [inferred]
- [criterion 3]: [inferred]

[If output contract inferred]: Output should be [format description].
[If constraints found]: I see [model/API/resource constraints].

3 iterations. Which criterion matters most, or are they equal?

流水线 / 工程内容评估

This is a pipeline optimization problem. Here's what I found:

**Evaluator:** [script path] — measures [what it measures, from reading the script]
**Output contract:** [inferred from pipeline output format / evaluator expectations]
**Validation:** [script path or proposed subset command] — [what it checks, estimated time]
**Search space:** [inferred from config + directory structure]
  - Models: [from config values]
  - Prompts: [prompt files found]
  - Topology: [strategy dirs, extensibility points]

For criteria:
- [criterion 1]: [from evaluator metrics] — [primary?]
- [criterion 2]: [from evaluator metrics]
- [criterion 3]: [from evaluator metrics]

**Constraints:** [API endpoints, available infrastructure from config]

[N] iterations. Does this look right? Anything to add or change?

用户可以怎么做

用户可以：

• 直接确认（“看起来不错”“是”“继续”）→ 继续生成简报
• 调整具体内容（“把首要标准改为 X”“将 Y 加入搜索空间”）→ 纳入调整后继续
• 覆盖推断（“不，实际的评估器是 X”“忽略那个脚本”）→ 替换推断值
• 补充信息（“我还可以使用模型 A 和 B”“预算是 $X”）→ 合并到简报中
• 要求澄清（“评估器实际上测量什么？”）→ 解释后重新提出方案

目标是只确认一轮。 如果用户的调整很明确，就将其纳入并生成简报。除非用户要求查看更新后的评估，否则不要重新提出方案。

阶段 4：询问缺失信息

用户确认方案后，如果关键字段仍未知，只询问无法推断的信息。说明每个问题的必要性。

可能无法推断的信息示例：

• 首要标准（如果用户的初始请求中不明显）
• 文件中看不到的背景约束（预算、截止日期、可用硬件）
• 用户是否希望探索可见参数之外的选项

不要询问已经推断出的信息。 如果你找到了 evaluate.sh 并读过它的评估内容，就不要问“应该如何评估？”

最多 3 项标准。 如果从评估器推断出的标准超过 3 项，就提出影响最大的 3 项。如果用户在初始请求中提到了标准，应优先采用这些标准，而不是推断出的标准。

每项标准都需要描述什么样的表现算 10/10。如果能从评估器推断出来（例如，根据覆盖率指标得出“100% 覆盖率”），就直接采用。如果无法推断，则询问：“[标准] 达到 10/10 应该是什么样？”

阶段 5：输出设置简报

请严格按以下格式生成——后续每个子技能都会使用此格式：

ARTIFACT: [full content if from-paste, file path if from-file, directory path if from-workspace, description if seedless]
ARTIFACT_TYPE: [single-file | workspace]
CRITERIA:
  - [criterion 1]: [what a 10/10 looks like]
  - [criterion 2]: [what a 10/10 looks like]
  - [criterion 3]: [what a 10/10 looks like]
PRIMARY: [criterion name — omit if equally weighted]
EVALUATOR: [command to run — omit for judge-only]
BACKGROUND: [constraints and resources — omit if not provided]
OUTPUT_CONTRACT: [valid output format description — omit for text/creative]
VALIDATION_COMMAND: [quick check command — omit if no cheap validation exists]
SEARCH_SPACE: [what's in scope to explore — omit if unconstrained]
JUDGE_MODE: [single | board — auto-select, see below]
ITERATIONS: [N]
MODE: [seedless | from-file | from-paste | from-workspace]
OUTPUT_DIR: [path, default: docs/simmer]

默认迭代次数为 3。若用户指定了其他次数（“反复打磨 10 轮”），则按指定次数执行。不要询问迭代次数——默认值为 3。

自动选择评审模式

根据问题复杂度选择 JUDGE_MODE。不要询问用户——根据产物和评审标准推断。

条件	JUDGE_MODE
文本/创意内容，且评审标准 ≤2 条，且产物简短（邮件、推文、标语、单段文字）	single
文本/创意内容，且评审标准有 3 条，或产物较长/复杂	board
代码/可测试内容（任何情况）	board
流水线/工程项目（任何情况）	board

**用户指定覆盖：**如果用户说“使用单个评审者”，则使用 single。如果用户说“使用评审团”或“使用评审小组”，则使用 board。以用户意图为准——但要检查是否存在不匹配：

**复杂度不匹配提示：**如果用户要求单个评审者，但产物较复杂（工作区、存在评估器、3 条评审标准、代码/流水线），则提示一次：

“这是一个[工作区/流水线/复杂]产物，包含[ N 条评审标准/一个评估器/多个文件]——使用评审团能更好地诊断问题。你想改用评审团，还是坚持使用单个评审者？”

只问一次。如果用户选择单个评审者，则尊重其选择并继续。

OUTPUT_DIR 默认为 docs/simmer。如果用户指定了其他位置，或当前在测试/临时环境中运行，则覆盖默认值。

将此简报返回给编排器。不要继续生成或评审——这些工作由编排器负责。

示例流程

文本/创意（尽量减少步骤）

User: "Simmer a DND adventure hook for a one-shot session.
The party is level 5, exploring a haunted lighthouse."

Agent: [no inspection needed — seedless creative writing]

Agent: "This is a creative writing piece — I'll use judge-only evaluation.

For criteria I'd suggest:
- Narrative tension: scenes have stakes, time pressure, and consequences
- Player agency: multiple meaningful decision points, not just a railroad
- Specificity: concrete details (names, descriptions, sensory hooks) not generic fantasy

3 iterations, seedless. Sound right?"

User: "yes"

→ Emit brief, hand to orchestrator

流水线/工程项目（全面检查）

User: "Simmer this pipeline at /tmp/pipeline —
I want the best model/prompt/topology for extracting entities."

Agent: [reads directory: config.json, run_pipeline.py, prompt.md,
        evaluate.sh, validate.sh, strategies/]
       [reads config.json: model=qwen3.5:4b, strategy=single-call]
       [reads evaluate.sh: measures coverage, precision, tokens per video]
       [reads validate.sh: runs 1 video, checks JSON format]
       [reads prompt.md: extraction prompt with JSON schema]
       [reads run_pipeline.py: supports pluggable strategies from strategies/ dir]

Agent: "This is a pipeline optimization problem. Here's what I found:

**Evaluator:** ./evaluate.sh — runs all 3 test videos, measures coverage
against ground truth, precision, and token count per model.
**Output contract:** JSON object with 'entities' array, each element has
'name' (string) and 'type' (string). Inferred from pipeline output format
and evaluator expectations.
**Validation:** ./validate.sh — runs 1 video, checks output is valid JSON
with correct schema. Takes ~1 min vs 5-30 min for full eval.
**Search space:**
  - Models: currently qwen3.5:4b in config.json (what else is available?)
  - Prompts: prompt.md (unlimited changes)
  - Topology: single-call currently, but run_pipeline.py supports pluggable
    strategies from strategies/ dir — multi-call is explorable

For criteria:
- Coverage: extracts maximum entities from ground truth (primary?)
- Efficiency: lowest token count while maintaining coverage
- Noise: minimal false positives

What models do you have available? And is coverage the primary goal?"

User: "qwen3.5 4b/9b/27b on Ollama. Yes, coverage is primary. 5 iterations."

→ Emit brief with all inferred + confirmed values

代码/可测试内容（轻量检查）

User: "Simmer this extraction prompt at local_extract_test.py as PROMPT_V4_FULL"

Agent: [reads local_extract_test.py — finds prompt, test harness,
        evaluator command pattern]

Agent: "This is a prompt optimization with a test harness. I see the evaluator
runs via: OLLAMA_MODEL=qwen3.5:27b python3 local_extract_test.py v4_full

Output should be JSON with 'entities' array (name + type from the taxonomy).

For criteria:
- Coverage: extracts every entity from ground truth
- Noise: zero false positives
- Conceptual depth: captures painting theory, not just concrete items

Which matters most?"

User: "Coverage is primary. 3 iterations."

→ Emit brief

常见错误

让用户描述你可以直接查看的内容

• 问题：用户不得不描述工作区里现成的文件
• 解决方法：先读取文件。只询问无法推断的信息。

提供表单，而不是评估结论

• 问题：当 evaluate.sh 已明确说明预期格式时，还询问“有效输出是什么样的？”
• 解决方法：读取评估器，推断要求并提出方案。

接连提出过多问题

• 问题：开始工作前要来回沟通 6-8 次
• 解决方法：在一条评估消息中提出所有内容。由用户确认或调整。

不读取评估器/验证脚本

• 问题：Agent 知道脚本存在，却不读取以了解它们评估的内容
• 解决方法：读取脚本。提取指标、格式和预期要求。

对文本/创意内容检查过度

• 问题：创意写作不需要检查工作区、要求或验证
• 解决方法：文本/创意流程保持轻量——建议评审标准、确认，然后继续。

提出超过 3 条评审标准

• 问题：评审信号被稀释，生成器试图同时解决过多问题
• 解决方法：最多 3 条；如果推断出更多，则请用户确定优先级。

不询问 10/10 的标准

• 问题：评审标准模糊，评审者缺少评分依据
• 解决方法：尽可能根据评估器指标推断 10/10 的标准。无法推断时再询问。

开始生成或评审

• 问题：设置阶段的任务仅限生成简报
• 解决方法：将简报返回给编排器，然后停止。

强制要求评估器的输出格式

• 问题：用户不得不修改现有脚本以符合要求
• 解决方法：不对评估器输出格式做任何要求——由评审者解读其输出。

细微调整后重新提出方案

• 问题：用户说“把主要项改成 X”，Agent 却重新展示整份评估内容
• 解决方法：纳入调整后生成简报。仅当用户要求重新审阅时，才重新提出方案。