auto-optimize

name	auto-optimize
description	迭代优化任何具有可量化指标的对象的标准流程。可用场景包括但不限于代码、提示词、文档、配置、流程、模型、交易策略等的优化。强调先定义目标和评估，再做受控迭代。
user-invocable	true

auto-optimize

用于“优化任何具有可量化指标的对象”的标准流程。可用场景包括但不限于代码、提示词、文档、配置、流程、模型、交易策略等的优化。强调先定义目标和评估，再做受控迭代。

使用该skill下的脚本 start_optimization.sh 可以快速生成一个包含上述内容的模板文件，帮助你梳理和记录优化过程。

开始前需要预先在文档或者对话中明确以下内容，其中一些是可选的，需要你根据具体情况判断是否每项是否必要：

• 优化对象和范围。
• 优化目标和成功标准。
• 指标定义、评估方法和基线。
• 约束条件和不可破坏属性。
• 实验预算和停止条件。 并将这些信息维护到 AGENT.md 中。

你的优化过程应该遵循以下步骤：

1. 创建一个专门的项目文件夹，整理相关文档、代码和评估工具。并使用git进行管理，确保每轮改动都能清晰追踪和回滚。 AGENT.md 和 optimization_history.json 等文档也应该放在这个文件夹中，但是必须被ignore掉，不要提交到git。始终维持main分支为最优的版本，所有改动都在分支上进行。
2. 明确问题和目标，并写入到项目的 AGENT.md 中。
3. 设计并验证评估方法，构建可靠的可复用的评估工具，测算评估所需的时间和资源预算。关键信息记录到 AGENT.md 中。
4. 建立基线版本。
5. 评估当前版本的指标，记录结果到 optimization_history.json 中。
6. 判断是否达到停止条件或成功标准，如果是，输出当前最优方案和后续建议；如果否，继续下一步。
7. 判断是否破坏了约束条件，如果是，放弃改动并记录原因，跳到第9步；如果否，继续下一步。
8. 判断当前结果是否优于上一个版本，如果是，merge到main分支，并记录结果；如果否，放弃改动并记录原因。
9. 基于当前结果和结论，选择下一轮改动的方向和内容，回到第5步。如有必要的话可以先进行充分的调研，形成明确的假设，再进行改动。

optimization_history.json

你需要将优化过程记录到一个结构化的文件中，例如 optimization_history.json，每轮记录以下内容：

• round: 实验轮数。
• git_commit: 相关改动的git commit hash。
• change: 核心改动点。
• evaluation: 评估结果，包括主指标和护栏指标，还有时间和资源开销。
• decision: 保留还是放弃。
• notes: 其他相关信息，例如遇到的挑战、学到的经验、下一步计划等。 除此之外，还应该在每轮结束时总结出关键经验教训，记录在 key_learnings 字段中。这些经验教训应该是具体的、可操作的，并且能够指导后续的优化工作。这个字段是全局的，不是每轮的，而是随着优化过程的推进不断更新和完善的。 此外，还需要在优化过程中维护：
• best_round 字段，记录当前最优版本对应的实验轮数序号。
• status 字段，记录当前优化状态，例如 "not_started"、"in_progress"、"succeeded"、"aborted" 等。
• metric_directions 字段，记录各指标的优化方向。默认指标按越大越好处理；如果某个指标越小越好，必须显式写成 "min"，例如 "latency_ms": "min"。可视化脚本会用它判断突破轮次。

初始的optimization_history.json文件可以使用start_optimization.sh脚本生成，内容为：

{
  "rounds": [],
  "status": "not_started",
  "best_round": null,
  "metric_directions": {},
  "key_learnings": []
}

Use This Skill When

• 用户明确表示想优化某个对象，例如代码、提示词、文档、配置、流程或模型使用方式。
• 用户希望 AI 能全自动的进行多轮改动和验证，而不是只给出一次性建议。
• 用户需要比较多个候选改动，并基于证据决定保留或放弃。

Do Not Use This Skill When

• 用户要的是一次性修复，而不是优化迭代。
• 用户没有给出目标，也不允许澄清。
• 优化结果无法验证，只能靠纯主观判断，且用户也没有给出明确比较标准。
• 单次验证成本过高，无法支撑小步实验。
• 用户只要求回答原理，不要求形成执行流程。

Core Principles

• 先定义成功，再提出改动。没有成功标准，就没有优化。
• 没有基线，就没有“变好”。所有优化都必须与当前状态比较。
• 主指标必须少。通常一个主指标，加少量护栏指标即可。
• 护栏指标必须明确。不能为了局部收益破坏关键质量属性。
• 单轮实验必须可归因。一次不要混入多个主要变量。
• 优化服从约束。更快、更短、更便宜不自动等于更好。
• 证据优先于直觉。结论来自验证，而不是“看起来更好”。
• 连续无收益时应停止并复盘，而不是机械继续。

Required Clarification

开始优化前，先确认信息充分。缺任何关键项时，先向用户补充，不要擅自脑补。