hillclimbing

爬山优化

1. 在首次更改前修复检查

• 将标准转化为一项有通过或失败结果的检查，并设置一个会随着工作逐渐接近目标而变化的分数。
• 逐字记录：所述目标和标准、检查及其阈值、保护条件（目前通过且之后仍须通过的检查），以及预算（仅当用户给出预算时）。

如果某项标准无法转化为可检查的内容，现在只询问一次，并提出一项检查。这是唯一计划中的提问。

运行检查和保护条件，获取基线结果。如果检查已通过，报告这一点并停止。将记录和迭代日志保存在工作树之外的进度文件中，并在上下文重置后重新读取。

2. 逐步优化

每次迭代：

• 根据上次运行的证据选择一项更改，且更改幅度要小到足以追溯分数变化的原因。
• 重新运行检查和保护条件。
• 只有在分数提高且每项保护条件都通过时才保留更改；否则，准确还原。
• 记录一行：更改、分数、保留或还原。
• 确保可以恢复到最佳状态。
• 迭代期间绝不询问是否继续。

分数存在噪声时，每次测量都需要多次运行；比较中位数。

连续三次迭代没有提升后，指出每次失败尝试共同依赖的假设，并采取更大幅度的调整来摒弃该假设。绝不重试已还原的更改。陷入平台期不是停止的理由。

3. 绝不改变目标

为达到标准，绝不：

• 编辑、跳过、删除或放宽测试、断言、阈值或检查
• 针对检查输入设置特殊处理，例如硬编码预期输出
• 隐藏检查报告的内容，例如吞掉错误或绕过钩子
• 将检查范围缩小到某个子集或更小的样本

错误的检查（测试断言了旧的缺陷）是用户面临的阻碍，不是要进行的更改。

4. 仅在以下情况之一发生时停止

1. 已达标。 从最终状态重新运行完整检查和所有保护条件。它们均通过。此前通过、运行子集或部分运行都不算。
2. 预算已用尽。 只能是用户给出的预算，绝不能在此自行编造。
3. 受阻于用户。 下一步需要获得许可、凭据、需要确认的破坏性操作或对外操作、在相互冲突的标准之间作出选择，或修正错误的检查。或者，标准已被证明无法达到：指出相关约束及证明这一点的测量结果或来源。“很难”和“多次尝试失败”都不构成证明。先完成所有不受阻碍影响的步骤。

最终报告，按需调整：

Status: met | budget spent | blocked: <what is needed from the user>
Score: <baseline> -> <final> (threshold <threshold>)
Check: <command>
<its output from the final run>
Iterations: <n> (<kept> kept, <reverted> reverted)