Push further：先要 200 毫秒，然后继续
该技能基于目标设定研究：具体而困难的目标优于“尽力而为”。同样地，向模型只提“更快一点”往往只会得到几处安全的小改动，随后便礼貌收尾；而给出一个远超显而易见值的数字，并把它当作可达目标，智能体就会从打磨细节转向质疑设计。
来源引述：Felix Rieseberg——“你的网站需要从 10 秒降到 5 秒？那就要求 200 毫秒。”以及当模型停滞时：“重申它非常可解，只是需要继续推进。”
第一部分——开始时：设定目标
- 测量基线：找到或构建能测量目标的命令（基准测试、测试、查询、Lighthouse 运行、成本报告），运行并记录数字。没有测量就没有目标；先建立测量。
- 寻找下限：物理或理论极限是什么（网络往返、必须读取的数据量、已发表的最佳结果、最快竞争者的表现）。这能显示真实空间还有多少。
- 设定三个数字：
- 预期值：正常努力可达到的水平（通常提升 1.5–2 倍）。
- 硬目标：约为基线的数量级提升，或接近下限。这是努力方向。
- 护栏：不能变差的部分（正确性、其他指标、成本），并包含复杂度预算：代码可读性与可维护性允许变差多少。一个团队无人能安全修改的 300 倍优化，往往不如人人能看懂的 20 倍优化。
- 说明硬目标迫使什么：10 倍目标通常排除小修小补，指向不同设计（缓存、预计算、消除工作、更换算法、改变数据布局）。在动代码前写出 2–3 个此类方向。
- 硬目标是工作目标，不是对用户的承诺。要如实报告达到了多远。
第二部分——会话中：不要提前停止
当进展停滞或即将说“够好了”时，运行以下循环：
- 重新测量：当前值对比基线与硬目标。剩余时间/成本实际花在哪里？用性能分析，不要猜。
- 记录被排除的方案及证据，避免重复尝试。
- 选择潜在收益最大的假设，而非最安全的。优先消除工作而非加速工作，优先更好的算法或数据布局而非底层技巧（位操作、手动展开），前者收益通常更大且保持可读。
- 尝试、测量、保留或回退。
- 重复。把目标视为可解：停滞意味着当前方法用尽，而非问题无解。每轮循环都应改变实际内容；只重写计划的循环不算数。
仅在以下情况之一成立时停止，并说明是哪一种：
- 达成硬目标（护栏仍成立）；
- 接近下限并能展示测量结果；
- 剩余每个方向都需要只有用户能做的决定或权限（明确指出）；
- 达到用户的时间/预算限制；
- 下一收益会突破复杂度预算，且当前结果已消除用户问题（例如该步骤不再是瓶颈——去测量真正的瓶颈）。
若尝试过快但复杂的变体，除非额外速度明显重要，否则代码中保留更简单的版本，并向用户报告两个数字供其选择。
输出
维护运行日志 push-further.md（或直接打印），包含：
# Push further — <metric>
| | Value |
|---|---|
| Baseline | ... (command: `...`) |
| Floor | ... (why) |
| Expected | ... |
| Hard target | ... |
| Guardrails | ... |
## Directions the hard target forces
- ...
## Attempts
| # | Hypothesis | Result (measured) | Kept? |
|---|---|---|---|
## Ruled out (with evidence)
- ...
## Status
<current value, % of the way to hard target, stop reason if stopped, simpler/faster variants with their numbers, next best move>