提示工程有哪些核心方法?

30 秒回答

1. 能系统分类提示工程方法（基础技巧、上下文学习、推理增强、Agent模式）
2. 准确说明CoT/ToT/ReAct的核心机制与区别
3. 能结合业务场景分析选型（简单任务vs复杂推理vs工具调用）
4. 指出提示工程的局限性（上下文长度、稳定性、可扩展性）

回答与解析

答案要点

• 能系统分类提示工程方法（基础技巧、上下文学习、推理增强、Agent模式）
• 准确说明CoT/ToT/ReAct的核心机制与区别
• 能结合业务场景分析选型（简单任务vs复杂推理vs工具调用）
• 指出提示工程的局限性（上下文长度、稳定性、可扩展性）

一、基础提示技巧

Zero-shot / Few-shot

• Zero-shot：直接描述任务，适合简单明确的需求（如格式转换、简单分类）
• Few-shot：给2-5个示例，显著提升小模型表现和输出格式稳定性
• 优缺点：零成本低，但复杂任务效果有限；示例设计耗精力，且占用上下文

角色设定与约束

• 通过"你是一位专家..."设定风格，用"必须/禁止"明确约束
• 适合对输出语气、格式有明确要求的场景（如客服话术、营销文案）

二、推理增强方法

Chain-of-Thought (CoT)

• 在提示中加入"Let's think step by step"或示例推理过程
• 场景：数学计算、逻辑推理、多步骤决策
• 局限：简单任务可能过度思考，增加延迟和成本

Tree-of-Thoughts (ToT)

• 让模型生成多个候选思路，评估后选择最优路径
• 场景：创意写作、策略规划、需要探索的复杂问题
• 代价：需要多次采样，推理成本显著增加

三、Agent与工具增强

ReAct (Reasoning + Acting)

• 交替进行思考→行动→观察，直到完成任务
• 场景：需要调用外部工具（搜索、计算、数据库）的动态任务
• 小红书场景：结合笔记搜索API做个性化推荐，实时获取用户画像数据

Function Calling / 结构化输出

• 定义工具schema，让模型生成可解析的调用参数
• 是Agent落地的工程基础，保证与后端系统的可靠对接

四、高阶优化方向

选型建议

• 简单任务（分类、摘要）：Zero-shot + 清晰指令
• 复杂推理（数据分析、决策）：CoT/ToT，权衡效果与成本
• 工具集成（搜索、推荐）：ReAct + Function Calling，注意异常处理链
• 规模化部署：考虑Prompt Tuning或转向SFT降低推理成本

提示工程的优势是快速迭代、零训练成本，但天花板明显——当提示长度超过1k tokens或需要数百条规则时，应考虑SFT或RLHF。

口语版讲法(约4分钟)

• 本质是问怎么跟大模型有效沟通
• 基础技巧：Zero-shot/Few-shot和角色设定
• 推理增强：CoT和ToT的适用边界
• Agent模式：ReAct和Function Calling落地
• 选型取舍与风险

这道题其实是在问，当你面对一个大模型时，怎么用提示词让它稳定、高效地完成你想要的输出。本质上，这是人和模型之间的沟通问题。我会从几个层次来讲：先是基础技巧，再是推理增强，然后是Agent模式，最后聊聊怎么选型和落地风险。

先说基础技巧。最简单的就是 Zero-shot，直接给指令，比如“把这段翻译成英文”。它适合特别明确、不需要额外示例的任务，比如格式转换、简单分类。但一旦任务复杂一点，效果就不稳定了。所以更常用的是 Few-shot，给两三个例子，模型就能模仿你的格式和思路，输出质量会明显提升，特别是小模型。不过代价是示例设计很耗精力，而且会占上下文长度。还有个常用的技巧是角色设定和约束，比如“你是一位资深客服，说话要礼貌但坚定”，或者“必须用JSON格式输出”。这对输出风格有要求的场景很管用，比如客服话术、营销文案。

接下来是推理增强。这里最核心的是 Chain-of-Thought，也就是让模型一步一步想。比如做数学题，你加一句“Let's think step by step”，它就能把中间步骤写出来，结果准确率大幅提升。但这里有个坑：简单任务上，CoT反而会过度思考，增加延迟和成本，说白了就是杀鸡用牛刀。所以我会区分场景，简单分类用Zero-shot，逻辑推理才上CoT。再进一步是 Tree-of-Thoughts，它让模型同时生成多个候选思路，然后评估选最优。适合创意写作、策略规划这类需要探索的问题。但代价很大，需要多次采样，推理成本高，所以我只在效果要求极高、预算又充裕的场景用。

然后是Agent模式。这块重点是 ReAct，也就是Reasoning + Acting。模型先思考要做什么，然后调用工具，观察结果，再继续思考，循环直到完成。比如在客服场景，用户问“我的订单怎么还没到”，模型可以思考“需要查物流状态”，然后调用查询API，拿到结果再回复。这里的关键是工具调用要可靠，所以 Function Calling 是工程基础，你要定义好工具schema，让模型生成可解析的参数。落地时有个常见失败场景：模型调用工具后，返回结果格式不对或者超时，链就断了。所以我会特别关注异常处理，比如加一个超时重试，或者让模型在失败时换一种方式思考。

最后聊选型。简单任务比如分类、摘要，用Zero-shot加清晰指令就够了。复杂推理比如数据分析、决策，用CoT或ToT，但要权衡效果和成本。如果涉及工具集成，比如搜索、推荐，那ReAct加Function Calling是标配。规模化部署时，如果提示长度经常超过1k tokens，或者规则特别多，我会考虑转向SFT或者 RLHF，因为提示工程的稳定性天花板很明显。

其实还有一个方向我最近在关注，就是 Self-Consistency 和多路径集成。CoT虽然好，但单次推理可能随机走偏，如果用多次采样再加投票，能显著提升可靠性，当然代价是推理成本翻倍。这块我觉得在金融、医疗等高容错场景很有价值，但怎么平衡成本和效果，还得看具体业务。

所以整体上，我更倾向把提示工程看成快速验证和轻量迭代的工具，它零训练成本，适合快速试错。但真要上线高并发、高稳定的系统，我会优先考虑SFT或者Agent框架，把提示词固化到模型里，减少运行时的不确定性。

关键一句:Self-Consistency 和多路径集成在CoT基础上进一步提升可靠性，但成本翻倍，适合高容错场景。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你正在做一个客服系统，用户问“我的订单到哪了”，你直接调接口返回物流信息，效果还行。但如果用户问“为什么比预计晚一天”，你打算怎么设计Prompt让模型先查物流、再结合规则推理延迟原因，而不是瞎编？

2. 问法 2 · 层层追问

   你觉得写好Prompt最关键的是哪几点？……那如果任务很复杂，比如让模型写一份市场分析报告，你会用什么技巧来提升推理质量？……这些技巧有副作用吗，比如成本或者稳定性问题？

3. 问法 3 · 直球架构

   请系统性地介绍一下提示工程的主要方法，包括基础技巧、推理增强、Agent模式等，每个方法的应用场景和优缺点，以及在实际项目中你怎么根据任务复杂度选型。