用途
Simmer Generator 是 simmer 的生成器子技能，职责是产出一个改进版的工件（artifact）。它的改进是定向的——基于上一轮评审（judge）给出的 ASI 反馈，而不是从零重写。
输入上下文
该技能会收到以下信息：
- 当前候选：完整工件文本（单文件模式）或工作区路径（工作区模式）
- 标准评分表（criteria rubric）：定义“更好”的含义，通常为 2-3 条带描述的标准
- ASI：本轮要追求的最高杠杆方向（来自上一轮评审）
- 迭代编号：当前是第几轮
- 工件类型：单文件或工作区
- 背景（可选）：约束、可用资源、领域知识
- 评审团审议摘要（可选，若启用评审团）：上一轮评审团得出的结论——需要保留的 WORKING 元素、需要避免的 NOT WORKING 做法、本轮 DIRECTION。该摘要用于执行上下文（例如评审团说“查找表效果好”，可据此决定改动格式），但不用于决定改什么——决定改什么是 ASI 的职责。
该技能不会收到评分历史或之前的候选。这是有意设计的——应依据 ASI 工作，而非依据分数。要信任 ASI：评审团已调查问题、审议并基于证据提出该方向，需熟练执行。
主要能力与使用方式
无种子迭代 1
如果 ASI 说“First iteration — generate initial candidate”：
- 你正在根据描述创建种子工件
- 仔细阅读标准，它们定义了“好”的样子
- 产出一个扎实的初稿，覆盖所有标准
- 不必追求完美，循环会继续优化
单文件模式
- 仔细阅读 ASI。评审已识别出单一最高杠杆的修复点，要专门解决它。
- 不要试图一次修复所有问题。聚焦的改进比分散的编辑更能累积效果。解决 ASI。如果发现其他不冲突的小改进，可以顺带处理，但 ASI 是主要目标。
- 保留有效部分。不要在 ASI 未提及的方面出现回退。例如 ASI 说“CTA 摩擦太大”，就不要重写开头段落。
- 尊重工件的自然范围。当标准要求时可以扩展（例如 API 规范需要种子没有的错误响应）；但对于范围紧凑的工件（推文、标语、邮件主题行），不要超出格式去扩展——在约束内改进。
- 产出完整的改进工件。不是 diff，不是说明，而是完整文本。写入编排器指定的文件路径。
工作区模式
- 仔细阅读 ASI。在工作区模式中，ASI 描述的是战略方向，可能涉及跨多个文件的协同改动。
- 执行完整方向。如果 ASI 说“把推理步骤换成更大的模型，抽取仍用 mini，调整两个提示词”，就在一次迭代中全部完成。这些是一个动作的协同部分，不是彼此独立的修复。
- 使用背景上下文。背景会说明可用资源（模型、API、基础设施约束）。要留在这些边界内。如果 ASI 建议的内容超出约束，找最接近的可行替代方案。
- 直接在工作区中修改。就地编辑文件。编排器通过 git 提交跟踪状态。
- 不要做无关改动。ASI 定义方向——除非 ASI 要求，不要顺便重构配置格式或重组目录结构。
- 当 ASI 要求拓扑或流水线变更（例如从单次调用改为多次调用，需要更新评估器调用流水线的方式）时，可以修改评估器脚本。评估器修改应改变流水线如何运行（拓扑、调用模式、预处理），而不是如何评分。如果修改改变了评分标准（使评估器更宽松或更严格），要明确说明，以便评审考虑。尽可能优先修改 config/prompt 文件——评估器改动更难回滚。Git 跟踪会记录所有改动。
- 在昂贵运行前先验证。做基础设施改动（换模型、改拓扑、改流水线结构）时，在完整评估器运行前先确认流水线仍能产出有效输出。如果 setup brief 中有 VALIDATION_COMMAND，就运行它；否则做最小冒烟测试——一个测试用例、一个输入分块，或以快速/子集模式运行评估器——确认输出格式正确并符合 OUTPUT_CONTRACT（若指定）。若冒烟测试失败，先修复或选择替代方案，避免浪费一整轮迭代。
Setup Brief 字段（工作区模式）
当 setup brief 包含以下字段时：
- OUTPUT_CONTRACT：改动后，在报告成功前验证输出符合该契约。如果改动破坏了契约（例如模型产出 XML 而非 JSON），先修复或回滚，再运行评估器。
- VALIDATION_COMMAND：在做基础设施改动（换模型、改拓扑）后运行它，以低成本验证流水线仍可用。若验证失败，先修复或尝试替代方案——不要把完整评估器运行浪费在坏掉的流水线上。
- SEARCH_SPACE：留在这些边界内。如果 ASI 建议探索搜索空间之外的内容，在边界内找最接近的可行替代方案。若认为应扩展搜索空间，在报告中说明。
输出
单文件模式：
- 将完整改进工件写入：{OUTPUT_DIR}/iteration-[N]-candidate.md（或编排器指定的扩展名）
- 用 2-3 句话报告具体改了什么以及为什么。
工作区模式：
- 直接在工作区目录中修改
- 用 2-3 句话报告具体改了什么以及为什么，并列出修改的文件。
单文件报告示例：
将行动号召从请求 30 分钟演示电话改为提供 2 分钟视频讲解链接。这直接解决了 ASI 关于在冷启动外联场景中降低 CTA 摩擦的要求。
工作区报告示例：
在 pipeline.py 中将推理步骤从 gpt-4o-mini 切换为 claude-sonnet，更新 prompts/reasoning.md 加入模型特定格式，并将 config.yaml 超时调整为 5s 以适配更大的模型。解决了 ASI 关于较小模型推理准确率上限的问题。 修改的文件：pipeline.py, prompts/reasoning.md, config.yaml
常见错误
- 从零重写
- 问题：丢失当前候选中的好部分，引入回退
- 修复：基于 ASI 做定向编辑，保留其余部分
- 工作区模式只做一处微小改动
- 问题：ASI 描述的是协同方向，但生成器只做了一部分
- 修复：执行完整方向——如果 ASI 说“换模型 + 调整提示词 + 更新配置”，三件都做
- 工作区模式做无关改动
- 问题：生成器“改进”了 ASI 未提及的内容，引入噪声
- 修复：专注于 ASI 方向。不要重构、重组或优化不属于当前动作的内容
- 忽略背景约束
- 问题：生成器提出超出可用资源的改动（模型不可用、预算超支）
- 修复：阅读背景上下文，留在边界内
- 为想象中的分数优化
- 问题：你没有分数，只能靠猜
- 修复：依据 ASI 文本工作，而非想象中的评分标准
- 产出 diff 或说明而非完整工件（单文件模式）
- 问题：编排器需要完整文本才能传给评审
- 修复：单文件模式始终产出完整工件
适用场景
适用于需要迭代式改进工件的自动化流程，尤其是由评审给出定向反馈（ASI）后，由生成器执行改进的场景。既可用于单文件工件（如文案、规范），也可用于工作区中跨文件协同的流水线调整。
限制
该技能不接收评分历史或之前的候选，因此不基于分数工作。工作区模式下的改动受背景约束与 SEARCH_SPACE 限制。评估器修改应只改变运行方式而非评分方式，若改变评分标准需明确说明。关于收费、价格、平台支持等信息，资料中暂未提供。