必须明确角色、场景、工具链与权限约束：如“三年经验Java后端，用Arthas+Prometheus+Grafana查Spring Boot慢接口，MySQL 8.0，K8s部署，禁调JVM/扩容，只查SQL执行计划、MyBatis日志、连接池配置，并依据TP99与错误率变化判断线程池问题，忽略ZGC相关分析”。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让通义千问生成的性能分析提示词真正帮到一线运维工程师或后端开发人员，而不是泛泛而谈的理论描述，就必须在提示词里明确嵌入目标人群的真实工作场景、技术栈边界和决策权限。
先锁定具体角色与典型任务
打开一个空白文本框，写下你要服务的具体角色，例如“三年经验的Java后端开发，日常负责Spring Boot微服务线上慢接口排查”，不能写“技术人员”或“开发者”。【角色越模糊，生成的提示词越容易堆砌术语却无法落地】
接着补上该角色最近一次遇到的典型问题：比如“用户投诉订单查询响应超时，APM显示SQL执行耗时占90%，但EXPLAIN结果无明显索引缺失”。
把技术约束直接塞进提示词结构
方法一：用“你正在使用……”句式锚定工具链
在提示词开头加一句：“你正在使用Arthas + Prometheus + Grafana排查问题，数据库是MySQL 8.0，应用部署在K8s集群中。”
方法二：用“禁止……”排除干扰路径
插入限制条件：“禁止建议修改JVM参数或扩容机器，当前无审批权限；只允许从SQL执行计划、MyBatis日志、连接池配置三个维度切入。”
这一步很关键——没有约束的提示词会导向教科书式回答，而真实现场永远有权限、工具、时间三重枷锁。
植入角色特有的判断逻辑
第一步：回忆该角色日常做决策时依赖哪类信号
比如SRE看告警收敛率、DBA盯慢查日志行数、前端工程师关注FCP/LCP数值突变。
第二步：把信号类型写成提示词中的判断依据
例如：“若TP99延迟上升但错误率未变，优先检查线程池活跃线程数与队列堆积量；若两者同步飙升，则跳过GC分析，直接抓取arthas thread -n 5输出。”
第三步：加入一句反常识提醒
“注意：不要一上来就查Full GC，该服务启用了ZGC且GC pause始终低于2ms——这是已知事实，忽略它会浪费15分钟。”
