提示词优化，是围绕具体任务，有步骤地改进 AI 指令。先定义什么样的结果可用，再用有代表性的输入测试当前版本，找出一个可以观察到的失败原因，最后只改最可能导致该问题的部分。这样得到的是经过样例验证的候选版本，并不意味着之后每次生成都一定正确。 这个定义也能区分真正的优化与简单的提示词改写。增加角色、形容词或更长的指令确实可能改变输出，但只有新版本通过任务验收条件，才说明改动有价值。对照测试通过后，规则清晰而简短的提示词通常也更容易维护。 官方文档同样把提示词工作视作迭代过程：明确任务、提供有用上下文，再根据评估结果调整。不同模型对指令和示例的反应可能有差异，所以比较版本时应记录测试条件。可以参考 OpenAI 的 编写有效提示词说明 、 提示词工程指南 与 模型准确度优化指南 。 提示词优化与提示词工程有什么区别？ 两者相关，但切入点不同。提示词工程更广，包含从任务需求出发设计指令；提示词优化则从已有提示词和可观察到的表现开始，针对一个具体问题验证改动。真实项目里，同一团队往往会先做工程设计，再持续优化。 提示词工程的原则可以帮助写出初稿，优化流程则继续修正它。区分这两个角度有助于排查问题：现在缺的是任务定义，还是需要针对现有指令做一项可验证的改动？IBM 的 提示词优化说明 也从迭代评估角度对比了这两个概念。 先写清模型需要做出的判断，以及什么样的答案可以交给下一步使用。“回答得更好”太笼统，容易让人根据语气或个人偏好不断加词。更可操作的目标是：“输出包含全部必填字段的有效 JSON；只引用给定规则；证据不足时标记人工复核。” 准备一组规模不大、但能代表真实任务的评估样例。至少包含一个常规输入、一个边界案例，以及一个信息缺失或互相矛盾的输入。对写作任务来说，常规样例可以是清晰的写作要求，边界案例可以是目标读者不明确，第三个则可以缺少回答问题所需的数据。少量精心挑选的输入比大量相似例子更有用，因为它们分别暴露不同的失败模式。 在使用总分之前，先用清单或通过 / 未通过规则确认关键条件。若使用另一个模型自动评分，也要检查它是否遵守和人工相同的判断标准；评分规则不贴合任务时，分数可能掩盖真实的回归问题。 可重复执行的提示词优化六步流程 描述要完成的工作。 写清输入是什么、模型要执行什么动作、结果会交给谁或哪个系统。把操作指令与引用、检索到的资料分开，避免把数据误当成新规则。 规定输出方式。 列出必需字段、格式、长度限制，以及无法满足要求时应该如何处理。结构定义或简短例子，往往比多加几句描述更容易让输出保持一致。 运行当前基线。 保存原始提示词和测试样例，记录现有版本在哪些条件下通过或失败。比较时保持模型、参数、工具和输入上下文一致，才能解释差异。 定位一个具体问题。 找出可观察到的失败，例如缺少字段、出现无来源的断言、标签错误或格式无效。若只缺一条关键规则，就不必推倒重写整份提示词。 只改一个可能原因。 针对问题，添加或调整最小范围内的指令、示例、约束或资料来源。一次改多个因素，就很难知道究竟是哪项改动带来了帮助或伤害。 重新测试并作决定。 重跑原有样例，并加入暴露问题的案例，然后接受、拒绝或继续修改候选版本。记录决定的原因，保留旧版本，以便出现回归时恢复。 这套流程把提示词优化方法变成可检查的工作：每次修改都有假设，旧版和新版面对相同输入，是否接受由任务标准决定，而不是只看哪段回答读起来更顺。 分类任务示例：把客服提示词变成可测试指令 假设团队最初只写了“给这条客服消息分类”。这个指令没有说明标签集合、如何处理多个问题、证据标准或输出格式。模型可能生成一句看似合理的描述，但工单系统无法稳定解析。 对于“我被重复扣费，现在又无法登录”，合理结果可以同时包含 billing 和 access ，分别提供简短证据，并把人工复核设为 false。对于“账单看起来有点奇怪”，提示词应允许模型表达不确定，而不是强迫它自信分类。这两个例子分别检查“多问题”规则和“不确定性”规则。 接受改写前，检查两个案例的 JSON 是否都能解析、标签是否来自许可集合、证据字段是否存在，以及模糊说法是否会触发复核。如果模型依旧编造细节，下一次调整应该加强证据边界，而不是加入无关的角色扮演描述。 提示词、上下文、模型还是工具：先判断该改哪一环 提示词只是 AI 工作流的一部分。答案失败时，先判断缺少的是指令、事实还是能力，再决定修改位置。多写几句话无法补上从未检索到的政策文件，也不能提供模型不可调用的工具，更无法让没有依据的猜测变可靠。 如果想先快速探索措辞，可以用 提示词优化器 生成候选版本，再拿自己的样例评估。改写只是候选；是否保留仍由针对任务的检查条件决定。

只优化一条好看的回答。 单个例子可能奖励脆弱规则。测试集要覆盖不同输入和已知失败方式。 一次同时改很多内容。 多项改动混在一起会失去因果线索。每轮做窄范围调整，并和基线对比。 认为细节越多越安全。 相互重复或冲突的指令会带来新歧义。删掉不会影响通过条件的内容。 评分标准过于模糊。 笼统的“质量分”可能掩盖格式、证据或不确定性处理失败。检查项应能客观观察。 忽略模型和上下文变化。 只有记录相关设置和输入资料，版本比较才有意义。条件变化后，应重新运行评估。 没有回滚方案就接受改写。 保存通过验收的版本及接受理由，日后出现退化时才容易定位和撤回。 这些是工作流程建议，不是对模型表现的保证。一套提示词应用于不同任务、模型或上下文时，可能需要新的测试。 小结：检查通过后再保留提示词改动 先定义什么样的结果可用，保存当前基线，再用相同的代表性输入比较每次有针对性的修改。若缺少的是知识或工具能力，就先补足资料或能力，而不是继续增加指令。记录模型、上下文、检查条件和接受理由，之后才方便解释差异或回滚。下一步可以阅读 提示词版本管理指南 ，让通过验收的版本可追溯。 提示词优化是围绕明确任务和可重复样例改进 AI 指令的过程。它包括澄清要求、补足必要上下文、测试改动，并且只有在新版本通过验收条件时才保留它。 先写清任务和输出格式，把指令与参考资料分开，为已知失败补充必要约束，再用正常输入和边界输入组成小型测试集。每轮只针对一个可能原因做改动，便于判断效果来自哪里。 用相同的代表性输入和模型设置分别运行旧版与新版，再按任务相关条件评分，例如必填字段、证据、格式有效性和缺少信息时的处理。只有关键检查通过且没有引入明显回归时，才接受新版。 提示词越长，AI 回答就越好吗？ 不一定。多余文字可能带来相互冲突的规则、增加模型要处理的上下文，或让简单任务更难理解。只有当一条信息会改变预期判断或输出时，才值得写进提示词。 什么时候应该改上下文，而不是改提示词？ 指令、判断规则或输出要求不清楚时，改提示词；模型缺少无法推断的事实时，补充上下文或检索资料；如果工具或模型能力不足，就处理能力缺口，而不是继续堆叠文字。 测试提示词需要准备多少个样例？ 没有适用于所有任务的固定数量。可以先准备常规输入、边界案例，以及信息缺失或冲突的输入；发现真实失败模式后再补充对应样例。小型样例集适合做初步检查，但不能证明提示词对所有未来输入都有效。 OpenAI：如何为 AI 模型编写有效提示词 — 面向使用者的提示词编写建议。 OpenAI：提示词工程指南 — 关于指令、示例和模型测试的官方说明。 OpenAI：Prompt Optimizer — 数据集、评分器、重复测试和人工复核建议。截至 2026 年 10 月 4 日，OpenAI 官方文档宣布弃用基于数据集的 Prompt Optimizer；Evals 将于 2026 年 10 月 31 日起对现有用户只读，并计划于 2026 年 11 月 30 日停用。依赖该功能前请核对链接中的最新状态。 OpenAI：优化语言模型准确度 — 以评估结果指导改进的技术方法。 AWS：什么是提示词？ — 提示词与提示工程定义及应用范围说明。