要精确识别代码中的性能瓶颈，不能仅凭“这段代码慢”这样模糊的描述。你需要引导 Copilot 明确搜索目标——清晰交代分析目的、运行环境与可观测指标，并附上可疑代码。接着按照“识别开销类型→定位瓶颈行→说明判断依据”的逻辑顺序进行排查。泛泛而问或关键信息缺失，只会换来一堆无法聚焦的通用优化建议。
要想让 Microsoft Copilot 快速锁定代码性能瓶颈，提示词必须指向可测量、可归因、可复现的运行时行为，不能只说“慢”或“卡”。你需要提供执行环境上下文、可观测指标线索，以及排除干扰的边界条件。
构造带上下文的结构化提示词
第一步，在提示词开头用一句话明确目标——必须写明“我要定位具体哪一行/哪个函数/哪类操作是性能瓶颈”。Copilot 不会主动推断你想要瓶颈位置，它默认只会给出泛泛的优化建议。
第二步，紧跟着给出三要素：执行环境（例如 .NET 6 + Windows Server 2024 + IIS）、观测现象（比如“API 响应 P95 从 120ms 突增至 850ms，GC 时间占比达 47%”）、代码片段（贴出包含 await、循环、LINQ 或序列化调用的可疑段落，不超过 20 行）。
第三步，用“请按以下顺序分析”强制约束推理路径：①识别高开销操作类型（同步阻塞？内存分配？锁竞争？序列化深度？）→②指出最可能拖慢执行的单行或调用链 →③说明判断依据（如“.ToList() 触发全量枚举+内存分配”或“HttpClient 未复用导致连接池耗尽”）。
避免无效提问的典型错误
第一种：不说版本和框架就问“怎么优化这段代码”——Copilot 只能基于通用规则猜测，无法结合 .NET 的 Span
第二种：只给日志片段“Error: timeout”却不提超时阈值、重试次数、上下游服务状态——Copilot 会把网络抖动、DNS 失败、线程饥饿全列一遍，难以聚焦。
第三种：贴出整个 Startup.cs 或 main.go——Copilot 对超过 30 行无注释的初始化代码无法准确建模调用时序，它可能把 ConfigureServices 里的一行 AddSingleton 误判为瓶颈。
实操中立刻见效的提示词模板
“我要定位具体哪一行代码是性能瓶颈。运行环境：Python 3.11 + FastAPI + Uvicorn（workers=4），观测到 POST /v1/process 接口平均延迟从 38ms 升至 420ms，火焰图显示 72% 时间在 json.loads() 调用栈内。以下是请求体解析部分代码：”
紧接着粘贴包含 json.loads() 的那 3～5 行代码。最后加一句：“请指出该段代码中导致反序列化变慢的直接原因，并说明如何用 cProfile 验证该行实际耗时。”