首先明确一个关键观点：要让豆包生成的性能优化记录提示词真正贴合用户的原始表达，核心不在于堆砌技术术语，而是要还原真实的交流语境。

想象一下压测告警或线上故障时的钉钉、飞书群聊——大家着急的时候，说话往往带着情绪和上下文。抓住这三点：口语化、带情绪、缺上下文。

还原用户真实提问场景

打开最近三次线上性能告警的群聊记录，直接复制原始消息——千万不要润色。保留这些原句：“咋又慢了”、“这个接口超时是不是DB问题？”、“刚发版就崩，求看下GC日志”。这些口语化、不完整、带猜测的句子，才是高质量素材。

把每条原始消息单独存成一行，删除@人和表情符号，但务必保留“？”、“！”、“…”等语气符号——它们直接反映用户的焦虑程度，这一点很重要。

提取高频非技术关键词

这里有两种方法。简单直接的做法：用Excel对原始语句做词频统计，筛选出出现3次以上且并非标准术语的词。例如“卡”、“懵”、“秒开变10秒”、“点不动”、“老板问了”、“和昨天不一样”。

第二种方法更费心思——人工标记每句话背后的真实诉求。举例：“这接口怎么越来越慢” → 【不是查原因，而是求对比基线】；“缓存加了还是慢” → 【隐含已自助尝试但失败】。理清这些，写出的提示词才更有针对性。

关键词里还有一类必须保留：就是“老板”、“运营说”、“用户投诉”这类角色词。它们直接决定提示词是否需要加入业务影响描述维度，不容忽视。

构造带上下文的提示词模板

第一步，设定身份——例如“你是一名刚接手系统、没看过历史文档的值班工程师”。这个身份能确保豆包生成时有一个清晰视角。

第二步，把上一步提取的5条最典型原话，用「」符号包裹，逐条插入提示词。比如：「首页加载从1s变成8s」「搜索框点了3次才出结果」「老板在晨会问为啥下单变慢」。这样豆包接收到的不是干巴巴的需求，而是真实的对话现场。

第三步，不要忘记限制输出格式。你可以要求豆包生成的优化记录必须包含三个要素：① 用户原话复述（不许改动原文） ② 对应的可观测线索（如APM中TraceID的前缀、慢SQL的特征） ③ 下一步动作（必须明确到具体命令或链接，比如 curl -X POST http://xxx/debug/profile?trace=abc123）。

这个过程其实很直观：把整理好的原始语句和格式要求拼接成一段完整的话，直接交给豆包即可。