prompt-optimize

提示词优化循环

一种针对提示词的进化式优化器（OpenEvolve / AlphaEvolve 风格）。优化对象是一个提示词，它会输入用户的系统；反馈信号是用户自己的评估命令打印出的标量指标。每轮提出一项以提升质量为目标的修改，重新运行评估，并且仅在指标改善时保留修改——逐步优化提示词以提高分数。评估是循环会运行但绝不会修改的黑盒预言机，因此优化会追踪真正重要的因素，而非钻指标的空子。

适用场景

当用户已有一个提示词和一条用于评估使用该提示词的系统的命令，并希望改进提示词以提高分数时使用。默认情况下，每轮诊断提示词当前最大的弱点，并应用针对该弱点的单一算子；如果评估反馈指向其他问题，则根据反馈调整。不适用于从零编写提示词、调优权重／超参数，或在没有分数可供比较的情况下进行单次手动修改。

设置

以交互方式解析绑定项。如果工作目录中存在 loop.run.yaml，则加载该文件，用一行确认其中的值，然后跳转到循环步骤。否则：在 Claude Code 上（可使用 AskUserQuestion 工具），推断每个绑定项的可能值，并将其作为推荐选项；在其他环境中，逐项以纯文本提问。然后写入 loop.run.yaml（格式：examples/run.example.yaml），并在创建任何其他文件前确认这些值。

绑定项	含义	默认值	推断方式
<prompt_file>	要优化的提示词——循环会不断演进的优化对象	—	扫描工作目录，查找评估所读取的提示词／模板文件
<eval_cmd>	**必填。**用于评估当前 <prompt_file> 的命令；打印指标（参见下方输出约定）。视为黑盒——绝不修改	—	询问用户；查找 eval／score／bench 脚本
<objective>	maximize 或 minimize，另加一行说明指标衡量的内容	maximize	询问用户
<target>	可选的提前停止分数	—	询问用户；否则不绑定
<sandbox_root>	提示词快照和记录账本的存放位置	./sandbox	—
<budget>	最大迭代次数	10	—
<patience>	连续 N 轮未提升后停止（进入平台期）	3	—

评估输出约定。 <eval_cmd> 必须在最后一行打印以下内容之一：JSON 对象 {"score": <number>, "feedback": "<optional notes/errors>", ...any extra metrics...}，或一个裸数字。除非 <objective> 为 minimize，否则分数越高越好。存在 feedback 字段时，它是信息最丰富的信号——像阅读 AlphaEvolve 的 artifacts 侧信道一样阅读它，以决定下一项修改。

评估在用户的环境中运行。 <eval_cmd> 可以调用推理端点或用户已安装的任何工具；循环只会执行命令并读取最后一行。如果提示词由你执行（即没有独立端点的交互式开发），则先使用用户的评估输入运行当前提示词以生成输出，将输出写入 <eval_cmd> 会读取的位置，然后运行 <eval_cmd> 进行评分。

循环

复制此检查清单并逐项勾选：

• 迭代 0 — 基线：运行 <eval_cmd>，使用 <prompt_file>，记录其分数作为当前最佳分数，并快照提示词。
• 根据最新分数、评估反馈和历史记录，诊断提示词最大的单一弱点。
• 对 <prompt_file> 应用一项有针对性的编辑（工具包中的一个操作）。
• 测量：重新运行 <eval_cmd>，并读取其最后一行中的新分数。
• 如果指标有所提升，则保留（如果评估具有随机性，则要求达到一定的提升幅度）；否则还原到最佳快照。
• 追加一行记录；如果陷入停滞，则从较早的高分变体分支；在达到 <target>、平台期（<patience>）或 <budget> 时停止。

迭代 0 — 基线。 运行 <eval_cmd>，将其分数记录为最佳分数，将 <prompt_file> 快照到 <sandbox_root>/iter0/，并开始记录历史（每行包含 {iter, edit, score, feedback}）。

然后，持续迭代直至停止（达到目标、平台期或预算上限）：

1. 诊断。 根据最新分数、<eval_cmd> 的反馈和近期历史记录，指出提示词当前最大的单一弱点——最可能拖累指标的一项问题。

2. 进行一项有针对性的编辑——选择能解决该弱点的工具包操作：

   • 清晰度 — 消除歧义、矛盾和含糊措辞。
   • 上下文 — 补充任务所需但缺失的领域知识、定义或背景信息。
   • 具体性 — 使指令具体明确；明确输出格式；定义什么样的结果算“好”。
   • 结构 — 将提示词按步骤或章节组织；添加一份简短的检查清单。
   • 示例 — 添加一两个展示理想输入 → 输出的示例。
   • 任务拆解 — 将复杂指令拆分为明确且有序的子步骤。
   • 防护措施 — 说明边缘情况以及需要避免的内容。

   每次迭代只做一项改动，以便将其对指标的影响归因于该改动。

3. 测量。 将编辑后的提示词快照到 <sandbox_root>/iter<N>/，运行 <eval_cmd>，并读取最后一行中的新分数。

4. 保留或还原。 如果指标根据 <objective> 有所提升，则保留（如果评估具有随机性，则要求小幅提升，以免仅因噪声而保留）；否则将 <prompt_file> 还原到之前的最佳快照。无论结果如何，都将 {edit, score, feedback} 追加到历史记录中。

5. 跳出局部最优。 如果连续几次迭代都没有提升分数，就不要再做细枝末节的调整——从较早的高分快照分支，或尝试更大幅度的重构（采用不同的任务拆解方式，或换一组全新的示例）。多样化胜过在同一座局部山坡上反复尝试。

停止时，将最佳提示词恢复到 <prompt_file>，并报告分数变化轨迹、哪些编辑推动了指标提升（哪些没有），以及最终提示词。

记录表

<sandbox_root>/ledger.tsv，使用制表符分隔，文本中不得出现逗号。表头：

iter	score	status	edit

status ∈ {baseline, keep, revert}。示例（指标 = 任务准确率，目标为最大化）：

iter	score	status	edit
0	0.42	baseline	original prompt
1	0.61	keep	specificity: define each output label and the exact output format
2	0.61	revert	examples: add 3 few-shot demos — no metric gain
3	0.78	keep	context: add the domain rules the task assumes but never states

报告最佳迭代，不一定是最后一次迭代。

约束

• 指标由用户决定。 不得编辑 <eval_cmd>、其数据或评分方式——这只是在操纵数字，而非改进提示词；评估是此循环唯一的真实标准。
• 只优化提示词，并保留任务意图。 改进任务的指令方式，而不是改变任务要求；不得为了利用评估中的特殊情况而定制提示词，以免影响实际使用。
• 每次迭代只做一项编辑，并通过重新运行完整的 <eval_cmd> 来比较指标，而不是只测单个样本，这样每次分数变化都能归因于该项编辑。
• 报告最佳变体，而不是最后一个。 沙盒是自包含的——不得使用 ../ 跳出。
• 不要暂停循环询问是否继续；持续运行，直到达到目标、进入平台期或用完预算。

停止条件

• 目标值 — 得分达到 <target>（如果已设置）。
• 停滞 — 连续 <patience> 轮没有任何迭代提升最佳得分（每次未提升的迭代都会计入耐心值；保留会将其重置）。
• 预算 — 达到 <budget> 次迭代。