performance-optimization

性能优化

通过反复测量、解释、修改和验证，每次处理一个瓶颈，从而改善与用户相关的结果。微基准测试变快，只能说明可能对用户有益；只有相关的端到端或实际场景指标证实这一点后，才能确认。

首次修改目标系统前，请根据用户请求或当前项目记录，确认目标、范围和回滚路径。只读探索无需确认。对于生产环境的遥测、标志、部署或清理操作，请遵循项目的授权和审查流程。

何时不使用

SLO 策略和事件恢复请使用 site-reliability-engineering；需求和支出预测请使用 capacity-and-cost-engineering；通用负载／压力／浸泡测试策略请使用 qa-methodology；产品行为 A/B 测试请使用 product-experimentation；特定功能故障请使用 systematic-debugging。如需操作指定的可观测性技术栈，请使用 telemetry 或 grafana。

循环

1. 选择一项用户旅程和预算。 找出用户、高频或高成本的用户旅程，以及他们实际体验到的一项主要结果：交互到渲染的延迟、任务完成时间、给定错误率下的吞吐量、内存、能耗或每次有效操作的成本。定义起始和结束事件、单位、工作负载组合、用户群体、平台，以及目标或实际可行的最低收益。同时纳入正确性、无障碍性、可靠性和资源方面的反向指标。不要孤立地优化一个方便衡量的指标。
2. 审查测量方式。 将现有的现场遥测、跟踪记录、性能分析、测试和报告对应到这项用户旅程。检查事件语义、缺失或采样事件、细分方式、版本／构建标签、时钟边界、隐私和测量开销。如果尚未测量该结果，就添加最少的检测手段或可复现的本地探测，以弥补这一缺口，并标明任何临时代理指标。记录基线，包括样本数量、时间段、百分位数或分布，以及已知的不确定性。选择信号或设计基准测试时，请阅读 measurement-and-benchmarks。
3. 定位瓶颈。 跟踪关键路径，并酌情区分客户端、网络、队列、服务、依赖项、存储和渲染所耗时间。对有代表性的慢路径进行性能分析；区分 CPU 工作、等待、分配、争用、I/O 和重复工作。在提出修复方案前，先用真实的数据和条件复现高成本路径。按受影响用户数 × 可实现的收益 × 置信度对机会排序，并明确呈现实现成本和回归成本。 如果症状已知，但不确定首先应查看哪项有效信号或性能分析，请阅读 diagnostic-guide。
4. 设计一项实验。 说明推测的作用机制、主要指标的预期变化、诊断指标和反向指标，以及最小且可逆的干预措施。在查看结果前，固定工作负载、构建版本、环境、预热和比较方法。对于噪声较大的测量，应重复运行或交错运行基线／候选版本，并报告分布；不要仅凭一次计时就认定有所改善。在将指令数或渲染提交次数等确定性代理指标用作门槛前，应在有代表性的收益、合理的回归和边界情况下，将其与用户相关的衡量指标进行校准。
5. 实施并验证。 先通过有意义的正确性检查确保行为不变，再进行有针对性的修改。在相同工作负载下比较基线和候选版本，并记录绝对差异和相对差异、运行次数、方差、硬件／构建版本，以及任何反向指标的变化。如果收益仅体现在代理指标上、基准测试不稳定、其他方面出现回归，或收益低于商定的实际门槛，则应拒绝该改动。有关决策规则，请阅读 experiment-and-rollout。
6. 评审、发布、观测。 提交差异、证据、风险、回滚触发条件和指定的人类负责人。对于用户可见或生产环境中的改动，应遵循项目的常规评审和发布门槛；技能本身不会授予部署权限。发布后，在足够长的时间窗口内，按构建版本、平台和相关用户细分群体比较现场结果。如果现场结果未达到目标或出现损害，应回滚／禁用并调查。如果表现符合预期，则保留稳定且有意义的回归检查或性能预算。CI 门槛的严格程度不得超过基准测试的可复现性所能支持的范围。
7. 重复或停止。 每次接受收益后，都重新分析这项用户旅程的性能；瓶颈可能会转移。当目标已达成、下一步预期收益低于实际价值、经过有限次数的测量后仍无法从噪声中分辨收益，或下一步需要负责人决策时，就停止。记录剩余机会和不确定性，不要把尚未运行的实验说成已实现的改进。

工作记录

对于多步骤工作，请使用 templates/optimization-record.md。每段用户旅程或每个瓶颈保留一份记录，并附上原始证据和提交的链接。将观测到的、推断出的和拟议的结果分开记录。本地基准测试、CI 通过、预发布环境结果和线上用户体验提升属于不同的证据状态。

如需查看可运行示例，了解如何分析瓶颈、检查行为、比较多次完整命令运行的耗时，并将现场验证标记为待处理，请阅读 worked-investigation。

范围路由

• 客户端渲染和 Web Vitals： frontend-engineering。后端查询和服务代码： backend-engineering。
• 需求、饱和度和成本： capacity-and-cost-engineering。Agent 质量与延迟权衡： agent-evals-and-observability。
• 遥测基础设施： telemetry。发布门禁和分阶段推出： release-engineering。

来源依据

从用户旅程 → 基准测试 → 审查后的更改 → 推出 → 现场评估 → 阈值调整的闭环，源自 Anthropic 关于 claude.ai 性能的介绍。参考资料说明了何时使用现场数据而非实验室数据，以及如何处理方差。Anthropic 报告的提升属于案例研究，不能直接作为可迁移的性能目标。