聊聊核心认知：在MarsCode里撰写性能分析提示词，前提是把技术栈、可观测工具和问题现象交代清楚，并且强制要求输出带验证动作的线性步骤，每一步都要有能直接运行的命令或代码片段，而且步骤之间必须环环相扣并形成数据依赖。否则，模型给出的诊断步骤根本无法落地，你照着操作多半是在做无用功。

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

第一步：编写提示词时，第一件事就是把当前项目的技术栈明确说明。例如“Spring Boot 3.2 + JDK 17 + Maven 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命令、Java代码行或者HTTP请求示例。”

方法二：把最小可执行单元固定下来，比如“每个步骤只能做一件事：要么执行一条Linux命令，要么修改一行application.yml，要么curl一个endpoint。”

方法三：要求步骤之间必须有数据依赖，比如“步骤2的输出必须作为步骤3的-c参数值”。这条约束是关键中的关键，没有它，MarsCode经常生成一堆并列式的建议，根本串不成闭环的排查路径。