定位并修复性能瓶颈时：先用仓库工具实测基线…

当需要在代码库中找出性能瓶颈并优化时，靠实测基线而非猜测来定位热点、给出最小改动并复测。

适用场景

解决思路

1. 默认只输出报告，除非用户明确要求实现；不要编造 SLO 或影响百分比。
2. 先阅读测试文档，若其中已定义性能预算（budget）就以其为准。
3. 用仓库自带的 profiler、trace、测试，或 `gh` 的 job 计时采集基线数据，不要用估算值。
4. 用这些证据定位真正归属的热点路径（query、render、allocation）。
5. 只推荐最小的改动；仅在获得授权时才真正实现。
6. 改动之后重新测量，确认效果。
7. 如果确实需要新的预算指标，把它写进现有的测试文档，而不是在这里自行发明一个 SLO。
8. 若行为或命令发生变化，用 `/w-docs` 更新文档。

适用边界 · 注意事项

• 仓库内没有可运行的 profiler、trace、测试或 CI 计时，拿不到实测基线时——应先补齐测量手段，而不是凭感觉下结论。
• 用户未授权修改代码时，只能停留在报告与建议，不要直接改。
• 需要从零设计整套 SLO/性能目标体系时，本技能只负责把新预算写进既有测试文档，不负责拍定目标值。