用 AI 写压测报告与容量结论
压测报告写得像流水账，通常是因为只记录了「压了什么、跑了多少」，没写「据此能部署几台」。一份能进评审的压测报告只有三个硬指标：环境与参数可复现、结论有证据、容量建议可执行且带不确定性说明。AI 适合做初稿生成与格式校验，但容量数字必须由你亲手核对。
报告骨架
一、结论摘要 ：三句话内说清安全容量、拐点位置、是否需要优化
二、环境 ：服务版本与启动参数、实例规格、中间件版本、压测机规格与拓扑
三、场景与参数 ：压测模型（定速/定并发）、档位、单档时长、预热时长、
连接复用方式、超时与重试配置、数据量与数据分布
四、结果数据 ：按档位的 QPS、P50/P90/P99、错误率、资源水位表
五、瓶颈定位 ：指标、日志、剖析三条证据链的结论
六、容量结论 ：单实例安全容量、满足峰值所需实例数、冗余比例
七、风险与建议 ：失效条件、未验证场景、优化项与预期收益
八、附录 ：原始输出文件、监控面板链接、采集命令与时间点
八节里最容易被省掉的是第二节和第八节，而这两节正是别人复现你结论的唯一入口。缺了启动参数与数据量，「单实例 1200 QPS」这句话没有意义。
结果数据表长这样
| 档位(目标 QPS) | 实测 QPS | P50 | P90 | P99 | 错误率 | 服务端 CPU | GC CPU | 压测机 CPU |
|---|---|---|---|---|---|---|---|---|
| 500 | 500 | 4ms | 8ms | 12ms | 0% | 22% | 1% | 18% |
| 1000 | 1000 | 5ms | 11ms | 15ms | 0% | 41% | 1% | 30% |
| 1500 | 1500 | 6ms | 14ms | 22ms | 0% | 58% | 1% | 42% |
| 2000 | 1998 | 7ms | 20ms | 38ms | 0% | 76% | 2% | 55% |
| 3000 | 2890 | 12ms | 90ms | 260ms | 1.2% | 88% | 8% | 55% |
压测机 CPU 一列不是装饰：它一旦接近饱和，后面所有结论都要作废。
让 AI 从原始数据生成初稿的提示词
你是性能测试负责人。下面是一次压测的原始数据与采集说明，请生成压测报告初稿。
【环境】Go 1.22，8 核 16G，GOMAXPROCS=8；MySQL 8.0 单机 8 核 32G；
Redis 6 单节点；压测机 4 核 8G 同机房；数据量：订单 800 万行，用户 50 万。
【参数】wrk2 定速，连接 64，超时 2s，无重试，预热 60s，每档 300s。
【数据】<粘贴上表>
【原始输出】<粘贴 wrk2 输出、错误码分布、pprof top 输出>
【要求】
1. 严格区分「观测事实」与「推断」两类表述，推断必须标注依据的数据行；
2. 结果表保留所有档位，异常档位单独说明；
3. 容量结论必须写成：单实例安全容量 X QPS（对应 P99 Y ms）、满足峰值 Z QPS 需 N 台、
按 30% 冗余取 M 台，并给出冗余计算过程；
4. 不确定性单列一节：列出本报告未覆盖的场景与会让结论失效的条件；
5. 不许出现我没提供的数字，缺数据的地方写「未采集」。
第 3、4 条是这个提示词的核心。多数 AI 初稿的问题不是格式，而是把「峰值吞吐 2890 QPS」直接写成了「容量 2890 QPS」，这跳过了「在哪个延迟约束下可接受」这一关键前提。
容量结论怎么算
容量结论的模板只有一句，但每个数字都要能追溯：
在 P99 ≤ 100ms 的约束下，单实例安全容量为 1200 QPS；
业务峰值为 6000 QPS，需 6000 / 1200 = 5 台；
按 30% 冗余取整为 7 台，可支撑 7 × 1200 × 70% ≈ 5880 QPS，
或在 7 台全量投入时支撑 8400 QPS，满足峰值并留出 30% 冗余。
| 步骤 | 本例取值 | 依据 |
|---|---|---|
| 确定延迟约束 | P99 ≤ 100ms | 由业务方给出的验收标准，不是压测里最漂亮的数字 |
| 找拐点 | 2000~3000 QPS 之间 | 3000 档 P99 260ms、错误率 1.2% |
| 折算出安全水位 | 1200 QPS | 拐点前档位下浮 40%，给抖动留空间 |
| 算实例数 | 5 台 | 峰值 6000 / 安全容量 1200 |
| 加冗余 | 7 台 | 5 × 1.3 向上取整 |
| 校验可用性 | 允许 2 台故障 | 7 台中损失 2 台仍有 6000 QPS 容量 |
注意最漂亮的那个数字（2890 QPS）通常不能当容量：它伴随 1.2% 错误率和 260ms 的 P99。安全容量必须落在拐点左侧，并且明确写出对应的延迟与错误率约束。
不确定性怎么写
| 不确定项 | 会怎样影响结论 | 报告里怎么写 |
|---|---|---|
| 数据量增长 | 索引与缓存效率下降，安全容量随之降低 | 说明当前数据量，给出数据量翻倍后需重压的条件 |
| 流量模型差异 | 生产读写比、参数分布与压测不同 | 列出压测的读写比与参数分布，注明未覆盖的接口 |
| 缓存命中率变化 | 命中率下降会成倍放大数据库压力 | 给出压测期间命中率，说明冷启动或失效时的风险 |
| 下游容量 | 本服务扩容可能把压力转移给下游 | 附下游在压测期间的自身水位 |
| 单机测试的局限 | 未验证多实例共享中间件时的竞争 | 明确本轮为单实例验证，多实例需补测 |
不确定性的写法有讲究：写「受多种因素影响，结论仅供参考」等于没写；写「若订单表数据量超过 2000 万行，需重新压测确认安全容量」才是可执行的条件。
报告评审前的自检
- 每个结论都能指到附录里的原始文件与采集时间。
- 环境与参数完整到别人可以照抄复现，包括启动参数、连接数与超时配置。
- 错误率非零的档位是否被当成容量依据，如果是，必须注明。
- 容量数字与延迟约束成对出现，没有孤立出现的 QPS。
- 优化建议分两栏：直接扩容能解决什么、改代码能解决什么，避免用扩容掩盖代码缺陷。
- 附录包含至少一份完整原始输出，而不是只有摘要表格。
- 让 AI 做一遍反向校验：把报告交给它，要求它列出「哪些结论缺乏数据支撑」，再把缺的数据补齐。
小结：报告用固定的八节骨架，环境与附录必须完整到可复现；让 AI 生成初稿时明确要求区分观测与推断、给出容量计算过程与不确定性；容量结论按「延迟约束 → 拐点 → 安全水位 → 实例数 → 冗余」五步算，最漂亮的峰值数字不能当容量，最后用自检清单和 AI 反查把缺数据的结论补上。