写给自己的提示词，别漏掉关键“刹车片”

先看一个真实场景。假设你手上有一套部署在Azure AKS上的Ja va Spring Boot微服务，主库是PostgreSQL 14，前端通过Nginx Ingress暴露HTTP接口。最近发现/api/orders接口的P95响应时间从300ms飙升到2.4s，而且只发生在每天上午9:15到10:30这个时段。APM面板显示数据库等待时间占比超过78%，但JVM堆内存几乎没有波动。现在要让Copilot生成一份可以直接在生产环境跑的性能排查清单——听起来很简单？提示词写不好，它只会给你一堆空话。

问题就在这儿：提示词里漏掉了关键限制条件，导致Copilot输出一堆泛泛而谈的建议，根本没法落地。下面这几条，是让提示词从“理论”变成“实操”的核心技巧。

明确排查范围与上下文

第一步：在提示词开头直接声明应用类型和部署形态。别只写“一个Web应用”，要说清楚“这是一套部署在Azure AKS上的Ja va Spring Boot微服务，使用PostgreSQL 14作为主数据库，通过Nginx Ingress暴露HTTP接口”。不写明这些，Copilot会默认按通用Web应用处理，忽略容器化、服务网格、云存储延迟等真实瓶颈点。

第二步：指定性能问题的具体现象。光说“变慢了”没用，必须写清可观测线索。比如“/api/orders接口P95响应时间从300ms升至2.4s，且仅发生在每天上午9:15–10:30，APM显示DB等待时间占比超78%，JVM堆内存无明显增长”。这些细节决定了Copilot的检查方向是网络层、数据库锁还是连接池。

约束输出结构与粒度

方法一：用分号分隔三类硬性要求——“按‘检查项→触发条件→验证命令/路径→预期正常值’四列表格输出；所有检查项必须对应可立即执行的操作；禁用任何需要修改代码或重启服务的建议。”

方法二：强制限定技术栈边界——“只允许涉及Linux系统命令（如top、pidstat、ss）、Prometheus查询语句（如rate(http_request_duration_seconds_sum[5m])）、kubectl原生命令（如kubectl top pods）、PostgreSQL内置视图（如pg_stat_activity）；禁止出现jstack、arthas、VisualVM等需额外注入工具的操作。”

这样一来，Copilot知道它只能在你已经装好的工具里找答案，不会凭空推荐你装个Arthas或者跑jstack——生产环境哪敢随便动这些。

封堵常见幻觉漏洞

最后一步，也是最容易被忽略的：在提示词末尾加一句杀手锏——“若某检查项依赖未提及的监控组件（如缺少OpenTelemetry Collector或没有Grafana），则跳过该项并标注‘缺失前提’；不编造不存在的日志字段、指标名称或配置路径。”

操作起来很简单，直接把这句话粘贴到提示词最后一行就行。但漏掉它，Copilot大概率会虚构出“查看otel-collector/logs_latency_bucket”这类根本不存在的指标路径。到时候你拿着清单去查，发现路径不对、字段没有，又得反过来改提示词。与其事后补救，不如一开始就堵死幻觉的漏洞。