提示词优化方法论:从一次写对到可复用工作流

概述:为什么“写好一次提示词”不够

很多人第一次接触提示词优化时,目标是“把这句话改得更聪明一点”。这在个人使用里够用,但放到真实 AI 应用里很快会失效。

原因很简单:生产环境里的提示词不是一次性文案,而是一段可重复执行的任务说明。它要面对不同用户、不同上下文、不同边界条件,还要在成本、速度、稳定性和格式约束之间取平衡。

一个提示词今天在 3 个样例上表现很好,不代表它在 300 个真实请求上也稳定。常见问题包括:

• 用户输入稍微换个说法,输出格式就崩了
• 文档上下文变长以后,模型抓错重点
• 约束写得太多,模型开始机械执行,答案不自然
• 示例写得太少,模型不知道边界案例怎么处理
• 换模型后,原来有效的提示词突然变得不稳定
• 团队里没人知道为什么这一版 prompt 是这样写的

所以提示词优化的目标不是“写出一句神奇咒语”,而是建立一套可复用流程:

明确任务目标
  ↓
构造初版 prompt
  ↓
用测试集验证
  ↓
发现失败模式
  ↓
针对性修订
  ↓
再次评估
  ↓
沉淀模板和规则

优化和换更大模型的边界

换更大模型确实经常有效,尤其是任务需要复杂推理、长上下文理解、多语言能力或更强遵循能力时。但它不是提示词优化的替代品。

可以用一个简单判断:

如果失败来自任务没有说清楚,换大模型只是让它更有信心地猜。
如果失败来自模型能力上限,再怎么改措辞也只是局部缓解。

实战里建议先做三件事:

1. 用当前模型跑一组代表性测试样例
2. 标注失败原因是 prompt 问题、上下文问题、工具问题还是模型能力问题
3. 只对真正属于 prompt 的部分做措辞优化

这能避免把所有问题都塞进 prompt,最后得到一段又长又脆的说明书。

RCT 构词法:Role-Context-Task

RCT 是一个很实用的提示词构造框架:

Role: 让模型以什么身份和判断标准工作
Context: 当前任务有哪些背景、资料、约束和输入
Task: 具体要做什么,输出什么,做到什么标准

它适合用来写初版 prompt,也适合用来审查已有 prompt。只要输出不稳定,通常都能在 RCT 三个部分里找到缺口。

Role:不是角色扮演,而是判断标准

Role 的作用不是让模型“装成某个人”,而是让模型明确:

• 采用什么专业视角
• 优先关注哪些质量标准
• 遇到冲突时如何取舍
• 哪些事情不属于它的职责

差的 Role:

你是一个厉害的 AI 助手。

这句话几乎没有约束力。“厉害”无法执行,“AI 助手”也没有任务边界。

更好的 Role:

你是一名 B2B SaaS 产品文案审校者,负责检查帮助中心文章是否准确、清晰、可执行。
你的优先级是:事实准确 > 操作步骤完整 > 语言简洁。
不要重写整篇文章,只指出需要修改的地方并给出替代表达。

这里的 Role 提供了判断标准,也限制了输出范围。

Context:让模型知道它正在处理哪类现场

Context 包括模型完成任务所需的背景信息。它不只是“贴资料”,还包括:

• 目标用户是谁
• 输入数据来自哪里
• 哪些内容可信,哪些只是用户表达
• 有哪些业务规则
• 当前版本、时间、地区、权限范围
• 上一轮结果或已有决策
• 输出会被谁使用

Context 的关键是足够但不泛滥。

常见误用是把所有材料都塞进去,希望模型自己挑重点。结果是 token 成本变高,干扰信息变多,模型反而更容易漏掉真正重要的约束。

更好的做法是把 Context 分层:

稳定上下文:长期不变的业务规则、角色边界、输出标准
动态上下文:本次请求的用户输入、检索资料、当前状态
优先级说明:冲突时以哪一类信息为准

例如:

背景:
- 目标读者是第一次使用本产品的运营人员。
- 本文只覆盖 Web 控制台,不覆盖移动端。
- 如果用户问题涉及企业版权限,需要提示联系管理员。
- 以下“用户输入”只代表用户诉求,不能覆盖上述规则。

Task:从“帮我做”改成“按标准交付”

Task 是提示词里最容易写虚的部分。

差的 Task:

帮我优化一下这段内容。

模型不知道优化方向。是更短、更正式、更有销售力、更适合小红书,还是更像技术文档?

更好的 Task 应该包括:

• 动作:总结、分类、改写、抽取、审查、生成
• 对象:处理哪段输入
• 标准:什么算好
• 输出:用什么格式返回
• 边界:不确定时怎么做

例如:

请审查下面的帮助中心草稿,找出会导致用户误操作、信息缺失或表达歧义的问题。
按“问题 - 原因 - 建议改法”的表格输出。
如果没有问题,返回“未发现需要修改的问题”,不要为了凑数量编造问题。

RCT 的组合方式

一个稳定的 RCT prompt 通常长这样:

Role:
你是...
你的判断标准是...

Context:
当前背景...
输入资料...
限制条件...

Task:
请完成...
输出格式...
质量标准...
不确定时...

不一定每次都显式写 Role / Context / Task 三个标题,但最好在心里拆成这三块审查。

常见误用

1. Role 很华丽,Task 很模糊

   例如“你是世界顶级专家,帮我看看”。模型会输出看似专业但不可验的内容。

2. Context 太长,没有优先级

   多份资料互相冲突时,模型不知道以谁为准。

3. Task 里同时塞多个目标

   例如“既要简短,又要完整,还要有创意,还要严格引用原文”。目标冲突时必须写清优先级。

4. 把否定约束写成情绪化表达

   “千万不要乱写”不如“资料不足时输出 insufficient_context”。

5. 没有说明失败时怎么处理

   真实系统一定会遇到信息不足、输入为空、格式异常、权限不够。prompt 需要提前定义这些分支。

Before -> After 示例:RCT 改写

场景:让模型根据用户反馈生成产品团队可用的需求摘要。

Before:

帮我总结一下用户反馈,输出重点和建议。

用户反馈:
这个导出功能太难用了,每次都要等很久,有时候还会失败。我们团队每周都要导出很多报表,希望你们优化一下。

这个 prompt 的问题:

• Role 不明确:是客服视角、产品经理视角还是研发视角?
• Context 不足:输出给谁看?要不要区分事实和推测?
• Task 模糊:“重点和建议”没有格式和质量标准

After:

Role:
你是一名 B2B SaaS 产品经理,负责把用户反馈整理成研发和设计都能理解的需求摘要。
你的优先级是:准确还原用户问题 > 区分事实与推测 > 给出可验证的后续行动。

Context:
- 反馈来自企业客户的一线使用者。
- 用户原文可能包含情绪表达,不要直接扩写成确定事实。
- 如果缺少关键信息,需要列出待澄清问题。

Task:
请基于用户反馈输出一份需求摘要,包含:
1. 用户场景
2. 明确问题
3. 影响范围
4. 可能原因,标注为“推测”
5. 建议下一步验证动作
6. 需要向用户澄清的问题

输出要求:
- 使用 Markdown
- 不要编造用户没有提到的数据
- 每条建议都必须能被产品或研发执行

用户反馈:
这个导出功能太难用了,每次都要等很久,有时候还会失败。我们团队每周都要导出很多报表,希望你们优化一下。

优化后的 prompt 不只是“更长”,而是把判断标准、上下文边界和交付格式补齐了。

提示词常见技巧

提示词技巧不是越多越好。每个技巧都有适用场景,也有反例。真正的优化不是把所有技巧堆进去,而是根据失败模式选择最小改动。

结构化输出

结构化输出适合需要被程序读取、进入工作流或方便人工审查的任务。

常见格式:

• JSON
• Markdown 表格
• 固定字段列表
• YAML
• XML-like 标签

适用场景:

• 信息抽取
• 分类标注
• 审查报告
• API 参数生成
• 批量处理结果

怎么做:

1. 明确字段名
2. 写清字段类型
3. 说明缺失值怎么填
4. 给出合法枚举
5. 要求只输出目标结构,不要额外解释

Before:

从下面的客户消息里提取重点信息。

After:

请从客户消息中提取信息,只输出 JSON,不要输出解释。

字段:
- customer_intent: string,客户想完成的事情
- urgency: "low" | "medium" | "high"
- mentioned_product: string | null
- blocking_issue: string | null
- follow_up_questions: string[]

规则:
- 如果原文没有提到产品名,mentioned_product 填 null
- 不要根据常识补全客户没说的信息
- urgency 只能从枚举值中选择

客户消息:
我们今天下午要给老板演示报表,但是导出一直失败,能不能尽快帮忙看一下?

反例:

• 创意写作、开放式头脑风暴不一定适合过强结构化
• 字段太多会让模型为了填表而牺牲判断质量
• JSON 要进入生产系统时,最好配合 schema 校验,不要只靠 prompt

Few-shot 示例

Few-shot 是给模型几个输入输出样例,让它学习任务边界和风格。

适用场景:

• 分类标准难以用规则说清
• 输出风格需要稳定
• 业务边界依赖例子
• 需要模型模仿某种审查口径

怎么做:

1. 示例要覆盖常见案例和边界案例
2. 示例输出要严格符合你希望的格式
3. 不要给互相冲突的样例
4. 示例数量够用即可,不要把 prompt 塞爆

示例:

你需要判断用户反馈属于哪一类。

分类:
- bug: 功能异常或结果错误
- ux: 功能可用但体验差
- feature_request: 请求新增能力
- unclear: 信息不足,无法判断

示例 1:
输入: 点击保存后页面直接白屏。
输出: bug

示例 2:
输入: 希望导出报表时可以选择更多字段。
输出: feature_request

示例 3:
输入: 这个页面不太好用。
输出: unclear

现在判断:
输入: 每次导出都要等三分钟,虽然最后能成功,但太慢了。
输出:

反例:

• 如果任务非常简单,zero-shot 已经稳定,Few-shot 只会增加成本
• 如果示例质量差,模型会稳定复现错误
• 如果示例覆盖不了真实分布,模型可能对少数样例过拟合

约束与否定

约束用于定义边界,否定用于避免常见错误。但否定提示词要写得可执行。

差的写法:

不要废话,不要乱说,不要写错。

好的写法:

如果资料不足以回答,输出:
无法根据现有资料判断。

不要使用资料外的数字、日期或政策名称。
不要给出法律、财务或医疗结论,只总结资料中已经出现的信息。

适用场景:

• 高风险内容
• 资料引用
• 格式严格的任务
• 容易幻觉的开放问答

反例:

• 否定约束太多,模型会变得保守,甚至拒绝完成合理任务
• “不要做 X”不如给出替代动作:“遇到 X 时输出 Y”
• 约束之间冲突会降低遵循率,例如“必须完整回答”和“只能用一句话”

分步推理

分步推理不是让模型把所有思考过程都展示出来,而是把复杂任务拆成可检查的中间步骤。

适用场景:

• 多条件判断
• 审查与诊断
• 需要先分类再生成
• 容易漏步骤的任务

推荐写法:

请按以下步骤处理:
1. 先判断输入是否包含足够信息。
2. 如果信息不足,只输出需要澄清的问题。
3. 如果信息充足,再生成最终回复。
4. 最终回复必须控制在 150 字以内。

如果你不希望输出冗长推理,可以要求模型只输出检查结果:

先在内部完成判断,最终只输出:
- decision
- reason_summary
- next_action

反例:

• 简单改写任务不需要分步,否则输出会变啰嗦
• 对延迟敏感的场景,过多步骤会增加 token 和响应时间
• 不要把“展示长篇推理过程”当成质量保证,真正要看的是最终答案是否可验证

角色分工

角色分工适合把一个复杂任务拆成多个视角,例如“生成者”和“审查者”。

常见模式:

第一步:以产品经理视角整理需求
第二步:以研发负责人视角指出实现风险
第三步:合并成一份用户故事和验收标准

适用场景:

• 需要多维度审查
• 一次生成容易漏风险
• 输出要兼顾业务、技术和用户体验

反例:

• 不要让模型假装多个专家开会,最后输出一堆空泛观点
• 如果每个角色的判断标准没有写清,角色分工只是增加噪声
• 对严格事实任务,多角色讨论可能放大猜测

更稳的做法是把角色分工写成检查维度:

请分别从以下维度审查:
- 用户价值:是否解决明确用户问题
- 实现风险:是否依赖未知系统能力
- 数据风险:是否涉及敏感信息
- 交付边界:是否能在两周内形成 MVP

基于反馈的迭代优化

提示词优化最重要的能力不是“会写技巧”,而是会根据反馈定位失败原因。

推荐使用这个迭代流程:

V1 初稿
  ↓
用测试样例运行
  ↓
人工审查并打分
  ↓
归类失败模式
  ↓
让模型或人工提出澄清问题
  ↓
修订 V2
  ↓
对照 V1/V2 评估
  ↓
记录改动原因

步骤 1:写 V1,不要一开始追求完美

V1 的目标是跑通任务,不是写到无懈可击。建议先用 RCT 搭骨架:

Role:
你是一名内容运营负责人。

Context:
用户会提供一段活动文案草稿。

Task:
请优化文案,让它更清晰、更有行动号召。
输出优化后的版本。

这版明显还粗,但足够拿去测试。

步骤 2:审查打分

不要只凭感觉说“好像变好了”。给它一个简单 rubric:

每个维度 1-5 分,再写一句失败原因。

步骤 3:让反馈变成可改的失败模式

低质量反馈:

输出不好,不够专业。

可执行反馈:

失败模式:
1. 模型擅自添加“限时 3 天”,原文没有这个信息。
2. 行动号召太泛,没有说明用户下一步点击哪里。
3. 语气偏营销,不适合企业后台公告。

只有第二种反馈能指导 prompt 修改。

步骤 4:澄清问题

在修订 prompt 前,先问:

• 哪些事实不能被改?
• 目标用户是谁?
• 输出用于什么渠道?
• 是否允许补充未出现的信息?
• 语气应该偏正式、亲切还是销售化?
• 是否有长度限制?

很多 prompt 优化失败,不是因为措辞不好,而是因为这些问题没人回答。

小案例:优化“用户反馈总结”prompt

V1:

请总结下面的用户反馈,输出问题和建议。

测试输入:

我们每周一都要导出上周所有门店的数据,现在导出要等很久,有时候还失败。失败后也不知道哪里错了,只能重新点。希望你们赶紧优化。

V1 常见输出问题:

• 把“每周一”扩写成“每周一上午”,编造时间
• 建议太泛,例如“优化系统性能”
• 没有区分用户痛点和待澄清问题
• 没有输出产品团队能执行的下一步

修订 V2:

Role:
你是一名 B2B SaaS 产品经理,负责把用户反馈转成可进入需求池的结构化摘要。

Context:
- 用户反馈来自真实客户,只能基于原文总结。
- 不要补充原文没有出现的时间、数量、系统模块名。
- 如果需要更多信息才能判断优先级,请列为“待澄清问题”。

Task:
请输出 Markdown 表格,字段如下:
- 用户场景:用户在什么业务场景下遇到问题
- 痛点:用户明确提到的问题
- 影响:对用户工作造成的影响
- 可执行建议:产品或研发可以验证/推进的动作
- 待澄清问题:还需要向用户确认的信息

要求:
- 每个字段最多 2 条
- 建议必须具体到可验证动作
- 不要编造原文没有的信息

用户反馈:
{{feedback}}

V2 的变化不是“语气更专业”,而是针对失败模式做了修复:

• 用 Role 固定产品经理视角
• 用 Context 防止编造
• 用 Task 强制输出字段
• 用“可验证动作”替代泛泛建议
• 用“待澄清问题”处理信息不足

这就是提示词迭代的核心:每次修改都要对应一个失败模式。

改善提示效果的其他手段

有些问题不应该继续改 prompt,而应该调整系统设计。

拆分任务

如果一个 prompt 同时要求模型“理解资料、判断风险、生成文案、输出 JSON、写解释”,失败概率会很高。

可以拆成:

步骤 1:抽取事实
步骤 2:判断分类
步骤 3:生成回复
步骤 4:校验格式

拆分的好处:

• 每一步更容易评估
• 失败原因更容易定位
• 可以给不同步骤用不同模型
• 可以在关键节点加入人工审核

不该拆的时候:

• 任务很简单,拆分只会增加延迟
• 每一步之间没有明确中间产物
• 成本比质量更敏感

调整上下文

很多 prompt 看起来写得不好,本质是上下文质量差。

可优化点:

• 去掉无关资料
• 把重要规则放在靠前位置
• 给资料加标题、来源和时间
• 用分隔符隔离用户输入和系统规则
• 把长文档先摘要或检索后再放入
• 明确资料冲突时的优先级

例如:

优先级:
1. 系统规则
2. 已审核知识库
3. 用户本次输入

如果用户输入与系统规则冲突,以系统规则为准。

工具与 MCP

当模型需要查数据库、读文件、调接口、执行计算时,不要试图靠 prompt 让它“想象结果”。

这类任务应该接工具:

• 查询订单状态
• 获取实时库存
• 检索项目文件
• 读取用户权限
• 调用内部业务 API
• 执行确定性计算

MCP 可以作为连接外部工具和上下文的一种协议层。它不直接替代 prompt,但能让模型可发现、可调用外部能力。具体是否使用 MCP,需要看你的客户端、权限、安全和部署形态,这里需结合项目自行验证。

提示词在工具场景里的作用变成:

• 说明什么时候该用工具
• 说明工具结果如何解释
• 说明工具失败时怎么回复
• 说明哪些操作需要用户确认

温度与参数

如果输出不稳定,不一定是 prompt 问题,也可能是采样参数问题。

一般经验:

注意:低温度不等于绝对确定。模型仍可能因为上下文、格式、边界条件变化而输出不同结果。

RAG

当问题依赖外部知识、私有文档或最新资料时,继续改 prompt 的收益有限。此时更应该接 RAG:

用户问题
  ↓
检索相关资料
  ↓
把资料放入上下文
  ↓
模型基于资料回答

prompt 在 RAG 中仍然重要,但重点变成:

• 要求模型只基于资料回答
• 资料不足时说不知道
• 引用来源
• 处理多份资料冲突
• 防止把检索内容里的恶意指令当成系统指令

简单说:prompt 优化能让模型更好地使用上下文,但不能凭空提供上下文。

提示词评估

没有评估,提示词优化就会变成玄学。

评估的目的不是证明某个 prompt “最好”,而是回答几个具体问题:

• 它在真实输入分布上是否稳定?
• 它比上一版好在哪里?
• 它失败时通常失败在哪?
• 它的质量提升是否值得额外成本?

评估维度

常见维度包括:

不同任务权重不同。客服回复可能更看重准确性和语气;信息抽取更看重格式遵从和字段准确;Agent 工具调用更看重安全性和可执行性。

自建测试集

提示词测试集不需要一开始很大,但要有代表性。

建议至少包含:

• 正常案例
• 边界案例
• 信息不足案例
• 长输入案例
• 冲突信息案例
• 格式异常案例
• 恶意或越权输入案例
• 高价值真实案例

每条样例最好包含:

input: 用户输入或上下文
expected: 期望输出或关键判断
must_have: 必须出现的点
must_not_have: 禁止出现的点
notes: 人工审查说明

对于生成类任务,不一定要求唯一标准答案。可以用 rubric 评估。

对照实验

不要只看 V2 的结果,要和 V1 对照。

基本做法:

同一批测试样例
  ↓
分别运行 Prompt V1 和 Prompt V2
  ↓
按同一个 rubric 打分
  ↓
比较通过率、平均分、失败类型、成本

关键是控制变量:

• 同一个模型
• 同一组输入
• 同样的参数
• 同样的评估标准
• 同样的人工审查口径

如果同时换了模型、改了 prompt、调了温度、换了检索逻辑,你就很难知道质量提升来自哪里。

人工 rubric

人工 rubric 要写得像验收标准,不要写成主观感受。

差的 rubric:

回答是否专业。

更好的 rubric:

5 分:完整回答用户问题,没有编造事实,包含下一步行动,语气符合企业客服标准。
3 分:基本回答问题,但缺少部分行动建议或表达略含糊。
1 分:答非所问、编造事实、格式错误或可能误导用户。

如果多人评估,要先用少量样例校准口径。否则每个人对“专业”“清晰”“有帮助”的理解都不一样。

自动评估与工具

自动评估可以帮你提高效率,但不要完全替代人工判断。

常见自动评估方式:

• 字段是否存在
• JSON 是否可解析
• 枚举值是否合法
• 是否包含必须关键词
• 是否违反禁用词
• 与参考答案的语义相似度
• 用另一个模型按 rubric 打分

工具和框架可以选你团队已有的方案,例如 prompt 测试框架、LLM eval 平台、日志回放系统或自建脚本。代表性工具会持续变化,这里不展开产品清单。核心思路是:

评估系统要能稳定复现输入、输出、评分和版本差异。

记录版本

每次 prompt 修改都应该记录:

• 修改时间
• 修改人
• 修改原因
• 解决了哪个失败模式
• 影响了哪些测试样例
• 是否增加成本或延迟
• 回滚条件

这听起来像工程管理,但提示词一旦进入产品,它就是业务逻辑的一部分。

总结:提示词优化检查清单

优化提示词时,可以按这 9 条检查:

1. 是否明确了 Role,并给出可执行的判断标准?
2. Context 是否只包含完成任务必要的信息,且有优先级?
3. Task 是否写清动作、对象、标准、输出和失败处理?
4. 是否用结构化输出降低格式漂移?
5. 是否用 Few-shot 覆盖了关键边界案例?
6. 是否把复杂任务拆成可评估的中间步骤?
7. 是否为信息不足、冲突、越权和异常输入定义处理方式?
8. 是否用测试集和 rubric 对比了 V1/V2?
9. 是否记录了每次修改对应的失败模式和成本变化?

推荐实践顺序:

1. 先用 RCT 写出清晰的 V1
2. 准备 20 条左右真实或接近真实的测试样例
3. 用人工 rubric 找出主要失败模式
4. 只针对失败模式做最小修改
5. 加入结构化输出、Few-shot 或约束
6. 如果仍不稳定,考虑拆任务、调参数、接 RAG 或工具
7. 最后把 prompt、测试集、评分标准和版本记录一起沉淀

提示词优化真正成熟的标志,不是你能写出很长的 prompt,而是你能说清楚:

这一版为什么这样写,它解决了什么失败模式,在哪些测试上更好,代价是什么。

做到这一点,提示词就不再是玄学经验,而会变成可以协作、可以评估、可以持续改进的 AI 应用工程资产。

下次见。

-EOF-