perf

在为了提速而修改代码之前，先进行测量。没有测量依据的速度声明只是猜测。基于猜测做出的改动可能会让代码变慢。

快速路径：如果用户只问某个测得的数值是否成立，不要改代码。阅读 verify 技能，并按照 measurement.md 检查该数值。如果用户只问代码为什么慢，或提供了性能分析文件或跟踪文件，也不要改代码。转到第 4 步，并按照其中引用的文档进行报告。

1. 在测量任何内容之前，创建一个任务列表，并将以下步骤作为其中的任务。如果任务列表已存在，就把这些步骤添加到列表中。跳过某一步时，将其标记为已完成，并在任务文本中添加 skip: <reason>。要返回较早的步骤时，将该步骤及其之后的每一步重新添加为新任务。
2. 用一句话说明目标：操作、输入，以及判定成功的数值。目标取自用户或规范。如果没有人给出目标，就将目标设定为：在真实输入上的提升幅度大于测量结果的波动范围。请明确说明这一点。
3. 构建可重复运行的测量：脚本或命令，以及真实输入。对两种情况各运行至少五次。信任测量结果之前，先按照 measurement.md 检查测量方法。第 4 步会回答其中的第一项检查。记录基线：数值、单位、运行次数和波动范围。
4. 通过观察找出限制数值进一步改善的那个资源。不要根据源代码猜测。使用性能分析器、跟踪记录或计数器。性能分析器会拖慢运行，因此绝不要报告性能分析运行中的数值。对于正在运行的进程，按照 live-process.md 操作。对于已有的性能分析文件、跟踪文件、转储文件或日志文件，按照 capture-file.md 操作。
5. 在限制因素上只改一处，并优先尝试成本最低的改动。先移除结果无人使用的工作；然后让工作只执行一次并保留结果；再减少工作量；然后延后工作；再把工作安排在无人等待时执行；再并行执行。只有最后才降低工作本身的成本。保留结果、延后工作或并行执行工作都可能改变行为。按照 implement 的要求，先编写一个会失败的测试。
6. 使用相同设置再次测量，并交替顺序运行旧版和新版。运行覆盖所改路径的测试。只有测试通过且提升幅度大于波动范围时才保留改动，否则就撤销。保留的改动达到目标后，转到第 7 步；否则返回第 4 步。
7. 报告提升之前，先阅读 verify 技能，并按照其要求运行测试、构建和代码检查工具。测量脚本是提升效果的演示，verify 将其定义为演示。报告提升时，应给出测得的数值，而不是已验证的标准。
8. 报告结果：改动前后的数值，以及各自的单位、运行次数、波动范围和限制因素。说明改动内容和测量所用的输入。

规则：

• 基线建立之前，不得为了提速而改代码。
• 两次测量之间只做一项改动，让每次提升都有唯一原因。
• 对诊断的请求应给出诊断，而非修复。每项发现都要引用证据。
• 死锁、崩溃或错误结果是缺陷，而非速度问题。应通过 debug 修复。
• 不要调优测量结果未显示为限制因素的代码。
• 连续三次改动的提升均未超过波动范围时，停止。报告测量结果和限制因素，并让用户决定。
• 如果工作在会话结束后仍将继续，按照 implement 的 build-the-lever 原则，在差异中保留测量脚本。
• 绝不编造数值。测量失败时，应如实报告失败。
• 必须阅读且超过约 2,000 行的原始载荷，应交给子 Agent 处理。按照 research 的 guard-the-context-window 原则，在会话中只保留精简后的发现。