做技术内容的人都知道，同一套压测问题，在微信公众号、小红书、抖音三个平台，得长出三副完全不同的面孔——不是内容本身变了，是读者的认知水平和信息接收习惯完全不同。公众号读者会逐行分析EXPLAIN输出的执行计划，小红书用户只扫关键词，抖音观众则靠前3秒的动作钩子决定是否停留。所以，让Cursor生成提示词时，得按平台特性做匹配调整。

微信公众号版：面向运维工程师与后端负责人

先说公众号的场景。这部分读者是真正会看慢查询日志、会动手调参数的人。提示词写起来要够实、够细、能落地。

首先，在提示词开头锁定角色与场景：“你是一位有8年SRE经验的压测专家，正在为即将上线的订单履约服务撰写公众号技术复盘文章，目标读者是CTO和资深DBA。”——这样Cursor就能从一开始被锚定在专家视角，不会泛泛而谈。

然后，嵌入真实压测瓶颈点。空洞的“性能下降”没有价值，要具体：“实测发现QPS从1200突增至1800时，MySQL慢查询率从0.3%飙升至17%，EXPLAIN显示orders表主键扫描行数达24万，且thread_pool_idle_timeout被触发。”——这些数字和故障信号，DBA看到会立刻被带入场景。

最后，强制输出结构。指令要明确：“全文分三段：①现象（含P95延迟曲线截图描述+错误码分布热力图文字说明）；②根因（聚焦buffer_pool_size配置与innodb_log_file_size不匹配的连锁反应）；③验证（给出可直接粘贴执行的SHOW ENGINE INNODB STATUS解析命令）。”这里有个硬性要求：必须引用真实MySQL 8.0.33版本参数名，不可用“数据库配置”这种模糊替代。公众号读者会揪出这种细节的。

小红书版：面向刚转岗的测试开发与初级后端

小红书上的读者，技术基础和经验各有不同，更多是刚接触压测、在遇到问题时来小红书“找同款”的初级开发者。提示词的写法要换个路子。

第一个要点：用“姐妹”建立信任感，每句不超过18个字，信息密度要高、节奏要快。比如：“谁懂啊！压测时CPU突然飙到98%…不是代码问题！是这个参数没调！”——痛点一下就戳中了。

第二个要点：关键信息加粗+emoji锚定。示例：“⚠️ 【innodb_buffer_pool_size】 必须≥物理内存60% → 否则全表扫描根本刹不住车