编程开发 编辑复核
性能瓶颈定位计划
从真实指标、请求链路和资源预算定位瓶颈，区分测量问题、代码问题和外部依赖。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名性能工程师。请根据真实测量结果设计最小成本的性能排查顺序，不要凭经验直接归咎于某个框架或库。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用户、设备、网络和时间窗口的指标基线
2. 加载、渲染、接口、数据库和第三方资源链路
3. 按影响和验证成本排序的瓶颈假设
4. 一次只改一个变量的实验与护栏指标
5. 目标、监测和回滚条件
输入变量：
- 性能现象（{{symptom}}）：说明慢在哪里、对谁慢和何时发生。
- 测量数据（{{metrics}}）：提供 RUM、Lighthouse、日志或 trace 数据。
- 技术栈（{{stack}}）：说明框架、CDN、数据库和第三方资源。
- 性能预算（{{budget}}）：提供目标和不能牺牲的指标。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先确认采样和分组，再决定优化优先级。
- 性能优化必须保留业务事件和可访问性护栏。
WHEN IT FITS
适用判断
适合这些情况
- 已经确认有性能问题，需要定位在哪一环。
- 你有可用的性能数据：耗时分布、火焰图或慢查询日志。
- 需要排出优先排查的顺序，避免盲目优化。
换个做法更好
- 你要定的是性能上限指标：用《Web 性能预算与瓶颈定位》。
- 还没测量就觉得慢：先测，猜测优化经常改错地方。
- 你没有任何数据：模型只能给通用建议。
FAILURE MODES
常见翻车与修正
- 模型直接建议加缓存或加索引。
这是没有数据时的默认答案。要求先基于你提供的数据指出耗时占比最大的环节，再谈方案。
- 优化建议的收益是编出来的百分比。
要求收益估算说明推算依据，或写成「优化后需实测」而不是给具体数字。
- 建议的优化会改变功能行为。
要求每条优化标注它是否改变了行为或数据一致性，改变的必须单独说明影响和验证方式。
ACCEPTANCE
怎么判断输出合格
- 定位基于你提供的实测数据，指出了耗时占比。
- 优化按投入产出排序，不是全部照做。
- 收益估算有依据，或明确标为待实测。
- 标出了哪些优化会改变行为，需要额外验证。
SAFETY BOUNDARY
使用边界
- 没有实测数据的优化方向是猜测，先做剖析再动手，凭直觉优化常常改在无关的地方。
- 性能剖析数据可能含请求参数和用户标识，分享前脱敏。