如何用 AI 优化提示词

提示词写得不稳，问题出在哪

同一个任务，提示词措辞稍有不同，输出就忽好忽坏：需求写得含糊，模型自由发挥太多；约束堆得太满，又变得脆弱、一改就崩。更麻烦的是缺少积累——每次都从头调，调好的版本没沉淀下来，下次遇到类似任务又得重来。对于代码生成、分析报告这类需要稳定结构和验收标准的任务，提示词不稳定，直接拖累产出的可靠性。

这个技能能帮你优化什么

它把"凭手感调提示词"变成"有方法、可积累的优化过程"。核心能力有四块：一是识别复杂、多步骤、技术输出、模板和精度关键型的提示词，判断哪些值得优化；二是调用优化流程，生成改写版本、改进说明和迭代建议，并控制迭代次数与收敛条件，避免过度优化反而变脆；三是在状态化模式下，基于历史向量检索、相似提示、反馈记录和成功率持续学习，让后续改写越用越准；四是结合 APE、OPRO、DSPy 等研究驱动的策略，把含糊需求改写成清晰、可测量、可复用的指令。优化结果会附上改进依据和迭代次数，让你看清"为什么这样改"。

怎么用它

用法是把你要优化的提示词和期望的稳定效果用自然语言交给它，它会改写并说明依据。例如可以这样对它说：

它适合这些场景：要把含糊需求改写成可复用的系统提示词或任务模板；代码生成、分析报告或结构化输出需要更稳定的约束和验收标准；长期项目希望记录提示词表现并基于成功案例持续改进；复杂代理流程要在不增加脆弱性的前提下提升指令清晰度。

大家常问

为什么同一个任务，提示词措辞稍微改一下，模型输出就忽好忽坏？

大模型每次调用都是无状态的独立计算，没有对上一次输出好坏的记忆，措辞稍变就走到不同的生成路径上，输出自然不稳。状态化提示词优化的做法是在调用之间建一条反馈回路：把历史输入、输出和评分累积起来，挑高分样本做滚动 Few-shot，再用反思-改写循环抑制随机波动，让"忽好忽坏"收敛成稳定输出。

什么是提示词的冷启动模式和状态化模式，它们的差别是什么？

冷启动模式是每次都从零构建提示词，不查、不留任何历史，效果完全取决于本次写得好不好。状态化模式则把每次提示词、响应和质量评分记录下来，建嵌入索引和成功率统计，新任务先检索相似的高分历史样本作参考。差别在于学习能力：冷启动每次原地重来，状态化越用越准，但需要存储和检索基础设施。

为什么提示词不能一次写好，需要多轮迭代和收敛判断？

因为你写提示词时脑子里的"理想输出"模型并不知道，模型对模糊指令的默认倾向也要等它真的产出文本才能看见。多轮迭代实际上是用实测数据反向修正你对模型的假设：上下文累积灌入你的标准，反思-改写分离诊断和修复，A/B 替换让数据决定哪种措辞活下来。收敛判断（连续几轮改进幅度低于阈值、评分达标、Token 预算耗尽等）则避免越改越脆的过度优化。

怎么判断一段提示词是『含糊型』还是『精度关键型』，对应的改写策略有什么不同？

把提示词套入「80% 正确是否仍然有用」这一问：写产品介绍、做主观分析这类回答"是"的属于含糊型；代码生成、信息抽取、SQL 查询这类回答"否"的属于精度关键型。含糊型改写重点在风格引导和方向一致——上下文用追加式累积偏好，Few-shot 选风格范例，预算可宽松；精度关键型重点在压缩误差——规则约束严格优先于历史，Few-shot 滚动覆盖易错边缘案例，强制开启链式思维做审计追踪。