MarsCode性能分析：提示词输出可执行步骤

在MarsCode中编写性能分析提示词时，核心在于清晰交代技术栈、可观测工具以及问题现象，同时强制要求输出带有验证动作的线性步骤。每个步骤必须包含可执行的命令或代码，且步骤之间需形成数据依赖关系。否则，模型生成的诊断步骤将无法落地，依此操作只会浪费时间。

明确指定运行环境和工具链

第一步：撰写提示词时，第一时间明确当前项目的技术栈。例如“Spring Boot 3.2 + JDK 17 + Ma ven 3.8.6”，这样可以避免模型基于默认的老旧工具链生成不兼容的命令。

第二步：必须注明已部署的可观测工具，例如“已部署Arthas 4.0.0，JFR未开启，Prometheus采集间隔15秒”。这一细节容易被忽略，一旦遗漏，MarsCode可能推荐安装大量额外插件，导致排查步骤尚未开始便卡在准备阶段。

第三步：用一句话精准描述问题现象，例如“/api/order/list接口的平均响应时间从200ms突增至1.8s，错误率未变化”。避免使用“接口变慢”这类模糊表述，否则提示词无效。

强制要求输出带验证动作的线性步骤

在提示词末尾添加指令：“仅输出编号步骤，每步必须附带具体命令或代码片段，且第n步的结果应能被第n+1步直接引用验证。”一个典型示例为：① 执行 arthas tunnel-server --port 7777 → ② 在目标JVM中运行 attach → ③ 输入 watch com.example.OrderController list '{params,returnObj}' -n 5。每一步的输出均为下一步的输入，环环相扣。

实际操作时，直接复制命令至终端即可。但若遗漏“-n 5”，Arthas将持续监听，进而阻塞后续所有步骤。

禁用抽象建议，限定输出粒度

方法一：添加否定约束，例如“避免出现‘检查配置’‘查看日志’等泛泛动词，每个步骤必须提供shell命令、Ja va代码行或HTTP请求示例。”

方法二：固定最小可执行单元，例如“每个步骤仅执行单一操作：要么运行一条Linux命令，要么修改一行application.yml，要么curl一个端点。”

方法三：要求步骤之间必须存在数据依赖，例如“步骤2的输出必须作为步骤3的-c参数值”。此约束至关重要，缺少它将导致MarsCode生成大量并列式建议，无法形成闭环排查路径。