撰写故障排查类提示词时，最令人困扰的情况就是模型仅回复“失败”二字——既不说明原因，也不指出日志位置，更提供不了可执行的命令。即便你输入了“服务启动失败”，对方也只是重复这个状态，根本无法推进排查流程。

问题的根源在于：提示词缺少对输出结构的明确限定。要解决这一问题，建议按照以下三个方向逐一优化。

确认提示词是否包含清晰的推理要求

打开MarsCode的提示词编辑框，检查当前提示词末尾是否包含类似“请分三步说明可能原因→定位方法→验证命令”这样的显式结构指令。如果没有，大模型默认会采用摘要式响应，而“失败”就是它最安全的兜底策略。

最简单的修正方法：在提示词末尾追加一句——【必须按“现象→常见原因→对应日志路径→可执行验证命令”四部分输出，缺一不可】。这样一来，模型就不会只回复两个字的结论了。

强制模型输出可操作的动作而非状态描述

第一个技巧：用角色和动词锁定输出类型。在提示词开头加上：“你是一名SRE工程师，正在远程协助同事处理故障。请输出3条可立即执行的终端命令，并注明每条命令预期返回什么才算正常。”角色+动词的组合能让模型进入“操作模式”，而非“描述模式”。

第二个方法：示例引导法。在提示词里嵌入一个微型样例，例如：“例如：现象=HTTP 502 → 原因=Nginx无法连接上游 → 日志=/var/log/nginx/error.log → 验证命令=curl -I http://localhost:8080”。模型会模仿这个格式自动续写后续的排查步骤。请注意：样例必须真实、简短，并包含具体路径和命令——虚构样例会导致模型生成不存在的日志路径。

剔除干扰性的模糊表述

第一步，删除提示词中所有“大概”“可能”“一般情况下”这类弱断言词汇。第二步，将“请分析一下问题”改为“请列出3个必须优先检查的系统组件，并为每个组件写出1条验证命令”。第三步，确保提示词中不含“请用通俗语言解释”——这句话会触发模型降级为口语化总结，从而停止输出命令和路径。

修改完成后重新提交，观察输出中是否出现了带路径的文件名和可直接粘贴执行的命令行。如果仍有问题，请再次检查第一条结构指令是否写到位。