性能压测问题的深度分析，最让人头疼的是什么？最怕AI直接丢过来一句“加缓存”“扩线程”——空泛、无用、无法落地执行。真正需要的是它能像资深诊断专家一样，首先给出逻辑清晰的结构化病根定位。如何让Codeium做到这一点？接下来为你详细拆解。

强制AI输出三层诊断结构

在Codeium编辑器中，将光标移动至压测报告文本的末尾，按下 Ctrl+I 调出指令框，随后粘贴下方这段提示词：

「请严格按照以下三步输出结构化诊断框架，不写原因、不给解决方案、不跳过任何层级：①【指标异常层】列出3个当前压测场景中实际超出阈值的核心指标（必须包含单位、采样周期、实测值与阈值的比值），仅限JMeter/Arthas/Grafana原生采集项；②【链路瓶颈层】从①中任选1个超标指标，反向追溯至最上游的服务调用节点，标注该调用节点的平均耗时、错误率、P99延迟（若无数据则填写“未采集”）；③【资源争用层】针对②中定位到的服务实例，逐一检查CPU、内存、文件句柄、数据库连接池这4类资源的占用率及其与上限的比率。禁止合并任何层级，禁止使用“可能”“大概”“一般”等模糊表述。」

关键要点就在这里：用「①→②→③」的递进结构强行锁定AI的推理路径。如果只是简单写“请分层分析”，AI很容易把三个层级混杂在一段文字中，比如“TPS下降可能因为DB慢，也可能因为GC频繁”——一旦失去结构化的约束力，输出就等于无效。

用真实监控截图锚定每一层

方法一：在提示词后面另起一行，直接粘贴Grafana面板截图中的关键文字信息（注意是文字内容，不是图片）：

// Grafana-TPS面板: 2026-07-02T11:23:00Z起TPS从1800骤降至220，持续5分钟，阈值=1500
// Arthas-trace结果: com.example.order.OrderService.createOrder() a vg-cost=428ms, p99=1840ms, error% = 0.3%
// top -H 输出: PID 12345 的线程数=217，ulimit -u=1024

千万不要贴图。AI对纯文本锚点的识别准确率比截图高出3倍以上。如果你只写一句“TPS下跌了”，AI会认为你指代模糊，直接跳过指标层进入推测模式。你需要提供的是精确的数值和时间戳。

方法二：在原始压测报告的末尾手动添加一行业务约束信息：

// 当前集群规格: 4核8G × 3节点，JVM堆内存=-Xmx4g，数据库连接池最大=50

这一行数据会强制AI在资源层计算时，把你给出的数字作为分母基准。如果没有这行信息，AI可能按照通用配置（比如16核32G）计算出“CPU仅用40%”，而实际上你的CPU早已跑满。

验证结构是否真正可用

拿到输出结果后，不要直接采信。请按照以下三步进行验证：

第一步：检查【指标异常层】中的每一条是否都包含“单位+采样周期+比值”三要素。例如“TPS=220/1500（5秒窗口）”是合格的，“TPS偏低”则不合格，直接退回让AI重新生成。

第二步：从【链路瓶颈层】中任意挑选一条，手动打开对应服务的Arthas trace日志，确认AI标注的调用点（比如OrderService.createOrder）是否真实出现在trace的首行。如果不在首行，说明AI没有做到真正的反向追踪，整个结构失效。

第三步：打开【资源争用层】中提到的服务实例的Prometheus查询页面，输入对应指标（如process_open_fds / process_limit_fds），核验实测值是否与AI给出的“占用率”一致。如果不一致，直接删除整层内容，重新提交提示词。不要心存侥幸，这一步直接决定了诊断结论能否真正落地执行。